Istio作为服务网格技术的代表作,通过sidecar代理拦截了微服务之间的所有网络通信,用统一方式实现服务之间的负载均衡、访问控制、速率限制等功能。应用无须了解底层服务访问细节,sidecar和应用可以独立升级,实现了应用逻辑与服务治理能力的解耦。Istio架构设计有4个关键目标,即:最大化透明度、可扩展性、可移植性、策略一致性。

一、Istio架构

Istio架构示意图,逻辑上分为数据平面和控制平面。

 1 Istio架构

数据平面由一组以sidecar方式部署的智能代理(Envoy)组成。这些代理可以调节和控制微服务及Mixer之间所有网络通信。

控制平面通过负责管理和配置代理来路由流量

●Pilot∶负责流量管理。

●Mixer∶负责提供策略控制和遥测收集。

●Citadel∶负责提供通信的安全保护。

 

二、Istio架构设计的关键目标

Istio 架构设计中有几个关键目标,这些目标对于系统能够应对大规模流量和提供高性能服务处理至关重要。

(一)最大化透明度

若想Istio被采纳,应该让运维和开发人员只需付出很少代价就可以从中受益。为此, Istio 将自身自动注入到服务间所有网络路径中。Istio使用sidecar代理来捕获流量,并且在尽可能的地方自动编程网络层,将流量路由到这些代理,而无须对已部署的应用程序代码进行任何改动。在Kubernetes中,代理被注入到Pod中,通过编写iptables规则来捕获流量。注入 sidecar代理到 Pod 中并且修改路由规则后, Istio 就能够调解所有流量。这个原则也适用于性能。当lstio应用于部署时,运维人员可以发现,为提供这些功能而增加的资源开销很小。所有组件和API在设计时都必须考虑性能和规模。

(二)可扩展性

随着运维人员和开发人员越来越依赖Istio提供的功能,系统必然和需求一起成长。虽然我们期望自己继续添加新功能,但是预计最大的需求是扩展策略系统、集成其他策略和控制来源,并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外,它允许扩展词汇表,以允许基于网格生成的新信号来执行策略。

(三)可移植性

使用 lstio 的生态系统将在很多维度上有差异。lstio必须能够以最小的代价运行在任何云或预置环境中。将基于Istio的服务移植到新环境应该是轻而易举的,而使用Istio将一个服务同时部署到多个环境中也是可行的

(四)策略一致性

在服务间的API调用中,策略的应用使得可以对网格间行为进行全面控制,但对于无须在API级别表达的资源来说,对资源应用策略也同样重要。例如,将配额应用到机器学习训练任务消耗的CPU数量上,比将配额应用到启动这个工作的调用上更为有用。因此,策略系统需要从代理中独立出来作为独特的服务来维护,并应具有自己的API。

原文地址:http://www.cnblogs.com/tiduyun/p/16848610.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性