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

微服务之后的内容不是函数

微服务架构有一个明确的目标。它针对更改进行优化。通过将应用程序拆分为业务域，该架构通过解耦、由独立团队管理并以独立速度发布的服务，为软件演进和可维护性提供了最佳的服务边界。

如果我们看一下无服务器架构的编程模型，它主要基于函数。函数针对可伸缩性进行了优化。通过函数，我们将每个操作拆分为一个独立的组件，以便它可以快速、独立和按需扩展。在此模型中，部署粒度是一个函数。之所以选择该函数，是因为它是具有输入的代码结构，其速率与缩放行为直接相关。这是一种针对极端可扩展性进行优化的体系结构，而不是复杂系统的长期可维护性。

那么无服务器的另一个方面呢，它来自AWS Lambda的普及及其完全托管的操作性质？在这方面，“AWS 无服务器”优化了预置速度，以消除缺乏控制和锁定的费用。但完全托管的方面不是应用程序架构，而是一种软件消费模型。它在功能上是一个正交的，类似于消费基于 SaaS 的平台，在理想情况下，该平台应该可用于任何类型的架构，无论是单体、微服务、机甲还是功能。在许多方面，AWS Lambda 类似于完全托管的 Mecha 架构，但有一个很大的区别：Mecha 不强制执行函数模型，而是允许围绕业务域进行更具凝聚力的代码构造，从所有中间件问题中分离出来。

架构优化

另一方面，Mecha架构优化了微服务以实现中间件独立性。虽然微服务彼此独立，但它们严重依赖于嵌入式分布式原语。Mecha架构将这两个问题拆分为单独的运行时，允许独立团队独立发布。这种分离改进了第 2 天的操作（例如修补和升级）以及业务逻辑的内聚单元的长期可维护性。在这方面，Mecha架构是微服务架构的自然发展，它根据引起最多摩擦的边界拆分软件。与函数模型相比，这种优化以软件重用和演变的形式提供了更多的好处，函数模型以过度分发代码为代价优化了极高的可扩展性。

结论

分布式应用程序有许多要求。创建有效的分布式系统需要多种技术和良好的集成方法。虽然传统的单体中间件提供了分布式系统所需的所有必要技术特性，但它缺乏快速更改、适应和扩展的能力，而这正是业务所要求的。这就是为什么基于微服务的架构背后的思想有助于容器和 Kubernetes 的快速普及;随着云原生领域的最新发展，我们现在将所有传统的中间件功能转移到平台和现成的辅助运行时中，从而完成了一个完整的循环。

应用程序功能的这种商品化主要使用进程外模型进行功能扩展，而不是运行时库或纯平台功能。这意味着将来我们很可能会使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务都会由多个运行时组成;自定义微业务逻辑的运行时，以及分布式基元的现成可配置运行时。