微服务自2014年3月由Martin Fowler首次提出以来，在Spring Cloud、Dubbo等各类微服务框架的帮助下，以燎原之势席卷了整个IT技术界，成为了最主流的分布式应用解决方案。但仍然还有很多问题没有得到根本性的解决，比如技术门槛高、多语言支持不足、代码侵入性强等。如何应对这些挑战成为了下一代微服务首要回答的问题。直到服务网格（Service Mesh）被提出，这一切都有了答案。

1 微服务之殇

时光回到2017年初，那时所有主流的微服务框架，不管是类库性质的Finagle、Hystrix，还是框架性质的Spring Cloud、Dubbo，本质上都归于应用内解决方案，都存在以下三个问题：

• 技术门槛高：随着微服务实施水平的不断深化，除了基础的服务发现、配置中心和授权管理之外，团队将不可避免的在服务治理层面面临各类新的挑战，包括但不限于分布式跟踪、熔断降级、灰度发布、故障切换等，这对团队提出了非常高的技术要求。

• 多语言支持不足：对于稍具规模的团队，尤其在高速成长的互联网创业公司，多语言的技术栈是常态，跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。
• 代码侵入性强：主流的微服务框架（比如Spring Cloud、Dubbo）或多或少都对业务代码有一定的侵入性，框架替换成本高，导致业务团队配合意愿低，微服务落地困难。

这些问题加起来导致的结果就是，在实施微服务的过程中，小团队Hold不住，大公司推不动。

2 另辟蹊径

如何解决上述三个问题呢？最容易想到的是代理模式，在LB层（比如Nginx、Apache HTTP Server）处理所有的服务调用，以及部分服务治理问题（比如分布式跟踪、熔断降级）。但这个方案有两个显著的缺点，第一，中心化架构，代理端自身的性能和可用性将是整个系统的瓶颈；第二，运维复杂度高，业务团队笑了，运维团队哭了。

难道这就是桃园吗？

服务网格（Service Mesh）应运而生！自2016年9月Linkerd第一次公开使用之后，伴随着Linkerd、Envoy、Istio、NGINX Application Platform、Conduit等新框架如雨后春笋般不断涌现，在微服务之后，服务网格和它的边车（Sidecar）模式引领了IT技术界2017一整年的走向。

3 服务框架选型

服务框架是一个比较成熟的领域，有太多可选项。 Spring Boot/Cloud 由于Spring社区的影响力和Netflix的背书，目前可以认为是构建Java微服务的一个社区标准，Spring Boot目前在github上有超过20k星。基于Spring的框架本质上可以认为是一种RESTful框架（不是RPC框架），序列化协议主要采用基于文本的JSON，通讯协议一般基于HTTP。RESTful框架天然支持跨语言，任何语言只要有HTTP客户端都可以接入调用，但是客户端一般需要自己解析payload。目前Spring框架也支持Swagger契约编程模型，能够基于契约生成各种语言的强类型客户端，极大方便不同语言栈的应用接入，但是因为RESTful框架和Swagger规范的弱契约特性，生成的各种语言客户端的互操作性还是有不少坑的。

Dubbo是阿里多年构建生产级分布式微服务的技术结晶，服务治理能力非常丰富，在国内技术社区具有很大影响力，目前github上有超过16k星。Dubbo本质上是一套基于Java的RPC框架，当当Dubbox扩展了Dubbo支持RESTful接口暴露能力。Dubbo主要面向Java 技术栈，跨语言支持不足是它的一个弱项，另外因为治理能力太丰富，以至于这个框架比较重，完全用好这个框架的门槛比较高，但是如果你的企业基本上投资在Java技术栈上，选Dubbo可以让你在服务框架一块站在较高的起点上，不管是性能还是企业级的服务治理能力，Dubbo都做的很出色。新浪微博开源的Motan（github 4k stars）也不错，功能和Dubbo类似，可以认为是一个轻量裁剪版的Dubbo。

gRPC是谷歌近年新推的一套RPC框架，基于protobuf的强契约编程模型，能自动生成各种语言客户端，且保证互操作。支持HTTP2是gRPC的一大亮点，通讯层性能比HTTP有很大改进。Protobuf是在社区具有悠久历史和良好口碑的高性能序列化协议，加上Google公司的背书和社区影响力，目前gRPC也比较火，github上有超过13.4k星。目前看gRPC更适合内部服务相互调用场景，对外暴露HTTP RESTful接口可以实现，但是比较麻烦（需要gRPC Gateway配合），所以对于对外暴露API场景可能还需要引入第二套HTTP RESTful框架作为补充。总体上gRPC这个东西还比较新，社区对于HTTP2带来的好处还未形成一致认同，建议谨慎投入，可以做一些试点。

4 服务网格

4.1 元定义

首先，我们来看一下服务网格的提出者William Morgan是如何描述它的。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. Consists of a control plane and data plane (service proxies act as “mesh”). - William Morgan, What’s a Service Mesh? And Why Do I Need One?

上面这段话非常清晰的指明了服务网格的职责，即处理服务间通讯，这正是服务治理的核心所在。而a dedicated infrastructure layer这几个单词将服务网格和之前所有的微服务框架（framework）划清了界限，也即服务网格独立于具体的服务而存在，这从根本上解决了前文提到的老的微服务框架在多语言支持和代码侵入方面存在的问题。并且，由于服务网格的独立性，业务团队不再需要操心服务治理相关的复杂度，全权交给服务网格处理即可。

那你可能会问，这不跟之前提到的代理模式差不多吗？区别在于服务网格独创的边车模式。针对每一个服务实例，服务网格都会在同一主机上一对一并行部署一个边车进程，接管该服务实例所有对外的网络通讯（参见下图）。这样就去除了代理模式下中心化架构的瓶颈。同时，借助于良好的框架封装，运维成本也可以得到有效的控制。

4.2 演化史

追本溯源，服务网格从无到有可分为三个演化阶段（参见下图）。第一个阶段，每个服务各显神通，自行处理对外通讯。第二个阶段，所有服务使用统一的类库进行通讯。第三个阶段，服务不再关心通讯细节，统统交给边车进程，就像在TCP/IP协议中，应用层只需把要传输的内容告诉TCP层，由TCP层负责将所有内容原封不动的送达目的端，整个过程中应用层并不需要关心实际传输过程中的任何细节。

4.3 时间线

最后，再来回看一下服务网格年轻的历史。虽然服务网格的正式提出是在2016年9月，但其实早在2013年，Airbnb就提出了类似的想法——SmartStack，只不过SmartStack局限于服务发现，并没有引起太多关注，类似的还有Netflix的Prana和唯品会的OSP Local Proxy。2016年服务网格提出之后，以Linkerd和Envoy为代表的框架开始崭露头角，并于2017年先后加入CNCF基金（Cloud Native Computing Foundation），最终促使了一代新贵Istio的诞生。2018年，Istio将发布1.0版本，这也许意味着微服务开始进入2.0时代。

5 后台服务选型

后台服务主要包括消息系统，分布式缓存，分布式数据访问层和任务调度系统。后台服务是一个相对比较成熟的领域，很多开源产品基本可以开箱即用。

消息系统，对于日志等可靠性要求不高的场景，则Apache顶级项目 Kafka 是社区标配。对于可靠性要求较高的业务场景，kafka其实也是可以胜任，但企业需要根据具体场景，对 Kafka的监控和治理能力进行适当定制完善，Allegro公司开源的 hermes 是一个可参考项目，它在Kafka基础上封装了适合业务场景的企业级治理能力。阿里开源的 RocketMQ也是一个不错选择，具备更多适用于业务场景的特性，目前也是Apache顶级项目。 RabbitMQ是老牌经典的MQ，队列特性和文档都很丰富，性能和分布式能力稍弱，中小规模场景可选。

对于 缓存治理 ，如果倾向于采用客户端直连模式（个人认为缓存直连更简单轻量），则SohuTv开源的 cachecloud 是一款不错的Redis缓存治理平台，提供诸如监控统计，一键开启，自动故障转移，在线伸缩，自动化运维等生产级治理能力，另外其文档也比较丰富。如果倾向采用中间层Proxy模式，则Twitter开源的 twemproxy和CodisLab开源的 codis是社区比较热的选项。

对于 分布式数据访问层 ，如果采用Java技术栈，则当当开源的 shardingjdbc是一个不错的选项，分库分表逻辑做在客户端jdbc driver中，客户端直连数据库比较简单轻量，建议中小规模场景采用。如果倾向采用数据库访问中间层proxy模式，则从阿里Cobar演化出来的社区开源分库分表中间件 MyCAT是一个不错选择 。proxy模式运维成本较高，建议中大规模场景，有一定框架自研和运维能力的团队采用。

任务调度系统，个人推荐徐雪里开源的 xxl-job，部署简单轻量，大部分场景够用。当当开源的 elastic-job也是一个不错选择，相比xxl-job功能更强一些也更复杂。

6 架构技术范围

为解决单体架构下的各种问题，微服务架构应运而生。与其构建一个臃肿庞大、难以驯服的怪兽，还不如及早将服务拆分。微服务的核心思想便是服务拆分与解耦，降低复杂性。微服务强调将功能合理拆解，尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。 将各个服务做轻，从而做到灵活、可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。

微服务技术是程序员绕不开的话题，在这里给大家推荐一个交流学习群：650385180，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，以下的课程体系图也是在群里获取。相信对于已经工作和遇到技术瓶颈的码友，在这个群里会有你需要的内容。

7 小结

以上就是我对服务网格的一些简单介绍，欢迎留言交流，和大家一起过过招。