就在微服务大热的时候Service Mesh（服务网格）也开始粉墨登场，今天我们来看看Service Mesh（服务网格）到底为我们解决了什么问题，我们是如何是用它的。
为什么需要Service Mesh
众所周知，微服务是对服务进行拆分，服务拆分以后就带来了一系列的问题。这些问题都是我们在单个服务时代没有遇到的，例如：负载均衡，服务注册发现，流量控制，熔断，服务跟踪，服务管理。这些都需要我们利用一系列的微服务组件来完成（例如：SpringCloud）。给我们的服务增加了很多网络通讯级别的代码。如果有一个架构可以让我们专注于业务本身的开发，摆脱网路通讯服务的束缚就好了，这时候Sidecar 就应运而生了。
Sidecar 设计刚好解决了这一点，它针对每个服务挂接了一个Sidecar专门用来负责服务之间的网络通讯，把上述的与网络相关的功能都整合到Sidecar中，让开发者专注于业务代码的开发。
Sidecar是Service Mesh中的一种链接方式，Service Mesh 更加强调将服务链接成网络，并且Service Mesh是通用的组件。如果调用方和被调用方都是用同一语言编写的通常会用直接链接的方式调用，否则会通过Sidecar 的方式来调用。而Service Mesh 会完全掌握所有的流量。上图这些服务通过Service Mesh通讯连成了一个网格结构，如上图绿色的部分就是服务，蓝色的部分就Service Mesh。
让我们在离近点看看Service Mesh，每个Sidecar（可选项） 都承载了服务发现和流量传输的工作，作为Service Mesh来说只是监控和管理着这一切的发生。我们彻底把网络传输层抽象以后交给了Service Mesh。而它是独立于业务逻辑的，Service Mesh的升级不会影响到业务逻辑。所有程序调用的入口都是Service Mesh，只要是支持REST请求的语言都可以调用服务。
Istio 实现 Service Mesh架构
Istio的架构有两部分组成
一. 数据平面，有上部分的Sidecar（Proxy）组成，主要负责调节和控制微服务于Mixer之间的网络通信。
二. 控制平面，下部分 Control Plane，主要负责管理和配置代理来路由流量。
Mixer 是独立于平台的组建，负责执行访问控制和使用策略，从代理和其他服务收集数据。
Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。
Citadel 通过内置身份和凭证管理赋能强大的服务间和最终用户身份验证。
Galley 代表其他的 Istio 控制平面组件，用来验证用户编写的 Istio API 配置。
閱讀更多 瘋狂的肉絲麵 的文章
