一、微服务的“痛点”

但微服务化易弄，服务治理难搞！
微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、apache thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。

微服务治理是头疼的事，也是微服务架构中的痛点。对于微服务而言，治理体现在以下诸多方面：

服务注册与发现
 
身份验证与授权
 
服务的伸缩控制
 
反向代理与负载均衡
 
路由控制
 
流量切换
 
日志管理
 
性能度量、监控与调优
 
分布式跟踪
 
过载保护
 
服务降级
 
服务部署与版本升级策略支持
 

错误处理

二、Service Mesh

独立地抽象出一层逻辑网络，专门用于“微服务通信与治理策略的落地”，让应用只关心业务，把服务治理的事情全部交由“这一层”去处理。
由“Service Govern Logic”这一层组成的逻辑网络被定义为Service Mesh，每个微服务都包含一个Service Mesh的端点。
Service Mesh是专用的基础设施层。
轻量级高性能网络代理。
提供安全的、快速的、可靠地服务间通讯。

与实际应用部署一起，但对应用透明。

传统微服务之间的微服务治理逻辑的位置：

微服务治理逻辑被独立出来之后的位置：

下图展示了服务网格的部署方式：

三、Istio

Istio项目是Service Mesh概念的最新实现，旨在所有主流集群管理平台上提供Service Mesh层，初期以实现Kubernetes上的服务治理层为目标。它由控制平面和数据平面组成（是不是感觉和SDN的设计理念相似啊）。控制平面由Go语言实现，包括pilot、mixer、auth三个组件；数据平面功能暂由Envoy在pod中以Sidecar的部署形式提供。下面是官方的架构图：





Sidecar中Envoy代理了pod中真正业务container的所有进出流量，并对这些流量按照控制平面设定的“治理逻辑”进行处理。而这一切对pod中的业务应用是透明的，开发人员可以专心于业务逻辑，而无需再关心微服务治理的逻辑。Istio代表的Service Mesh的设计理念被认为是下一代“微服务统一框架”，甚至有人认为是微服务框架演化的终点。