怎样将微服务和无服务器相结合？用新型事件驱动型架构CQRS！
|
副标题[/!--empirenews.page--]
本文是将介绍如何在微服务中实施CQRS模式，并深入探讨为什么无服务器和这种类型的系统无比契合。在最后，将介绍一个使用Spring Cloud Stream实施CQRS的参考应用。 什么是事件驱动型架构？ 事件驱动型架构会优先处理领域事件，但这种架构已经逐渐被淘汰。 我们日常使用的一个示例是前端应用。在如今使用的Web浏览器中，事件的处理方法是捕获用户表单的输入数据，而连接到页面元素的事件将由一个显式映射函数来处理，在触发时在用户界面应用对状态的更改。 最近，随着微服务的广泛普及，人们对如何在分布式后端系统中利用事件驱动技术重新产生了兴趣。
CQRS 如今，事件驱动型架构中最热门的实践之一叫做CQRS，全称是命令查询责任分离。CQRS是一种架构风格，能让您使用不同模型来更新和读取领域数据。
CQRS的基本理念是，您用来更新和读取数据的模型要相互分离是很自然的事情。上图描述了这种基本思想。 CQRS之所以在事件驱动型架构中如此受欢迎，是因为作为输入的领域事件与其所属的领域模型在结构上有所差异。以下面这个代表一个帐户的领域模型对象为例。 示例1.帐户整合
当某个服务想查询帐户时，就会使用该模型。那么，如果我们要将状态更新为ACCOUNT_SUSPENDED，该怎么办？通常，只需简单更新领域对象的状态字段即可。现在，如果我们想使用领域事件来更新状态，该怎么办？由于领域对象在结构上与事件不同，我们需要一个可将不同模型作为命令接受的API。 以下代码段是将帐户状态从ACCOUNT_ACTIVE转换为ACCOUNT_SUSPENDED的领域事件。 示例2.帐户事件
要处理此领域事件并将更新应用到查询模型，我们必须有接受命令的API。该命令将包含领域事件的模型，并使用模型来处理对帐户查询模型的更新。
将命令模型与查询模型相分离是对CQRS最简单的解释。我们如今常见的复杂性更多地与实施类型有关，将模式应用到微服务时尤为如此。 CQRS和微服务 如果CQRS与微服务相结合，毫不夸张地说，情况就变得有点复杂了。我们来看看使用Spring Boot实施CQRS的“简单”微服务是什么样。
上图是CQRS模式实施的简略图示。图中，我们将一个微服务分为命令端、查询端和事件处理器，这三个部分可以相互独立地部署。 命令端 本示例中的命令端提供了REST API，可接受通过HTTP发送的请求。请求采取命令的形式，可以驱动对微服务所拥有的领域数据的状态更改。简单来说，对领域数据的任何写入都将以命令形式从API请求流出，处理导致数据库发生更改的操作。
命令触发操作，操作触发领域事件。领域事件保存在事件存储中，也就是“一个将数据库与消息代理相结合的系统。”最合适入门使用的事件存储是Eventuate，是由Chris Richardson创建的项目，旨在帮助将CQRS和Event Sourcing应用到微服务。 领域事件存储为按时间顺序排列的一系列事件，附加在日志上。由于每个命令都生成一个事件，我们能够根据收集的事件历史记录重新构建当前系统的总体状态。 事件处理器 我们要探讨的下一个组件是事件处理器。这个CQRS组件采用Worker应用的形式，负责摄取领域事件。事件处理器是无状态的，并侦听来自事件存储的消息，对传入的事件消息采取操作。
事件处理器可通过很多有用的方式对新的领域事件作出响应。一个领域事件可以生成多个事件，这些事件可以发送到其他微服务。这就是为什么大多数微服务开发人员都被CQRS吸引，因为通过这种方法可以发布和订阅来自限界环境之外的应用的领域事件。 这种方法为我们提供了一种机制，可确保领域数据的引用完整性。来自其他微服务的消息可用来处理领域事件，从而让我们能够维护分布式系统中与其他记录的领域数据相关的恼人的外键关系。 查询端 事件处理器首要负责应用可改变领域整合状态的领域事件。每个领域事件都可用来更新数据库记录，形成描述整合的增量实体化视图。反过来，查询端将提供一个REST API，允许HTTP客户端读取从已处理事件生成的实体化视图。
查询端组件中的限制是领域数据是只读的。此系统中的所有状态更改都会从命令端流入，然后形成可在查询端读取的实体化视图。 是分布式一体化还是微服务？ 如今，大多数人想到单个微服务时，他们想到的是一个独立的服务组件。在大多数情况下，微服务被构建为应用，专注于处理好一件事情。最重要的是，这种服务可以独立于其他服务进行升级和部署。 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
