服务网格的未来Part 2:Istio 1.0之后何去何从?

2018年11月1日 | 作者 Stephen McPolin & Venil Noronha | 译者 陈冬 | 审校者 宋净超 | 1200字 | 阅读大约需要3分钟
查看原文 | 归档于 translation | 标签 #servcie mesh

在服务网格系列的第一部分中,我们认为服务网格是微服务体系架构发展的必然和有益的结果。随着 Istio 1.0 的发布,我们在服务网格领域已经经过了一个重要的里程碑,在这个重要的的时间节点上,我们需要思考服务网格的未来将如何发展。

在 VMware 我们非常愿意花时间和精力支持开源的服务网格架构。我们已经成为 Istio 和 Envoy(Istio 用来动态控制微服务的特定的开源服务代理)的贡献成员。我们在改善网络方面投入了大量的精力,同时在其他领域贡献力量。

我们考虑到几乎每个 Istio 的演示目前都是基于一个单一的示例。保加利亚的一位 VMware 同事目前正在构建一个全新的 Istio 演示示例,用于演示如何在封闭字幕等服务之间管理视频质量,并演示 Istio 在微服务环境中的动态路由的能力。

因为我们认为服务网格是有价值的,而且可以一直存在,所以我们一只在寻求将 VMware 自己的世界级系统管理工具集与服务网格框架进行集成。这里有一个很好的例子,我们最近创建了一个适配器,将 Istio metrics 导出到 VMware 的 Wavefront 监测和分析工具中。如果我们能够将微服务中的更多信息合并到我们的系统管理工具中,我们相信这些工具能够更好的管理系统。

从我们的角度来看,这样的工作是为了扩大微服务生态系统。然而,服务网格平台本身还不够完善。比如说,Istio 是一个复杂的软件,当它不能正常工作时很难调试。当它在工作,它能很好的帮助你监测你的微服务是否正常运行。当它不能正常工作,又很难弄清楚它为什么不能工作。这种复杂度已被社区中被广泛理解的,并且我们一直在花时间和精力思考如何克服这种复杂性,但目前我们还没有解决这个问题。

目前服务网格平台刚开始处理多集群情况。如果你将应用部署在单集群上,可以使用 Istio 和 Envoy 这样的应用管理他们。但是当你希望将单集群扩展到多集群,并让服务在集群边界上进行通信(从安全的角度来看是一个好想法),那这将是一个挑战。社区理解 Istio 这样的情况,于我们而言,正在逐步改进设计以支持多集群管理。

至此,我们正在关注一个新的提议,来自 Google 的 Knative。从根本上说,这是基于 Google 的“函数即服务”概念,从 Kubernetes 和 Istio 中衍生出来的。在不久的将来,它将向 Istio 提出更多的需求,但是目前还不清楚这些需求从何而来。例如,“事件”对于 Istio 来说是一个完全陌生的概念,但是对于处理临时数据还是必要的。Knative 则增加了这方面的组件,并推向 Istio 的下层。

现在,我们只是在看到 Space—Knative 推出了大约一个半月,并且还有很多问题没有解决,在我们决定如何应对这些问题之前,我们也在寻求新的变革。因此,现在还有很多的事情要做,同时也有很多需要关注的地方。但是可以肯定的是,服务网格会有持续发展。

请继续在 Open Source Blog 关注我们对服务网格系列后续的更新,并在Twitter上关注我们(@vmwopensource)。