微服务适配器。一对多或多/国对一/国。架构/部署决策

Question

比如说，我有 System1 通过它们之间的适配器微服务连接到 System 2。

System1 -> rest-calls --> Adapter (converts request-response + some extra logic, like validation) -> System2

System1 更像是一个整体，存在于许多国家/地区（但它可能会改变）。

问题是：从微服务架构和部署的角度来看，Adapter应该是每个国家一个。说Adapter-Uk、Adapter-AU等。还是应该只是可以同时处理多个国家的Adapter？

我的意思是：

拥有单一系统/适配器服务：

优势：拥有一个代码库，90% 的国家之间的自适应代码逻辑是相同的。易于引入新的变化。

缺点：一旦我们部署了系统，并且出现了一个错误，它可能会同时影响到许多国家。不安全。

要有一个单独的系统：

缺点：一旦对一个系统进行了一些通用更改，那么对于所有其他国家/地区/服务都应该“复制粘贴”。从开发人员的角度来看，重复，不聪明.. 工作。

优势： 更改/部署更安全。

问：从微服务架构的角度来看，哪种方式更可取？

Answer 1

我建议如下：

• 适配器覆盖所有国家/地区，以维护单一代码库并提高代码可重用性
• 单元和/或集成测试以应对错误
• 生成多个相同的适配器实例，前面带有负载平衡器

Answer 2

自从 Prabhat Mishra 在评论中问道。 两年后..（花了一些时间来理解我的要求。）

当时，对我来说，拥有一个弹性系统非常重要，也就是说，如果我更改一个适配器中的代码，我不希望我的所有国家/地区都出现故障（它是 SAP 企业系统，数百万客户）。我只希望一个国家垮台（仍然是百万客户，但更少了：））。

因此，对于这种情况：我会为每个国家/地区创建多个适配器，但是，我会使用一些代码生成的通用解决方案来创建它们，例如 common jar - 所以我不会重复我的 infrastructure 或通信层。就像脚手架一样。

1. 国家适配器新“国家 1”
2. 添加一些特定于国家/地区的代码（不更改任何生成的代码（重复的代码更少，支持的代码更少））

否则，如果您觉得安全（例如代码审查您的更改，确保您没有更改其他国家/地区的代码），那么 1 个适配器就可以了。

另一种解决方案是从 1 个适配器开始，如果它很关键，则拆分为更多（如果失败，对潜在的损坏/成本感到不安全）。

总的来说，似乎一切都归结为同一个问题，即：何时将“单体”拆分成碎片。答案总是：当它导致问题变得如此之大时。但是，如果您对您的系统非常了解，您就会提前知道现在是（或不是）WHEN。