前情提要
前段时间去QCon深圳2020大会围观了一下，听了一下大厂们当初在干的事件，后端这一块支流都在探讨云原生，当中美团分享了他们在Service Mesh架构下面的实际，集体感觉挺有价值，写篇博文记录一下

Service Mesh的演变历程

一个服务从我的项目一开始，通常会是一个简略的单体利用，一个利用提供了所需的所有服务，所有模块都蕴含在这个利用外面，随着需要的迭代，这个利用的模块数量越来越宏大，性能集成也越来越多，模块与模块之间在利用内强耦合，以致于到前期可能改一个小东西就可能会影响整个利用，导致线上事变

倒退到这个阶段，个别就要进行服务拆分了，从业务上进行划分，把实现同类性能的利用放到一组，通常状况下拆分之后业务与业务之间会有互相调用的需要，原先基于单个利用下的模块与模块之间的间接调用当初变成服务与服务之间的RPC调用，基于这个前提，在网络层面就衍生出了几个以后OSI 7层网络模型无奈反对的更高维度的问题

服务注册与服务发现

服务之间要实现互相调用，首先必须先找到对方，相似于DNS查找，通过名称查找到具体端点（IP+端口号），所以首先须要一个相似DNS的服务，充当注册核心，性能下面要求一个服务下面或者销毁的时候，注册核心要可能感知到这个事件，以便在第二步：服务发现的时候可能精确拿到可用的目标端点，通常的流程如下所示：

  1. 被调方向注册核心注册本人的地址
  2. 调用方向注册核心询问被调方的服务地址列表3. 向被调方发动申请最间接的方法，就是搞个DNS服务器，用来充当注册核心，然而DNS通常会有缓存，更新不会实时，而且服务注册除了“注册”这个动作，还须要有“销毁”的动作，否则一个节点挂了，DNS下面还保留着这个节点的信息，调用方发动调用将会失败，总体上DNS并不能完满胜任这种工作，须要想方法另外去解决
负载平衡

上图能够看到，被调方这个服务下能够有多个实例，散布在不同的主机上运行，事实中为了防止单点故障，基本上都会安排多个实例同时提供服务，这就导致调用方拿到的服务地址不是一条，而是一组列表，而怎么样从这组列表中选出一个端点来发动申请呢，这就须要调用方有负载平衡的能力，比方rr轮询，random随机拜访呢

熔断限流

微服务的集群下，每个服务负责不同的性能，一条申请进来可能会穿梭多个微服务，而如果在这当中，某些微服务呈现性能瓶颈，比方一些解决流程比较慢的服务，当并发申请量上来之后，可能就间接被打挂了，而这个服务恰好是一个要害门路，导致前端所有申请都报错，这时候就须要有一种爱护机制，可能在适当的时候对某些步骤进行降级操作，比方某个服务达到性能瓶颈之后进行熔断，不让申请进来，服务入口间接回绝拜访，等到这个服务复原可用的时候再把它加进来

平安

如果在一个不信赖的集群中，服务与服务之间可能还须要加密通信，这意味着单方要进行身份认证、密钥替换，身份认证须要一个权威的平安核心来颁发证书，否则可能会有中间人窃听，这些次要看业务须要的安全等级

以上这些问题，统称服务治理，基本上服务治理通过了三个阶段

第一阶段，在应用程序中蕴含治理逻辑

这个阶段，利用自身除了业务代码之外，还加进了治理逻辑局部的代码，利用自身亲自来解决服务发现、负载平衡等等问题，这种形式存在以下问题：

  1. 业务代码与治理逻辑强耦合，意味着开发者在实现业务的同时还必须去关怀这些治理的问题，无奈开发纯正的业务代码
  2. 存在大量反复的代码，集群内的所有服务的业务代码都得实现这样一套治理逻辑，保护艰难，搞不好一出bug还得所有服务都得改一遍
第二阶段，独立出治理逻辑SDK

为了解决耦合的问题，业务尝试把这些逻辑形象进去，独立成一个SDK库，由业务代码去调用，对业务来说相当于一个黑盒子，总体上，代码逻辑下面可能做到业务与治理拆散，然而引入SDK又有了新的问题

  1. 语言强绑定，SDK须要与语言适配，每种语言都得实现一套雷同性能的SDK
  2. SDK版本不易治理，SDK自身也会有降级迭代的过程，而业务开发通常是惰性的，不要指望业务会被动去降级SDK，这就导致集群内会有各种各样版本的SDK，性能不够对立，对SDK维护者来说不好治理
  3. 依然有代码级的侵入，尽管说独立成SDK，然而业务代码自身还须要跟SDK进行适配，这种状况下，服务治理无奈齐全对业务通明
第三阶段，独立出治理逻辑过程

从第一阶段和第二阶段的教训能够总结出，如果要想让业务玩得爽，必须尽量把服务治理这块逻辑一直地下沉，最好可能实现对业务齐全通明，比如说，业务齐全不须要加任何非凡逻辑，间接向某个服务名发动http申请，而后取得预期的返回这是最好的

举例来说，就像tcp的倒退历程一样，从最早的时候，tcp/ip还没被制订进去，机器与机器之间的连贯可能就间接通过一条网络直连（甚至都没有网线这种货色，间接就用一条RS232串口线连贯），A机器收回的数据流由B机器间接接管，起初，有了更远距离的通信，网络问题开始浮现呈现，比如说数据可能会提早、可能会丢包、包序可能是乱的，更甚者如果两台机器性能不统一，一端拼命地发数据，一端来不及收数据等等，这时候就须要某种策略来确定来至多解决以下几个问题

  1. 单方须要有一个应答逻辑来确定对端到底有没有收到数据
  2. 须要有一个超时重启机制来确认网络中有没有产生丢包，不能让人有限期待上来
  3. 须要有一个拥塞管制机制，来确认发送方达到能以多大的速度向对方发数据
  4. 须要保证数据包程序

这是不是很像tcp解决的问题？是的，因为这种机器间通信的需要太广泛了，所以制订了tcp/ip协定，把他变成网络通信的基础设施，业务层不再须要亲自去解决这种网络治理问题，这其实就是一种逻辑档次的下沉，业务一直往下层倒退，基础设施一直下沉，向下层屏蔽治理的细节

那微服务时代的服务治理逻辑有没有机会下沉成基础设施，让应用层不再须要去关怀这些货色呢，目前没有看到OSI 7层模型有持续升高的想法，那就让治理逻辑人为地下沉，尽最大可能地向业务层屏蔽底层细节

这就是第三阶段的倒退方向：治理逻辑独立过程

通过把治理逻辑的代码独立进去变成一个过程，负责劫持业务过程的出入流量，并负责实现服务治理逻辑，对业务过程来说，它齐全不晓得这个治理过程的存在，这个旁路过程就是SideCar，也称为proxy代理

如果咱们把集群内的所有proxy治理起来，服务间通信齐全由proxy来负责，并有一个控制中心来负责管制这些proxy，实现一张服务治理的网，这种模式就叫Service Mesh 服务网格

Service Mesh解决了以下问题：

  1. 对业务层齐全通明，感知不到网格的存在
  2. 网格上的控制中心和利用节点上的proxy共同完成服务治理：服务注册、服务发现、服务熔断、负载平衡等性能，甚至可能实现动静路由散发、监控、调用链跟踪等高级性能

Istio架构

Istio就是以后Service Mesh状态上比拟热门的实现计划，由Google推出，所以Istio可能实现跟K8s深度联合，因为师出同门，所以Istio的路线就是能依赖K8s的性能就尽量复用K8s的，基于K8s的生态去构建一个Service Mesh服务，当然Istio也能够跟基本平台进行联合，只不过跟K8s是配合得最好的，上面是Istio官网首页的图

总结出以下四种性能

流量治理
  • 实现负载平衡，动静路由，同时可能反对灰度公布、故障注入等高级的治理能力
可察看性
  • 接管了利用的流量，那就能够实现对流量的监控，根本拜访日志及流量维度的各种监控是基本功能，另外还反对调用链跟踪，Istio能够给流经prox的申请打上span跟踪ID，而后Istio接上一个有跟踪能力的后端比方zipkin啥的，就能够马上实现调用链跟踪，不须要业务层染指开发
策略执行
  • 可能实现熔断限流等拜访策略
平安
  • 通信安全

基本上在微服务下面所要解决的对于服务治理的需要，Istio都可能反对

在架构下面，Istio跟K8s一样，分为两层，底层管制面，下层数据面

数据面会在服务创立的时候主动向一个Pod外面注入Istio的prox容器（应用的是Envoy组件），这个注入过程业务层是无感知的，这个Proxy容器会通过iptables转发的方法把出入流量从Pod的业务容器中劫持走

再说管制面，这个是Istio的控制中心，次要由Pilot（控制器），Citadel（负责平安相干的性能）、Galley（负责各种配置）组成，旧版本中还有一个Mixer组件，次要负责遥测采集，proxy会向Mixer上报各种指标，Mixer来控制策略，因为会有性能瓶颈，这个组件在新版Istio中曾经被废除，相干能力下放到数据面的Proxy来实现

对K8s来说，Istio是以插件的模式对K8s的一种性能补齐，K8s自身只实现了运维部署、根本的服务发现等根底层，Istio则是在其之上，业务层之下，处于两头的平台层，实现了以上的服务治理能力

Istio的服务治理规定

提供了四种逻辑模型

  • Gateway: 作为一个集群的入口网关，内部流量通过这个网关来拜访外部服务
  • VitualService: 制订路由规定，比方依据门路散发，依据Http cookies匹配散发等，能够了解为Nginx下的server配置，server下你能够有各种location匹配规定
  • DestinationRule: 拜访策略的规定，比方过滤指标节点，设置负载平衡模式等，能够了解为Nginx下的upstream配置，server.location匹配到规定后就会向指定的upstream发动申请，而DestinationRule就相当于upstream下的各种管制规定，比方定义后端服务列表，定义最大连接数等
  • ServiceEntry，这个是集群内服务申请内部服务的进口网关，当然也能够不必这个货色，间接由Proxy发动连贯

以上，基于VitralService+DestinationRule的规定，能够实现各种拜访模式，比方蓝绿部署，金丝雀部署，A/B test等

Istio具备监控能力，后端能够接各种监控零碎，比方promethus，实现监控告警，而无需业务层染指

Istio的服务发现依赖于K8s，Isito会通过list/wath监听来自KubeAPIServer的事件，所以Istio不须要实现服务注册

最初，最近在看一本华为云出的对于Istio的书，看完到时再续一下更具体的内容，今晚写作的时候被工作打断了，没有思路了，先暂停一下，对于Istio先介绍到这里

学习过程中参考了一些材料如下：
Pattern: Service Mesh
Istio入门级实训-华为云CloudNative 系列培训课程
《云原生服务网格Istio》