architecture - 微服务新出口的边界——如何拆分？

Question

我有一个具有以下域的给定微服务架构。每个域只有一个数据库。

• 存储 S
• 卖我

S 包含一组可以出售的物品（书籍、杂志）。此外，这里还保留了增值税。所以 S 包含一个服务 s1 用于物品的 CRUD 和税收的 CRUD。此外，它还有一个消耗 jms 的服务 s2。

域我处理所有关于销售（发票，交货条件，...）

到目前为止，我包含一个微服务 i1，它处理发票的 CRUD（创建发票、列出发票等）。

我计划拥有另一个微服务 i2，它是 csv 的导出，仅包含政府官员需要的特殊信息。

我不确定是将新功能放在 i1 中还是放在新的微服务 i2 中。

当然，导出总是会崩溃并杀死应用程序。如果集成在 i1 中，整个 i 域可能会崩溃。另一方面，我有另一个应用程序要部署......

您是否有一点经验可以在服务之间进行切割？

标签： architecturemicroservices

Answer 1

微服务主要围绕有界上下文 (DDD) 设计。有界上下文甚至可以有多个微服务。一切都是关于给予和接受，没有正确的答案。在我看来，只要服务是独立的并且它们不会相互干扰就应该是可行的方法。在你的情况下，我会说去寻求额外的服务，即出口服务。就像您提到的那样，如果部署在现有应用程序中，它可能会影响现有应用程序。

与影响现有服务并同时处理这两个问题相比，部署和管理服务更容易。对现有服务的影响并调查为什么导出不起作用。让他们分开。易于调试，最重要的是不会影响您正在运行的服务。
您还可以更好地保护它或轻松应用其他业务规则。