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。
Istio 逐步走向架构简化
从 1.5 版本开始，Istio 就走上了架构简化的道路，这是因为 Istio 自身的控制面组件在运维方面遇到了很多难题，例如管理职责划分的问题，将控制组件拆分出来的初衷是为了分离功能职责，由不同的运维或开发人员单独管理，但是实际应用中，运维往往是由一个人或团队管理，并没有起到单独管理的作用；部署复杂的问题，组件拆分之后，系统的可运维性难度陡然上升，增多的配置和参数增加了部署的复杂性等等。
http://www.sipaiyibiao.com/article/liuliangyibiao/73.html
正是因为这些复杂性，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 的安装过程，用更直观、更精简的命令改善安装过程的体验。
Istio 的未来发展趋势
经过 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 所做的。
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 等等。