微服务的最近趋向火热，国内外有很多企业都在进行研究，5月24日，IBM和Google共同发布Istio，帮助开发人员无缝对接、管理和保护不同微服务网路且与平台、源代码或供应商无关。本文来自Istio官方文档， 由数人云资深架构师敖小剑&Service Mesh社区共同编译。
Istio是一个用来连接、管理和保护微服务的开放平台，它提供一种简单的方式来建立已部署服务网络，具备负载均衡、服务间认证、监控等功能，而不需要改动任何服务代码。想要为服务增加对Istio的支持，只需要在环境中部署一个特殊的边车（sidecar），使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。
Istio目前仅支持在Kubernetes上的服务部署，但未来版本中将支持其他环境。
为什么要使用Istio
在从单体应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，Istio可以帮助解决这些问题。术语服务网格（Service Mesh）通常用于描述构成这些应用程序的微服务网络以及它们之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。其需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。
Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能：
- 流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
- 可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
- 策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
- 服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。
除此之外，Istio针对可扩展性进行了设计，以满足不同的部署需要：
- 平台支持：Istio旨在在各种环境中运行，包括跨云, 预置，Kubernetes，Mesos等。最初专注于Kubernetes，但很快将支持其他环境。
- 集成和定制：策略执行组件可以扩展和定制，以便与现有的ACL，日志，监控，配额，审核等解决方案集成。
这些功能极大的减少了应用程序代码，底层平台和策略之间的耦合。耦合的减少不仅使服务更容易实现，而且还使运维人员更容易地在环境之间移动应用程序部署，或换用新的策略方案。因此，结果就是应用程序从本质上变得更容易移动。
架构
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
Pilot负责收集和验证配置并将其传播到各种Istio组件。它从Mixer和Envoy中抽取环境特定的实现细节，为他们提供用户服务的抽象表示，独立于底层平台。此外，流量管理规则（即通用4层规则和7层HTTP/gRPC路由规则）可以在运行时通过Pilot进行编程。
〓 Istio-Auth
Istio-Auth提供强大的服务间认证和终端用户认证，使用交互TLS，内置身份和证书管理。可以升级服务网格中的未加密流量，并为运维人员提供基于服务身份而不是网络控制来执行策略的能力。Istio的未来版本将增加细粒度的访问控制和审计，以使用各种访问控制机制（包括基于属性和角色的访问控制以及授权钩子）来控制和监视访问服务，API或资源的人员。
设计目标
接下来再了解下Istio设计的核心原则，Istio的架构有几个关键设计目标，这些目标对于使系统能够大规模和高性能地处理服务至关重要。
- 最大化透明度
要让Istio被采纳，运维人员或开发人员应该能够只做很少的工作就可以从中受益。为此，Istio将自身自动注入到服务间所有的网络路径中。Istio使用边车代理来捕获流量，并且在尽可能的地方自动编程网络层，以路由流量通过这些代理，而无需对已部署的应用程序代码进行任何改动。在Kubernetes中，代理被注入到pod中，通过编写iptable规则来捕获流量。一旦注入边车代理到pod中并且修改路由规则，Istio就能够调解所有流量。这个原则也适用于性能。当将Istio应用于部署时，运维人员可以发现，为提供这些功能而增加的资源开销是很小的。所有组件和API在设计时都必须考虑性能和规模。
- 增量
随着运维人员和开发人员越来越依赖Istio提供的功能，系统必然和他们的需求一起成长。虽然我们期望继续自己添加新功能，但是我们预计最大的需求是扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外，它允许扩展词汇表，以允许基于网格生成的新信号来执行策略。
- 可移植性
使用Istio的生态系统将在很多维度上有差异。Istio必须能够以最少的代价运行在任何云或预置环境中。将基于Istio的服务移植到新环境应该是轻而易举的，而使用Istio将一个服务同时部署到多个环境中也是可行的（例如，在多个云上进行冗余部署）。
- 策略一致性
在服务间的API调用中，策略的应用提供了对网格行为的大量控制，但对于无需在API级别表达的资源来说，对资源应用策略也同样重要。例如，将配额应用到ML训练任务消耗的CPU数量上，比将配额应用到启动这个工作的调用上更为有用。因此，策略系统作为独特的服务来维护，具有自己的API，而不是将其放到代理/sidecar中，这容许服务根据需要直接与其集成。
以上是Isito的概念、面板组件、以及设计目标，希望对大家有所帮助。后续小数会继续给大家分享由敖小剑&Service Mesh社区共同编译的Istio官方文档。