共计 1583 个字符，预计需要花费 4 分钟才能阅读完成。
作为新一代微服务架构体系，Service Mesh 技术无效地解决了 Spring Cloud 微服务架构和服务治理过程中的痛点问题，一经推出便引起了很大的反应。近一年来，随同着云原生的热气腾腾，Service Mesh 被推向了巅峰，从生疏走向大家的视界，甚至一些初创企业都想从中取得第一桶金。对于初创企业或全新产品，抉择 Service Mesh 变得绝对轻松很多，毕竟不存在迁徙的问题。但对于大部分企业或成熟的产品体系，这样大的架构转型就变得很难以施行，须要多加权衡利弊，面对 Service Mesh 带来的益处，不得不迫使向它聚拢。
目前很多企业还是采纳基于 SDK 的传统微服务框架（例如，Dubbo、Spring Cloud）进行服务治理，而随着 Service Mesh 的遍及，越来越多的企业开始布局本人的 Service Mesh 框架体系，但少数企业刚开始不会激进地将所有业务迁徙至 Serivice Mesh，毕竟这样危险太大、收益太慢。像 Java 技术栈利用仍然保留原框架，而非 Java 技术栈利用采纳 Service Mesh 框架，不同开发语言能够用不同的技术框架，但业务不能被框架割裂，那么在这两种架构体系下应用服务如何互联互通？微服务如何对立治理？传统微服务又如何平滑迁徙至 Service Mesh 呢？
如何解决上述问题呢？明天咱们就针对构建基于 Spring Cloud 向 Service Mesh 框架迁徙过程中的诸多问题展开讨论，尽可能提供一套欠缺的解决方案和迁徙思路，供大家参考。
1、背景
微服务是近些年来软件架构中的热名词，也是一个很大的概念，不同人对它的了解都各不相同，甚至在晚期微服务架构中呈现了一批四不像的微服务架构产品，有人把单纯引入 Spring Boot、Spring Cloud 框架也叫做微服务架构，却只是将它作为服务的 Web 容器而已。
随着微服务的炽热，越来越多的团队开始实际，将微服务纷纷落地，并投入生产。但随着微服务规模的一直壮大，每减少一个微服务，就可能会减少一些依赖的基础设施和第三方的配置，比方 Kafka 实例等，相应 CI/CD 的配置也会减少或调整。同时随着微服务数量增多、业务复杂性的晋升及需要的多样性等（如，对接第三方异构零碎等），服务间通信的盘根错节，一步步地将微服务变得更加臃肿，服务治理也是难上加难，而这些问题在单体架构中很容易解决。为此，有人开始狐疑当初微服务化是否是理智之选，甚至思考回归到传统单体利用。
1.1 传统微服务架构面临的挑战
面对上述暴露出的问题，并在传统微服务架构下，通过实际的一直冲击，面临了更多新的挑战，综上所述，产生这些问题的起因有以下这几点：
过于绑定特定技术栈。当面对异构零碎时，须要破费大量精力来进行代码的革新，不同异构零碎可能面临不同的革新。
代码侵入度过高。开发者往往须要破费大量的精力来思考如何与框架或 SDK 联合，并在业务中更好的深度交融，对于大部分开发者而言都是一个高曲线的学习过程。
多语言反对受限。微服务提倡不同组件能够应用最适宜它的语言开发，然而在 Spring Cloud 框架下就是 Java 的天下，多语言的反对难度很大。这也就导致在面对异构零碎对接时的无奈，或退而求其次的计划了。
老旧系统维护难。面对老旧零碎，很难做到对立保护、治理、监控等，在适度期间往往须要多个团队分而管之，保护难度加大。
上述这些问题都是在劫难逃，咱们都晓得技术演进来源于实际中一直的摸索，将性能形象、解耦、封装、服务化。随着传统微服务架构暴露出的这些问题，将迎来新的挑战，让大家纷纷寻找其余解决方案。
1.2 迎来新一代微服务架构
为了解决传统微服务面临的问题，以应答全新的挑战，微服务架构也进一步演变，最终催生了 Service Mesh 的呈现，迎来了新一代微服务架构，也被称为下一代微服务。为了更好地了解 Service Mesh 的概念和存在的意义，咱们来回顾一下这一演进过程。
