2

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

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

解决方案1：

  • 制作一个单独的“类别”微服务来管理类别的 CRUD
  • 在产品服务中有一个 API 调用将类别 ID 链接到产品
  • 在用户服务中有一个 API 调用将类别 ID 链接到用户
  • 在产品服务中，我们有一个 API 调用来获取按偏好订购的产品。为了完成这项工作，产品服务需要调用用户服务来获取用户类别（或监听用户服务发出的事件）

解决方案2：

  • 制作一个单独的“类别”微服务来管理类别的 CRUD

  • 类别服务还有一个 API 调用来将产品 ID 链接到类别

  • 类别服务还有一个 API 调用来将用户 ID 链接到类别

  • 在产品服务中，我们有一个 API 调用来获取按偏好订购的产品（为了使这项工作正常工作，产品服务需要调用类别服务来获取用户和产品类别（或监听事件）

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

4

3 回答 3

0

我会说你应该有一个更复杂的服务和三个简单的服务。你的分类服务应该只是分类的CRUD，你的用户服务应该是用户的CRUD，你的产品应该更复杂，称之为productlisting服务，然后还有一个简单的产品服务。

您的产品列表服务应该具有所有的复杂性，但可能是非规范化的。

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。分布式系统中的这种关系约束只是自找麻烦。

于 2017-11-07T20:28:13.483 回答
0

好吧，解决方案 2 已经过时了，因为您将在不同的服务中为很多事情使用类别，并且它会破坏关注点的分离，以使类别服务在所有这些不同的域中实现搜索。

此外，现实的产品或用户搜索可以包括除类别之外的其他标准。让所有这些不同条件的服务实现自己的产品搜索通常不是一个好的实现，因为在多条件搜索中合并结果可能会很昂贵，所以这种在定义条件对象的服务中实现搜索的模式确实不是规模。

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

于 2017-11-08T04:11:55.133 回答
0

第三个替代解决方案是不要只制作表。仅将具有 CRUD 功能的“事物”放在单独的服务中的问题在于，大多数情况下，它们会有很多交叉依赖关系。这就是你现在遇到的问题。

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

有些人已经在这里写过这种方法，名为 Self-Contained Systems。

于 2017-11-08T08:37:32.540 回答