关于云原生-cloud-native:专访-Christian-PostaIstio-17-将成为生产可用的最稳定版本

3次阅读

共计 3114 个字符，预计需要花费 8 分钟才能阅读完成。

作者 | 田晓旭、Christian Posta

2017 年，Istio 公布了 0.1 release 版本之后，其优雅的架构设计就取得了大家的认可。随着版本迭代，有开发者吐槽 Istio 太简单。于是，Istio 1.5 版本颠覆了之前的架构设计，提出了“回归单体”的架构设计，1.6 版本的 Release note 更是在开篇就表明了要将极简主义进行到底。

Istio 1.5 和 1.6 版本的架构设计变动引发了泛滥开发者的探讨，大家都很关怀 Istio 架构简化将会走向何方？行将推出的 1.7 版本又会有哪些惊喜？万众期待的 Envoy 与 WebAssembly 集成的进度如何？…… 为了揭开以上问题的答案，在云原生微服务大会揭幕之际，咱们采访到了前 Red Hat 首席架构师、Istio in action 作者、solo.io Field CTO Christian Posta。

从 1.5 版本开始，Istio 就走上了架构简化的路线，这是因为 Istio 本身的管制面组件在运维方面遇到了很多难题，例如治理职责划分的问题，将管制组件拆分进去的初衷是为了拆散性能职责，由不同的运维或开发人员独自治理，然而理论利用中，运维往往是由一个人或团队治理，并没有起到独自治理的作用；部署简单的问题，组件拆分之后，零碎的可运维性难度陡然回升，增多的配置和参数减少了部署的复杂性等等。

正是因为这些复杂性，GitHub 中呈现了各种各样的部署相干 issue，例如 lstio operator、Istioctl 等等，但遗憾的是均未获得突破性的停顿。Istio 1.5 版本大胆进行了一次“自我反动”，将管制立体的所有组件组合并成一个单体构造 Istiod。

Istiod 的设计初衷是“How I Learned to Stop Worrying and Love the Monolith”，并在一开始就明确提出了设计指标：升高装置复杂度、升高配置复杂度、减少管制面可运维性、进步问题诊断能力、提高效率和响应速度、打消不必要的耦合。Istiod 是一个单体，反对以前版本的所有性能，之前组成管制立体的服务在我的项目中依然是作为子模块实现（包含边界和契约等），但操作体验失去改善。

Istio 1.6 版本其实是对 1.5 版本未实现工作的收尾，其中最大的简化工作是将原有组件的性能齐全整合入 Istiod，让 Istiod 更加残缺，也彻底移除了 Citadel、Sidecar Injector 和 Galley。另外，增加了 istioctl install 命令来代替 manifest apply 的装置过程，用更直观、更精简的命令改善装置过程的体验。

通过 1.5 和 1.6 两个版本的迭代，Istio 的架构简化曾经逐步成型，然而目前仍有性能和需要未能实现，例如完结 Mixer 之后，中心化的限流、黑白名单等性能还未呈现相应的弥补措施。因而，大家对于 Istio 1.7 版本充斥了期待与好奇，接下来咱们就看看 Christian Posta 是如何解读 Istio 将来发展趋势的。

Q：Istio 1.5 版本提出了要“回归单体”，接着 1.6 版本提出了将极简主义进行到底，社区对于 Istio 架构的简化工作是如何思考的？

Christian Posta：在 Istio 1.5 公布之前，我写过一篇具体的博客《Istio as an example of when not to do microservices》来探讨这个问题。在博客中，我探讨了构建分布式组件（微服务）的动机以及一些毛病，摸索了 Istio 我的项目从新架构的动机，其中一个非常明显的起因是分布式组件的技术红利并未实现。咱们须要十分坦诚地评估零碎架构过程中的衡量（tradeooff），尤其是当这些衡量（tradeooff）最终无奈使零碎取得技术红利。这时候，最好是“修改路线”，这正是 Istio 所做的。

https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/

Q：Istio 的版本公布周期改为了季度公布，那么新的版本中有哪些能够走漏的新性能？

Christian Posta：Istio 1.7 版本很快就会公布（Beta 2 8 月 12 日才公布），此版本的一些次要性能是用于多个群集的地方 Istiod 控制器，对 VM 反对的继续加强，还有最重要的是稳定性方面的改良。

Q：国内很多技术人员都很关怀 Envoy 与 WebAssembly 的强强联手，不晓得社区当初有什么动作和布局？

Christian Posta：没错! WebAssembly（WASM）越来越靠近集成到上游 Envoy proxy 我的项目中，并且咱们始终在致力改善应用 WASM 和 WASM + Envoy 的开发体验。咱们在 2019 年 12 月发表了 WebAssembly Hub，并在 2020 年 3 月对 Istio 1.5 进行了重大改良，特地是应用 wasme（WebAssembly Hub CLI）来作为应用 WebAssembly 扩大 Istio 的官网正式办法。一般而言，WASM 和 WASM + Envoy 都在与社区进行单干中，并且还有很多工作要做，敬请期待！

Q：Kubernetes 在 1.8 版本的时候根本曾经稳固，当初 Istio 曾经到了 1.6 版本，您预测 Istio 到哪个版本能够达到稳固？

Christian Posta：对于要防止应用哪些版本、要采纳哪些版本，我始终很坦诚。能够这么讲，在 1.5 之前的 1.x 系列中，1.4.x 是最稳固的。当初，在 1.5 之后，我认为行将推出的 1.7 会成为生产可用的稳固版本。

Q：您是如何看到目前寰球整个 Service Mesh 的市场格局？Istio 在这个格局中又表演什么样的角色？

Christian Posta：Service Mesh 的寰球市场仍在迅速倒退！早在 2018 年 11 月的 Solo.io，咱们就预测将有多个网格实现，并且没有显著的胜者。这个预测曾经实现。市面上不仅有多个服务网格选项，云厂商们都开始提供本人的服务网格实现。例如 AWS AppMesh、Google Traffic Director、阿里云 ASM，最近，微软引入了 Open Service Mesh，咱们置信它将成为微软云的一部分。咱们在 Solo.io 建设了 Service Mesh Hub，以帮忙加重这种波动性和多样性，以对立跨多个服务网格部署的各种工作负载。总体而言，咱们当初看到越来越多的组织开始采纳开源或厂商提供的服务网格技术，而不是自建。我集体认为，Istio 将持续成为组织用于“自治理”服务网格的主导服务网格技术，并将长期与云厂商的服务网格一起倒退上来。

嘉宾介绍

Christian Posta 前 Red Hat 首席架构师、Istio in action 作者、solo.io Field CTO。在金融、保险、批发等传统行业从事分布式系统的开发工作近 20 年。从 Kubernetes 1.0 版本前，就始终在应用 K8s，并始终参加社区工作；在 Istio 公开公布之前，在社区中就十分沉闷。目前在 Solo.io 负责 Field CTO，全职致力于构建下一代 API 基础设施，包含 API 网关、服务网格、Web Assembly 等等。

首届云原生微服务大会正在炽热直播中，点击 PC 端地址即可观看：https://developer.aliyun.com/topic/microservices2020#/