如果不懂Service mesh，就不要谈微服务了

提到微服务，spring cloud等经典框架被使用的最为广泛，但是在2016年才被提起的Service Mesh，已经被Paypal、Lyft、Ticketmaster和Credit Karma等等一些大流量平台所使用，在生产应用中添加了Service mesh。今年随着Linkerd传入国内，Service mesh才在国内的技术社区里出现，而与此同时，2017年1月份Service mesh成为CNFC的官方项目。

那么，什么是Service mesh

Service mesh被用来处理服务间通讯的专用基础设施层，通过复杂的拓扑结构让请求传递的过程变得更可靠，这些服务成为新一代云原生应用程序。

在实际应用中，Service mesh通常作为一组轻量级高性能网络代理，这些代理和程序代码部署在一起，但是应用程序不需要对代理有任何动作。

Service mesh作为单独层的概念与云原生应用程序的大规模普及有关。 在云原生模型中，单个应用程序可能包含数百个服务; 每个服务可能又包含数千个实例;并且这些实例中的每一个都可能处于不断变化的状态，因为它们是由像Kubernetes这样的服务协调程序动态调度的。世界上的服务通讯不仅极其复杂，而且是运行时行为（runtime behavior）的一个普遍和基本的组成部分。管理好它对于确保端到端性能和可靠性是至关重要的。

Service mesh是网络模型

Service mesh是一个网络模型，它是位于TCP/IP之上的抽象层。它假定底层的L3/L4网络是真实存在的，并且能够点对点地传递字节。(它还假定了这个网络像运行环境的其他方面一样，是不可靠的； 因此，Service mesh必须能够处理网络故障。)

Service mesh在某些方面其实是类似于TCP/IP。就像TCP栈抽象出了网络端点之间可靠传递字节的机制一样，Service mesh在服务之间可靠地传递请求的机制也是抽象的。与TCP相同的是，Service mesh并不关心实际的有效负载，也不关心它的编码问题。应用程序有一个高级目标(“从A到B发送一些数据”)， Service mesh的职责，和TCP一样，是在这个数据的发送过程中解决故障并圆满完成数据发送。

但与TCP不同的是，Service mesh具有更高的性能，它的使命超越了“仅仅让它可以工作”， 并且有一个更重要的目标: 它提供了统一的、应用广泛的观点，应用程序在运行操作时具有可视性和可控性。Service mesh的明确目标是将服务通讯从不可见的、隐含的基础设施中抽离出来，在云原生系统中扮演重要的一级成员的角色,从而可对系统进行监控，管理和控制。

Service mesh能做什么

在云原生应用中可靠地传递请求可能非常复杂。 像Linkerd这样的Service mesh，通过一系列强大技术来管理这种复杂性: 链路熔断、延迟感知、负载均衡，eventually consistent (“advisory”) 服务发现，服务续约及下线与剔除。这些功能必须协同工作，而这些功能与它们所操作的复杂环境之间的交互作用是非常微妙的。

为什么要使Service mesh

Service mesh最终并不是引入一项新功能，而是功能定位的转变。Web应用程序总是必须管理服务间通信的复杂性。要想了解Service mesh模型的起源， 我们可以追溯过去15年以来的这些应用程序的发展历程。

你可以思考下2000年的中型web应用程序的典型架构: 三层应用程序。 在这个模型中，应用程序逻辑、web服务逻辑和存储逻辑都是单独的一层。 层之间的通信虽然复杂，但这种复杂性是限定在一定范围内，因为毕竟只有两个跳转。这里没有“网格”，但是在每个层的代码中处理的跳转之间有通信逻辑。

当这种架构方式在面对应用程序内部逻辑越来越复杂化的情形时，它就开始崩溃了。 像Google、Netflix和Twitter这样的公司无时无刻都面临着巨大的流量需求，它们实现了云原生方案的前身: 应用层被分解成许多服务(有时称为“微服务”)，层级间则形成了一个拓扑结构。 在这些系统中，广义的通讯层突然变得相关起来， 但通常以“胖客户端”的库集（library）形式出现， 比如twitter的Finagle，Netflix的Hystrix，以及Google的Stubby就是这样的例子。

从很多方面上来讲，像Finagle, Stubby和Hystrix这些库集其实是Service mesh的雏形。虽然它们受其周围环境的细节影响，并且需要使用特定的语言和框架，但是它们是用于管理服务到服务间通信的专用基础设施，并且(在开源Finagle和 Hystrix库集的情形下)可以在其公司之外使用。

到了云原生应用时期， 云原生模型本身结合了许多小型服务的微服务方法和两个额外的因素:容器(例如Docker)，它提供了资源隔离和依赖关系管理，以及一个编排层(例如Kubernetes)，它将底层硬件抽象出了一个同质池。

这三个组件支持应用程序在负载下可弹性伸缩的自然机制， 并能够处理云平台环境中存在的部分故障。

但面对数百个服务或数千个实例，和随时在重新安排实例的编排层，单个请求经由服务拓扑的路径可能非常复杂， 而由于容器使每个服务用不同的语言写入处理变得更容易了，库集方法也就不再可行了。

这种复杂性和关键性的结合，激发了对服务到服务间通信的专用基础层的需求，这个专用层与应用程序代码分离出来，并能够捕捉底层环境的高度动态特性。就是这一专用层我们称之为Service mesh。

学习Service mesh有哪些资料？

1.入门级资料

什么是Service Mesh（服务网格）

https://jimmysong.io/posts/what-is-a-service-mesh/

Pattern: Service Mesh

//philcalcado.com/2017/08/03/pattern_service_mesh.html

中文翻译：

//www.infoq.com/cn/articles/pattern-service-mesh

What is Istio? It’s a service mesh. Great. What’s a service mesh?

https://www.mirantis.com/blog/what-is-istio-its-a-service-mesh-whats-a-service-mesh

https://www.slideshare.net/dbryant_uk/oreilly-2017-introduction-to-service-meshes

Google、IBM和Lyft开源的微服务管理框架Istio简介

//dockone.io/article/2397

2.Service mesh热点文章

万字解读:Service Mesh服务网格新生代--Istio https://zhuanlan.zhihu.com/p/29586032

再谈 Kubernetes，微服务以及 Service Mesh

//baijiahao.baidu.com/s?id=1579758778464216551

系列文章：A SERVICE MESH FOR KUBERNETES

1.Top-line service metrics https://buoyant.io/a-service-mesh-for-kubernetes-part-i-top-line-service-metrics/

2.Pods are great, until they’re not https://buoyant.io/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/

3.Encrypting all the things https://buoyant.io/a-service-mesh-for-kubernetes-part-iii-encrypting-all-the-things/

4.Continuous deployment via traffic shifting

5.Dogfood environments, ingress, and edge routing

6.Staging microservices without the tears

7.Distributed tracing made easy

8.Linkerd as an ingress controller

9.gRPC for fun and profit

10.The Service Mesh API

11.Egress (this article) https://buoyant.io/2017/06/20/a-service-mesh-for-kubernetes-part-xi-egress/

12.Retry budgets, deadline propagation, and failing gracefully

13.Autoscaling by top-line metrics

部分中文翻译：

Kubernetes的service mesh——第一部分：Service的重要指标

//blog.csdn.net/hty46565/article/details/78179005

Kubernetes的service mesh——第二部分：以DaemonSet方式运行linkerd

//blog.csdn.net/hty46565/article/details/78188434

Kubernetes的service mesh——第三部分：将一切加密

//blog.csdn.net/hty46565/article/details/78210626

Kubernetes与云原生应用概览

//www.infoq.com/cn/articles/kubernetes-and-cloud-native-app-overview

NGINX 发布微服务平台、OpenShift Ingress Controller 和Service Mesh预览版

//www.infoq.com/cn/news/2017/09/nginx-platform-service-mesh

3.Service mesh可以参考的项目

Istio

https://istio.io/

IBM、Google、Lyft支持的一个开源的微服务连接、管理平台，并给微服务提供安全管理，支持Kubernetes、Mesos等容器管理工具，其底层依赖于Envoy。

Linkerd

https://linkerd.io/

Buoyant开发，基于Twitter的Fingle，经过长期的实际产线运行经验及验证，支持Kubernetes、DC/OS容器管理平台，也是CNCF官方支持的项目之一。据说其CEO就是service mesh概念的提出者，官方博客有很多高质量的文章，几篇网络热文均出自他们。

Envoy

https://www.envoyproxy.io/

Lyft开发，7层代理及通信总线，支持7层HTTP路由、TLS、gRPC、服务发现以及健康监测等。

原文：http://dy.163.com/v2/article/detail/D2AKGNHU0518NIIT.html

---

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com