Istio核心流程是怎么实现的
更新:HHH   时间:2023-1-7


本篇内容介绍了“Istio核心流程是怎么实现的”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

一、通用交互流程

图示:

  • 灰色圆形,为业务服务

  • 紫色六边形,为Envoy代理

二者相生相伴。

起初,上游调用方ServiceA访问下游服务提供方ServiceB的V1版本,在ServiceB的V2版本部署好之后,调用方如何知道“SvcA切分1%的流量至SvcB的V2版本”这个指令的呢?

整个过程主要分为三大步骤:

  • 用户在控制平面的后台,通过Pilot的API,修改A到B的路由策略(标号1);

  • Pilot将路由策略固化存储,以便未来新注册的调用方A能够知道当前***的路由策略;对于已经存在的调用方A,Pilot则通过主动通知的方式告之调用方A对应的Envoy(标号2);

  • Envoy作为数据平面,实施***的路由策略(标号3),在本例中,即将1%的流量导给灰度版本Bv2;

二、服务发现与负载均衡

讲了通用的流控策略实施通用流程,而服务发现与负载均衡,只是一个种策略实施的特例:

  • 提供服务的SvcB新增一个Pod(标号1);

  • 在Pilot后台修改SvcB的集群配置(标号2);

  • Pilot将SvcB的***信息同步给该配置的订阅方(标号3),即SvcB的调用方SvcA对应的Proxy;

  • 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内部结构

Pilot它的内部结构并不复杂:

  • Pilot的核心,是各种流控策略的维护,Abstract Model;

  • 必然,Pilot需要提供接口给用户,增删查改这些策略,Rules API;

  • 一方面,Pilot需要保持各类底层基础设施的兼容性,Platform Adapter;

  • 另一方面,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并没有大家想的复杂。

“Istio核心流程是怎么实现的”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注天达云网站,小编将为大家输出更多高质量的实用文章!

返回开发技术教程...