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

云原生趋势

传统的中间件功能强大。它具有所有必要的技术功能，但缺乏快速变化和扩展的能力，这是现代数字业务需求所要求的。这就是微服务架构及其设计现代分布式应用程序的指导原则所要解决的问题。

微服务背后的思想及其技术要求有助于容器和 Kubernetes 的普及和广泛使用。这开启了一种新的创新方式，它将在未来几年影响我们处理分布式应用程序的方式。让我们看看 Kubernetes 和相关技术如何影响每组需求。

Lifecycle

容器和 Kubernetes 发展了我们将应用程序打包、分发和部署为独立于语言的格式的方式。有很多关于 Kubernetes 模式和 Kubernetes 对开发人员的影响的文章，我将在这里保持简短。但请注意，对于 Kubernetes，要管理的最小原语是容器，它专注于在容器级别和流程模型交付分布式原语。这意味着它在管理应用程序的生命周期方面、运行状况检查、恢复、部署和扩展方面做得很好，但它在改进容器内的分布式应用程序的其他方面做得不好，例如灵活的网络、状态管理和绑定。

你可能会指出，Kubernetes 具有有状态的工作负载、服务发现、cron 作业和其他功能。这是真的，但所有这些原语都处于容器级别，在容器内部，开发人员仍然必须使用特定于语言的库来访问我们在本文开头列出的更精细的功能。这就是推动Envoy，Linkerd，Consul，Knative，Dapr，Camel-K等项目的原因。

Networking

事实证明，Kubernetes 提供的围绕服务发现的基本网络功能是一个很好的基础，但对于现代应用程序来说还不够。随着微服务数量的增加和部署速度的加快，对更高级的发布策略、管理安全性、指标、跟踪、从错误中恢复、模拟错误等的需求变得越来越有吸引力，并自行创建了一类新的软件，称为服务网格。

这里更令人兴奋的是，将与网络相关的问题从包含业务逻辑的服务转移到单独的运行时中，无论是挎斗还是节点级代理。今天，服务网格可以进行高级路由，帮助测试，处理安全性的某些方面，甚至可以使用特定于应用程序的协议（例如Envoy支持Kafka，MongoDB，Redis，MySQL等）。虽然服务网格作为一种解决方案可能还没有被广泛采用，但它触及了分布式系统中的一个真正的痛点，我相信它会找到它的形状和存在形式。

除了典型的服务机甲之外，还有其他项目，如Skupper，证实了将网络功能放入外部运行时代理的趋势。Skupper通过第7层虚拟网络解决多集群通信挑战，并提供高级路由和连接功能。但是，它不是将 Skupper 嵌入到业务服务运行时中，而是在每个 Kubernetes 命名空间运行一个实例，该实例充当共享挎斗。

综上所述，容器和 Kubernetes 在应用程序的生命周期管理方面向前迈出了重要一步。服务网格和相关技术遇到了真正的痛点，并为将更多责任从应用程序转移到代理奠定了基础。让我们看看接下来会发生什么。

State

我们前面列出了依赖于状态的主要集成原语。管理状态很困难，应委托给专门的存储软件和托管服务。这不是这里的主题，但是在语言中立的抽象中使用状态来帮助集成用例才是。今天，许多努力试图在语言中立的抽象背后提供有状态的原语。有状态工作流管理是基于云的服务中的强制性功能，例如 AWS Step Functions、Azure 持久函数等。在基于容器的部署中，CloudState 和 Dapr 都依赖于 sidecar 模型来更好地解耦分布式应用程序中的有状态抽象。

我期待的是将上面列出的所有有状态功能抽象到一个单独的运行时中。这意味着工作流管理、单例、幂等性、事务管理、cron 作业触发器和有状态错误处理都在挎斗（或主机级代理）中可靠地发生，而不是存在于服务中。业务逻辑不需要在应用程序中包含此类依赖项和语义，并且可以从绑定环境以声明方式请求此类行为。例如，挎斗可以充当 cron 作业触发器、幂等使用者和工作流管理器，自定义业务逻辑可以作为回调调用或在工作流的某些阶段、错误处理、临时调用或唯一幂等请求等插入。

另一个有状态用例是缓存。无论是由服务网格层执行的请求缓存，还是使用 Infinispan、Redis、Hazelcast 等内容进行数据缓存，都有将缓存功能推出应用程序运行时的示例。

State

虽然我们正在讨论将所有分布式需求与应用程序运行时分离的主题，但绑定的趋势也在继续。连接器、协议转换、消息转换、错误处理和安全中介都可以移出服务运行时。我们还没有达到目标，但是Knative和Dapr等项目已经朝着这个方向进行了尝试。将所有这些职责移出应用程序运行时将导致更小、以业务逻辑为中心的代码。这样的代码将存在于独立于分布式系统需求的运行时中，这些需求可以作为预打包的功能使用。

另一个有趣的方法是Apache Camel-K项目。该项目不是使用代理运行时来伴随主应用程序，而是依赖于智能 Kubernetes Operator，该运算符使用 Kubernetes 和 Knative 的附加平台功能构建应用程序运行时。在这里，单个代理是负责包含应用程序所需的分布式系统基元的操作员。不同之处在于，一些分布式原语被添加到应用程序运行时，而一些在平台中启用（其中也可能包括一个挎斗）。