1、背景

1.1 传统微服务架构面临的挑战

面对上述暴露出的问题，并在传统微服务架构下，经过实践的不断冲击，面临了更多新的挑战，综上所述，产生这些问题的原因有以下这几点：

• 过于绑定特定技术栈。当面对异构系统时，需要花费大量精力来进行代码的改造，不同异构系统可能面临不同的改造。
• 代码侵入度过高。开发者往往需要花费大量的精力来考虑如何与框架或 SDK 结合，并在业务中更好的深度融合，对于大部分开发者而言都是一个高曲线的学习过程。
• 多语言支持受限。 微服务提倡不同组件可以使用最适合它的语言开发，但是在 Spring Cloud 框架下就是 Java 的天下，多语言的支持难度很大。这也就导致在面对异构系统对接时的无奈，或退而求其次的方案了。
• 老旧系统维护难。面对老旧系统，很难做到统一维护、治理、监控等，在过度时期往往需要多个团队分而管之，维护难度加大。

1.2 迎来新一代微服务架构

1.2.1 耦合阶段

• 基础设施功能（如，服务发现，负载均衡、熔断等）和业务逻辑耦合。

• 每个微服务都重复实现了想相同功能的代码。

• 管理困难。如果某个服务的负载均衡发生变化，则调用它的相关服务都需要更新变化。

• 开发者不能集中精力只关注于业务逻辑开发。

1.2.2 公共库 SDK

• 这些公共库 SDK 存在较为陡峭的学习成本，需要耗费开发人员一定的时间和人力与现有系统集成，甚至需要考虑修改现有代码进行整合。
• 这些公共库 SDK 一般都是通过特定语言实现，缺乏多语言的支持，在对现有系统整合时有一定的局限性。
• 公共库 SDK 的管理和维护依然需要耗费开发者的大量精力，并需专门人员来进行管理维护。

1.2.3 Sidecar 模式

• 服务注册。帮助服务注册到相应的服务注册中心，并对服务做相关的健康检查。

• 服务路由。当应用服务调用其它服务时，Sidecar 可以帮助从服务发现中找到相应的服务地址，完成服务路由功能。

• 服务治理。Sidecar 可以完全拦截服务进出的流量，并对其进行相应的调用链跟踪、熔断、降级、日志监控等操作，将服务治理功能集中在 Sidecar 中实现。

• 集中管控。整个微服务架构体系下的所有服务完全可以通过 Sidecar 来进行集中管控，完成对服务的流控、下线等。

于是，应用服务终于可以做到跨语言、更专注于业务逻辑的开发。

1.2.4 Service Mesh

1.3 什么是 Service Mesh

1.3.1 Service Mesh 介绍

• 应用程序间通讯的中间层。

• 轻量级网络代理。

• 应用程序无感知。

• 解耦应用程序的重试/超时、监控、追踪和服务发现。

Service Mesh 的出现解决了传统微服务框架中的痛点，使得开发人员专注于业务本身，同时，将服务通信及相关管控功能从业务中分离到基础设施层。

1.3.2 Service Mesh 的功能

• 动态路由。可通过路由规则来动态路由到所请求的服务，便于不同环境、不同版本等的动态路由调整。
• 故障注入。通过引入故障来模拟网络传输中的问题（如延迟）来验证系统的健壮性，方便完成系统的各类故障测试。
• 熔断。通过服务降级来终止潜在的关联性错误。
• 安全。在Service Mesh上实现安全机制（如TLS），并且很容易在基础设施层完成安全机制更新。
• 多语言支持。作为独立运行且对业务透明的 Sidecar 代理，Service Mesh 很轻松地支持多语言的异构系统。
• 多协议支持。同多语言一样，也支持多协议。
• 指标和分布式链路追踪。

• 可见性：运行时指标遥测、分布式跟踪。
• 可管理性：服务发现、负载均衡、运行时动态路由等。
• 健壮性：超时、重试、熔断等弹性能力。
• 安全性：服务间访问控制、TLS 加密通信。

1.3.3 Service Mesh 解决什么问题

• 基础设施层是Service Mesh的定位，致力于解决微服务基础设施标准化、配置化、服务化和产品化的问题。
• 服务间通信是Service Mesh技术层面对的问题，对微服务屏蔽通信的复杂度，解决微服务的通信治理问题。
• 请求的可靠传递是Service Mesh的目标。
• 轻量级网络代理是Service Mesh的部署方式。
• 对应用程序透明是Service Mesh的亮点和特色，实现对业务无侵入。
  
  

• 完善的微服务基础设施
  通过将微服务通信下沉到基础设施层，屏蔽了微服务处理各种通信问题的复杂度，形成微服务之间的抽象协议层。开发者无需关心通信层的具体实现，也无需关注RPC通信（包含服务发现、负载均衡、流量调度、流量降级、监控统计等）的一切细节，真正像本地调用一样使用微服务，通信相关的一起工作直接交给Service Mesh。
• 语言无关的通信和链路治理
  功能上，Service Mesh并没有提供任何新的特性和能力，Service Mesh提供的所有通信和服务治理能力在Service Mesh之前的技术中均能找到，比如Spring Cloud就实现了完善的微服务RPC通信和服务治理支持。
  Service Mesh改变的是通信和服务治理能力提供的方式，通过将这些能力实现从各语言业务实现中解耦，下沉到基础设施层面，以一种更加通用和标准化的方式提供，屏蔽不同语言、不同平台的差异性，有利于通信和服务治理能力的迭代和创新，使得业务实现更加方便。
  Service Mesh避免了多语言服务治理上的重复建设，通过Service Mesh语言无关的通信和服务治理能力，助力于多语言技术栈的效率提升。
• 通信和服务治理的标准化
• 微服务治理层面，Service Mesh是标准化、体系化、无侵入的分布式治理平台。
• 标准化方面，Sidecar成为所有微服务流量通信的约束标准，同时Service Mesh的数据平台和控制平面也通过标准协议进行交互。
• 体系化方面，从全局考虑，提供多维度立体的微服务可观测能力（Metric、Trace、Logging），并提供体系化的服务治理能力，如限流、熔断、安全、灰度等。
通过标准化，带来一致的服务治理体验，减少多业务之间由于服务治理标准不一致带来的沟通和转换成本，提升全局服务治理的效率。

1.3.4 Service Mesh 框架选型

1.4 框架迁移迫在眉睫

为了更好的占领市场，满足更多业务场景的需求，传统微服务架构（如，基于 Spring Cloud 框架的微服务架构）面临了众多新的挑战，而 Service Mesh 的出现正好解决了这些问题。面对新的框架体系，对于传统微服务架构该如何应对？

对于 Spring Cloud 框架的微服务向 Service Mesh 框架迁移必将迫在眉睫，是推翻重来，还是循序迁移？

2、Service Mesh 迁移方案

2.1 迁移场景

传统微服务框架，我们以最为典型的 Spring Cloud 框架为例进行迁移说明。首先，我们先看一下这样的一个迁移场景，目前的微服务架构是这样的，如下图左边部分：

• 应用是部署在虚拟机或物理机上。（服务还未容器化）
• 框架是基于 Spring Cloud 框架开发。（服务中包含业务逻辑和 Spring Cloud 组件等依赖，业务和框架耦合度过高）
• 开发语言是以 Java 为主。（存在跨语言的限制）
• 注册中心采用的是 Consul 或 Eureka。（服务需引入注册中心依赖包，存在一定的耦合）

2.2 迁移路径

• 是否真的有必要引入迁移到 Service Mesh 上？

• 当前微服务架构下，是否面临传统微服务架构面临的挑战？

• 当前微服务架构，是否已经阻碍或影响未来业务的发展？

• 公司或技术团队，是否有能力、人力、精力来投入到 Service Mesh 的迁移？

  
  

其次，完成 Service Mesh 微服务平台的搭建。当前所处阶段是否已经支持容器化和 Kubernetes。如果当前业务已经运行在 Kubernetes 之上，则 Service Mesh 的迁移将会非常顺畅；如果当前业务没有运行在Kubernetes上，因 Service Mesh 当前典型的 Istio 框架对 Kubernetes 有着过度依赖，所以可能就无法直接从 Spring Cloud 迁移到 Istio 框架，即使定制修改 Istio 以接触对 Kubernetes 的依赖，将会付出很大的代价。这时通常有两条迁移路径可以选择。

路径一：非 Kubernetes 环境下，先接入 Sidecar

如果当前业务没法快速容器化，同时又有引入 Service Mesh 的迫切需求，可采取先接入 Sidecar，来满足当前业务的痛点需求。在引入 Sidecar 时，要注意其未来的演进方向，考虑后续可能继续向 Service Mesh 迁移，一旦时机成熟并引入 Kubernetes 容器化后，则能够顺利由 Sidecar 的方式直接演进到 Service Mesh。

Service Mesh 当前典型的 Istio 框架在非 Kubernetes 下没有很好的支持（据说未来会完全脱离对Kubernetes 的依赖），对 Istio 进行定制化修改以支持非 Kubernetes 环境将会付出很大的代价，非特别强烈的需求和强大的技术储备，一般不建议这么做，特别是对于一些中小公司而言。

如果一定要在非 Kubernetes 环境下引入 Service Mesh，数据平面可使用 Envoy，控制平面可根据 XDS 协议进行自研。

路径二：先进行 Kubernetes 容器化改造，再接入 Service Mesh

倘若公司有云平台或容器化团队，可采用公司资源共享的方式，先借助其他团队来完成 Kubernetes 容器化改造，再接入 Service Mesh。

最后， 基于构建的 Service Mesh 框架，将业务应用逐步迁移到 Service Mesh 上来。

2.3 迁移原则

• 渐进式迁移： 为了避免 Service Mesh 迁移过程中的风险，必须采用渐进式迁移原则，每次只迁移少量服务，待迁移后观察足够长的时间，没有问题后再继续迁移。

• 业务透明： 为减少 Service Mesh 迁移对业务的影响，减少业务的迁移阻力，迁移初期必须确保业务完全透明且不需要过多的变更和修改。

• 方案上，为保证迁移对业务的完全透明，在数据平面通信上可采用支持透明拦截的方式，对业务请求流量透明拦截。

• 兼容性： 在迁移阶段，必然会存在两种模式（ Spring Cloud 和 Service Mesh 框架）并存，在迁移过程中需要充分考虑两者的兼容性，使得迁移前后网络打通，至少能够满足未迁移和已迁移部分能够通信。

2.4 迁移方案

2.4.1 Spring Cloud 架构分析

• 代理&网关：提供统一对外或对内的访问入口，包括路由、鉴权、限流、熔断、降级等统一处理。
• 注册中心：提供服务的注册与发现功能。
• 应用服务：覆盖整个业务服务，包括业务逻辑实现、框架 SDK 及外部组件依赖交互等。
• 中间件&数据存储：为应用服务提供额外的支持能力。
• CI&CD：持续集成、持续部署。

上述这几部分中哪些内容是我们可以去掉或者说基于 Service Mesh （以 Istio 为例）能够去做的？经过分析得知，可以替换的组件包括网关（Gateway 或者 Zuul，由 Ingress gateway 或者 egress 替换），熔断器（hystrix，由 Sidecar 替换），注册中心（Eureka 及 Eureka client，由 Polit，Sidecar 替换），负责均衡（ Ribbon，由 Sidecar 替换）等。

此阶段，我们能够大致知道 Spring Cloud 中的哪些内容可以由 Istio 处理，哪些内容可以继续沿用。

2.4.2 容器化改造

• 更省：极大的资源利用效率， 最大限度榨取和共享物理资源，多项目更能体现出容器化多优势，节约部署 IT 成本。
• 更快：秒级启动，实现业务系统更快的开发迭代 和 交付部署。
• 弹性：可根据业务负载进行弹性容器伸缩，弹性扩展。
• 方便：容器化业务部署支持蓝绿/灰度/金丝雀等发布，回滚，更加灵活方便。
• 灵活：监控底层 node 节点健康状态，灵活调度至最优节点部署。
• 强一致性：容器将环境和代码打包在镜像内，保证了测试与生产环境的强一致性。

• 掌握 Docker 技术：开发人员需熟悉 Docker 容器化技术，熟练编写 Dockerfile 文件。

• 掌握 Kubernetes 编排系统：熟悉 Kubernetes 容器化编排系统，  熟悉各组件资源清单编写、高可用、 RBAC 安全策略等。

• 容器化构建：将基于 Spring Cloud 搭建的所有服务实现容器化构建，实现 Docker 镜像打包。

• 容器化管理：基于 Kubernetes 进行服务容器的管理。

2.4.2.1 容器化构建

FROM java:8RUN mkdir /microserviceWORKDIR /microserviceADD /service-provider-1.0.jar /microservice/EXPOSE 8001ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/microservice/service-provider-1.0.jar"]

（2）配置 pom docker-maven-plugin插件。

在服务serviceProvider 的 pom.xml 中配置 build 部分，内容如下：

<!-- 打包配置 -->  <build>    <defaultGoal>install</defaultGoal>    <!-- build后的文件名，默认值是${artifactId}-${version}。-->      <finalName>service-provider-${project.version}</finalName>
    <plugins>      <plugin>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-maven-plugin</artifactId>      </plugin>
      <!-- 配置docker maven插件，绑定install生命周期，在运行maven install时生成docker镜像 -->          <plugin>              <groupId>com.spotify</groupId>              <artifactId>docker-maven-plugin</artifactId>              <version>0.4.13</version>              <executions>                  <execution>                      <phase>install</phase>                      <goals>                          <goal>build</goal>                          <goal>tag</goal>                      </goals>                  </execution>              </executions>              <configuration>                  <!-- 修改这里的docker节点ip，需要打开docker节点的远程管理端口2375。可在hosts中进行dockerip的配置 -->                  <dockerHost>http://dockerip:2375</dockerHost>                  <imageName>${project.build.finalName}</imageName>                  <baseImage>java</baseImage>                  <!-- 这里的entryPoint定义了容器启动时的运行命令，容器启动时运行 java -jar 包名 , -Djava.security.egd这个配置解决tomcat8启动时，因为需要收集环境噪声来生成安全随机数导致启动过慢的问题-->                  <entryPoint>                      ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/${project.build.finalName}.jar"]                  </entryPoint>                  <resources>                      <resource>                          <targetPath>/</targetPath>                          <directory>${project.build.directory}</directory>                          <include>${project.build.finalName}.jar</include>                      </resource>                  </resources>                  <image>${docker.image.prefix}/${project.build.finalName}</image>                  <newName>${docker.image.prefix}/${project.build.finalName}:${docker.tag}</newName>                  <forceTags>true</forceTags>                  <!-- 如果需要在生成镜像时推送到远程库，pushImage设为true -->                  <pushImage>false</pushImage>              </configuration>          </plugin>    </plugins>  </build>

（3）打包。

2.4.2.2 容器化管理

2.4.3 Service Mesh 微服务平台搭建

2.4.3.1 istio 基础框架搭建

• 控制平面：提供服务⽹格控制指令下发、服务配置、 权限控制等功能。

• 数据平台：提供服务治理、服务监控及运维、流量管控等功能。

至此，一个 Istio 基础框架搭建完成，能够提供 Service Mesh 的所有能力。

2.4.3.2 istio 扩展和定制

2.4.3.3 两种框架并存

对于体量较大的业务，不可能一次性迁移完成，需遵守“渐进式迁移”原则，逐步迁移，所以实际迁移过程中可能面临这样的诉求：

• 一些存量老业务运行在虚拟机或者物理机上，暂时没有容器化改造计划，但希望通过 Service Mesh 来做服务治理。
• 新上的业务或者存量的非关键业务可以做为试点，先容器化、Service Mesh 化，其它业务依然采用原有的运行方式和微服务框架。
• 对于未迁移的存量应用和迁移完成的 Service Mesh 应用依然能保持业务上的互通。

面对上述这些真实而又合理的诉求，在进行 Service Me 还是微服务平台搭建时，必然会存在两种框架并存的场景，如下图所示，左边是未迁移的存量服务，右边是容器化并 Service Mesh 化的试点服务，但这种模式服务间却是互不相同，且无法统一治理。

至此，实现了基于Spring Cloud 和 Istio 两种框架的并存。

2.4.4 应用迁移

2.4.4.1 去除重叠功能

从上表功能情况，存在大量重叠功能，需将Spring Cloud 与 Istio 中重叠功能去除，缺失功能保留，理论上可轻松去重。对于 Spring Cloud 而言，这些重叠功能大部分只需去除 pom.xml 中依赖包、相关配置及代码中注解即可轻松完成，剩余一个相对干净的应用。

2.4.4.2 应用注入

Sidecar 注入，分为手动注入和自动注入：

• 手动注入：通过手动执行 istioctl kube-inject 来重新构造应用的 CRD yaml。

• 自动注入：通过 Kubernetes 的 mutable webhook 回调 istio-sidecar-injector 服务来重新构造应用的 CRD yaml。

3、总结

1. https://istio.io/latest/docs/concepts/what-is-istio/
2. 刘俊海 著《Service Mesh 微服务架构设计》
3. https://mp.weixin.qq.com/s/y9PZLgHhVcdsMuTzAyIMsQ
4. https://www.servicemesher.com/blog/service-mesh-rebuild-microservice-market/
5. https://mp.weixin.qq.com/s/-MszFJORuDJKf3V5ndyimw
6. https://www.servicemesher.com/blog/netease-yeation-service-mesh/

图书推荐

▊《Service Mesh实战：用Istio软负载实现服务网格》

周遥 著

方剑 编著

 
如果喜欢本文
欢迎 在看丨留言丨分享至朋友圈 三连

 热文推荐  

BPF 之巅：洞悉 Linux 系统和应用性能
拍立淘创始人为你揭开“以图搜图”的神秘面纱！
图神经网络在生化医疗方面的相关应用
用C++ 和OpenCV 实现视频目标检测