微服务进入2.0时代

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

1 微服务之殇

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

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

图片出处：Service Mesh：下一代微服务（https://servicemesh.gitbooks.io/awesome-servicemesh/mesh/2017/service-mesh-next-generation-of-microservice/）

多语言支持不足：对于稍具规模的团队，尤其在高速成长的互联网创业公司，多语言的技术栈是常态，跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。
代码侵入性强：主流的微服务框架（比如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?（https://dzone.com/articles/whats-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?（https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one）

3.2 演化史

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

图片出处：Pattern: Service Mesh（http://philcalcado.com/2017/08/03/pattern_service_mesh.html）

3.3 时间线

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

图片出处：Service Mesh：下一代微服务（https://servicemesh.gitbooks.io/awesome-servicemesh/mesh/2017/service-mesh-next-generation-of-microservice/）

4 小结

以上就是我对服务网格的一些简单介绍，欢迎你到我的留言板（https://github.com/emac/emac.github.io/issues/2）留言交流，和大家一起过过招。下一篇我会教大家如何在本地从零搭建一个基于Istio的服务网格，敬请期待。

5 参考

What’s a Service Mesh? And Why Do I Need One?（https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one）
Pattern: Service Mesh（http://philcalcado.com/2017/08/03/pattern_service_mesh.html）
Awesome Service Mesh（https://servicemesh.gitbooks.io/awesome-servicemesh/）
Service Mesh：下一代微服务（https://servicemesh.gitbooks.io/awesome-servicemesh/mesh/2017/service-mesh-next-generation-of-microservice/）
解读2017之Service Mesh：群雄逐鹿烽烟起（http://www.infoq.com/cn/articles/2017-service-mesh?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=%E6%9E%B6%E6%9E%84%20&%20%E8%AE%BE%E8%AE%A1-articles）

出处：http://emacoo.cn/arch/service-mesh-overview/

转载至21CTO

分割线