2018微服务年之服务网格Service Mesh

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

1 微服务之殇

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

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

多语言支持不足：对于稍具规模的团队，尤其在高速成长的互联网创业公司，多语言的技术栈是常态，跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。

代码侵入性强：主流的微服务框架（比如Spring Cloud、Dubbo）或多或少都对业务代码有一定的侵入性，框架替换成本高，导致业务团队配合意愿低，微服务落地困难。

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

2 另辟蹊径

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

服务网格是一个用于改进服务与服务之间的通信的基础架构层[1]，也是目前最流行的原生云类别。随着容器变得越来越普遍，服务拓扑变得越来越动态，需要更先进的网络功能。服务网格可以通过服务发现、路由、负载均衡、健康检查和可观察性来帮助管理流量。服务网格试图驯服难以控制的容器复杂性。

随着像HAProxy、Træfik和NGINX这样的负载均衡器开始重新定位为数据平面，它的服务网格变得越来越受欢迎。我们还没有看到广泛的部署，但确实知道在生产环境中运行服务网格的业务。此外，服务网格并不仅限于微服务或Kubernetes环境，还可以应用于VM和Serverless环境。例如，国家生物技术信息中心不是运行容器，而是使用Linkerd。

服务网格也可用于混沌工程，“在分布式系统上进行实验的规程，以建立对系统抵御混乱状况能力的信心[2]。”服务网格不需要在每个主机上安装一个守护进程，而是将延迟和失败注入到环境中。

2017 年的 Service Mesh 市场，从 Linkerd 的风光无限开始，到 Istio 的横空出世，最后止于 Conduit 的绝地反击，可谓一波三折；产品也经历从第一代的 Linkerd/Envoy，跨越性的演化出第二代的 Istio/Conduit；同时，技术社区的态度也从年初的逐步接受发展到年底的热烈追捧，下面这张 KubeConf 上的图片非常有代表性地展示了社区的热切期望：

以下是广告内容

你好，我是胡忠想，微博技术专家。从2012年加入微博到现在，我一直在做微博首页信息流的相关业务研发，几乎亲历了微博后端架构的每一次重大升级。不仅参与了微博后端架构从大的单体应用迁移到微服务架构的改造；还作为主要负责人之一，主导了微服务架构在公司多个业务线的推广和落地。所以谈到将微服务落地，我有很多实战干货和你分享