I want to decompose my application to adopt microservices architecture, and i will need to come up with a solid strategy to split my database (Mysql) into multiple small databases (mysql) aligned with my applications.
问问题
493 次
1 回答
0
TL;DR：取决于场景和每个服务将做什么
尽管对此没有明确的答案，但由于它确实取决于您的需求以及每个服务应该做什么，因此您可以提出一个通用的起点（假设您不需要保留现有的数据库类型）。
假设您有一个用于电子商务的单体应用程序，并且您希望将该应用程序拆分为更小的服务，每个服务都有自己的数据库。您可以使用的方法是创建一些服务来处理网站的某些部分：例如，您可以拥有一项服务来处理用户身份验证，一项用于订单，一项用于产品，一项用于发票等等......
现在，每个服务都将拥有自己的数据库，这又带来了另一个问题：特定服务应该拥有哪个数据库？因为这种架构的优点之一是每个服务都可以有自己的数据库，所以例如产品服务可以有一个非关系数据库，比如 MongoDB，因为它所做的只是获取产品的详细信息，所以你不必管理任何关系。
另一方面，订单服务可能有一个关系数据库，因为您希望在订单和该订单的发票之间保持关系。但是等等，发票是由发票服务处理的，那么如何在不共享数据库的情况下保持这两者之间的关系呢？嗯，这是这种方法的“问题”之一：您必须保持服务独立，同时还要让它们相互通信。我们应该怎么做？这里也没有明确的答案......一种方法可能是将所有发票详细信息也传递给订单服务，或者您可以在保存订单时仅传递发票 ID，然后通过 API 调用检索发票发票服务，
于 2020-02-20T11:26:06.973 回答