华为云DevOps系列之 —— 持续运维与监控（六）应用服务网络

服务治理的三种实现方式

第一代

• 服务治理能力内嵌在业务代码中
  
• 业务代码中除了要完成常用的一些业务功能之外，还要完成一些服务，发现和负责这些动态路由等制约的逻辑
• 优点
  • 简单使用依赖少
• 弊端
  • 代码耦合、代码重复高
  • 运维负载、开发要求高

第二代

• 服务治理能力抽象到统一 SDK 实现
  
• 公布的代码放在一个 SDK 里面，向用户提供职业的能力、
• 优点
  • 代码重复少
  • 治理逻辑代码和业务代码分开
• 弊端
  • SDK 语言绑定
  • 代码侵入
  • 基于 SDK 开发学习门槛高
  • 在用系统改造代价大
  • 治理能力升级影响用户业务

第三代

• 服务治理能力归一到服务网格
  
• 将逻辑从业务的进程中彻底地提取出来，成为一个独立的进程。如上图，两个服务之间相互访问的时候，流量会被 proxy 拦截，proxy 来执行各种制约的逻辑
• 各种业务代码用专注于自己的业务处理机构
• 优点
  • 独立进程，用户业务非侵入
  • 语言无关
  • 治理逻辑升级业务无感知
  • 已有系统无需改造即可治理
  • 可以渐进的微服务化
• 弊端
  • 代理的性能和资源开销

比较以上三种形态，可以比较明显看出来一个差别：治理逻辑的位置在逐步地下降，由业务的代码到提出出来，和业务的解耦合越来越低，治理的位置也越来越和技术的设施进行融合

服务网格：一种云原生、应用层的、网络技术

• 所有的 APP 经过 proxy 的拦截，在 proxy 上执行 APP 之间访问的一些制约逻辑，但是 APP 本身感知不到 proxy 的存在，它还会像原来的方式一样互相访问
• 为了对付网格上的数据链进行统一的治理规则下发和统一的管理，一般网络都会有上面的一个服务叫 控制面，它是数据面的 proxy 下发策略、下发治理的逻辑，并且对 proxy 进行一些管理，这里的服务网格这种形态，提供了一个透明的代理，来完成它们之间访问的治理
• 在当前的语言生产环境下，特别是服务方案比较频繁的时候，向用户提供一个透明的，高性能的治理形态
• 从 云原生 的角度看：面向弹性、（微）服务化、去中心化业务场景
• 从 业务场景 的角度看：以应为中心，关注应用的发布、监控、恢复等
• 从 网络 的角度看：关注应用组件之间的接口、流量、数据、访问安全等
• 传统我们在网络上用到的东西在网格中都有体现

Istio

• Istio 是一个提供连接、保护、控制以及观测功能的开放平台，通过提供完整的非侵入式的微服务治理解决方案，能够很好的解决云原生服务的管理、网络连接以及安全管理等服务网络治理问题
• 从治理逻辑上来看，其本身是一个场景上和 K8S 紧密结合的，对于 K8S 来说，它本身提供了一个复杂的部署，因为扩缩容的问题，并且 K8S 有一个非常核心的概念，即本身提供了 服务发现 和 健康检查 的能力，但是对于 K8S 来说，它主要是提供在 4 层，它关注的主要还是一个 Service 可以互相访问的问题，如果用户相对 Service 进行一个 更细致化的管理（比如传统微服务中心的熔断），在 K8S 中是无法支持的，因为 K8S 本身的工作粒度是在每个节点上，而且只处理 4 层的一个能力。但是如果叠加上了 Istio 就可以解决这个问题，比如说典型的结合场景中间，Istio 就可以提供 K8S Service 的熔断、限流、动态路由、调用链追踪等服务访问管理的能力
• 服务网格（Service Mesh）通常用于描述构成应用程序的微服务网络以及应用之间的交互。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等

Istio + Kubernetes：云原生应用治理 + 云原生应用设施

• 微服务和容器都有共同的 轻量、敏捷 的特点，微服务运行在容器中日益流行
• K8S 在容器编排领域成为事实标准
• Istio 和 K8S 紧密结合，基于 K8S 构建，补齐了 K8S 的治理能力，提供了端到端的微服务运行治理平台
• Istio 提供 ServiceMesh 方式无侵入微服务治理能力，成为微服务治理的趋势

对于云原生应用，采用 Kubernetes 构建微服务部署和集群管理能力，采用 Istio 构建服务治理能力，将逐渐成为应用微服务转型的标准配置

Istio 服务架构

• 如图为 Istio 的主要架构，我们可以看到上面是 数据面，下面是 控制面，Service A 访问 Service B 的时候，，流量会被 Proxy 拦截，比如说 Service 出的流量会被左边的 Proxy 拦截，在进入 Service B 之前，也会被 Service B 的 Proxy 拦截
• Proxy 拦掉流量之后就可以执行控制面的各种流量规则，比如比较常用的利用配置的灰度的规则来做一些灰度发布，配置一些熔断、限流等相关能力，以及图上标注的 mTLS，也就是说 Service A 和 Service B 可以是一个简单的服务，但是，通过配置可以开启 Service A 和 Service B 之间访问的一个双向认证，这些对应用来说是透明的，业务代码也会非常的简单，所有的治理的逻辑只要一键启动就可以使用
• 控制面 包含了三个部分
  • Pilot·：传统的组件统一的网格管理方式
  • Mixer：完成一个全统一的策略和遥感数据以及网络数据的收集，
  • Citadel：可以给 Proxy 之间进行动态的维护证书，进行证书的过期替换，由于组件的存在才可以透明的向网格提供安全的能力

Istio 遵从 Kubernetes 架构：CRD、容器化、Pod

• Istio 和 K8S 结合中间的数据面 Envoy 是透明的，驻在 K8S Pod 里面
• 用户使用的时候完全不用感知 Proxy 的部署、安装以及升级的过程，即整个部署的过程对用户来说是透明的
• K8S 本身提供了服务发现的能力，无需用户建立一个服务注册，K8S 可以从中提取和转化过来
• 本身的配置都是 K8S 的 CRD 对象，所以可以通过 Kube 就可以对网格进行个人的策略管理

Istio 关键功能

• 流量管理 - Pilot
  • 负载均衡
  • 动态路由
  • 灰度发布
  • 故障注入
• 可观察性 - Mixer
  • 调用链
  • 访问日志
  • 监控
• 策略 - Mixer
  • 限流
  • ACL
  • 配额
  • 计费
• 认证安全 - Citadel
  • 认证
  • 授权
  • 审计

Istio 与 Spring Cloud 的对比

思考题

（判断）限流是为了改变网络流量所经过的途径而修改路由信息的技术

答案：True

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊