从分布式到微服务图解,微服务分布式开发流程

首页 > 经验 > 作者:YD1662022-10-28 06:20:08

通过变更数据捕获实现的服务协同

Debezium 可以监控数据库的事务日志,执行必要的过滤和转换,并将相关的变更投递到 Apache Kafka 的主题中。这样的话,服务 B 就可以监听主题中的通用事件,而不是轮询服务 A 的数据库或 API。我们通过这种方式,将数据库轮询转换成了流式变更,并且在服务间引入了一个队列,这样会使得分布式系统更加可靠、可扩展,而且为新的使用场景会引入其他消费者提供了可能性。Debezium 提供了一种优雅的方式来实现发件箱模式,能够用于基于编排式和协同式的Saga模式实现。

这种方式的一个副作用在于,服务 B 有接收到重复消息的可能性。这可以通过实现幂等的服务来解决,可以在业务逻辑层面来解决,也可以使用技术化的去重器(deduplicator,比如 Apache ActiveMQ Artemis 的重复消息探测或者 Apache Camel 的幂等消费者模式)。

使用事件溯源的协同式模式

事件溯源(event sourcing)是另外一种服务协同的实现模式。在这种模式下,实体的状态会被存储为一系列的状态变更事件。当有新的更新时,不是更新实体的状态,而是往事件的列表中追加一个新的事件。往事件存储中追加新的事件是一个原子性的操作,会在一个本地事务中完成。如图 9 所示,这种方式的好处在于,对于消费数据更新的其他服务来讲,事件存储的行为也是一个消息队列。

从分布式到微服务图解,微服务分布式开发流程(13)

通过事件溯源实现的服务协同

在我们样例中,如果要转换成使用事件溯源的话,要把客户端的请求存储在一个只能进行追加操作的事件存储中。服务 A 可以通过重放(replay)事件重新构建当前的状态。事件存储需要让服务 B 也订阅相同的更新事件。通过这种机制,服务 A 使用其存储层作为与其他服务的通信层。尽管这种机制非常整洁,解决了当有状态变更时可靠地发布事件的问题,但是它引入了一种很多开发人员所不熟悉的编程风格,并且围绕状态重建和消息压缩,会引入额外的复杂性,这需要专门的存储。

协同式的优点和缺点

不管使用哪种方式来检索数据变更,协同式的模式都解耦了写入,能够实现独立的服务可扩展性,并提升系统整体的弹性。这种方式的缺点在于,决策流是分散的,很难发现全局的分布式状态。要查看一个请求的状态需要查询多个数据源,这对于服务数量众多的场景来说是一个挑战。表 4 总结了这种方式的优点和缺点。

从分布式到微服务图解,微服务分布式开发流程(14)

表 4:协同式的优点和缺点

并行管道

在协同式模式中,没有一个中心化的地方可以查询系统的状态,但是会有一个服务的序列,以便于在分布式系统中传播状态。协同式模式创建了一个处理服务的序列化管道,所以我们能够知道当一个消息到达整个过程的特定步骤时,它肯定已经通过了前面的所有步骤。如果我们能够放松这个限制,允许独立地处理这些步骤的话,情况又会怎样呢?在这种场景下,服务 B 在处理一个请求的时候,根本不用关心服务 A 是否已经处理过它。

在并行管道的方式中,我们会添加一个路由服务,该服务接收请求,并在一个本地事务中通过消息代理将请求转发至服务 A 和服务 B。如图 10 所示,从这个步骤开始,两个服务可以独立、并行地处理请求。

从分布式到微服务图解,微服务分布式开发流程(15)

通过并行管道进行处理

尽管这种模式很容易实现,但是它只适用于服务之间没有时间约束的场景。例如,服务 B 不管服务 A 是否已经处理过该请求,它都能够对请求进行处理。同时,这种方式需要一个额外的路由服务,或者客户端知道服务 A 和服务 B,从而能够给它们发送消息。

监听自身

这种方式有一种轻量级的替代方案,被称为“监听自身(listen to yourself)”模式,在这里,其中有个服务会同时担任路由。在这种替代方式下,当服务 A 接收到一个请求时,它不会写入到自己的数据库中,而是将请求发送至消息系统中,而消息的目标是服务 B 以及服务 A 本身。图 11 阐述了这种模式。

从分布式到微服务图解,微服务分布式开发流程(16)

上一页12345下一页

栏目热文

文档排行

本站推荐

Copyright © 2018 - 2021 www.yd166.com., All Rights Reserved.