在实践中设计微服务

Question

关于如何或如何不拆分微服务的另一个问题：-D

方案： 我们需要什么？ 在电子商务订单流程的工作流程中的不同时间点发送电子邮件。这些邮件将包含订单信息。

我们有什么？

1 x持久性服务，可检索订单信息

订阅订单事件并处理相关用例（例如，确认，交付，发票）的几种服务

1 x可以触发发送邮件的服务

下一步是什么？ 设计可转换订单信息的体系结构组件，以使其适合电子邮件呈现服务的数据结构。

当前选项是

1，每个处理服务都转换邮件模板的现有订单信息，并将其发送到邮件呈现服务。

2让每个处理服务调用一个新服务，该服务将聚合并转换订单信息并调用邮件呈现服务。

目前，我们不确定邮件模板的数据结构是否会普遍使用还是会有所不同。

那么从凝聚力，耦合性和关注点分离方面，您如何看待这些选择？ 您是否需要更多信息？任何建设性的想法都欢迎！

Answer 1

您的软件体系结构应反映您的组织结构，请参见Conway's law

1. 您是否有多个团队，并且想要最小化团队之间的依赖性。

2. “服务”是否足够大且复杂，足以证明将其分为模块？

3. 产品的规模是否足以证明已经安排了高级开发人员来协调微服务？

4. 在各个“服务”的部署和可替换性方面是否需要灵活性？

如果您可以对大多数这些问题回答“是”，那么选择微服务是很有意义的。否则，您只会使生活变得复杂。

坦率地说，微服务需要大量的协调开销，这只有在产品足够大的情况下才有意义。大多数（小型）项目都可以使用整体式和MVC架构。

Answer 2

这是我建议继续进行的工作，这是我项目的体系结构之一如何完成所有与SMTP相关的工作。

1. API收到HTTP请求
2. 它将所需的数据持久存储到数据库中。
3. 它将长时间运行且占用大量内存的过程分担给邮件构建器。
4. 可选，邮件构建器可以构建附件文件（XLSX，PDF等）
5. 邮件构建器上载到文件服务器
6. 邮件构建器将常规SMTP发送卸载到SMTP服务。

我建议使用这种格式，因为它允许您根据处理管道中的瓶颈来缩放每件的实例（邮件构建器将具有大量实例）。

Answer 3

鉴于您已经在microservices中问了这个问题，我假设您是在问有关云原生模式的问题。

我建议您从研究微服务模式开始。 https://microservices.io/patterns/microservices.html是一个很好的模式网站。

您的问题没有必要的详细信息，无法就哪些模式合适和什么不合适提供有教养的建议。所以，我建议您看看这几种模式... https://microservices.io/patterns/data/shared-database.html https://microservices.io/patterns/data/database-per-service.html

还可以查看事件源模式 https://microservices.io/patterns/data/event-sourcing.html

希望这会有所帮助。