Istio设计理念

PS：《Service Mesh实战》笔记

解决的问题：当前越来越多的微服务、系统调用及流量，如何才能有效的管理起来？而且同时还要支持不同的语言及不同的部署平台。

优势：

• 针对HTTP、gRPC、WebSocket及TCP等协议的自动负载均衡。
• 精细的请求流量控制，支持众多路由、重试及容灾层面上的规则，支持故障模拟。
• 模块化插件扩展支持，可通过API进行访问、频率限制及配合方面的控制。
• 全自动化的请求遥测（Telemetry）、日志分析及全链路跟踪系统，所有的请求都在掌控之内。
• 全链路安全访问控制与身份认证

核心意义：适配多种Pass平台，把调用链路相关工作从业务逻辑中彻底剥离出来。形成“数据平面”，再通过添加“控制平面”进行统一控制，把整个链路负载工作都下沉到了PaaS技术栈上层，业务开发工程师不在需要关心内部实现，就像使用云服务一样简单。

结构划分：

• 数据平面：网关代理组成，服务之间的桥梁。与Nginx不同的是，API实时接收配置并生效，实现动态化的流量代理。

  • Sidecar: 用来将不同的节点形成“数据平面”这个面。在K8S的生态中，Sidecar会被自动注入Pod（也可以手动注册），将其后面的服务纳入Service Mesh的生态中。

• 控制平面：对“数据平面”中网关的统一配置与维护平台。配置包含：请求路由，还包括限流降级、熔断、日志收集、性能监控等。其中控制平面由被划分成了Pilot、Mixer、Citadel。

  • Pilot：为数据平台的Sidecar提供服务发现能力。其本身并不做服务注册，只提供一个接口，对接已有的服务注册系统。
  • Mixer：负责在服务调用之间实施控制策略，同时在调用间收集请求到的遥测数据。抽象逻辑上可以分为两个方面：1. 后端逻辑抽象：将后端功能实现细节抽象化屏蔽，只留下直观的接口，方便调用与扩展；2. 中心化的控制：对每个请求进行细致的控制，让任何通信都处于管控范围内。
  • Citadel：对非加密的请求进行安全强化，将其升级至加密的安全传输。Citadel提供安全性非常强的服务到服务（Service-to_Service）以及用户到用户（User-to-User）的认证功能，内置角色与秘钥管理，支持基本的RBAC。