星火文集从SpringCloud到Ser
云原生技术范式颠覆
——从SpringCloud到
ServiceMesh框架重构之路
神州信息
徐超
02.ServiceMesh迁移方案
对于还未涉足ServiceMesh的企业或产品，其传统微服务架构如若已采用SpringCloud框架构建，此时向ServiceMesh框架迁移又该如何做？需要综合考虑哪些因素？是否有依可据？
接下来，就构建基于SpringCloud向ServiceMesh框架迁移提供一些建议方案和思路，供大家参考。
2.1
迁移场景
传统微服务框架，以最为典型的SpringCloud框架为例进行迁移说明。首先，先看一下这样的一个迁移场景，目前的微服务架构如下图左边部分：
●应用是部署在虚拟机或物理机上。（服务还未容器化）。
●框架是基于SpringCloud框架开发。（服务中包含的业务逻辑和SpringCloud组件相依赖，业务和框架高度耦合）
●开发语言以Java为主。（存在跨语言的问题）
●注册中心采用的是Consul或Eureka。（服务需引入注册中心依赖包，存在一定的耦合）
目前开源Istio已经成为ServiceMesh事实上的标准，更是新一代微服务架构发展的趋势，因此公司希望尝试迁移到Istio框架，希望最终形成类似上图的右边部分。
2.2
迁移路径
面对上述迁移场景，确定要引入ServiceMesh前，需要彻底搞清楚ServiceMesh迁移的具体路径。
首先，要对自己项目做以下评估：
●是否真的有必要引入迁移到ServiceMesh上？
●当前微服务架构下，是否面临传统微服务架构面临的挑战？
●当前微服务架构，是否已经阻碍或影响未来业务的发展？
●公司或技术团队，是否有能力、人力、精力来投入到ServiceMesh的迁移？
其次，完成ServiceMesh微服务平台的搭建。当前所处阶段是否已经支持容器化和Kubernetes。如果当前业务已经运行在Kubernetes之上，则ServiceMesh的迁移将会比较顺畅；如果当前业务没有运行在Kubernetes上，因ServiceMesh当前典型的Istio框架对Kubernetes有着过度依赖，所以可能就无法直接从SpringCloud迁移到Istio框架，即使定制修改Istio以接触对Kubernetes的依赖，将会付出很大的代价。这时通常有两条迁移路径可供选择。
●路径一：非Kubernetes环境下，先接入Sidecar
如果当前业务没法快速容器化，同时又有引入ServiceMesh的迫切需求，可采取先接入Sidecar，来满足当前业务的痛点需求。在引入Sidecar时，要注意其未来的演进方向，考虑后续可能继续向ServiceMesh迁移，一旦时机成熟并引入Kubernetes容器化后，则能够顺利由Sidecar的方式直接演进到ServiceMesh。
ServiceMesh当前典型的Istio框架在非Kubernetes下没有很好的支持（据说未来会完全脱离对Kubernetes的依赖），对Istio进行定制化修改以支持非Kubernetes环境将会付出很大的代价，非特别强烈的需求和强大的技术储备，一般不建议这么做，特别是对于一些中小公司而言。
如果一定要在非Kubernetes环境下引入ServiceMesh，数据平面可使用Envoy，控制平面可根据XDS协议进行自研。
●路径二：先进行Kubernetes容器化改造，再接入ServiceMesh
倘若公司有云平台或容器化团队，可采用公司资源共享的方式，先借助其他团队来完成Kubernetes容器化改造，再接入ServiceMesh。
最后，基于构建的ServiceMesh框架，将业务应用逐步迁移到ServiceMesh。
2.3
迁移原则
在实施迁移时，必须要时刻遵守以下迁移原则。
●渐进式迁移：为避免ServiceMesh迁移过程中的风险，必须采用渐进式迁移原则，每次只迁移少量服务，待迁移后观察足够长的时间，没有问题后再继续迁移。
●业务透明：为减少ServiceMesh迁移对业务的影响，减少业务的迁移阻力，迁移初期必须确保业务完全透明且不需要过多的变更和修改。
●兼容性：在迁移阶段，必然会存在两种模式（SpringCloud和ServiceMesh框架）并存，在迁移过程中需要充分考虑两者的兼容性，使得迁移前后网络打通，至少能够满足未迁移和已迁移部分能够通信。
2.4
迁移方案
从SpringCloud向ServiceMesh框架迁移，大体上分为四个步骤：SpringCloud架构分析、容器化改造、ServiceMesh微服务平台搭建和应用迁移。
2.4.1SpringCloud架构分析
SpringCloud架构分析的目的在于重新了解当前微服务架构下的所有功能，便于在向ServiceMesh迁移时做准备，考虑哪些功能需要迁移，哪些不需要迁移，哪些需要改造等。如下图所示是基于SpringCloud完整构建的微服务架构解决方案。
从上图经过分析，可以汇总得知它主要由以下几部分组成：
●代理网关：提供统一对外或对内的访问入口，包括路由、鉴权、限流、熔断、降级等统一处理。
●注册中心：提供服务的注册与发现功能。
●应用服务：覆盖整个业务服务，包括业务逻辑实现、框架SDK及外部组件依赖交互等。
●中间件数据存储：为应用服务提供额外的支持能力。
●CICD：持续集成、持续部署。
上述这几部分中哪些内容是我们可以去掉或者是基于ServiceMesh（以Istio为例）能够去做的？经过分析得知，可以替换的组件包括网关（Gateway或者Zuul，由Ingressgateway或者egress替换），熔断器（hystrix，由Sidecar替换），注册中心（Eureka及Eurekaclient，由Polit，Sidecar替换），负载均衡（Ribbon，由Sidecar替换）等。
此阶段，我们能够大致知道SpringCloud中的哪些内容可以由Istio处理，哪些内容可以继续沿用。
2.4.2容器化改造
容器化改造，主要针对目前还未引入Kubernetes容器化的场景。在容器化改造之前，有必要知道改造的优势及要求。
容器化改造优势：
●更省：极大的资源利用效率，最大限度榨取和共享物理资源，多项目更能体现出容器化的优势，节约部署IT成本。
●更快：秒级启动，实现业务系统更快的开发迭代和交付部署。
●弹性：根据业务负载进行弹性容器伸缩，弹性扩展。
●方便：容器化业务部署支持蓝绿/灰度/金丝雀等发布，回滚，更加灵活方便。
●灵活：监控底层node节点健康状态，灵活调度至最优节点部署。
●强一致性：容器将环境和代码打包在镜像内，保证了测试与生产环境的强一致性。
容器化改造要求：
●掌握Docker技术：开发人员需熟悉Docker容器化技术，熟练编写Dockerfile文件。
●掌握Kubernetes编排系统：熟悉Kubernetes容器化编排系统，熟悉各组件资源清单编写、高可用、RBAC安全策略等。
容器化改造，主要分为以下两个阶段：
●容器化构建：将基于SpringCloud搭建的所有服务实现容器化构建，实现Docker镜像打包。
●容器化管理：基于Kubernetes或容器云平台进行服务容器的管理。
2.4.3ServiceMesh微服务平台搭建
ServiceMesh框架选取业界典型的Istio框架。
2.4.3.1Istio基础框架搭建
基于Istio框架搭建Istio基础框架，在控制平面和数据平台分别提供以下能力：
●控制平面：提供服务格控制指令下发、服务配置、权限控制等功能。
●数据平台：提供服务治理、服务监控及运维、流量管控等功能。
上述SpringCloud的功能在Istio框架上都能找到对应的功能，并通过适当的资源清单配置即可完成。
Istio架构图如下：
至此，一个Istio基础框架搭建完成，能够提供ServiceMesh的所有能力。
2.4.3.2Istio扩展和定制
在迁移路径中已经提及过，对于非Kubernetes环境，建议先引入Sidecar，并采取Istio对虚拟机的支持方案，在虚拟机环境下运行。但如果有多平台支持的场景，比如既有Kubernetes环境，又有虚拟机环境，需对Istio进行定制化改造，去掉对Kubernetes的强依赖和耦合，增加对其他平台的支持。（对于多平台的支持，目前Istio还未支持，但从Istio官方相关文档可以看出，多平台的支持最终肯定支持，我们只需拭目以待。）
Istio对Kubernetes的耦合主要有以下几个方面，因此需要针对性的适配修改。
（1）API资源管理层对KubernetesAPIServer的依赖
资源管理层是Istio对Kubernetes依赖最大的地方。Istio对核心资源的管理，是以KubernetesCRD为基础，并使用kubectl作为命令行操作入口，kubectl调用APIServer，将资源存放在etcd中，并通过KubernetesCRD机制触发资源变更事件通知，通知关心Istio资源变更事件的模块进行相关处理。
如需解除Istio对Kubernetes的绑定，则需要自行实现这一套API管理方式，并且做到平台无关。
（2）通信访问层面对kubeDNS的依赖
通信层面，在客户端发送请求前，先通过DNS获取服务的虚拟IP地址，Istio的DNS实现沿用KubernetesDNS方案，基于DNS通过服务名实现直接访问。因此需要在DNS方案层面接触和Kubernetes的耦合，并使用平台无关的DNS解决方案。
2.4.3.3两种框架并存
对于体量较大的业务，不可能一次性迁移完成，需遵守“渐进式迁移”原则，则实际迁移过程中可能面临这样的诉求：
●一些存量老业务运行在虚拟机或者物理机上，暂时没有容器化改造计划，但希望通过ServiceMesh来做服务治理。
●新上的业务或者存量的非关键业务可以做为试点，先容器化、ServiceMesh化，其它业务依然采用原有的运行方式和微服务框架。
●对于未迁移的存量应用和迁移完成的ServiceMesh应用依然能保持业务上的互通。
面对上述这些真实而又合理的诉求，在进行ServiceMesh微服务平台搭建时，必然会存在两种框架并存的场景，如下图所示，左边是未迁移的存量服务，右边是容器化并ServiceMesh化的试点服务，但这种模式服务间却是互不相同，且无法统一治理。
然而两种框架并存时，如何服务间互通，统一治理？
在业内流行这样一句话：计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。
同样，我们可以针对ServiceMesh的控制平面做些文章，通过自定义控制插件（WASM）将SpringCloud框架中原有注册中心的功能纳入进来，由控制平面提供原有服务注册与发现的能力，并结合Istio中入口网关Ingress和ServiceEntry资源配置，以实现服务间互通，统一治理，整个实现逻辑架构如下图所示。
至此，实现了基于SpringCloud和Istio两种框架的并存。
2.4.4应用迁移
到这里，已经完成了ServiceMesh微服务平台的搭建，在这样的平台上我们如何将SpringCloud应用逐步向ServiceMesh迁移？
2.4.4.1去除重叠功能
先来看一下SpringCloud框架与Istio框架的功能重叠情况：
从上表功能对比分析，存在大量的重叠功能，需将SpringCloud与Istio中重叠功能去除，缺失功能保留，理论上可轻松去重。对于SpringCloud而言，这些重叠功能大部分只需去除pom.xml中依赖包、相关配置及代码中注解即可轻松完成，剩余一个相对干净的应用。
2.4.4.2应用注入
应用注入是指在将应用服务部署到网格时，将Sidecar注入到应用服务中，以实现网格的代理。
Sidecar注入，分为手动注入和自动注入：
●手动注入：通过手动执行istioctlkube-inject来重新构造应用的CRDyaml。
●自动注入：通过Kubernetes的mutablewebhook回调istio-sidecar-injector服务来重新构造应用的CRDyaml。
如下图所示：
无论是手动注入还是自动注入，Sidecar注入的本质是将运行Sidecar所需要的镜像地址、启动参数、所连接的Istio集群及配置信息填充到注入模版，并添加到应用的CRDyaml中，最终通过Kubernetes持久化资源并拉起应用和Sidecar的POD。
此时，应用已成功迁移部署到ServiceMesh。
03.总结
正如《数字化的力量》一书中所说：
这种升级改造和技术范式的转换并不是在一夜之间完成的,数字技术需要通过在社会经济的各个方面进行逐步应用,通过量的积累进而最终引起质的飞跃,使我们从新的技术范式的形成阶段进入到稳定发展阶段。郭为.数字化的力量[M].北京：机械工业出版社，.
这篇文章从传统微服务架构开始一步步介绍到ServiceMesh，并提出了传统微服务架构面临的挑战，针对现状，为了更好的满足市场需求，而不被市场淘汰，介绍了传统微服务如何平滑迁移到ServiceMesh的过程，并给出了一些解决方案、步骤及思路，供大家参考。
参考资料
郭为.数字化的力量[M].北京：机械工业出版社，.
