微服务之 - ServiceMesh

Service Mesh（服务网格）概念在社区里头非常火，有人提出2018年是Service Mesh年，还有人提出Service Mesh是下一代微服务架构基础。那么到底什么是Service Meth? 它的诞生是为了解决什么问题？企业是否适合引入Service Meth?

微服务架构的核心技术问题

在业务规模和研发效能提升等因素的驱动下，从单块应用向微服务架构的转型，已经称为很多企业（尤其是互联网企业）数字化转型的趋势。

在微服务模式下，企业内部服务少则几个到几十个，多则上百个，每个服务一般都以集群方式部署，这时自然产生两个问题 (如下图所示)：

 

一、服务发现： 服务的消费方 (Consumer) 如何发现服务的提供方 (Provider)？

二、负载均衡： 服务的消费方如何以某种负载均衡策略访问集群中的服务提供方实例？

作为架构师，如果你理解了这两个问题，也就理解了微服务架构在技术上最核心问题。

 

三种服务发现模式

 

服务发现和负载均衡并不是新问题，业界其实已经探索和总结出一些常用的模式，这些模式的核心其实是代理 (Proxy，如下图所以)，以及代理在架构中所处的位置。

 

在服务消费方和服务提供方之间增加一层代理，由代理负责服务发现和负载均衡功能，消费方通过代理间接访问目标服务。根据代理在架构上所处的位置不同，当前业界主要有三种不同的服务发现模式：

模式一：传统集中式代理

 

 

 

这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队 (一般是运维或框架) 负责治理和运维。常用的集中式代理有硬件负载均衡器 (如 F5)，或者软件负载均衡器 (如 Nginx)，F5(4 层负载)+Nginx(7 层负载) 这种软硬结合两层代理也是业内常见做法，兼顾配置的灵活性 (Nginx 比 F5 易于配置)。

这种方式通常在 DNS 域名服务器的配合下实现服务发现，服务注册 (建立服务域名和 IP 地址之间的映射关系) 一般由运维人员在代理上手工配置，服务消费方仅依赖服务域名，这个域名指向代理，由代理解析目标地址并做负载均衡和调用。

国外知名电商网站 eBay，虽然体量巨大，但其内部的服务发现机制仍然是基于这种传统的集中代理模式，国内公司如携程，也是采用这种模式。

模式二：客户端嵌入式代理

 

这是很多互联网公司比较流行的一种做法，代理 (包括服务发现和负载均衡逻辑) 以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。

Netflix 开源的 Eureka(注册中心)[附录 1] 和 Ribbon(客户端代理)[附录 2] 是这种模式的典型案例，国内阿里开源的 Dubbo 也是采用这种模式。

模式三：主机独立进程代理

这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同模式二。

 

阿里、微博、摩拜、唯品会等公司都在积极探索Service Mesh的架构模式，只是在实践中一般具备一定开发能力的公司都会选择基于Istio进行二次开发，如目前阿里开源的SOFAMesh/SOFAMosn两个项目。

 

 Service Mesh（服务网格）

 

 Service Mesh又称为服务网格，本质上就是我们前面介绍过的模式三。之所为称之为服务网格是因为按照模式三的结构，每个主机上同时运行了业务逻辑代码和代理，此时这个代理被形象地称之为SideCar（业务代码进程相当于主驾驶，共享一个代理相当于边车），服务之间通过SideCar发现和调用目标服务，从而形成服务之间的一种网络状依赖关系，然后通过独立部署的一种称之为控制平面（ControlPlane）的独立组件来集中配置这种依赖调用关系以及进行路由流量调拨等操作，如果此时我们把主机和业务逻辑从视觉图上剥离，就会出现一种网络状的架构，服务网格由此得名。

 

在新一代的Service Mesh架构中服务消费方和提供方的主机（或容器）两边都会部署代理SideCar，此时SideCar与服务所在的主机又称之为数据平面（DataPlane），与我们前面说到的用于依赖关系配置和流量调拨操作的控制平面相对应。

 

Istio

 

通过上述的内容，我们从概念上应该是大概理解了什么是Service Mesh。而具体要落地Service Mesh只有概念是远远不够的，相反，如果没有一种可落地执行的开源框架，这个概念也不会这么快被大家所接受。

 Istio就是目前受Google/IBM 等大厂支持和推进的一个 ServiceMesh开源框架组合。它解决了开发人员和运维人员在整体应用程序向分布式微服务体系结构过渡时所面临的挑战。我们知道无论是基于SpringCloud的微服务架构体系还是目前我们说到的Service Mesh，随着微服务规模的增长会带来很多的复杂性，如服务发现、负载均衡、故障恢复、监控,甚至A/B测试、访问控制等。而要对涉及这些问题的微服务架构体系进行管理，如果没有成熟的组件的话，就会需要耗费很多的精力去开发一些运维工具，而这个成本是非常高的。

 

而Istio则提供了一个完整的解决方案来满足微服务应用程序的各种需求。下图是Istio官网（https://istio.io）所展示的关于Istio的一张架构图：

 

 

在这张架构图中Istio服务网格在逻辑上还是分为数据平面和控制平面。数据平面中的SideCar代理是由一款叫做Envoy的组件来承担的，它是一款用C++开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。

 

Envoy提供了很多内在的特性如：

• 动态服务发现

• 负载均衡

• TLS终止

• HTTP/2和gRPC代理

• 熔断器

• 健康检查

• 基于百分比的流量分割

• 故障注入

• 丰富的指标

 

从上面的特性上看实际上Envoy已经提供了很完备的SideCar的功能，只是由于其采用的是C++开发的，目前在国内的落地实践中会有不同的取舍和选择，如蚂蚁金服内部在实践的过程中就没有使用Istio默认集成的Envoy，而是用 Golang 开发了新的 Sidecar，已经开源的SOFAMosn，来替代 Envoy。

 

在Istio控制平面中的各个组件的作用如下：

• Mixer：负责收集代理上采集的度量数据，进行集中监控；

• Pilot：主要为SideCar提供服务发现、智能路由（如A/B测试）、弹性（超时、重试、断路器）的流量管理功能；

• Citadel：负责安全控制数据的管理和下发；

 

以上就是关于Istio及其组件的一些介绍，具体如何使用Istio进行服务开发及安装操作，大家可以看看Istio的官网，另外需要强调的是kubernetes是目前 Isito 主力支持的容器云环境。

 

Service Mesh的优势

 

事实上Service Mesh这种架构模式并不新鲜，很早就有公司进行过尝试，之所以最近又火起来的原因，主要还是因为模式一、模式二的确有一些固有的缺陷，模式一相对比较重，有单点问题和性能问题。

 

而模式二则有客户端复杂，支持多语言困难，路由、熔断、限流等服务操作无法集中治理的问题。而Service Mesh则正好弥补了二者的不足，它是纯分布式的，没有单点的问题，性能也比较优秀并且与开发语言无关，还可以集中进行治理。

 

此外，随着微服务化、多语言和容器化的发展趋势，很多公司也迫切需要一种轻量级的服务发现机制，加上一些大厂如Google/IBM的助推（如kubernetes与Docker的容器之争），正好Service Mesh迎合了这种趋势，所以才有今天火热的局面。
 

三种服务发现模式的比较

上面介绍的三种服务发现模式各有优劣，没有绝对的好坏，可以认为是三种不同的架构风格，在不同的公司都有成功实践。下表总结三种服务发现模式的优劣比较，业界案例和适用场景建议，供架构师选型参考

 

服务网格ServiceMesh

所谓的ServiceMesh，其实本质上就是上面提到的模式三~主机独立进程模式，这个模式其实并不新鲜，业界(国外的Airbnb和国内的唯品会等)早有实践，那么为什么现在这个概念又流行起来了呢？我认为主要原因如下：
 

ServiceMesh其实并不是什么新东西，本质就是上面提到的服务发现模式三~主机独立进程模式，这个模式很早就有公司在探索和实践，但是一直没有普遍流行起来，说明这个模式也是存在落地挑战的。从表面上看，模式三是模式一和模式二的折中，同时解决了模式一和模式二存在的问题，但是在每个主机上独立部署一个代理进程，是有很大运维管理开销的，一方面是规模化部署的问题(考虑服务很多，机器也很多的场景)；另一方面是如何监控治理的问题，代理挂了怎么办？你的团队是否具备自动化运维和监控的能力？另外开发人员在服务调试的时候，会依赖于这个独立的代理，调试排错比较麻烦，这个问题怎么解决？

Istio的确做了一些标准化工作，但是没有什么特别的创新，可是说换汤不换药，就是把模式三规范化和包装了一下。透过现象看本质，Google/IBM等行业大厂在背后推Isito/ServiceMesh，背后有一些市场利益诉求考虑，例如Google要推进它的kubernates和公有云生态。

ServiceMesh在年初声音比较大，最近渐渐安静下来，我听到国内只有一些大厂(华为，新浪微博，蚂蚁金服等)在试水，实际生产级落地的案例聊聊无几。大多数企业对ServiceMesh只是观望，很多架构师对ServiceMesh实际落地都存在疑虑。

所以我的个人建议，对于大部分企业(一般运维和研发能力不是特别强)，采用模式一~集中代理模式就足够了。这个模式比较传统不新鲜，但是在很多一线企业已经切实落地，我甚至认为，除了一些大厂，大部分中小企业的服务发现架构采用的就是集中代理。我本人经历过三家互联网公司，大的有eBay，中等有携程，小的有拍拍贷，都是采用集中式代理模式，而且玩得都很好。我的架构理念很简单，对于生产级应用，不追新，老实采用大部分企业落地过的方案。

模式一的最大好处是集中治理，应用不侵入，语言栈无关，另外因为模式一是集中部署的，不像模式三是分布式部署，所以模式一的运维开销也远小于模式三。对于模式一，大家最大的顾虑是性能和单点问题，其实性能还是OK的，如果架构和容量规划合理的话，实际生产中经过集中代理的性能开销一般可以控制在小于10个ms，eBay和携程等大流量企业的成功实践已经验证了这点。单点问题一般建议采用两层负载结构，例如硬件F5+软件nginx两层负载，F5以主从HA部署，nginx则以集群多实例部署，这种架构兼顾了高可用和配置的灵活性。

另外，模式一还可以和服务注册中心结合，从而降低手工配置的复杂性，实现DevOps研发自助部署，一种方案如下图所示：

 

 

服务启动时自动注册到服务注册中心并定期报心跳，Proxy则定期到服务注册中心同步实例。这种方式下，不需要为每个服务申请一个域名，只需一个泛域名即可，消费者访问服务时采用服务名+泛域名即可，整个服务上线流程可以做到DevOps研发自助。目前社区流行的一些开源代理如traefik[附录7]和kong[附录8]等都支持和多种服务注册中心(Consul/Eureka/Etcd/Zookeeper等)进行集成。目前这种方案在拍拍贷有初步成功实践，采用kong[附录7]和自研服务注册中心Radar[附录8]，同时和容器云调度平台配合，实现了研发全自助式发布上线。

结论

1. 服务注册发现和负载均衡是微服务架构在技术上的根本问题，解决的办法是采用代理Proxy。根据代理在架构上的位置不同，服务发现代理一般有三种模式：

模式一：集中式代理

模式二：客户端嵌入式代理

模式三：主机独立进程代理 这三种模式没有绝对的好还之分，只是三种不同的架构风格，各有优劣和适用场景，在不同企业都有成功落地案例。

2. ServiceMesh本质上就是模式三~主机独立进程代理，它结合了模式一和模式二的优势，但是分布式部署运维管理开销大。Istio对ServiceMesh的架构、功能和API进行了标准化。

3. ServiceMesh还在演进中，生产落地仍有挑战，一般企业不建议生产级使用。集中式代理最成熟，对于一般中小企业，建议从集中式代理开始，等达到一定规模和具备一定的研发运维能力，再根据需要考虑其它服务发现模式。

4. 架构师不要盲目追新，在理解微服务架构原理的基础上，可以学习和试点新技术，但是对于生产级应用，应该以成熟稳定，有大规模落地案例作为选型第一准则。

------------- 「 Service Mesh 」的原理与应用？ -------------

 

Service Mesh 的核心其实就2个模块：SideCar 与  Control Plane，如图：

搞懂了 SideCar 与  Control Plane 也就对 Service Mesh 的基础思想原理明白了。

1. SideCar：

   上面说到的与服务部署在一起的轻量级网络代理也就是指SideCar，它的作用就是实现服务框架的各项功能，这样，就可以让服务（Service A 或 Service B）回归业务本质。

   传统的微服务架构中，各种服务框架的功能（例如：服务发现、负载均衡、限流熔断等）都代码逻辑或多或少的都需要耦合到服务实例的代码里，给服务实例增加了很多无关业务的代码，也带来了复杂度。

   有了SideCar之后，服务节点只做业务逻辑自身的功能，服务之间的调用交给了SideCar，由SideCar去注册服务、去做服务发现、去做请求路由、去实现熔断限流、去做日志统计。

   那么在这种新的微服务架构中，所有的 SideCar 组成在一起，其实就是一个服务网格了。那么这个大型的服务网格并不是完全自治的，它还需要一个统一的控制节点，也就是 Control Plane。

2. Control Plane：

   

   Control Plane 是用来从全局的角度上控制 SideCar 的。比如 它负责所有 SideCar 的注册，它存储一个统一的路由表，帮助各个 SideCar 进行负载均衡和请求调度。它收集所有 SideCar 的监控信息和日志数据。它就相当于 Service Mesh架构 的大脑。Control Plane 控制着 SideCar 来实现服务治理的各项功能。

在文章的最开始提到过，以 Linkerd 为代表的被称为第一代 Service Mesh，而以 Istio 为代表的称为了第二代 Service Mesh。主要的不同就是 Istio 引入了 Control Plane 的概念，可以通过  Control Plane 来对服务进行一些精细化控制，所以 Istio 也被称为是实际上的 Service Mesh 标准产品。

 

参考资料：
https://www.jianshu.com/p/27a742e349f7
https://blog.csdn.net/zl1zl2zl3/article/details/84440685