《云原生服务网格Istio》第1章 你好，Istio

第1章 你好，Istio

前言

• 服务网格是服务（包括微服务）之间通信的控制器。随着越来越多的容器应用的开发和部署，一个企业可能会有成百上千或数万计的容器在运行，怎样管理这些容器或服务之间的通信，包括服务间的负载均衡、流量管理、路由、运行状况监视、安全策略及服务间身份验证，就成为云原生技术的巨大挑战
• 依据CNCF基金会（Cloud-Native Computing Foundation）的定义，云原生是对在现代的动态环境下（比如云计算的三大场景：公有云、私有云及混合云）可用来构建并运行可扩展应用的技术的总称；服务网格则是云原生技术的典型代表之一，其他技术还包括容器、微服务、不可变基础设施、声明式API等
• 从技术发展的角度来看，我们可以把云原生理解为云计算所关注的重心从“资源”逐渐转向“应用”的必然结果
• 微服务更多地从设计、开发的视角来描述应用的一种架构或开发模式，而服务网格事实上更为关注运行时视角，因此，采用“服务”这个用于描述应用内外部调用关系的术语更为合适。服务网格与微服务在云原生技术栈中是相辅相成的两部分，前者更关注应用的交付与运行时，后者更关注应用的设计与开发

1.1 Istio是什么

• 介绍
  • Istio是一个用于服务治理的开放平台
  • Istio是一个Service Mesh形态的用于服务治理的开放平台
  • Istio是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台
• 任何服务，只要服务间有访问，如果需要对服务间的访问进行管理，就可以使用 Istio
• 服务治理涉及连接（Connect）、安全（Secure）、策略执行（Control）和可观察性（Observe）
  • 连接：Istio 通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能
  • 安全：Istio 提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性
  • 策略执行：Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能力
  • 可观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状况，发现并解决问题

1.2 通过示例看看Istio能做什么

• 这里以一个天气预报应用中forecast服务对recommendation服务的访问为例

• Istio做了什么
  • 自动通过服务发现获取recommendation服务实例列表，并根据负载均衡策略选择一个服务实例
  • 对服务双方启用双向认证和通道加密
  • 如果某个服务实例连续访问出错，则可以将该实例隔离一段时间，以提高访问质量
  • 设置最大连接数、最大请求数、访问超时等对服务进行保护
  • 限流
  • 对请求进行重试
  • 修改请求中的内容
  • 将一定特征的服务重定向
  • 灰度发布
  • 自动记录服务访问信息
  • 记录调用链，进行分布式追踪
  • 根据访问数据形成完整的应用访问拓
• 所有这些功能，都不需要用户修改代码，用户只需在 Istio 的控制面做些配置即可，并且动态生效

1.3 Istio与服务治理

• Istio是一个服务治理平台，治理的是服务间的访问，只要有访问就可以治理，不在乎这个服务是不是所谓的微服务，也不要求跑在其上的代码是微服务化的

1.3.1 关于微服务

• Martin Fowler对微服务的描述是“微服务是以一组小型服务来开发单个应用程序的方法，每个服务都运行在自己的进程中，服务间采用轻量级通信机制（通常用 HTTP 资源API）
• 微服务在本质上还是分而治之、化繁为简的哲学智慧在计算机领域的一个体现

• 这种方式带给我们很多好处
  • 从开发视角来看，每个微服务的功能更内聚，可以在微服务内设计和扩展功能，并且采用不同的开发语言及开发工具
  • 从运维视角来看，在微服务化后，每个微服务都在独立的进程里，可以自运维；更重要的是，微服务化是单一变更的基础，迭代速度更快，上线风险更小
  • 从组织管理视角来看，将团队按照微服务切分为小组代替服务大组也有利于敏捷开发
• 微服务机制带来了大量的工作，比如服务如何请求目标服务，需要引入服务发现和负载均衡等，以及对跨进程的分布式调用栈进行分布式调用链追踪，等等

1.3.2 服务治理的三种形态

• 服务治理的演变至少经过了以下三种形态

第1种形态：在应用程序中包含治理逻辑

• 微服务越多，重复的代码越多，维护越难；而且，业务代码和治理逻辑耦合，不管是对治理逻辑的全局升级，还是对业务的升级，都要改同一段代码

第2种形态：治理逻辑独立的代码

• 在解决第1种形态的问题时，我们很容易想到把治理的公共逻辑抽象成一个公共库，让所有微服务都使用这个公共库
• 非常典型的这种服务治理框架就是Spring Cloud。这种形态的治理工具集在过去一段时间里得到了非常广泛的应用
• SDK模式虽然在代码上解耦了业务和治理逻辑，但业务代码和 SDK还是要一起编译的，业务代码和治理逻辑还在一个进程内
• 业务代码必须和 SDK 基于同一种语言，即语言绑定

• SDK对开发人员来说有较高的学习门槛，虽然各种SDK都会讲如何开箱即用，但如果只是因为需要治理逻辑，就让开发人员放弃自己熟悉的内容去学习一套新的语言和开发框架，可能代价有点大

第3种形态：治理逻辑独立的进程

• SDK模式仍旧侵入了用户的代码，那就再解耦一层，把治理逻辑彻底从用户的业务代码中剥离出来，这就是如图1-7所示的Sidecar模式

• 比较以上三种服务治理形态，我们可以看到服务治理组件的位置在持续下沉，对应用的侵入逐渐减少

1.3.3 Istio不只解决了微服务问题

• 微服务作为一种架构风格，更是一种敏捷的软件工程实践，说到底是一套方法论；与之对应的 Istio 等服务网格则是一种完整的实践，Istio 更是一款设计良好的具有较好集成及可扩展能力的可落地的服务治理工具和平台
• 从场景来看，Istio管理的对象大部分是微服务化过的，但这不是必需的要求
• 从能力来看，Istio对服务的治理不只包含在微服务中强调的负载均衡、熔断、限流这些一般治理能力，还包含诸多其他能力

1.4 Istio与服务网格

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

1.4.1 时代选择服务网格

• 在云原生时代，随着采用各种语言开发的服务剧增，应用间的访问拓扑更加复杂，治理需求也越来越多
• 首先，从单个应用来看，Sidecar与应用进程的解耦带来的应用完全无侵入、开发语言无关等特点解除了开发语言的约束，从而极大降低了应用开发者的开发成本
• 然后，从全局来看，在多个服务间有复杂的互相访问时才有服务治理的需求
• 最后，Sidecar是网格动作的执行体，全局的管理规则和网格内的元数据维护通过一个统一的控制面实现

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

• 这就引入两个问题
  • 增加了两处延迟和可能的故障点
  • 多出来的这两跳对于访问性能、整体可靠性及整个系统的复杂度都带来了新的挑战
• 其中，后者本来就属于基础设施层面可维护性、可靠性的范畴，业界的几个产品都用各自的方式在保证
• 另外，对于这些高性能的代理，只要消耗足够的资源总能达到期望的性能，特别是云原生场景下服务的弹性特点使得服务实例的弹性扩展变得非常方便，通过扩展实例数量总是能得到期望的访问性能
• 对于考虑使用服务网格的用户来说，事情就会变成一个更简单的选择题：是否愿意花费额外的资源在这些基础设施上来换取开发、运维的灵活性、业务的非侵入性和扩展性等便利。相信，

1.4.2 服务网格选择Istio

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

• 首先，在控制面上，Istio作为一种全新的设计，在功能、形态、架构和扩展性上提供了远超服务网格的能力范围
• 然后，在数据面的竞争上，Istio的标准数据面Envoy是由Lyft内部于2016年开发的，比 Linkerd更早
• 最后，在大厂的支持上，Istio 由谷歌和 IBM 共同推出，从应用场景的分析规划到本身的定位，从自身架构的设计到与周边生态的结合，都有着比较严密的论证
• 云原生社区的定位与多个云厂商的规划也不谋而合。华为云已经在 2018 年 8 月率先在其容器服务CCE（Cloud Container Engine）中内置Istio；Google的GKE也在2018年12月宣布内置 Istio；越来越多的云厂商也已经选择将 Istio作为其容器平台的一部分提供给用户，即提供一套开箱即用的容器应用运行治理的全栈服务

1.5 Istio与Kubernetes

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

1.5.1 Istio，Kubernetes的好帮手

• Istio复用了Kubernetes Service的定义，在实现上进行了更细粒度的控制。Istio的服务发现就是从 Kube-apiserver中获取 Service和 Endpoint，然后将其转换成 Istio服务模型的 Service 和 ServiceInstance，但是其数据面组件不再是 Kube-proxy，而是在每个 Pod 里部署的 Sidecar，也可以将其看作每个服务实例的 Proxy。这样，
• 甚至有人认为 Istio 就是 Kubernetes团队开发的 Kubernetes可插拔的增强特性

1.5.2 Kubernetes，Istio的好基座

数据面

• 数据面Sidecar运行在Kubernetes的Pod里，作为一个Proxy和业务容器部署在一起。用户甚至感知不到部署 Sidecar的过程。用户还是用原有的方式创建负载，通过 Istio 的自动注入服务，可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy，则不会有这样的便利

统一服务发现

• Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成，省去了再搭一个类似 Eureka 的注册中心的麻烦，更避免了在 Kubernetes 上运行时服务发现数据不一致的问题

基于Kubernetes CRD描述规则

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

1.6 本章总结

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