【宝贝团】EDAS应用迁移服务网格云应用经验分享

更新时间：2023/06/25 访问次数：7061

一、背景介绍
二、服务网格云应用迁移调研
三、云应用服务网格迁移思路
四、实战迁移
五、总结

一、背景介绍

宝贝团应用原有微服务架构为SpringCloud，注册中心已经集成在了EDAS的生产环境，我们不用关心生产环境的注册中心，需要关心的是本地环境和daily环境的注册中心搭建，按照EDAS的接入说明，我们dev与daily环境选择的是以NACOS作为注册中心的方案，选择NACOS的好处是它与EDAS生产环境中的注册中心可以无缝衔接，互不干扰，免去了一堆环境隔离要做的事情。

二、服务网格云应用迁移调研

调研结论：支持SpringCloud作为微服务架构，但是现阶段暂时不支持NACOS作为注册中心的无缝接入，小二答复后期会支持，本地注册中心推荐的是eureka。

三、云应用服务网格迁移思路

生产环境按照小二发过来的文档，引入sofa相关的sdk后就差不多完成迁移了，但是为了兼容现有的dev与daily环境，本打算迁移nacos注册中心为eureka，经团队调研与评估，首先认为eureka真的没有nacos好用（也许是大家用习惯了），其次迁移注册中心影响面与工作量还是挺大，所以我们还是选择了继续沿用NACOS作为本地注册中心的方案。

为了能平稳切割环境，我们计划按流量缓慢切入的方式作为迁移方案，也就是灰度发布中让一小部分生产环境中的真实用户进入到新的云应用环境中试用，试跑几天后逐步切入更多的生产环境流量，直至最终完成新老两套生产环境的切割。

四、实战迁移

环境说明：因为确定了不动dev、daily环境的前提下只做生产环境的迁移，所以我们现在总共需要管理的环境有三套，分别是老的EDAS生产环境，新的云应用服务网格环境和我们的本地dev与daily联调测试环境（这里dev和daily只算一套环境，因为共用nacos注册中心）。

1. 环境准备

迁移文档中涉及sofa sdk的依赖引用，所以改代码是必不可少的，我们将所有EDAS应用新拉了service-mesh分支（迁移过程中生产环境的正常迭代发布会正常合并到service-mesh分支）。然后按照官方文档，按步骤接入sofa sdk，并且在聚石塔控制台上也创建好对应的应用，将service-mesh分支部署到云应用中，这里详细步骤不多讲，官方文档都非常细致。这里需要补充的是，因为涉及NACOS环境的兼容，在环境配置中的jvm参数需要配置一个排除掉nacos服务发现配置项：-Dspring.cloud.nacos.discovery.enabled=false。为什么不在工程中的配置文件添加的原因是本地dev与daily环境需要使用nacos的服务发现，与之相对应的，dev与daily环境的配置文件需要排除掉sofa的服务发现，所以对于dev与daily的profile需要加上sofa的排除配置项：sofa.mesh.discovery.enabled=false。

2. 切入流量

在全新的云应用服务网格应用搭建好后，内部做好充分测试后，开始考虑进行灰度测试并引入生产流量了。因为云应用暂时不能像EDAS那样做分组发布（同一个应用部署不同版本的源码），经过实践，只能通过新建云应用的方式实现。

为了能合并管理EDAS环境与云应用环境中的实例（方便流量比例分配），我们在SLB中新配置一套公网SLB，然后在后端服务器配置的地方融合了EDAS应用实例与云应用实例（见例图一）。

3. 完成环境切割并下线EDAS应用

经过几周的灰度发布测试，期间我们把流量分配的比例从10%、20%、50%、75%、100%逐步提高后，EDAS环境最终完成历史使命，安然下线（鼓掌）。

五、总结

服务网格底层用到了K8S集群，因为宝贝团也是首次用K8S集群，感受是：这个太舒服了，扩容改改实例数字即可完成扩容，再也不用新购买ECS，然后一台一台的加入到EDAS集群中完成扩容了；另外如果实例挂了，还能自动完成实例重启...等等一些K8S集群的特性，大家有时间慢慢深挖。

最后与EDAS的对比，大的东西两边都有，服务治理、服务监控、调用栈查询、数据库监控、MQ监控，虽然存在一些小的不足，比如应用没有方便的重启操作，没有分组发布，发布只能上传jar包等等，这些都是小问题，不影响大局。毕竟聚石塔新上线的服务网格云应用跟已经商业化几年的阿里云EDAS对比没有什么对比性，最后提醒大家唯一需要适应的点那就是K8S集群虚化效率较低，毕竟需要安装的组件肯定比EDAS要多很多，因为更智能了，按照官方的推荐，虚化效率比较高的宿主ECS是8C16G机器，宝贝团选择的是16C32G的机器。

PS：迁移过程中确实碰到过一些“小坑”，如果原有架构用到了xxl-job的同学，请注意因为sofa和xxl-job都依赖了hessian做序列化，但是发现版本冲突，导致xxl-job序列化出问题了，后面的解决方案是：exclude掉xxl-job服务端与客户端依赖的hessian包，引入sofa中的hessian包（com.alipay.sofa:hessian:3.3.0）

另外还有一点需要提醒大家的是，如果创建了多个集群，新建应用后务必去运维中心-资源分配策略中新建策略（见例图二），因为新建应用中是没有选择对应集群的选项的，宝贝团就出现过新应用部署到了错误集群中的情况，这一点期望后期聚石塔迭代中能把交互改得更人性化一点。