我是微服务的新手，并一直在努力将我的大脑包裹起来。从表面上看，它们听起来是个好主意，但从实际的角度来看，我无法摆脱我的集中式数据库背景。举个例子，我有这个真实的市场示例，我无法弄清楚微服务是否会有所帮助或受到伤害。这个网站运作良好，直到PO要求“私人产品”。现在它很脆弱，所以我需要做一个重要的重构。实现微服务的好时机。我觉得很多系统都有这种类型的耦合，因此解构这个例子非常有启发性。
当前状态
这是一个b2b市场，用户属于彼此购买产品的公司。目前，存在一个单一的数据库：用户，公司，目录，产品和订单。 （这是一种简化，实际情况要复杂得多，用户有角色，订单有标题/详细信息，产品有库存等）。
到目前为止一切顺利。我可以看到将应用程序分解为主要实体边界上的微服务。
新要求
不幸的是，对于我的架构愿望，产品所有者需要更多功能。在这种情况下：私人产品。
这个看似简单的请求突然使一切变得复杂。
用例 - 用户显示产品列表
例如，列出或搜索产品曾经只是要求产品列出/搜索自己的简单案例。它是系统上最热门的查询之一。不幸的是，现在一个简单的用例就变得混乱了。
初始单片方法
这可以在数据库级别解决，但SQL基本上将所有表连接在一起（而不仅仅是主数据表，所有事务也是如此。）虽然它比以前慢很多，因为DBMS是设计用于大型连接似乎是合适的工具。所以我可以开始优化查询。但是，正如我所说，由于这个原因和其他原因，系统感觉很脆弱。
初步设计思想......最终我的问题
因此，考虑到微服务架构是一个潜在的新方向，我开始思考如何开始。数据冗余似乎是必要的因为，如果我将我的主要实体转换为服务，要求获得没有数据冗余的产品列表，就会让所有服务相互调用并且速度很慢。
从创建“产品和目录”作为自己的微服务的想法开始。由于目录只是产品的集合，它们似乎属于一体 - 我只是把整个事情称为“产品服务”。该服务将具有用于管理产品和目录的API，最重要的是，用于搜索和列出它们。
作为一项单独的服务，执行产品搜索需要大量冗余数据，因为它必须订阅任何影响产品隐私的事件，例如：
我开始担心保持全部同步。
最后，产品服务将复制当前架构的很大一部分。所以我开始想，也许微服务不会适用于这种情况。或者我是戏剧性的，架构会更简单，更容易管理，更快，所以值得吗？
总的来说，我是否正确地考虑了整个方法？这是基于微服务的设计是如何被考虑的？如果没有，有人可以向我推动另一个方向吗？
答案 0 :(得分：1)
尝试将系统一次又一次地分解为服务直到有意义为止。用你的直觉。阅读更多书籍，文章，论坛，其他人描述他们是如何做到的。
您已经提到将ProductService拆分为Product和ProductSearch没有意义 - 公平，尝试实现它。如果由于某种原因或性能瓶颈而最终会出现相当复杂的架构 - 这是继续进一步分裂的好兆头。如果没有 - 对于您的特定域名来说就好了。
并非所有产品服务都是平等的。在某些情况下，您必须每天能够创建数百万甚至数十亿的产品。在这种情况下，您最有可能考虑分离产品目录和产品搜索。原因是性能：要使搜索执行速度更快（索引），您必须减慢插入速度。这是两个相互排斥的目标，如果不将数据分成不同的微服务（这也将导致数据重复），很难实现这两个目标。