服务网格：微服务进入2.0时代

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

1 微服务之殇

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

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

图片出处：Service Mesh：下一代微服务

• 多语言支持不足：对于稍具规模的团队，尤为在高速成长的互联网创业公司，多语言的技术栈是常态，跨语言的服务调用也是常态，但目前开源社区上并无一套统一的、跨语言的微服务技术栈。
• 代码侵入性强：主流的微服务框架（好比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 服务网格

3.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）划清了界限，也即服务网格独立于具体的服务而存在，这从根本上解决了前文提到的老的微服务框架在多语言支持和代码侵入方面存在的问题。而且，因为服务网格的独立性，业务团队再也不须要操心服务治理相关的复杂度，全权交给服务网格处理便可。

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

图片出处：What's a Service Mesh? And Why Do I Need One?

3.2 演化史

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

图片出处：Pattern: Service Mesh

3.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时代。

图片出处：Service Mesh：下一代微服务

4 小结

以上就是我对服务网格的一些简单介绍，欢迎你到个人留言板留言交流，和你们一块儿过过招。下一篇我会教你们如何在本地从零搭建一个基于Istio的服务网格，敬请期待。

5 参考

• What's a Service Mesh? And Why Do I Need One?
• Pattern: Service Mesh
• Awesome Service Mesh
• Service Mesh：下一代微服务
• 解读2017之Service Mesh：群雄逐鹿烽烟起