上一篇文章，说到为什么不看好服务网格，核心是没有强大的运维监控以及性能问题，那么lstio的出现让那个我们看到了一线曙光。因为实际生产活动中，各种运营上报、https证书各种对接、各种监控指标采集、流控策略下发，往往十分耗散开发人员的精力，使得我们无法专注于业务开发，为什么说大公司拉通多，就是这么来的。那么我想lstio就是为了来解决这种问题的。据说lstio的代理能力和已经和nginx差不多，不过没经过太多生产实践，还可以观望下。毕竟
服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。在典型的服务网格中，这些代理作为一个 sidecar（边车）被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。相互连接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。
关于sidecar我们在下一篇文章中来介绍。
总而言之，Service Mesh 的基础设施层主要分为两部分：
- 控制平面
- 数据平面
当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造；接下来我们通过介绍lstio来进一步了解这种基础设施：
使用Istio实施服务网格
尽管有其他几种服务网格，但最受欢迎的是Istio。我们将使用Istio探索云原生应用程序的Service Mesh架构。
如以上各节所述，在微服务体系结构中， Istio通过形成基础结构层来实现此目的，以连接，保护和控制分布式服务之间的通信。Istio 在每个服务旁边部署一个 Istio代理（称为Istio sidecar），而该服务本身的代码更改几乎很少或没有。所有服务间流量都定向到Istio代理，该代理使用策略控制服务间通信，同时实施部署，故障注入和断路器的基本策略。
Istio的核心能力
- 流量管理：这是 Istio 的最基本的功能。
- 策略控制：通过 Mixer 组件和各种适配器来实现，实现访问控制系统、遥测捕获、配额管理和计费等。
- 可观测性：通过 Mixer 来实现。
- 安全认证：Citadel 组件做密钥和证书管理
核心Istio组件
从 2017 年 5 月发布以来，Istio 经历了四个重要的版本和由此划分的三个发展阶段。在不到三年的产品迭代过程中，出现了两次重大的架构变动。我们来简要分析一下这个变迁历程。
- 0.1 版本：2017 年 5 月发布。作为第二代 Service Mesh 的开创者，宣告了 Istio 的诞生，也燃起了网格市场的硝烟与战火。
- 1.0 版本：发布于 2018 年 7 月，对外宣传生产环境可用。从 0.1 到 1.0 版本，开发时间经历了一年多，但持续的发布了多个 0.x 版本，这一阶段处于快速迭代期。
- 1.1 版本：发布于 2019 年 3 月，号称企业级可用的版本。一个小的版本号变化居然耗费了半年之久，其主要原因是出现了第一次架构重构，这一阶段算是调整期。
- 1.5 版本：发布于 2020 年 3 月，再次进行架构的重建，将多组件整合为单体形态的 istiod。从 1.1 到 1.5 版本的一年中，Istio 开始遵循季节性发布，进入了产品的稳定发展期
虽然又变成了单体，但是从职责划分上我们还是可以从组件化去分析：
Istio的控制平面和Envoy的数据平面共同构成了一个引人注目的服务网格实现。两者都拥有蓬勃发展和充满活力的社区，并且面向下一代服务架构。Istio是独立于平台的，可运行于各种环境中，包括跨云、内部部署、Kubernetes、Mesos等。你可以在Kubernetes 上部署Istio或在具有Consul的Nomad上部署。Istio目前支持在Kubernetes上部署的服务、使用Consul注册的服务以及在虚拟机上部署的服务。
控制平面
控制平面部分包括了Pilot、Mixer、Citadel和Galley四个组件
- Pilot
Istio的Pilot组件用于管理流量，可以控制服务之间的流量流动和API调用，通过Pilot可以更好地了解流量，以便在问题出现之前发现问题。这使得调用更加可靠、网络更加强健，即使遇到不利条件也能让应用稳如磐石。借助Istio的Pilot，你能够配置熔断器、超时和重试等服务级属性，并设置常见的连续部署任务，如金丝雀发布、A/B测试和基于百分比拆分流量的分阶段发布。Pilot为Envoy代理提供服务发现功能，为智能路由和弹性能力（如超时、重试、熔断器等）提供流量管理功能。Pilot将控制流量行为的高级路由规则转换为特定于Envoy代理的配置，并在运行时将它们传播到Envoy。此外，Istio提供了强大的开箱即用故障恢复功能，包括超时、支持超时预算和变量抖动的重试机制、发往上游服务的并发连接和请求数限制、对负载均衡池中的每个成员进行的定期主动运行状况检查，以及被动运行状况检查。
Pilot将平台特定的服务发现机制抽象化并将其合成为标准格式，符合数据平面API的任何Sidecar都可以使用这种标准格式。这种松散耦合使得Istio能够在多种环境下运行（例如Kubernetes、Consul、Nomad），同时可保持用于流量管理的操作界面相同。Pilot中的adapter机制可以适配各种服务发现组件（Eureka、Consul、Kubenetes）,最好的是Kubernetes
- Mixer
Istio的Mixer组件提供策略控制和遥测收集功能，将Istio的其余部分与各个后端基础设施后端的实现细节隔离开来。Mixer是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。代理提取请求级属性，发送到Mixer进行评估。
Mixer中包括一个灵活的插件模型，使其能够接入到各种主机环境和后端基础设施，从这些细节中抽象出Envoy代理和Istio管理的服务。利用Mixer，你可以精细控制网格和后端基础设施后端之间的所有交互。
- Citadel
Istio Citadel安全功能提供强大的身份验证功能、强大的策略、透明的TLS加密以及用于保护服务和数据的身份验证、授权和审计（AAA）工具，Envoy可以终止或向网格中的服务发起TLS流量。为此，Citadel需要支持创建、签署和轮换证书。Istio Citadel提供特定于应用程序的证书，可用于建立双向TLS以保护服务之间的流量。
控制平面主要是对数据平面组件的管理和维护，因此形成了Istio Service Mesh最重要的层。
- Galley
Galley用于验证用户编写的Istio API配置。随着时间的推移，Galley将接管Istio获取配置、处理和分配组件的顶级责任。它负责将其他的Istio组件与从底层平台（例如Kubernetes）获取用户配置的细节中隔离开来。
数据平面
摘要 Istio使用Envoy代理作为默认的开箱即用服务代理，这些Envoy代理与参与服务网格的所有应用程序实例一起运行，但不在同一个容器进程中，形成了服务网格的数据平面。只要应用程序想要与其他服务通信，就会通过服务代理Envoy进行。由此可见，Envoy代理是数据平面和整个服务网格架构中的关键组成部分。
Envoy代理
Envoy最初是由Lyft开发的，用于解决构建分布式系统时出现的一些复杂的网络问题。它于2016年9月作为开源项目提供，一年后加入了云原生计算基金会（CNCF）。Envoy是用C++语言实现的，具有很高的性能，更重要的是，它在高负载运行时也非常稳定和可靠。网络对应用程序来说应该是透明的，当网络和应用程序出现问题时，应该很容易确定问题的根源。正是基于这样的一种设计理念，将Envoy设计为一个面向服务架构的七层代理和通信总线。
首先，Envoy是一种代理，在网络体系架构中扮演着中介的角色，可以为网络中的流量管理添加额外的功能，包括提供安全性、隐私保护或策略等。在服务间调用的场景中，代理可以为客户端隐藏服务后端的拓扑细节，简化交互的复杂性，并保护后端服务不会过载。例如，后端服务实际上是运行的一组相同实例，每个实例能够处理一定量的负载。
其次，Envoy中的集群（Cluster）本质上是指Envoy连接到的逻辑上相同的一组上游主机。那么客户端如何知道在与后端服务交互时要使用哪个实例或IP地址？Envoy作为代理起到了路由选择的作用，通过服务发现（SDS，Service Discovery Service），Envoy代理发现集群中的所有成员，然后通过主动健康检查来确定集群成员的健康状态，并根据健康状态，通过负载均衡策略决定将请求路由到哪个集群成员。而在Envoy代理处理跨服务实例的负载均衡过程中，客户端不需要知道实际部署的任何细节。
Istio组件功能及相互协作方式
Istio 的主要组件及其相互关系大致如图所示摘自《云原生服务网格Istio》
找了很多资料，但是偶然发现了社区，开源里面的力量太强大，感恩这个时代：
这本书给你总结的明明白白：
Pilot · Istio Handbook - Istio 服务网格进阶实战 by ServiceMesher(服务网格社区)
更多有用：
300
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
