每个数据库表的微服务答案

【问题标题】：Microservices Per DB table每个数据库表的微服务
【发布时间】：2017-07-30 05:37:37
【问题描述】：

我遇到了电子商务应用程序的微服务架构，其中每个表都有自己的微服务，基本上带有 CRUD 操作（类似于每个表的休息客户端）。现在我正在考虑围绕业务领域对它们进行组合和建模，在此之前我想知道是否有人遇到过这种情况，它是否是正确的架构。任何建议都会非常有帮助。谢谢。

【问题讨论】：

每个微服务必须有一个单独的表，服务间的通信是通过网络完成的。它们不能共享相同的持久性。在这里阅读更多：amazon.com/Building-Microservices-Sam-Newman/dp/1491950358/…
感谢康斯坦丁的回复我完全同意你的观点，微服务必须隐藏它的实现和数据库，但在这种情况下，每个表都有单独的微服务。例如，对于 A 表，它们有 MicroserviceA ，对于 B 微服务 B 并且每个表都相同，有多少表有这么多微服务。

【解决方案1】：

每个微服务都应该有自己的一组 SQL 表，其他微服务无法访问这些表。但是每个 SQL 表有一个微服务，并且每个微服务只支持 CRUD 操作通常是一种反模式：它将强大的 DBMS 和查询语言变成一个简单的记录管理器：没有跨表事务、连接、过滤、排序、分页等。

【讨论】：

【解决方案2】：

你把不同的、不相关的东西混在一起了。

（微）服务是执行某些特定任务的逻辑实体。它们与其他服务通信以执行更大范围的任务。

表/CRUD/SQL/NO-SQL 来自一个完全不同的层次。数据的保存位置和访问方式。

服务确实使用 SQL 并具有表。为每个服务设置单独的表也可能是一个好主意。我什至会说，如果 2 个服务直接使用同一张表，那么您可能会遇到设计问题。

但您不能将服务等同于表格，从概念上讲，它们属于不同的世界。

【讨论】：

【解决方案3】：

微服务是任何应用程序的逻辑块，在 sql 级别组合它们没有任何意义。

例如：假设您创建了一个订单服务，允许客户下订单。

现在订单也包含订单项目，并且可能有客户对象的引用，对于所有这些，您最终可能会创建多个表。所以不要只把sql表和微服务想在一起

如果您仍有疑问，请发布更准确的问题，这会有所帮助:)

【讨论】：