当公式的组织 架构 及其代码被拆分以后,但仍然存在紧密耦合时,就会出现分布式单体。这已经成为一个问题,因为系统的规模增加,单体的所有部分都需要一起管理,这会放慢开发速度并增加任何变化的风险。
能够识别何时处理分布式单体很重要:
1. 锁步部署
当两个服务需要一起部署时,它们是耦合的。如果它们在一个单体中,这很容易管理。但是,如果它们是实际上应该独立管理的独立服务,部署可能会变得缓慢和痛苦。我们可以通过识别耦合的原因并重构我们的解决方案来解决这个问题。
如果这两个服务使用共享代码,则解决方案可以重组代码以共享一个单独管理的库。如果他们使用共享基础设施,这可能意味着将服务拆分到不同的主机上。
2.版本耦合
如果服务 A 直接调用服务 B 的一个版本,则每次更新服务 B 时,我们都需要更新服务 A 的配置。这种更改耦合会使管理两个应用程序的生命周期变得复杂,但这是可能的。
理想情况下,服务 A 应该调用服务 B 的端点,该端点不是特定版本,并且也由服务 B 管理。这通常可以通过使用 CNAMES 的 DNS 来完成,如下所示:
A1.domain.com > 调用 > B.domain.com > B1.domain.com
而不是:
A1.domain.com > 调用 > B1.domain.com
3. 双向依赖
如果服务 A 调用服务 B 并且服务 B 调用服务 A,则很难测试对任一系统的更改。发生