前言
istio 文档有很多，但是多是面向使用者的角度，介绍了好多个新概念，对于开发者而言，不是很友好。
最近折腾了一番 istio，以开发者的视角，简单谈谈我的理解。
一句话介绍
Istio 是零散的网关配置的组装 & 推送通道
背景
在现代网关软件中，已经积累了大量的通用能力，比如：路由，限流，鉴权，日志，等等各式各样的能力。
而且这些能力并不是一成不变的，而是在不同业务场景下，需要有不同的策略调整。
所以，网关软件会通过暴露配置，来满足各种场景的定制需求。
以往常规的搞法是，搞个配置文件，网关软件启动之后，读取本地的配置文件，按照配置文件的规则来执行网关的各种逻辑。
比如，经典的 Nginx，就是提供了一套配置语法，用户将配置写在文件里。
但是，随着网关规模越来越大，配置越来越多，更新也越来越频繁，配置文件已经不太能满足需求了。（主要是，不太好做到动态局部更新）
所以，又单独搞了一个软件，负责管理这些配置，其主要用途就是将配置同步给网关软件。
这里，也就对应了两个概念：
- 控制面，提供配置的软件；本文主角 istio 就是代表
- 数据面，具体执行网关逻辑的软件；比如 Envoy，它通常是作为 Istio 的搭档出场。
干什么的
搞懂一个软件，核心是抓住输入 & 输出
- 输入：各种零散的网关配置
- 输出：Envoy 能理解的配置
这里引出两个层次概念：
Istio CRD
如上所述，在网关领域，有各种各样的配置，那么，在 Istio 这一层，则对这些配置进行了一层语义抽象。
按照 k8s 的套路，也就有了 CRD 这个概念，Custom Resource Description（k8s 把啥都抽象为了资源）。
（当然，Istio 也可以读取 k8s 里的中的标准资源，比如 Service，Endpoints 等）
具体是咋个抽象的呢？列举几个 CRD：
- Gateway：描述网关层，流量进来的端口，协议，域名之类的
- VirtualService：描述的虚拟服务，主要是路由规则，比如不同请求的转发处理策略
- Destination Rule：描述服务的流量策略，复杂均衡算法，连接池策略等
- Service Entry：描述服务，地址，端口，等
举个栗子，有这么个需求：http://example.com/v1.txt 随机转发到 1.1.1.1:80，2.2.2.2:80 这两个地址，需要拆分为四个资源：
- Gateway，定义一个网关，端口是 80，协议是 http，域名是
example.com - Virtual Service，定义个虚拟服务，uri 是
/v1.txt的转发到一个目标xxx - Destination Rule，指定
xxx目标的复杂均衡策略：随机 - Service Entry，指定
xxx服务的地址：1.1.1.1:80，2.2.2.2:80
这里不同种类的资源，也就是 Istio 的输入，零散的网关配置。
CRD 是面向使用的抽象，用户只需要将希望的效果，通过 CR 描述出来，具体的实现是不用关心的。
为啥要拆开成这么多资源呢？以我开发者的视角，主要还是为了方便局部动态更新，比如应用服务扩容了，只需要更新 Service Entry 就行了，其他的不用动。
xDS
在数据面，也就是 Envoy 这一层，并不是直接接受 CR 的，而是又提供了一套自己的抽象。
也就是 LDS，RDS，CDS，EDS 这些，统称为 xDS，这里就不详细展开了。
简单点来说，xDS 的抽象更贴近 Envoy 的实现细节，Istio CRD 更贴近用户描述。
xDS，既是 Envoy 的输入，也是 Istio 的输出。
工作流程
首先，基本模式是，Envoy 是向 Istio 订阅指定资源。
当 Istio 收到一个 xDS 订阅时（比如 LDS），大致有这么几个环节：
- 筛选当前订阅的 xDS，所需要用到的 CR
这里的筛选条件还是挺复杂的，也不细说了。举一个简单的，用 Envoy 所属的 namespace 来筛选 - 组装 & 转换
一个 xDS 可能会对应多个 CR，这个时候需要组装起来，转换为 xDS 格式 - 推送
推送给 Envoy，如果后续某个 CR 有更新，也是这个推送流程
那么，Istio 用到的 CR 资源是从哪里来呢？
有多种方式，从 k8s API server 来，从 MCP server 来，从本地 watch 的文件来，等。
Istio 收到了 CR 之后，就全量存储在本地内存中（是的，就是这么简单粗暴）
- 收到了 Envoy 的订阅，就走上面的筛选 & 组装 & 推送流程
- 收到了 CR 更新，也是走类似的筛选 & 组装 & 推送流程
总结
打个比方，Istio 就是一个工厂，将原材料 CR，加工成为 xDS，也就是它的下游（Envoy）所需要的原材料。
不过呢，它对需要的原材料是有标准的，也就是 CRD 描述的标准。
最后，软件系统就像积木一样，是一层层搭建出来的，每一层都有抽象出一套自己的标准。
如果抽象得好，表达能力强，适用范围广，大家都遵循这套标准，那就成为了业界标准，也就有了更长远的生命力。
如果只是一个小范围流行，生命力就没那么强了，不是说一定活不下去，但是很难说得上绚烂。