《 ServiceMesh究竟解决什么问题? 》
《 Istio究竟是什么? 》
《 Istio分层架构设计? 》
Istio 架构体系中,流控 (Traffic Management) 虽然是数据平面的 Envoy Proxy 实施的,但整个架构的核心其实在于控制平面的 Pilot 。
灰度发布的过程在《Istio,灰度发布》一文中已经有过描述,今天重点说说 Pilot 和 Envoy 的交互流程与内部结构。
图示:
灰色圆形,为业务服务
紫色六边形,为 Envoy 代理
二者相生相伴。
起初,上游调用方 ServiceA 访问下游服务提供方 ServiceB 的V1版本,在 ServiceB 的V2版本部署好之后,调用方如何知道“ SvcA 切分1%的流量至 SvcB 的V2版本”这个指令的呢?
整个过程主要分为 三大步骤 :
(1)用户在控制平面的后台,通过 Pilot 的API,修改A到B的路由策略 (标号1) ;
(2) Pilot 将路由策略固化存储,以便未来新注册的调用方A能够知道当前最新的路由策略;对于已经存在的调用方A, Pilot 则通过主动通知的方式告之调用方A对应的 Envoy (标号2) ;
(3) Envoy 作为数据平面,实施最新的路由策略 (标号3) ,在本例中,即将1%的流量导给灰度版本Bv2;
讲了通用的流控策略实施通用流程 ,而服务发现与负载均衡,只是一个种策略实施的特例:
(1)提供服务的 SvcB 新增一个 Pod (标号1) ;
(2)在 Pilot 后台修改 SvcB 的集群配置 (标号2) ;
(3) Pilot 将 SvcB 的最新信息同步给该配置的订阅方 (标号3) ,即 SvcB 的调用方 SvcA 对应的 Proxy ;
(4) SvcA 对应的 Proxy 增加到 SvcB 的链接 (标号4) ,并实施负载均衡;
画外音:实际是链接到 SvcB 对应的 Proxy 。
整个过程,与使用配置中心来实施服务发现基本类似。
ServiceMesh 的核心,是 技术基础设施与业务服务的解耦 ,服务A调用服务B,再次强调:
一个容器 Pod 内的一个服务, 服务进程( SrvA/SrvB )和边车进程( Proxy ) 是相生相伴的,他们之间的交互是 本地交互 (标号1)
跨容器 Pod 之间的 远程调用 ,必须 通过 Proxy 进行 (标号2)
言下之意,服务A调用服务B,请求的流程是:
SvcA -> SvcA Proxy -> SvcB Proxy -> SvcB
响应的流程则反过来:
SvcB -> SvcB Proxy -> SvcA Proxy -> SvcA
跨网之间调用, 请求的入口和出口,都是 Proxy 。
Pilot 它的内部结构并不复杂:
(1) Pilot 的核心,是各种流控策略的维护, Abstract Model ;
(2)必然, Pilot 需要提供接口给用户,增删查改这些策略, Rules API ;
(3)一方面, Pilot 需要保持各类底层基础设施的兼容性, Platform Adapter ;
(4)另一方面, Pilot 又需要保持不同 Proxy 实接口的兼容性, Envoy API ;
这么设计的好处是:
Istio 设计时已经考虑了异构的基础设施,不管底层是 K8s 还是其他体系,都可以兼容
任何第三方可以实现自己的 proxy ,只要符合相关的API标准,都可以和 Pilot 集成
Pilot 与 Envoy 的配合,是 Istio 的核心,如此一来:
服务发现 (discovery)
负载均衡 (load balancing)
故障恢复 (failure recovery)
服务度量 (metrics)
服务监控 (monitoring)
A/B测试 (A/B testing)
灰度发布 (canary rollouts)
限流限速 (rate limiting)
等很多能力都可以实现了。
MerviceMesh 并没有大家想的复杂。
思路 比结论重要。
架构师之路 -分享技术思路
相关文章:
《 ServiceMesh究竟解决什么问题? 》
《 Istio究竟是什么? 》
《 Istio分层架构设计? 》
《 Istio,灰度发布 》