restful-architecture - 在线商店和微服务

Question

我在一家大型在线商店工作。目前我们的架构有点奇怪，我们有微服务实际上都共享同一个数据库(根本不能正常工作......)。我正在考虑改进它，但在如何使它们独立方面存在一些挑战。

这是一个用例。我有客户，客户购买产品。假设我有 3 个微服务:客户身份验证、订单管理、产品管理。订单链接到客户和产品。您能否描述以下问题的解决方案:

1. 您如何在订单和客户之间建立联系？
2. 假设两种服务共享一个客户 ID，您如何处理数据一致性？如果您在客户服务端删除客户，最终会出现不一致。如果您的服务必须通知其他服务，那么您最终会得到紧密耦合的服务，这对我来说听起来像是您首先要避免的。您可以通过一个通知所有人的事件机制来避免这种情况，但是当您甚至不知道谁应该接收该事件时网络错误怎么办？
3. 我想做一个简单的查询:检索购买产品 A 的美国客户。假设有 300 万人购买了产品 A，而我们在美国有 100 万客户；您如何才能使它具有合理的性能？ (我们当前的数据库将在几毫秒内执行)

我想不出我们代码的任何部分没有这种关系。我能想到的解决方案之一是复制数据。例如。当客户购买东西时，订单管理服务将存储客户详细信息和产品详细信息。您最终会进行大量数据复制，不确定这是否是一件好事，我仍然会担心一致性。

我找不到解决这些问题的论文。有哪些不同的选项？

Answer 1

At the moment our architecture is something weird where we have microservices which actually all share the same DB (doesn't work well at all...). I am considering improving that but have some challenges on how to make them independant.

恕我直言，通过为订单、客户和产品提供一个 OLTP 数据库，架构更加简单，因为它允许您使用 JOINS 和存储过程。可能是数据库可以使用一些配置和调整 TLC 与软件重新架构。当您考虑如何解决性能问题时，请保持这扇门敞开。

How do you make the link between an order and a customer?

在 orders 表中有一列用于 customer_id。 orders 表中的 customer_id 字段将是 customers 表中 id 字段的外键。这将为您提供最佳性能。

您可以对已删除的用户(及其订单)进行定期清理或基于事件的清理。但请确保这些旧订单和客户存储在某个地方。也许存档表或后端数据仓库可以对这些数据进行报告和分析 (OLAP)。

Let say both services share a customer ID, how do you handle data consistency? If you remove a customer on the customer service side, you end up with inconsistency. If your service has to notify the other services then you end up with tighlty coupled services which to me sounds like what you wanted to avoid in the first place. You could kind of avoid that by having an event mechanism which notify everyone but what about network errors when you don't even know who is supposed to receive the event?

有多种方法可以做到这一点。如前所述，您可以创建一个事件来处理客户删除或定期进行数据库清理。但有一件事是肯定的，订单服务不需要在清理完成时得到通知，除非你想要它。不需要，但如果您希望通过订单服务完成订单剔除，则可能需要。执行此操作的简单方法是创建一个存储过程，将 customer_id(或 customer_id 的列表)作为输入并从订单表中删除与该 customer_id 匹配的所有订单。请务必做好数据备份，以便日后进行数据分析和审计。

I want to do a simple query : retrieve the customers from US that bought product A. Given that 3million people bought product A and we have 1 million customers in the US; How could you make that reasonably performant? (Our current DB would execute that in few milliseconds)

这也是为什么将客户、产品和订单表保存在同一个数据库中是有意义的，因为当它们在同一个数据库中时，可以更轻松地快速执行此查询。您可以利用数据库的设计和优化工具以及 EXPLAIN/DESCRIBE 输出来调整表索引等。如果您使用的是 Mysql，则可以更改数据库引擎(我推荐 TokuDB 数据库引擎)。

最后，我的主要建议是为 OLTP 保留一个数据库。因为您将在相同数量的硬件上获得更高的效率和性能。将 DB 拆分为多个 DB 会对您的代码、体系结构、网络和 CPU 产生间接成本。重要的是您的数据库可以水平扩展，并且可以针对对其进行的查询进行微调。移动OLAP到它自己的数据库。这可以使用 ETL 来完成将数据从 OLTP 数据库移动到 OLAP 数据库。您示例中的查询听起来像是在 OLAP 数据库中完成的查询。对于您的 OLAP 数据库，您可以使用列式数据库，例如 Vertica 或可以轻松水平扩展的等效数据库。需要注意的重要一点是，通过拆分您的 OLAP 和 OLTP，您可以针对各自的目的调整和配置它们。

无论您将客户、订单和产品服务作为整体(我的建议)还是作为微服务运行，数据库设计都不应更改。如果您将 OLTP 数据库拆分为多个数据库，将会导致您的代码中的查询发生变化，因为现在您无法执行简单的 JOIN 或存储过程。

这就是 Martin Fowler 所说的 Monolith First。 http://martinfowler.com/bliki/MonolithFirst.html