微服务新手 - 重构单体 "Marketplace" 数据库
New to Microservices - refactoring a monolith "Marketplace" database
我是微服务的新手，一直在努力思考它。从表面上看，它们听起来是个好主意，但从实际的角度来看，我无法摆脱我的中心化数据库背景。例如，我有一个真实世界的市场示例，我无法确定微服务是有益还是有害。在 PO 要求 "Private Products." 之前，该站点运行良好，但现在它脆弱且缓慢，因此我需要进行重大重构。实施微服务的好时机。我觉得很多系统都有这种类型的耦合，所以解构这个例子会很有启发性。
当前状态
这是一个 b2b 市场，用户属于相互购买产品的公司。目前，存在一个单一的数据库：用户、公司、目录、产品和订单。 （这是一个简化，实际场景要复杂得多，用户有角色，订单有header/detail，产品有库存等）
- 用户属于公司
- 公司有其产品目录
- 公司有其他公司的产品订单
到目前为止一切顺利。我可以看到将应用程序分解为主要实体边界上的微服务。
新要求
不幸的是，对于我的架构愿望，产品所有者想要更多功能。在这种情况下：私有产品。
- 产品 Public 或私有
- 公司向其他公司的用户发送有时限的产品或目录邀请
这个看似简单的要求一下子就复杂了起来。
用例 - 用户显示产品列表
例如，列出或搜索产品曾经只是简单地要求产品 list/search 自己。它是系统上最热门的 运行 查询之一。不幸的是，现在一个简单的用例变得一团糟。
- 用户应该能够看到所有 public 产品（简单）
- 用户应该能够看到自己公司的所有私人产品（不可怕）
- 无论隐私如何，用户都可以看到他们公司过去订购的任何产品（哦，现在产品需要知道用户公司的订单历史记录）
- 用户可以看到他们有活动邀请的任何私人产品（哦，现在产品需要了解用户的产品或目录邀请，这些邀请是时间相关的）
初始整体方法
这可以在数据库级别解决，但是 SQL 基本上将所有表连接在一起（不仅是主数据表，还有所有事务）。虽然它比以前，因为 DBMS 是为大连接而设计的，所以它似乎是合适的工具。这样我就可以开始优化查询了。然而，正如我所说，由于这个和其他原因，系统感觉很脆弱。
最初的设计思路...以及最终我的问题
所以考虑微服务架构作为一个潜在的新方向，我开始思考如何入手。数据冗余似乎是必要的。因为，如果我将我的主要实体转化为服务，那么要求获得没有数据冗余的产品列表只会让所有服务相互调用，而且会造成一大堆缓慢的混乱。
从开辟 "Product and Catalog" 作为自己的微服务的想法开始。由于目录只是产品的集合，它们似乎属于一体——我将把整个东西称为 "Product Service"。此服务将有一个 API 用于管理产品和目录，最重要的是，用于搜索和列出它们。
作为一项单独的服务，执行产品搜索需要大量冗余数据，因为它必须订阅任何影响产品隐私的事件，例如：
- 监听订单，至少保留采购产品与采购公司关系的摘要
- 收听邀请并维护 活跃 User/Product/Time 关系列表
- 侦听用户和公司事件以维护用户与公司的关系
我开始担心如何保持同步。
最终，产品服务将复制当前模式的大部分。所以我开始想，也许微服务不适合这种情况。还是我太夸张了，模式会更简单，更易于管理，速度更快，所以值得吗？
总的来说，我是否正确地考虑了整个方法？这就是基于微服务的设计的设计思路吗？如果没有，有人可以给我一个不同方向的推动吗？
尝试一遍又一遍地将您的系统拆分为服务，直到它有意义为止。使用你的直觉。阅读更多书籍、文章和论坛，其他人会在其中描述他们是如何做到的。
您已经提到将 ProductService 拆分为 Product 和 ProductSearch 没有意义 - 很公平，尝试那样实现它。如果由于某种原因或性能瓶颈，您最终会得到一个非常复杂的模式——这是继续进一步拆分的好兆头。如果不是 - 对于您的特定域来说，这很好。
并非所有的产品服务都是平等的。在某些情况下，您必须能够每天创建数百万甚至数十亿个产品。在这种情况下，您很可能应该考虑将产品目录和产品搜索分开。原因是性能：为了使搜索执行得更快（索引），您必须减慢插入速度。如果不将数据分离到不同的微服务中（这也会导致数据重复），这两个相互排斥的目标很难实现。
我是微服务的新手，一直在努力思考它。从表面上看，它们听起来是个好主意，但从实际的角度来看，我无法摆脱我的中心化数据库背景。例如，我有一个真实世界的市场示例，我无法确定微服务是有益还是有害。在 PO 要求 "Private Products." 之前，该站点运行良好，但现在它脆弱且缓慢，因此我需要进行重大重构。实施微服务的好时机。我觉得很多系统都有这种类型的耦合，所以解构这个例子会很有启发性。
当前状态
这是一个 b2b 市场，用户属于相互购买产品的公司。目前，存在一个单一的数据库：用户、公司、目录、产品和订单。 （这是一个简化，实际场景要复杂得多，用户有角色，订单有header/detail，产品有库存等）
- 用户属于公司
- 公司有其产品目录
- 公司有其他公司的产品订单
到目前为止一切顺利。我可以看到将应用程序分解为主要实体边界上的微服务。
新要求
不幸的是，对于我的架构愿望，产品所有者想要更多功能。在这种情况下：私有产品。
- 产品 Public 或私有
- 公司向其他公司的用户发送有时限的产品或目录邀请
这个看似简单的要求一下子就复杂了起来。
用例 - 用户显示产品列表
例如，列出或搜索产品曾经只是简单地要求产品 list/search 自己。它是系统上最热门的 运行 查询之一。不幸的是，现在一个简单的用例变得一团糟。
- 用户应该能够看到所有 public 产品（简单）
- 用户应该能够看到自己公司的所有私人产品（不可怕）
- 无论隐私如何，用户都可以看到他们公司过去订购的任何产品（哦，现在产品需要知道用户公司的订单历史记录）
- 用户可以看到他们有活动邀请的任何私人产品（哦，现在产品需要了解用户的产品或目录邀请，这些邀请是时间相关的）
初始整体方法
这可以在数据库级别解决，但是 SQL 基本上将所有表连接在一起（不仅是主数据表，还有所有事务）。虽然它比以前，因为 DBMS 是为大连接而设计的，所以它似乎是合适的工具。这样我就可以开始优化查询了。然而，正如我所说，由于这个和其他原因，系统感觉很脆弱。
最初的设计思路...以及最终我的问题
所以考虑微服务架构作为一个潜在的新方向，我开始思考如何入手。数据冗余似乎是必要的。因为，如果我将我的主要实体转化为服务，那么要求获得没有数据冗余的产品列表只会让所有服务相互调用，而且会造成一大堆缓慢的混乱。
从开辟 "Product and Catalog" 作为自己的微服务的想法开始。由于目录只是产品的集合，它们似乎属于一体——我将把整个东西称为 "Product Service"。此服务将有一个 API 用于管理产品和目录，最重要的是，用于搜索和列出它们。
作为一项单独的服务，执行产品搜索需要大量冗余数据，因为它必须订阅任何影响产品隐私的事件，例如：
- 监听订单，至少保留采购产品与采购公司关系的摘要
- 收听邀请并维护 活跃 User/Product/Time 关系列表
- 侦听用户和公司事件以维护用户与公司的关系
我开始担心如何保持同步。
最终，产品服务将复制当前模式的大部分。所以我开始想，也许微服务不适合这种情况。还是我太夸张了，模式会更简单，更易于管理，速度更快，所以值得吗？
总的来说，我是否正确地考虑了整个方法？这就是基于微服务的设计的设计思路吗？如果没有，有人可以给我一个不同方向的推动吗？
尝试一遍又一遍地将您的系统拆分为服务，直到它有意义为止。使用你的直觉。阅读更多书籍、文章和论坛，其他人会在其中描述他们是如何做到的。
您已经提到将 ProductService 拆分为 Product 和 ProductSearch 没有意义 - 很公平，尝试那样实现它。如果由于某种原因或性能瓶颈，您最终会得到一个非常复杂的模式——这是继续进一步拆分的好兆头。如果不是 - 对于您的特定域来说，这很好。
并非所有的产品服务都是平等的。在某些情况下，您必须能够每天创建数百万甚至数十亿个产品。在这种情况下，您很可能应该考虑将产品目录和产品搜索分开。原因是性能：为了使搜索执行得更快（索引），您必须减慢插入速度。如果不将数据分离到不同的微服务中（这也会导致数据重复），这两个相互排斥的目标很难实现。