我有一个关于分解成微服务的问题。假设我们有2个微服务：用户和产品。假设我们现在需要向系统添加类别。更具体地，产品具有一个或多个类别（例如，产品红色微型法拉利属于玩具和汽车类别）并且用户可以具有她喜欢的类别（例如玩具和鞋子）。现在，当我们检索完整的产品列表时，我们希望对它们进行排序，使得属于首选用户类别的产品位于顶部。
基本上有一个在微服务（在这种情况下是类别）之间共享的概念。如何在微体系结构环境中对此进行最佳建模？我看到两个解决方案：
解决方案1：
解决方案2：
制作一个单独的“类别”微服务，管理类别的CRUD
类别服务还有一个API调用，用于将产品ID链接到类别
类别服务还有一个API调用，用于将用户ID链接到类别
在产品服务中，我们有API调用来获取按优先顺序排序的产品（要使此工作产品服务需要调用类别服务以获取用户和产品类别（或收听事件）
两种解决方案的优点/缺点是什么？
答案 0 :(得分：0)
我说你应该有一个更复杂的服务，还有三个简单的服务。您的类别服务应该只是CRUD的类别，您的用户服务应该是用户的CRUD，您的产品应该更复杂，称之为产品列表服务，然后仍然有一个简单的产品服务。
您的产品列表服务应具有所有复杂性，但可能会被非规范化。
GET/POST/PUT/DELETE /product
GET/POST/PUT/DELETE /category
GET/POST/PUT/DELETE /user
POST/PUT /productlisting/usercategory/<userid> <list of categories>
POST/PUT /productlisting/productcategory/<productid> <list of categories>
GET /productlisting
要么是这个，要么将它们全部组合成一个整体...它们不是分开的问题，并且通过ID将它们耦合会让你感到悲伤，因为你的耦合会很脆弱。我从不让一个服务知道另一个服务的实体ID。分布式系统中的这种关系约束只是在寻找麻烦。
答案 1 :(得分：0)
嗯，解决方案2已经淘汰了，因为你要在不同的服务中使用很多东西的类别，这会破坏关注点的分离，使类别服务在所有不同的域中实现搜索。
此外，除了类别之外，真实的产品或用户搜索还可以包含其他标准。为所有这些各种标准提供服务实现自己的产品搜索通常不是一个好的实现，因为在多标准搜索中合并结果可能代价高昂，因此在定义的服务中实现搜索的这种模式标准对象无法扩展。
解决方案1已关闭，但没有理由让产品服务了解或致电用户服务。产品服务应具有使用各种标准（包括类别）搜索产品的API。通过让客户端传递类别ID列表而不是用户ID来实现类别搜索可能会更好。然后，它不必调用用户服务本身，并保持产品和用户服务的独立性。此外，按类别搜索产品对于其他事情（例如浏览产品！）非常有用，并且由于您没有将类别搜索与用户联系起来，因此您可以使用相同的API来处理其他情况。
答案 2 :(得分：0)
另一种解决方案是不使微服务只是表。将CRUD功能的“东西”放在单独的服务中的问题是，大多数情况下，它们会有很多交叉依赖。这就是你现在遇到的问题。
您可以使服务与功能而不是数据保持一致。制作“搜索”服务，“购物车”服务，“结算”服务等。所有这些通常需要相同“事物”（如产品）的不同方面。我可以想象，例如，类别仅与“搜索”相关，而不是与其他两个相关。
有些人已经写过这种方法here, named Self-Contained Systems。