我正在将整体应用程序拆分为微服务，我能够将其拆分为三个微服务，为了便于解释，假设这些是：
所有这些都是截然不同的有限上下文，我正在使用数据库表进行微服务。所以在DB中我有：
USERS table
id
surname
lastname
...
OTHER_THINGS table
id
col1
col2
...
MESSAGES table
id
title
created_time
USER_ID
OTHER_THING_ID
...
现在，我的网页需要按所有这些表的所有指定列搜索/过滤消息。例如：
网页用户可以输入：
我应该只返回过滤的行。
使用monolith我使用了简单的数据库JOINS，但在这种情况下我找不到最佳选择。你能告诉我可能的选择以及哪些更好吗？
答案 0 :(得分：3)
＆＃34;假设我有Orders和Customers表，其中ORDER有FK到CUSTOMER。对我来说，这些似乎在不同的微服务中。 ＆＃34;
对外键仍然不感兴趣。 Orders微服务有一个带有自己的Customers表的数据存储。 Customer Update微服务具有一个带有自己的Customers表的数据存储。客户订单搜索将是Orders微服务的一项功能，因此将搜索其数据存储而不是客户更新数据存储。
关于微服务的重点是缺乏依赖性。它们本身就是完整的离散系统。这使它们易于构建且易于部署。问题就在于你要克服的问题：数据管理。大多数企业都渴望获得有关其数据的单一事实来源。这通常意味着中央数据库，它对应用程序施加约束，因为所有内容都必须共享相同的数据模型，并且对客户等常见实体的更改会导致严重的动荡。
微服务似乎通过分解拥有自己的数据模型的功能子集来提供解决方案。这不可避免地意味着整个企业的数据完整性更加宽松，因为它是异步处理的。不再是单一的事实来源。
因此，客户更新微服务将发布有关客户的更新，作为订单微服务将使用和应用的消息。同样，如果Orders微服务可以创建新客户，那么它将发布客户更新微服务将使用和应用的类似消息流。如果两个微服务在刷新之间的同一窗口中为同一个新客户创建记录会发生什么？嗯，是的，一个很好的问题。
结果是，微服务在某些情况下会起作用，在其他情况下绝对是灾难性的。当然，大多数企业应用程序在很大程度上仍然不仅仅是惯性，而是因为集中共享数据的好处在很多情况下超过了微服务的灵活性。