带你玩转Istio-第2篇---原理篇

Istio与服务网格

业界比较认同的是William Morgan关于服务网格（Service Mesh）的一段定义，这里提取和解释该定义中的几个关键字来讲解服务网格的特点。

◎ 基础设施：服务网格是一种处理服务间通信的基础设施层。
◎ 云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务拓扑间可靠地传递请求。
◎ 网络代理：在实际使用中，服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。
◎ 对应用透明：轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作。

经典的服务网格示意图如图1-8所示。

                                    图1-8 经典的服务网格示意图

时代选择服务网格

在云原生时代，随着采用各种语言开发的服务剧增，应用间的访问拓扑更加复杂，治理需求也越来越多。原来的那种嵌入在应用中的治理功能无论是从形态、动态性还是可扩展性来说都不能满足需求，迫切需要一种具备云原生动态、弹性特点的应用治理基础设施。

首先，从单个应用来看，Sidecar与应用进程的解耦带来的应用完全无侵入、开发语言无关等特点解除了开发语言的约束，从而极大降低了应用开发者的开发成本。这种方式也经常被称为一种应用的基础设施层，类比TCP/IP网络协议栈，应用程序像使用TCP/IP一样使用这个通用代理：TCP/IP 负责将字节码可靠地在网络节点间传递，Sidecar 则负责将请求可靠地在服务间进行传递。TCP/IP 面向的是底层的数据流，Sidecar 则可以支持多种高级协议（HTTP、gRPC、HTTPS 等），以及对服务运行时进行高级控制，使服务变得可监控、可管理。

然后，从全局来看，在多个服务间有复杂的互相访问时才有服务治理的需求。即我们关注的是这些 Sidecar 组成的网格，对网格内的服务间访问进行管理，应用还是按照本来的方式进行互相访问，每个应用程序的Inbound流量和Outbound流量都要经过Sidecar代理，并在Sidecar上执行治理动作。

最后，Sidecar是网格动作的执行体，全局的管理规则和网格内的元数据维护通过一个统一的控制面实现，如图 1-9 所示，只有数据面的 Sidecar 和控制面有联系，应用感知不到Sidecar，更不会和控制面有任何联系，用户的业务和控制面彻底解耦。

                                                         图1-9 服务网格的统一控制面

 

当然，正所谓没有免费的午餐，这种形态在服务的访问链路上多引入的两跳也是不容回避的问题。

如图1-10所示，从forecast服务到recommendation服务的一个访问必须要经过forecast服务的 Sidecar拦截 Outbound流量执行治理动作；再经过 recommendation服务的 Sidecar拦截Inbound流量，执行治理动作。这就引入两个问题：

◎ 增加了两处延迟和可能的故障点；
◎ 多出来的这两跳对于访问性能、整体可靠性及整个系统的复杂度都带来了新的挑战。

                                                       图1-10 服务网格访问路径变长

其中，后者本来就属于基础设施层面可维护性、可靠性的范畴，业界的几个产品都用各自的方式在保证。而前者引入的性能和资源损耗，网格提供商提供的方案一般是这样解决的：通过保证转发代理的轻量和高性能降低时延影响，尤其是考虑到后端实际使用的应用程序一般比代理更重，叠加代理并不会明显影响应用的访问性能；另外，对于这些高性能的代理，只要消耗足够的资源总能达到期望的性能，特别是云原生场景下服务的弹性特点使得服务实例的弹性扩展变得非常方便，通过扩展实例数量总是能得到期望的访问性能。

所以，对于考虑使用服务网格的用户来说，事情就会变成一个更简单的选择题：是否愿意花费额外的资源在这些基础设施上来换取开发、运维的灵活性、业务的非侵入性和扩展性等便利。相信，在这个计算资源越来越便宜、聪明的程序员越来越贵的时代，对于把程序员从机械的基础设施就可以搞定的繁杂事务中解放出来，使其专注于更能发挥聪明才智和产生巨大商业价值的业务开发上，我们很容易做出判断。

目前，华为、谷歌、亚马逊等云服务厂商将这种服务以云服务形态提供了出来，并和底层的基础设施相结合，提供了完整的服务治理解决方案。这对于广大应用开发者来说，更加方便和友好。

服务网格选择Istio

在多种服务网格项目和产品中，最引人注目的是后来居上的 Istio，它有希望成为继Kubernetes之后的又一款重量级产品。

Istio从2017年5月发布第1个版本0.1开始就被广泛关注。据Istio官方称，Istio 1.1解决了生产大规模集群的性能、资源利用率和可靠性问题，提供了众多生产中实际应用的新特性，已经达到企业级可用的标准。

首先，在控制面上，Istio作为一种全新的设计，在功能、形态、架构和扩展性上提供了远超服务网格的能力范围。它基于xDS协议提供了一套标准的控制面规范，向数据面传递服务信息和治理规则。Istio的早期版本使用Envoy V1版本的API，即Restful方式，其新版本使用Envoy V2版本的API，即gRPC协议。标准的控制面API解耦了控制面和数据面的绑定。Nginx的nginMesh、F5 Networks的Aspen Mesh等多种数据面代理支持Istio的控制面，甚至有些老牌微服务SDK也开始往Istio上集成，虽然其本身的功能定位和功能集合有些“不对齐”，但至少说明了Istio控制面的影响力和认同程度。

然后，在数据面的竞争上，Istio的标准数据面Envoy是由Lyft内部于2016年开发的，比 Linkerd更早。2016年9月，Envoy开源并发布了 1.0.0版本；2017年 9月，Envoy加入CNCF，成为第2个Service Mesh项目；2018年11月，Envoy从CNCF毕业，这标志着其趋于成熟。从开发语言上看，Envoy是使用C++开发的，其性能和资源占用比用Rust开发的 Linkerd Proxy 要更好，更能满足服务网格中对透明代理的轻量高性能要求；从能力上看，Envoy提供L3/L4过滤器、HTTP L7过滤器，支持HTTP/2、HTTP L7路由及gRPC、MongoDB、DynamoDB等协议，有服务发现、健康检查、高级LB、前端代理等能力，具有极好的可观察性、动态配置功能；从架构实现上看，Envoy是一个可高度定制化的程序，通过 Filter机制提供了高度扩展性，还支持热重启，其代码基于模块化编码，易于测试。除了在Istio中应用，Envoy在其他Service Mesh框架中也被广泛应用，渐渐成为Service Mesh的数据平面标准。

最后，在大厂的支持上，Istio 由谷歌和 IBM 共同推出，从应用场景的分析规划到本身的定位，从自身架构的设计到与周边生态的结合，都有着比较严密的论证。Istio项目在发起时已经确认了将云原生生态系统中的容器作为核心打包和运行时，将Kubernetes作为管理容器的编排系统，需要一个系统管理在容器平台上运行的服务之间的交互，包括控制访问、安全、运行数据收集等，而 Istio 正是为此而生的；另外，Istio 成为架构的默认部分，就像容器和Kubernetes已经成为云原生架构的默认部分一样。

云原生社区的定位与多个云厂商的规划也不谋而合。华为云已经在 2018 年 8 月率先在其容器服务CCE（Cloud Container Engine）中内置Istio；Google的GKE也在2018年12月宣布内置 Istio；越来越多的云厂商也已经选择将 Istio作为其容器平台的一部分提供给用户，即提供一套开箱即用的容器应用运行治理的全栈服务。正因为看到了 Istio 在技术和产品上的巨大潜力，各大厂商在社区的投入也在不断加大，其中包括Google、IBM、华为、VMware、思科、红帽等主流厂商。

Istio与Kubernetes

Kubernetes是一款用于管理容器化工作负载和服务的可移植、可扩展的开源平台，拥有庞大、快速发展的生态系统，它面向基础设施，将计算、网络、存储等资源进行紧密整合，为容器提供最佳运行环境，并面向应用提供封装好的、易用的工作负载与服务编排接口，以及运维所需的资源规格、弹性、运行参数、调度等配置管理接口，是新一代的云原生基础设施平台。

从平台架构而言，Kubernetes的设计围绕平台化理念，强调插件化设计与易扩展性，这是它与其他同类系统的最大区别之一，保障了对各种不同客户应用场景的普遍适应性。另外，Kubernetes与其他容器编排系统的显著区别是Kubernetes并不把无状态化、微服务化等条件作为在其上可运行的工作负载的约束。

如今，容器技术已经进入产业落地期，而Kubernetes作为容器平台的标准已经得到了广泛应用。Kubernetes从2014年6月由Google宣布开源，到2015年7月发布1.0这个正式版本并进入CNCF基金会，再到2018年3月从CNCF基金会正式毕业，迅速成为容器编排领域的标准，是开源历史上发展最快的项目之一，如图1-12所示。

                                                         图1-12 Kubernetes的发展历史

Istio,Kubernetes的好帮手

从场景来看，Kubernetes已经提供了非常强大的应用负载的部署、升级、扩容等运行管理能力。Kubernetes 中的 Service 机制也已经可以做服务注册、服务发现和负载均衡，支持通过服务名访问到服务实例。

从微服务的工具集观点来看，Kubernetes本身是支持微服务的架构，在Pod中部署微服务很合适，也已经解决了微服务的互访互通问题，但对服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在Kubernetes的能力范围内。那么，如何提供一套从底层的负载部署运行到上层的服务访问治理端到端的解决方案？目前，最完美的答案就是在Kubernetes上叠加Istio这个好帮手，如图1-13所示。

                                                           图1-13 在Kubernetes上叠加Istio这个好帮手

Kubernetes的Service基于每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息，并将对 Service 的请求经过负载均衡转发到对应的 Endpoint 上。但Kubernetes只提供了4层负载均衡能力，无法基于应用层的信息进行负载均衡，更不会提供应用层的流量管理，在服务运行管理上也只提供了基本的探针机制，并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。

Istio复用了Kubernetes Service的定义，在实现上进行了更细粒度的控制。Istio的服务发现就是从 Kube-apiserver中获取 Service和 Endpoint，然后将其转换成 Istio服务模型的 Service 和 ServiceInstance，但是其数据面组件不再是 Kube-proxy，而是在每个 Pod 里部署的 Sidecar，也可以将其看作每个服务实例的 Proxy。这样，Proxy 的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理，如图 1-14 所示。通过拦截Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种应用层协议，Istio可以提供真正的应用层治理、监控和安全等能力。

总之，Istio和Kubernetes从设计理念、使用体验、系统架构甚至代码风格等小细节来看，关系都非常紧密，甚至有人认为 Istio 就是 Kubernetes团队开发的 Kubernetes可插拔的增强特性。

                                                    图1-14 更细粒度的Proxy提供更多更细粒度的能力

Kubernetes,Istio的好基座

Istio最大化地利用了Kubernetes这个基础设施，与之叠加在一起形成了一个更强大的用于进行服务运行和治理的基础设施，并提供了更透明的用户体验。

1.数据面

数据面Sidecar运行在Kubernetes的Pod里，作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行的时候感知不到Sidecar的存在。而基于Kubernetes的一个 Pod 多个容器的优秀设计使得部署运维对用户透明，用户甚至感知不到部署 Sidecar的过程。用户还是用原有的方式创建负载，通过 Istio 的自动注入服务，可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy，则不会有这样的便利。

2.统一服务发现

Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成，省去了再搭一个类似 Eureka 的注册中心的麻烦，更避免了在 Kubernetes 上运行时服务发现数据不一致的问题。
      尽管 Istio 强调自己的可扩展性的重要性在于适配各种不同的平台，也可以对接其他服务发现机制，但在实际场景下，通过深入分析 Istio 几个版本的代码和设计，便可以发现其重要的能力都是基于Kubernetes进行构建的。

3.基于Kubernetes CRE描述规则

Istio的所有路由规则和控制策略都是通过 Kubernetes CRD实现的，因此各种规则策略对应的数据也被存储在 Kube-apiserver 中，不需要另外一个单独的 APIServer 和后端的配置管理。所以，可以说Istio的APIServer就是Kubernetes的APIServer，数据也自然地被存在了对应Kubernetes的etcd中。

Istio非常巧妙地应用了Kubernetes这个好基座，基于Kubernetes的已有能力来构建自身功能。Kubernetes里已经有的，绝不再自己搞一套，避免了数据不一致和用户使用体验的问题。

如图1-15所示为Istio和Kubernetes架构的关系，可以看出，Istio不仅数据面Envoy跑在Kubernetes的Pod里，其控制面也运行在Kubernetes集群中，其控制面组件本身存在的形式也是Kubernetes Deployment和Service，基于Kubernetes扩展和构建。

 

                                                         图1-15 Istio与Kubernetes架构的关系

如表1-2所示为Istio+Kubernetes的方案与将SDK开发的微服务部署在Kubernetes上的方案的比较。

                                              表1-2 两种方案的比较

本章总结

如图1-16所示为Istio、微服务、容器与Kubernetes的关系。

                                           图1-16 Istio、微服务、容器与Kubernetes的关系

Kubernetes在容器编排领域已经成为无可争辩的事实标准；微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上匹配，这类服务在容器中的运行也正日益流行；随着Istio 的成熟和服务网格技术的流行，使用 Istio 进行服务治理的实践也越来越多，正成为服务治理的趋势；而 Istio 与 Kubernetes 的天然融合且基于 Kubernetes 构建，也补齐了Kubernetes的治理能力，提供了端到端的服务运行治理治理平台。这都使得Istio、微服务、容器及Kubernetes形成一个完美的闭环。

云原生应用采用 Kubernetes 构建应用编排能力，采用 Istio 构建服务治理能力，将逐渐成为企业技术转型的标准配置。