共计 4287 个字符，预计需要花费 11 分钟才能阅读完成。
前情提要
前段时间去 QCon 深圳 2020 大会围观了一下，听了一下大厂们当初在干的事件，后端这一块支流都在探讨云原生，当中美团分享了他们在 Service Mesh 架构下面的实际，集体感觉挺有价值，写篇博文记录一下
Service Mesh 的演变历程
一个服务从我的项目一开始，通常会是一个简略的单体利用，一个利用提供了所需的所有服务，所有模块都蕴含在这个利用外面，随着需要的迭代，这个利用的模块数量越来越宏大，性能集成也越来越多，模块与模块之间在利用内强耦合，以致于到前期可能改一个小东西就可能会影响整个利用，导致线上事变
倒退到这个阶段，个别就要进行服务拆分了，从业务上进行划分，把实现同类性能的利用放到一组，通常状况下拆分之后业务与业务之间会有互相调用的需要，原先基于单个利用下的模块与模块之间的间接调用当初变成服务与服务之间的 RPC 调用，基于这个前提，在网络层面就衍生出了几个以后 OSI 7 层网络模型无奈反对的更高维度的问题
服务注册与服务发现
服务之间要实现互相调用，首先必须先找到对方，相似于 DNS 查找，通过名称查找到具体端点（IP+ 端口号），所以首先须要一个相似 DNS 的服务，充当注册核心，性能下面要求一个服务下面或者销毁的时候，注册核心要可能感知到这个事件，以便在第二步：服务发现的时候可能精确拿到可用的目标端点，通常的流程如下所示：
- 被调方向注册核心注册本人的地址
- 调用方向注册核心询问被调方的服务地址列表 3. 向被调方发动申请最间接的方法，就是搞个 DNS 服务器，用来充当注册核心，然而 DNS 通常会有缓存，更新不会实时，而且服务注册除了“注册”这个动作，还须要有“销毁”的动作，否则一个节点挂了，DNS 下面还保留着这个节点的信息，调用方发动调用将会失败，总体上 DNS 并不能完满胜任这种工作，须要想方法另外去解决
负载平衡
上图能够看到，被调方这个服务下能够有多个实例，散布在不同的主机上运行，事实中为了防止单点故障，基本上都会安排多个实例同时提供服务，这就导致调用方拿到的服务地址不是一条，而是一组列表，而怎么样从这组列表中选出一个端点来发动申请呢，这就须要调用方有负载平衡的能力，比方 rr 轮询，random 随机拜访呢
熔断限流
微服务的集群下，每个服务负责不同的性能，一条申请进来可能会穿梭多个微服务，而如果在这当中，某些微服务呈现性能瓶颈，比方一些解决流程比较慢的服务，当并发申请量上来之后，可能就间接被打挂了，而这个服务恰好是一个要害门路，导致前端所有申请都报错，这时候就须要有一种爱护机制，可能在适当的时候对某些步骤进行降级操作，比方某个服务达到性能瓶颈之后进行熔断，不让申请进来，服务入口间接回绝拜访，等到这个服务复原可用的时候再把它加进来
平安
如果在一个不信赖的集群中，服务与服务之间可能还须要加密通信，这意味着单方要进行身份认证、密钥替换，身份认证须要一个权威的平安核心来颁发证书，否则可能会有中间人窃听，这些次要看业务须要的安全等级
以上这些问题，统称服务治理，基本上服务治理通过了三个阶段
第一阶段，在应用程序中蕴含治理逻辑
这个阶段，利用自身除了业务代码之外，还加进了治理逻辑局部的代码，利用自身亲自来解决服务发现、负载平衡等等问题，这种形式存在以下问题：
- 业务代码与治理逻辑强耦合，意味着开发者在实现业务的同时还必须去关怀这些治理的问题，无奈开发纯正的业务代码
- 存在大量反复的代码，集群内的所有服务的业务代码都得实现这样一套治理逻辑，保护艰难，搞不好一出 bug 还得所有服务都得改一遍
第二阶段，独立出治理逻辑 SDK
为了解决耦合的问题，业务尝试把这些逻辑形象进去，独立成一个 SDK 库，由业务代码去调用，对业务来说相当于一个黑盒子，总体上，代码逻辑下面可能做到业务与治理拆散，然而引入 SDK 又有了新的问题
- 语言强绑定，SDK 须要与语言适配，每种语言都得实现一套雷同性能的 SDK
- SDK 版本不易治理，SDK 自身也会有降级迭代的过程，而业务开发通常是惰性的，不要指望业务会被动去降级 SDK，这就导致集群内会有各种各样版本的 SDK，性能不够对立，对 SDK 维护者来说不好治理
- 依然有代码级的侵入，尽管说独立成 SDK，然而业务代码自身还须要跟 SDK 进行适配，这种状况下，服务治理无奈齐全对业务通明
第三阶段，独立出治理逻辑过程
从第一阶段和第二阶段的教训能够总结出，如果要想让业务玩得爽，必须尽量把服务治理这块逻辑一直地下沉，最好可能实现对业务齐全通明，比如说，业务齐全不须要加任何非凡逻辑，间接向某个服务名发动 http 申请，而后取得预期的返回这是最好的
举例来说，就像 tcp 的倒退历程一样，从最早的时候，tcp/ip 还没被制订进去，机器与机器之间的连贯可能就间接通过一条网络直连（甚至都没有网线这种货色，间接就用一条 RS232 串口线连贯），A 机器收回的数据流由 B 机器间接接管，起初，有了更远距离的通信，网络问题开始浮现呈现，比如说数据可能会提早、可能会丢包、包序可能是乱的，更甚者如果两台机器性能不统一，一端拼命地发数据，一端来不及收数据等等，这时候就须要某种策略来确定来至多解决以下几个问题
- 单方须要有一个 应答逻辑 来确定对端到底有没有收到数据
- 须要有一个 超时重启 机制来确认网络中有没有产生丢包，不能让人有限期待上来
- 须要有一个 拥塞管制 机制，来确认发送方达到能以多大的速度向对方发数据
- 须要保证数据 包程序
这是不是很像 tcp 解决的问题？是的，因为这种机器间通信的需要太广泛了，所以制订了 tcp/ip 协定，把他变成网络通信的基础设施，业务层不再须要亲自去解决这种网络治理问题，这其实就是一种逻辑档次的下沉，业务一直往下层倒退，基础设施一直下沉，向下层屏蔽治理的细节
那微服务时代的服务治理逻辑有没有机会下沉成基础设施，让应用层不再须要去关怀这些货色呢，目前没有看到 OSI 7 层模型有持续升高的想法，那就让治理逻辑人为地下沉，尽最大可能地向业务层屏蔽底层细节
这就是第三阶段的倒退方向：治理逻辑独立过程
通过把治理逻辑的代码独立进去变成一个过程，负责劫持业务过程的出入流量，并负责实现服务治理逻辑，对业务过程来说，它齐全不晓得这个治理过程的存在，这个旁路过程就是 SideCar，也称为 proxy 代理
如果咱们把集群内的所有 proxy 治理起来，服务间通信齐全由 proxy 来负责，并有一个控制中心来负责管制这些 proxy，实现一张服务治理的网，这种模式就叫 Service Mesh 服务网格
Service Mesh 解决了以下问题：
- 对业务层齐全通明，感知不到网格的存在
- 网格上的控制中心和利用节点上的 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》