多运行时微服务架构（系列四）

未来架构趋势

从广义上看，我们可以得出结论，通过将功能移动到平台级别，分布式应用程序的商品化达到了新的前沿。除了生命周期之外，现在我们还可以观察到网络、状态抽象、声明性事件和端点绑定也是现成的，EIP 是此列表中的下一个。有趣的是，商品化是使用进程外模型（sidecar）进行功能扩展，而不是运行时库或纯平台功能（例如新的 Kubernetes 功能）。

我们现在正在将所有传统的中间件功能（又名 ESB）移动到其他运行时中，很快，我们在服务中要做的就是编写业务逻辑。

传统中间件平台和云原生平台概述

与传统的 ESB 时代相比，这种架构更好地将业务逻辑与平台分离，但尚未完全分离。许多分布式原语，例如经典的企业集成模式 （EIP）：拆分器、聚合器、过滤器、基于内容的路由器;和流式处理模式：映射、过滤、折叠、连接、合并、滑动窗口;仍然必须包含在业务逻辑运行时中，许多其他依赖于多个不同且重叠的平台附加组件。

如果我们把在不同领域进行创新的各种云原生项目堆叠起来，我们最终会得到如下图片：

多运行时微服务

此处的图表仅用于说明目的，它有意选择具有代表性的项目并将它们映射到分布式原语类别。实际上，您不会同时使用所有这些项目，因为其中一些项目是重叠且不兼容的工作负载模型。如何解释此图？

• Kubernetes 和容器在多语言应用程序的生命周期管理方面取得了巨大的飞跃，并为未来的创新奠定了基础。
• 服务网格技术通过高级网络功能改进了 Kubernetes，并开始利用应用程序问题。
• 虽然 Knative 主要通过快速扩展专注于无服务器工作负载，但它也解决了服务编排和事件驱动的绑定需求。
• Dapr 以 Kubernetes、Knative 和 Service Mesh 的思想为基础，深入到应用程序运行时中，以解决有状态的工作负载、绑定和集成需求，充当现代分布式中间件。

此图旨在帮助您可视化，将来很可能我们最终将使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务将由多个运行时组成，很可能是两个运行时 - 自定义业务逻辑运行时和分布式基元运行时。