分解为微服务

Question

我有一个关于分解为微服务的问题。假设我们有 2 个微服务：用户和产品。假设我们现在需要向系统添加类别。更具体地说，产品具有一个或多个类别（例如，产品红色微型法拉利属于玩具和汽车类别），并且用户可以具有她喜欢的类别（例如玩具和鞋子）。现在，当我们检索产品的完整列表时，我们希望对它们进行排序，以便属于首选用户类别的产品位于顶部。

基本上有一个在微服务之间共享的概念（在本例中为类别）。如何在微架构环境中对此进行最佳建模？我看到两种解决方案：

解决方案1：

• 创建一个单独的“类别”微服务来管理类别的 CRUD
• 在产品服务中，有一个 API 调用来将类别 ID 链接到产品
• 在用户服务中具有 API 调用以将类别 ID 链接到用户
• 在产品服务中，我们有一个 API 调用来获取根据偏好订购的产品。要实现此工作，产品服务需要调用用户服务以获取用户类别（或侦听用户服务发出的事件）

解决方案2:

>

创建一个单独的“类别”微服务来管理类别的 CRUD

类别服务还具有 API 调用，用于将产品 ID 链接到类别

类别服务还具有将用户 ID 链接到类别的 API 调用

在产品服务中，我们有一个API调用来获取按偏好排序的产品（为了完成此工作，产品服务需要调用类别服务来获取用户和产品类别（或侦听事件）

两种解决方案的优点/缺点是什么？

Answer 1

好吧，解决方案2已经出来了，因为你将在不同的服务中使用类别来处理很多事情，如果让类别服务在所有这些不同的领域中实现搜索，就会破坏关注点的分离。

此外，实际的产品或用户搜索可以包括类别以外的其他条件。让所有这些不同条件的服务实现自己的产品搜索通常不是一个好的实现，因为在多条件搜索中合并结果的成本可能很高，因此这种在定义条件对象的服务中实现搜索的模式无法缩放。

解决方案1很接近，但是没有理由让产品服务知道或调用用户服务。产品服务应该有一个使用各种标准搜索产品的API，包括类别。通过让客户端传递类别ID列表而不是用户ID来实现类别搜索可能会更好。那么它就不必调用用户服务本身，你保持产品和用户服务的独立性。此外，按类别搜索产品对其他事情也很有用(比如浏览产品！)，并且因为您没有将类别搜索与用户绑定，所以您可以使用相同的API来处理其他情况。

Answer 2

我会说你应该有一个更复杂的服务和三个简单的服务。你的品类服务应该只是品类的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。这种关系约束在分布式系统中只是自找麻烦。

Answer 3

第三个备选解决方案是不要让微服务只是表格。将具有CRUD功能的“东西”放在单独的服务中的问题是，大多数时候，它们会有很多交叉依赖。这就是你现在的问题。

您可以创建与功能而不是数据一致的服务。创建“搜索”服务、“购物车”服务、“计费”服务等。所有这些通常都需要同一“事物”（如产品）的不同方面。例如，我可以想象类别仅与“搜索”相关，但与其他两个无关。

一些人已经在这里写过这种方法，名为自容系统。