ISTIO
概念：
一个用来连接、管理和保护微服务的开放平台。Istio提供一种简单的方式来建立已部署服务网络，具备负载均衡、服务间认证、监控等功能而不需要改动任何服务代码。想要为服务增加对Istio的支持，只需要在环境中部署一个特殊的边车(sidecar)，使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。
由来与主要功能：
在从单体应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，使用Istio可以解决这些问题。服务网格（Service Mesh）通常用于描述构成这些应用程序的微服务网络以及它们之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。
核心功能：
它在服务网络中统一提供了许多关键功能：
1）流量管理。控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
2）可观察性。了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
3）策略执行。将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
4）服务身份和安全。为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。除此之外，Istio针对可扩展性进行了设计，以满足不同的部署需要：
5）平台支持。Istio旨在可以在各种环境中运行，包括跨云、预置环境、Kubernetes、Mesos等。最初专注于K8s，但很快将支持其他环境。6）集成和定制。策略执行组件可以扩展和定制，以便与现有的ACL、日志、监控、配额、审核等解决方案集成。这些功能极大的减少了应用程序代码，底层平台和策略之间的耦合。耦合的减少不仅使服务更容易实现，而且还使运维人员更容易地在环境之间移动应用程序部署，或换用新的策略方案。因此，结果就是应用程序从本质上变得更容易移动。
微服务，有学者描述“微服务是以一组小型服务来开发单个应用程序的方法，每个服务都运行在自己的进程中，服务间采用轻量级通信机制（通常用 HTTP 资源API）。这些服务围绕业务能力构建并可通过全自动部署机制独立部署，还共用一个最小型的集中式管理，可用不同的语言开发，并使用不同的数据存储技术”，可以看出，微服务在本质上还是分而治之、化繁为简的哲学智慧在计算机领域的一个体现。这种方式带给我们很多好处：1）开发视角：每个微服务的功能更内聚，可以在微服务内设计和扩展功能，并且采用不同的
开发语言及开发工具；2）运维视角：在微服务化后，每个微服务都在独立的进程里可以自运维；更重要的是，微服务化是单一变更的基础，迭代速度更快，上线风险更小；3）组织管理：有利于敏捷开发。但是，微服务化也给开发和运维带来很大的挑战，因为微服务化仅仅是一种分而治之的方法，业务本身的规模和复杂度并没有变少，反而变多。这就需要一些工具集来做一些通用的工作，包括服务注册、服务发现、负载均衡等。在原来未微服务化的时候，单体应用的多模块之间根本不需要进程间通信，也不需要服务发现。所以，我们将这些工具集理解为用于解决微服务化带来的新问题似乎更合理一些。
服务网格（Service Mesh）：
业界比较认同的是William Morgan关于服务网格的一段定义，它是一种抽象，为分布式应用程序提供流量路由，策略管理和遥测。服务网格由数据平面和控制平面组成。在数据平面中，代理与服务一起运行，服务的每个请求都通过代理进行路由。在控制平面中，应用程序所有者可以控制分布在整个应用程序中的代理的行为，服务网格的特点。1）服务网格是一种处理服务间通信的基础设施层。2）云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务拓扑间可靠地传递请求。3）网络代理：在实际使用中，服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。4）对应用透明：轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作。
Istiot架构：
Istio服务网格逻辑上分为数据面板和控制面板。数据面板由一组智能代理（Envoy）组成，代理部署为边车，调解和控制微服务之间所有的网络通信。控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。下图显示了构成每个面板的不同组件：
Envoy：
Istio使用Envoy代理的扩展版本，Envoy是以C ++开发的高性能代理，用于调解服务网格中所有服务的所有入站和出站流量。Envoy的许多内置功能被istio发扬光大，例如动态服务发现，负载均衡，TLS终止，HTTP/2&gRPC代理，熔断器，健康检查，基于百分比流量拆分的分段推出，故障注入和丰富指标。Envoy被部署为边车,和对应服务在同一个Kubernetes pod中。这允许Istio将大量关于流量行为的信号作为属性提取出来，而这些属性又可以在Mixer中用于执行策略决策，并发送给监控系统，以提供整个网格行为的信息。边车代理模型还可以将Istio的功能添加到现有部署中，而无需重新构建或重写代码。可以阅读更多来了解为什么我们在设计目标中选择这种方式。
Mixer：
Mixer负责在服务网格上执行访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。代理提取请求级属性，发送到Mixer进行评估。Mixer包括一个灵活的插件模型，使其能够接入到各种主机环境和基础设施后端，从这些细节中抽象出Envoy代理和Istio管理的服务。
Pilot：
它负责收集和验证配置并将其传播到各种Istio组件。它从Mixer和Envoy中抽取环境特定的实现细节，为他们提供用户服务的抽象表示，独立于底层平台。此外流量管理规则(即通用4层规则和7层HTTP/gRPC路由规则)可以在运行时通过Pilot进行编程。Istio-Auth提供强大的服务间认证和终端用户认证，使用交互TLS，内置身份和证书管理。可以升级服务网格中的未加密流量，并为运维人员提供基于服务身份而不是网络控制来执行策略的能力。Istio的未来版本将增加细粒度的访问控制和审计，以使用各种访问控制机制（包括基于属性和角色的访问控制以及授权钩子）来控制和监视访问您的服务，API或资源的人员。
设计目标：
Istio的架构设计中有几个关键目标，这些目标对于使系统能够应对大规模流量和高性能地服务处理至关重要。
1）最大化透明度：
让运维和开发人员只需付出很少的代价就可以从中受益。为此Istio将自身自动注入到服务间所有的网络路径中。Istio使用sidecar代理来捕获流量，并且在尽可能的地方自动编程网络层，以路由流量通过这些代理，而无需对已部署的应用程序代码进行任何改动。在Kubernetes中，代理被注入到pod中，通过编写iptable规则来捕获流量。一旦注入sidecar代理到pod中并且修改路由则，Istio就能够调解所有流量。这个原则也适用于性能。当将Istio应用于部署时，为提供这些功能而增加的资源开销是很小的。所有组件和API在设计时都必须考虑性能和规模。
2）增量：
随着运维人员和开发人员越来越依赖Istio提供的功能，系统必然和他们的需求一起成长。虽然我们期望继续自己添加新功能，但是我们预计最大的需求是扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外，它允许扩展词汇表，以允许基于网格生成的新信号来执行策略。
3）可移植性：
使用Istio的生态系统将在很多维度上有差异。Istio必须能够以最少的代价运行在任何云或预置环境中。将基于Istio的服务移植到新环境应该是轻而易举的，而使用Istio将一个服务同时部署到多个环境中也是可行的（例如，在多个云上进行冗余部署）。
4）策略一致性：
在服务间的API调用中，策略的应用使得可以对网格间行为进行全面的控制，但对于无需在API级别表达的资源来说，对资源应用策略也同样重要。例如，将配额应用到ML训练任务消耗的CPU数量上，比将配额应用到启动这个工作的调用上更为有用。因此，策略系统作为独特的服务来维护，具有自己的API，而不是将其放到代理/sidecar中，这容许服务根据需要直接与其集成。
下图是Istio得知识图谱
