要想业务中台建得快，最好用Service Mesh来带

本文由作者授权网易云发布，未经许可，请勿转载！

作者：裴斐，网易杭州研究院云计算技术部资深架构师

业务中台呼唤Service Mesh

当业务系统研发团队至少大几十人（含外包的），需求多变化快，系统又涉及多个领域（比如做ERP、电商的），业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚，提升软件复用能力，加快需求响应速度。

中台是一个独立的组织负责并为多个前台业务服务，因此需要一个标准的服务接口、成熟的服务治理能力和高效的敏捷研发技术，相对于传统的基于ESB（企业服务总线）的面向服务架构（SOA）技术，微服务架构成为业界的共同选择。微服务提供快速迭代、灰度发布、持续交付及声明式运维的特点，与业务中台的追求天然契合。

微服务化也是互联网软件产品发展的必然结果，以网易微服务演进的历程为例，最初的单体应用在业务规模、并发访问量不断增长时，都会被拆分成一些微服务，由不同的小团队维护，以获得研发、部署和运维上的便捷性。

在微服务演进的过程中，不少的企业已经引入Dubbo、Spring Cloud等传统的微服务框架，来解决服务通信的效率，以及服务治理相关的问题。然而，这种传统的微服务框架并不足以应对建设企业业务中台的挑战。作为前台共性业务能力，中台天然需要一个统一的技术栈，实现异构系统整合，以及微服务设施下沉，而这些，是Dubbo或者Spring Cloud力有未逮的。

首先，大型企业或多或少都有统一技术栈的需求，即便都是Java业务，所采用的技术栈也有Dubbo、Spring Cloud以及自研RPC框架之分。其次，有的老的业务采用.Net、C++或者其他语言，需要和新的Java业务整合，难度很大。另外，从架构上看，中台是一种基础设施的下沉，微服务框架则是一种不彻底的下沉，因为它还是在业务开发代码里面的。而这种对业务的侵入性，也造成了服务框架升级的困难。

微服务圈的新贵Service Mesh就是应对上述挑战的曙光。Service Mesh是用以处理服务与服务之间的通信的专用基础设施层，也就是说这种下沉使得服务治理不再和业务代码融合在一起，而是作为一层专用的微服务设施。

如图是一个简化的Service Mesh架构，服务A和服务B相互调用，不再是以前通过微服务框架直接指向的方式，而是在中间加了两个叫做Sidecar（边车）的东西，各种服务都在这里处理数据上的逻辑。Sidecar的作用是数据面的代理，它是更贴近于数据的；而Sidecar不能完全不受控，上面控制它的就叫做控制面。


实际业务中，尤其是中台架构下，企业往往需要很多的微服务，也就是上述服务A、服务B相互调用的情况会不断扩展，就会逐渐形成更多的服务加Sidecar的组合，就变成了一个真正意义的Service Mesh。


Service Mesh具有三个明显的优势：第一它是一个 独立的进程，和业务是解耦的，对业务代码无侵入；第二，是具 备跨语言特性，上文说的Dubbo和Spring Cloud其实都是Java技术栈，而Service Mesh具备整合一些C++、Golang之类的异构语言应用的能力，因为它没有进入到进程内；第三是它提供了熔断、限流等丰富的 微服务服务治理功能。

这些优势，使得Service Mesh可以比较容易地解决中台架构下微服务化存在的问题。对于使用采购或外包模式的传统企业尤其如此。传统企业往往需要将后台的应用进行封装或者重构为中台，来支撑前台灵活的业务变化，自研系统还可以采用Spring Cloud来重构，但采购的系统只能使用封装的模式，而 采购的不同系统一般采用.Net、Spring MVC、PHP、Python等不同的技术栈，如果没有Service Mesh，接入微服务体系就会是一场噩梦。

实施Service Mesh的技术方案

Service Mesh先进的理念，是否已经有相应的技术方案？

答案是肯定的。主流云原生Service Mesh框架是Istio，它是谷歌、IBM、Lyft联合开发的。Istio采用Go语言写的，与容器编排系统Kubernetes一脉相承，承载了服务治理方面的期待。因为Kubernetes在容器圈是无可争议的王者，大家比较看好Istio。

Istio提供了完整的Service Mesh的解决方案，数据面是一个叫Envoy的组件，控制面的组件包括Pilot、Mixer、Citadel和Galley等。在下图服务A调用服务B的流程中，支持这种调用的Sidecar就是用Envoy组件来实现的，下半部分是控制面的组件，最主要的是Pilot，其他是配合功能完整性的一些组件。


先看 数据面核心组件Envoy。数据面跟微服务本身相关性非常大的，因为所有的流量以及大部分治理都需要经过它。

目前网易和业界不少探索Service Mesh的公司都采用Envoy作为数据面的标准组件，这源于它的七大优势。第一，它是基于现代C++开发的网络L4/L7的代理，这意味着它能够提供很高的性能。根据网易轻舟微服务团队的实测，使用经典的HTTP网络协议，Envoy的性能确实是比较强的。第二是流量管理，Envoy可以对服务流量做路由、分流等动态的管理。第三是服务治理方面的特性，包括熔断、限流，以及在里面注入一些故障。第四是多协议支持，Envoy除了支持比较经典的HTTP 1.x版本，还支持2.x版本，也支持gRPC、TCP、Web Socket等。它不仅可以对服务之间调用的流量进行管理，一些DB、缓存其实也可以做到，因为它是网络4-7层的。第五是负载均衡，Envoy支持的算法非常多。第六是动态配置API，作为一个数据面应该有接口可以动态去控制，让控制面来调用配置。第七是可观察性设计，作为一个数据面应该把经过它的流量和数据上报，让后端更庞大的监控系统看到整个微服务体系到底是一个怎样的状态。最后是支持自定义插件扩展能力的，企业对Envoy本身的功能如果不满足，还可以通过插件进行扩展。

Istio的 控制面核心组件是Pilot，它最主要的功能是和Sidecar建立双向的gRPC连接，可以通过控制面实时下发配置或是服务发现的信息，包括服务发现和抽象，以及配置的转化和分发。

另外三个组件，Mixer主要是做策略检查跟遥测，包括检查一些权限，或者通过它上报监控数据。Citadel负责安全性方面，可以做证书与秘钥管理相关的分发。Galley是1.1版本正式引入的，主要做配置校验。这些组件中，业界诟病最多的是Mixer做策略检查操作的时候会有性能问题。

小结

由于业务无侵入、跨语言的特性以及丰富的服务治理能力，不论是建设业务中台，实现部门级、企业级甚至集团级业务能力的整合与复用，还是只建设微服务基础设施，支撑大规模互联网业务，或是解决IT竖井难题，Service Mesh架构都可以成为企业的一大助力。

需要注意的是，Service Mesh原生的开源方案还存在一些问题。首先，到目前为止，社区版本还存在一些性能问题；其次，它的稳定性和产品化还有待验证，真实落地的产品和企业还是非常少的；第三点，它有一定技术门槛，企业如果直接使用开源版本的话成本还是比较高的，概念非常多，而且还需要懂容器、Kubernetes和一些服务治理相关的东西。

当然，踩过坑的团队，也会发现破解Service Mesh落地难题的一些“套路”，我们将于下文解析，敬请期待。