不是所有的应用都需要Service Mesh架构

“微服务架构”的含义在过去十年里不断演变，今天的服务网格实现已经相当复杂，第二代 Service Mesh 诞生在 Kubernetes 之后，它的代表是 lstio。在 lstio 之外，同时存在着各种层出不穷的框架，解决的却都是相同的问题。

正确的选择框架却不是件简单的事情。就像在容器编排领域，之前我们有 Kubernetes、Docker Swarm、Mesos 和 Cloud Foundry，其中一些后来逐渐被市场淘汰，没有选择 Kubernetes 的企业有可能得从头再来一次。在微服务领域，我们不希望有类似的情形出现。现在，各种框架竞争激烈，你的业务适合采用哪一个？使用微服务架构，除了 Service Mesh 还有其他选择吗？针对这些问题，我们采访了腾讯 TSF Mesh 研发及负责人张培培，他给出了一些很好的见解。

采访嘉宾：张培培，腾讯研发高级工程师，TSF Mesh 研发及负责人，热衷于云原生和开源技术，在容器、Service Mesh、消息队列、区块链等领域拥有丰富经验，目前致力于 Service Mesh 和 Mecha 多运行的落地和推广。

InfoQ：这十年里微服务领域有哪些大的变化？

张培培： 微服务的概念最早是在 2011 年威尼斯一个的软件架构会议上被提及的，随后又有一大批的技术框架和文章涌现出来，越来越多的公司开始借鉴和使用微服务架构相关的技术，我觉得这十年微服务架构的演进分为四个重要阶段：

第一个阶段：RPC 通信，应用从单体拆分成运行于多主机的微服务，首要解决的问题就是微服务间的通信问题，这里又分为两类，一类跟语言平台绑定的框架如阿里 Dubbo、微博 Motan、腾讯 Tars，另一类跨语言平台的框架如 Thrift、gRPC。这个阶段，特别是早期版本的 RPC 框架，并没有支持太多的服务治理能力，开发人员需要在应用程序中解决服务发现、熔断重试等微服务架构所面临的问题，这就导致大量的非功能性代码耦合在业务代码中；

第二个阶段：服务治理 SDK 化，随着微服务架构在企业大规模落地，调用链路越来越复杂，微服务架构所面临的问题也越来越突出，亟需一套统一且完善的服务治理能力，而最直接的集成方式就是融合到 RPC 框架中，这个阶段比较有代表性的框架如 Dubbo、Spring Cloud，只需要少量代码和注解，即可集成各种所需的服务治理能力。而 Spring Cloud 更是对各种治理能力进行了模块化抽象如服务注册发现 Spring Cloud Eureka、服务调用负载均衡 Spring Cloud Feign、服务熔断 Spring Cloud Hystrix 等；

第三个阶段：服务治理 Sidecar 化，基于 SDK 的微服务框架，解决了治理能力统一的问题，但也带来的诸多问题，如 SDK 升级维护成本高、难以支持多语言、策略控制不统一等问题。Service Mesh 方案应运而生，服务治理能力下沉到 Sidecar，治理策略有控制面统一管理。这个阶段比较有代表性的框架如 Linkerd、Istio 等；

第四个阶段：多运行时，对于一个复杂的大型分布式系统，不管是基于 SDK 的服务治理和 Service Mesh，更多解决的是服务间通信的问题，而一个分布式应用的需求远远不止于此，还需要状态管理如 Workflow 管理、应用幂等实现、应用执行状态等等，需要绑定外部依赖如数据存储、事件驱动等，传统的方式依然是通过 SDK 集成各种分布式能力，要真正做到应用完全专注于业务逻辑，这部分分布式能力也应该下沉到 Sidecar，这就是由一位大牛 bibryam 提出的 Mecha 多运行时的思想，目前比较有代表性的框架如 Dapr。

InfoQ：在您看来，为什么服务网格越来越受欢迎？它能解决传统微服务架构的哪些痛点？

张培培： 先理解下什么是传统微服务架构，就是微服务治理能力如服务注册、发现、熔断、限流等与业务逻辑解耦，单独以 SDK 的形式提供给开发者，但服务治理和业务逻辑还是跑在一个进程中的。再看下这种传统微服务架构带来了哪些痛点：

1. SDK 升级维护成本高，由于 SDK 耦合在业务进程中，那每次 SDK 升级必然需要绑定业务一起升级，这对于拥有成千上万的业务系统是很难接受的，而且涉及到 SDK 大版本的变更可能还会有兼容性问题；
2. 多语言框架 SDK 维护成本高，SDK 意味着和语言绑定，那不同语言都要维护不同的 SDK 版本，所以很少有多语言的传统微服务框架，能流行起来的也就是某个语言的框架如 JAVA 系的 Spring Cloud、Dubbo，go 系的 go-micro 等；
3. 没有统一微服务策略控制，各种治理能力控制比较分散，配置方式也比较随意；
4. 额外组件的引入特别是注册中心带来的运维成本。

而 Servive Mesh 之所以越来越受欢迎，在提供更丰富的服务治理、安全性、可观测性等核心能力外，其从架构设计从解决了以上几个痛点，服务治理能力以 Sidecar 的模式下沉到数据面，解决了 SDK 升级及多语言的问题，由于没有 SDK 的依赖，开发人员可以选择任何开发语言，只需专注于业务逻辑的开发，无需关注服务治理，Sidecar 作为基础设施层，也可以独立升级。对于像负载均衡、熔断、限流等策略配置，由控制面统一管理和配置，并下发到数据面生效。同时，Kubernetes 已被认为是云原生时代的操作系统，越来越多的应用基于 Kubernetes 进行编排，而主流的 Service Mesh 方案像 Isitio、Linkerd 都是承载在 Kubernetes 上，那微服务的核心之一服务注册发现，就完全不需要额外引入外部注册中心，编排在 Kubernetes 上的应用会自动在 Mesh 体系中被感知。

InfoQ：像 Spring Cloud 、Zuul、Eureka、Consul… 这些涵盖了微服务体系的服务注册与发现、限流、熔断降级、负载均衡、服务配置的开发框架或服务组件，在设计理念上与 Service Mesh 存在哪些差别？

张培培： 像 Dubbo、Spring Cloud 都属于传统的微服务框架，与服务治理相关的大部分逻辑都是以 SDK 的方式耦合在具体的微服务应用之中，服务注册、服务调用、负载均衡以及服务熔断、限流等高级治理都需要引入 SDK，同时，为了整个分布式系统的正常运作，还需要额外引入注册中心、微服务网关的基础组件。对于服务治理策略的控制，支持硬编码到代码逻辑、配置文件或者远程配置中心，基本是由开发人员控制的，像熔断、限流、负载均衡等服务治理的策略配置，也比较分散。总之，传统微服务框架更多的是面向开发者，没有形成统一的微服务控制平面。

Service Mesh 被定义为用于处理服务间通信的基础设施层，其在架构设计上采用了控制面 + 数据面的模式，微服务的治理能力下沉到数据面，与应用进程完全解耦，以 Sidecar 模式运行，并由控制面统一控制，以 Istio 为例，控制面实时感知服务治理策略的变更并通过 xDS 协议下发到数据面。尤其，在以 Kubernetes 为代表的容器编排技术逐步成为软件运行主流基础环境的背景下，目前主流的 Service Mesh 方案都是基于 Kubernetes 进行构建，像 Istio 天然依托于 Kubernetes，注册中心、边界网关包括配置管理的基础组件，都不需要额外引入。开发人员负责将只包含纯业务逻辑的应用编排进 Kubernetes，服务治理由数据面和控制面协作完成。

InfoQ：在您看来，目前有哪些 Mesh 主流的框架，如 lstio、Linkerd？各有什么优势？

张培培： 业内 Mesh 方案较多，如 Istio、Linkerd、Consul Connect，Kuma，AWS App Mesh 和 OpenShift，而成熟度较高、社区较为活跃的无疑是 Istio 和 Linkerd。

下面来对比下 Istio 和 Linkerd 的 Mesh 方案：

首先，目前两者都已经成熟，并已被多家企业用于生产，都是控制面 + 数据面的架构模式，支持多集群多网络的部署模式，支持 gRPC、HTTP/2、HTTP/1.x、Websocket 和所有 TCP 流量，涵盖了流量管理、安全性、可观测性等核心功能。

其次，再看下各自的优势。

Istio：

1. Istio 有 IBM、Google 和 Lyft 等行业领军者的支持，背景更加强大，社区也非常活跃；
2. 统一的东西流量和南北流量管理方案；
3. 功能相对丰富些，如熔断、延时注入等流量控制，安全方面支持基于 RABC 的访问控制。

Linkerd：

1. Linkerd 是业界的第一款 Service Mesh 框架，轻量级，相比 Istio 复杂而灵活的配置选项，Linkerd 配置简单，且内置开箱即用的配置，安装相对容易，运维成本也较低；
2. 控制面 namerd 支持直接对接多注册中心如 Kubernetes、ZooKeeper、Consul、etcd，Istio 虽然支持 service entry、mcp over xDS 的方式扩展除 Kubernetes 外的第三方注册中心，但需要用户自行编写组件扩展；
3. 性能较好，根据第三方基准测试，Istio 1.6 VS Linkerd 2.7，Linkerd 快 3-5 倍；
4. 企业支持较好，Buoyant 开发了 Linkerd OSS 版本， 提供了完整的企业级工程、支持和培训。

总结下来，Istio 社区更活跃、功能更完善，也更复杂；Linkerd 更轻量、性能更好，操作简单但也欠灵活。

InfoQ：您认为服务网格目前的局限性表现在哪些方面？

张培培：Service Mesh 让开发人员可以专注于业务逻辑的开发，无需关注服务治理，但也存在不少局限性。Istio 是目前业内最为流行的 Mesh 方案，下面就以 Istio 为例参考社区的几点总结：

1. 复杂性增加，Service Mesh 通过 Sidecar 侵入到业务数据流的，而 Sidecar 对业务进程又是透明的，虽然业务代码简单了，但整个数据流变复杂了，一次简单的调用从两跳变为六跳，这就极大的增加了开发调试及运维的难度；
2. 无法做到完全对应用透明，对于一些微服务框架已经集成了一些治理能力如重试机制，如果在 Sidecar 中再重试，容易引起重试风暴，还有 tracing header 的传递，也需要应用代码的参与，总之，现有的业务体系接入 Mesh，还是要充分考虑到所用的框架是否和 Mesh 有重合、冲突的地方；
3. 对非 Kubernetes 环境支持有限，目前主流的 Service Mesh 方案像 Istio 还是比较依赖于 Kubernetes 的，对于非容器环境或者非 Kubernetes 环境，服务注册发现、策略配置管理可能需要自行扩展，Sidecar 注入也需要自行维护管理；
4. 协议支持有限，目前主流的 Service Mesh 方案像 Istio、Linkerd 中 HTTP1.x/2.0、gRPC 才是一等公民，对于其它协议要么只局限在四层治理上，要么治理能力不全如 Dubbo、Thrift、Redis 等，这就导致一些传统的微服务框架很难直接迁移到 Service Mesh；
5. 扩展的门槛并不低，比如扩展第三方注册中心，虽然 Istio 提供了多种标准的扩展方式如 controller 实现、Service entry 或者 mcp over xDS，但依然需要理解各种复杂的接口或定义并实现；再比如对私有协议的支持，首先你需要在 Istio 的 API 代码库中进行协议扩展，其次你需要修改 Istio 代码库来实现新的协议处理和下发，然后你还需要修改 xDS 代码库的协议，最后你还要在 Envoy 中实现相应的 Filter 来完成协议的解析和路由等功能，这过程中可能还涉及到编译问题、代码合并问题、开源升级问题；
6. 性能损耗，由于服务调研经过了 Sidecar 代理，势必会带来性能上的损耗，目前公开的 Service Mesh 中 Envoy 造成的额外访问延时大概是 3 毫秒，这对延时极其敏感的业务会产生一定影响；
7. 资源占用问题，考虑到开箱即用，用户不用进行过多的配置，Istio 默认下发全量的规则，仅仅几个服务，Envoy 所收到的配置信息就有将近 20w 行，可以想象，在稍大一些的集群规模，Envoy 的内存开销、Istio 的 CPU 开销、xDS 的下发时效性等问题，也会变得尤为突出；同时，Envoy 作为流量代理，是 CPU 密集型应用，随着 QPS 的增加 Envoy 的 CPU 开销也是不可忽视，在内部一个模拟业务的压测场景下，Envoy 要额外吃掉 20%-30% 的 CPU 资源。

InfoQ：为什么服务网格落地时，会是百花齐放的局面？很多企业会自己实现一套？

张培培： 究其原因还是很多公司的业务系统存在较重的历史包袱，很难推翻现有平台或框架直接替换 Service Mesh 框架，因此在实际落地时会结合当前业务场景来打造自己的 Service Mesh。

比如：不少传统公司还没有容器化改造或者全量容器化改造，更不要说接入 Kubernetes，而像 Istio 这样的 Mesh 方案是非常依赖 Kubernetes 的，那可能就需要改造 Istio，支持控制面容器化部署，支持数据面容器化部署，由于不依赖 Kubernetes，那服务注册发现、策略配置管理就需要自己整一套。

再比如，在传统微服务框架盛行的年代，很多公司基于像 Dubbo、Spring Cloud 进行开发，或者一些公司自己的微服务体系，需要平滑、逐步迁移到 Service Mesh，那必然要考虑存量业务和 Mesh 业务共存的问题，同时保证两者的互联互通，而老系统有一套甚至多套注册中心像 ZooKeeper、Consul，有完整的服务治理控制平台，那可能就要设计注册中心同步或者双注册方案。

InfoQ：企业在实施微服务 / 服务网格可能会存在哪些技术债？总结起来会由哪些情况导致？

张培培： 总结下来，有以下几个方面：

1. 业务系统是否已经做了微服务改造，如果还是单体应用或者 SOA 体系，引入 Service Mesh 所带来的收益也并不明显，反正增加了额外的运维成本；
2. 业务系统是否已经容器化 /Kubernetes 编排，像主流 Mesh 方案还是强依赖于 Kubernetes，虽然对非容器环境有一定支持，但如果希望能直接融入 Mesh 体系，最好先容器化；
3. 业务系统中服务间通信是否基于如 HTTP/gRPC，否则需要扩展第三方协议，上面也聊到扩展协议其实并不那么轻松；
4. 运维体系是否完善，在大规模应用场景下，大量的应用意味着有等量的 Sidecar 需要运维，一套完善的运维系统才能保证应用及 Sidecar 在部署、灰度及升级阶段中的稳定性。

InfoQ：在微服务选型时，您认为需要一个什么样的前期的决策过程？需要哪些步骤？

张培培： 首先，捋下现有业务系统的痛点，比如，是否是单体应用微服务改造的问题，是否是传统微服务 SDK 的升级问题，是否是多语言多框架服务治理不统一的问题。再深入了解下 Service Mesh 适用场景、能力矩阵，看引入 Service Mesh 是否能真正解决自己的业务痛点。

其次，评估下上面提到的 Service Mesh 局限性是否能接受，是否能够驾驭的了 Service Mesh。

最后，如果决定引入 Service Mesh，评估下现有业务系统的迁移成本，是否有完善的开发配置基础设施如 CI/CD、统一的治理平台。

Service Mesh 解耦了开发和运维，开发简单了，但运维复杂了，如果考虑到运维成本较大或者迁移成本较大，也可以考虑下现有云厂商的 Mesh 平台托管，目前不少云平台已经解决了跨 Paas 平台、多注册中心、多框架多协议等问题，极大的降低了迁移成本。

InfoQ：未来还有哪些趋势值得关注？

张培培： 未来大家可以多关注下“Mecha”多运行时的发展。如果 Service Mesh 解决的是服务间的通信问题，解决的是网络运行时，那“Mecha”多运行时，就是 Service Mesh 的延展和升华，对分布式应用运行时所需的能力进行了抽象，对外暴露统一的分布式原语 API，并且不局限于 Sidecar 模式，甚至支持 node 模式，以适应 Iot 或者 Faas 的应用场景。

而针对不用的应用场景和架构可能又会分化出两种不同的落地实现：

1. 微服务治理能力的多运行，可以看作是 Service Mesh 的 Mecha 实现，从目前业内 Service Mesh 的落地实践来看，并没有完全撼动传统微服务系统的地位，归根结底还是之前提到的一些局限性导致很多公司掌控不了 Service Mesh。因此依然采用像 gRPC、Spring Cloud、Dubbo 甚至自研框架，但传统微服务的痛点又依然存在，而微服务治理能力的多运行实现正好迎合了这种场景，路由、泳道、熔断、负载均衡、限流、鉴权等微服务能力高度抽象，治理能力的实现和扩展下沉到 Sidecar 或 node，同时提供统一治理接口，并支持适配各种开发框架，这里没有实际侵入应用的数据流，因此，调用链路并不复杂，性能影响很小，运维成本也很小。目前，我们内部已经孵化出一款轻量级的云原生多运行时微服务框架，支持多语言、多框架、多平台，预计在今年 10 月份开源，敬请期待！
2. 分布式应用能力的多运行，对于构建一个复杂的业务系统，除了需要满足应用生命周期的管理、服务治理的需求，还需要如分布式配置、分布式锁、状态管理、事件驱动等能力，分布式应用能力的多运行就是对诸如这些能力的抽象，对应用提供统一的访问接口，这种实现方式就不过多介绍，有兴趣的可以了解下业内第一个多运行的开源实践项目 Dapr。