我遇到了电子商务应用程序的微服务架构，其中每个表都有自己的微服务，基本上都是CRUD操作（类似于每个表的rest客户端）。 现在我正在考虑围绕业务领域进行组合和建模，在此之前我想知道是否有人遇到过这种情况并且是否正确的架构。 任何建议都会非常有帮助。 感谢。
答案 0 :(得分：2)
你正在混淆不同的，不相关的东西。
（微）服务是执行某项特定任务的逻辑实体。他们与其他服务进行通信以执行更大范围的任务。
Tables / CRUD / SQL / NO-SQL来自完全不同的级别。它保存数据的位置以及访问方式。
服务使用SQL并拥有表是正确的。对每个服务都有单独的表也可能是一个好主意。我甚至会说，如果2个服务直接使用同一个表，你可能会看到一个设计问题。
但是你不能将服务与表等同起来，从概念上讲，它们属于不同的世界。
答案 1 :(得分：1)
每个微服务都应该有自己的一组SQL表，其他微服务都无法访问。但是每个SQL表有一个微服务，并且每个微服务只支持CRUD操作通常是反模式：它将强大的DBMS和查询语言转换为简单的记录管理器：没有跨表事务，连接，过滤，排序，分页等等。
答案 2 :(得分：1)
微服务是任何应用程序的逻辑块，在sql级别组合它们没有任何意义。
例如：让我们考虑您创建一个订单服务，允许客户下订单。
现在订单也包含订单商品，并且可能有客户对象的引用，对于所有这些，您最终可能会创建多个表。所以不要只考虑sql表和微服务
如果您仍然怀疑发布更确切的问题，将会有所帮助：）