背景
单体服务的痛点导致单体服务被拆分为多个微服
每个微服必须要解决负载均衡、服务发现、熔断等功能
为了让上层开发更加快速和无需关注通用能力，在网络栈和应用业务层之间抽出一个透明网络代理层。
Service Mesh
轻量级网络代理，负责微服之间的通信（HTTP、TCP、gRPC），包含控制面（控制服务如何通信）和数据面（可靠交付应用请求），是一个位于网络栈和业务层之间的独立基础设施层。
它虽然和业务应用部署在一起，但对业务透明，业务层无需感知。
功能
负载均衡
所有请求对Mesh层可见，提供负载均衡算法实现流量分发，降低整体时延
服务发现
基于DNS/KV存储的服务发现，提供简单、统一、平台无关的服务发现（新部署一个服务/下掉一个服务）
熔断
某个实例发生服务中断时，快速监测并从负载均衡池中移除异常实例；避免后续请求无效地继续请求该实例。
动态路由
目的：服务的高可用、高稳定、高SLA
目标：解决部署时导致的服务中断和稳定性下降问题
解决问题：将服务从a版本切到b版本；将流量从线上隔离环境切到线上环境等
Mesh层通过动态路由机制+蓝/绿部署或者canary金丝雀部署，实现目标。
安全通信
Mesh层实现诸如TLS的加解密和服务访问控制
多语言
多协议
指标和分布式追踪
单个服务的运行指标、整个服务的运行指标
重试和最后期限
业务代码无需关注重试，无需将重试逻辑写入业务层，由Mesh层负责有限次的重试（最后期限对应一次请求的最长生命周期）
性能
可见性
运行时指标、分布式跟踪
可管理性
服务发现、负载均衡、运行时动态路由
健壮性
超时重试、请求最后期限、熔断
安全性
服务访问控制、TLS加密
相关产品
Linkerd
高性能网络代理程序，使用scala语言，运行于JVM
每秒可处理万级请求，易于水平扩展
代理
twitter的Finagle库
熔断
基于连接的熔断器
基于请求的熔断器
服务发现
基于文件的服务发现
基于consul的服务发现
基于zookeeper的服务发现
基于kubernetes的服务发现
部署模式
sidecar
per-host
协议
http/1.x http/2.x gRPC
负载均衡
轮询
最小负载等
附录
什么是sidecar
传统形态下，SDK代表着一个特定语言的库、工具包等，由应用程序和微服务框架（比如dubbo）共处同一个进程，在发布升级中共享生命周期，同时发布，同时升级。
sidecar方案下没有引入新的功能，调用的拓扑也没有改变，只是改变了原有功能的位置，以独立的应用来存在。
Sidecar是一种设计模式，概念上指将应用的一部分功能从应用本身剥离出来作为单独进程的实现方式。该种模式支持以无侵入的方式向应用添加多种功能，同时也实现了多个应用的公共部分实现与每个应用的自有部分实现解耦的目的，因此目前广泛应用于微服务领域。
Sidecar模式对于构建高度高度可伸缩、可扩展、安全且可便于监控的微服务架构系统至关重要。Sidecar模式降低了与微服务架构相关的复杂性，并提供了负载平衡、服务注册、服务发现、服务调用、流量管理、应用认证、遥测、故障注入等微服务都需要的基础功能特性。
Sidecar是独立部署的进程，降低了应用程序代码和底层代码的耦合度，帮助异构服务通过sidecar快速接入微服务体系。
异构服务本身不和注册中心有直接联系，所以异构服务的调用也需要走sidecar，通过sidecar进行服务发现调用，sidecar收到异构服务的请求后通过服务发现和负载均衡选中目标服务实例，转发请求至目标服务。
在ServiceMesh架构中，给每一个微服务实例部署一个SidecarProxy。该SidecarProxy负责接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流、降级、分布式跟踪等功能从服务中抽离到该Proxy中。
Sidecar以一个独立的进程启动，可以每台宿主机共用同一个Sidecar进程，也可以每个应用独占一个Sidecar进程。所有的服务治理功能，都由Sidecar接管，应用的对外访问仅需要访问Sidecar即可。当该Sidecar在微服务中大量部署时，这些Sidecar节点自然就形成了一个服务网格。
微服务框架的痛点和改进
对于基础架构框架开发者来说存在痛点：面向开发者的模式：新加了功能需要使用框架的应用开发人员配合升级版本，比如要升级maven中的依赖版本号，重新打包发布应用程序，时间上受制于相应的业务应用。业务开发人员相对来说只考虑自身业务稳定等因素，对基础框架的升级具有天然的抗拒心理。
使用SideCar模式带来的改进：这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。两个优点：
1、面向运维：解耦了调用业务方和微服务，让它们具备不同发布/升级生命周期
2、SideCar作为一个代理，可以完成更多功能，比如跨语言、限流、负载均衡、灰度、熔断等都可以放到SideCar代理
缺点：
1、从调用方到服务方增加了两次调用，有性能上的损失。（针对这个做优化，物理机上所有应用跟SideCar之间虽然是跨进程，处于不同的JVM应用中，但它们处于同一台物理机，故它们之间的调用可以走内核态方式，整体性能的损失可以在1%以内，平均延迟1.5毫秒左右），理论上多一跳的平均性能损耗在1.5毫秒左右；
2、调用复杂度增加，问题排查难度加大
总结：
对于大规模部署微服务，内部服务异构程度高的场景，使用ServiceMesh方案是一个不错的选择。ServiceMesh实现了业务逻辑和控制的解耦，但是也带来了额外的开销，由于网络中多了一次调用，增加了性能的损耗和访问的延迟。同时，由于每个服务（一般每一台物理机）都需要部署Sidecar,这也会使本来就具有一定复杂度的分布式系统变得更加复杂。尤其是在实施初期，对ServiceMesh的管理和运维会是一个比较棘手的问题。
