怎样将微服务和无服务器相结合？用新型事件驱动型架构CQRS！

如果与大多数微服务部署相比，CQRS部署是十分复杂的。对于微服务团队来说，能够持续将功能交付至生产是目标。由于CQRS中分离的组件仍可以独立部署，我们可以说每个部署单元仍可满足独立将功能交付至生产的最低要求。微服务的一个功能应该始终需要且最多一个可部署单元。当交付一项功能时需要同时协调部署多个单独组件，就会产生所谓的分布式一体化。

微服务和无服务器

无服务器也称为FaaS（功能即服务），可让您在不需要设置或管理应用服务器或容器的情况下，将代码部署为功能。无服务器是一种新型架构风格，在构建和运行云原生应用方面越来越受到关注。使用无服务器功能的一个显著优势是，事件概念被优先处理。

有很多人以为，微服务和无服务器不兼容，彼此的架构风格完全不同。但是回想一下前面提到的CQRS你就会明白，这种想法是错误的。让我们来看一个场景，你认为在此场景中微服务的边界在哪里？

一种方法是认为微服务的边界就是团队的边界。只要一个团队可以独立、连续地将特性部署为功能，那么微服务的边界就只是负责为团队拥有的特性提供支持的功能子集。

权衡

要采用微服务和无服务器相结合的方法，需要您仔细权衡多项内容，让我们来看看需要注意的事项。

速度

对于微服务来说，速度就是目标。我们可以通过关注以下两个问题来衡量速度，平均时间越低，团队交付功能的速度就越快。：

开发人员改变一行代码并将其安全地部署到生产中的速度有多快？

新开发人员快速上手并安全地更改代码库的速度有多快？

无服务器具有学习曲线，但有助于提高微服务的速度。它将大量工作流程管理从核心组件移出，放入独立升级和部署的小型可组合功能中，从而提高速度。这在最大程度上缩短了开发人员了解单个功能的工作原理以及如何安全更改所需的时间。

无服务器功能也易于升级或部署，但可能会让了解整体系统更加复杂。将数百个无服务器功能作为一个整体来管理，这听起来就有点头大。

复杂性

软件中的复杂性无可避免，随着代码库逐渐老化，复杂性也随时间增加。当复杂性增加，或者当框架或语言过时的时候，一体化应用就变得笨重、难以改变。微服务器将这种复杂性分解到分布式系统中，其中的每个可部署单元都易于理解，易于由一小部分敏捷开发人员进行更改。

云原生CQRS参考应用

这里有一个将云原生CQRS应用，构建为事件驱动型微服务和无服务器功能相结合的参考应用。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!