忘了你的微服务吧！池架构的无与伦比的好处。

当单体架构是解决你的扩展挑战的方案时。

微服务因其允许每个功能独立成长而受到称赞。虽然微服务在用户流量均匀的B2C世界中表现出色，但在B2B领域，用户之间的流量差异往往独特且难以处理。在这条吸引点击的标题背后，我将向您介绍一个更简单的解决方案，称为池架构，旨在为每个客户量身定制扩展功能！

一个由观赏鱼和鲸鲨共用的水箱（乔治亚水族馆）

让我们以这个水族箱为例。有很多小鱼和一条鲸鲨共用一个鱼缸。不用担心，尽管名字叫鲸鲨，它们只以浮游生物为食。它们与小鱼和平共处。然而，食物分配仍然存在问题。

服务作为一个鱼缸

想象你的服务就是这个水箱。每个客户是一条鱼，它们共享相同的基础设施（水和食物）。你不能单独喂每条鱼。唯一的选择是往水箱里投放食物。如果你投放的食物不够，鲸鲨可能会在其他小鱼之前把所有食物吃光，导致小鱼挨饿。如果你投放的食物过多，每种鱼会吃掉它们需要的部分，但会有一些剩余的食物被浪费掉。这与CPU的情况完全相同。如果一个客户频繁使用你的服务，他可能会对其他客户发起DDoS攻击（吃光所有食物）。如果你有太多的实例，你只是在浪费钱。

例如，AWS 资源是跨客户共享的。这意味着你可能与 Netflix 共用同一数据中心中的同一 CPU。当他们发布新剧集时，你可能会发现自己在争夺资源。一个共享基础设施的服务看起来就是这样。

每个客户端共享相同的基础设施。

一个鱼，一个鱼缸

细胞架构背后的思想是将系统拆分成细胞：“一组组件，从设计和实现的角度进行分组，并部署在一起。一个细胞可以独立部署、管理和监控”（参见WSO2网站）。

领域驱动开发（DDD）根据领域划分细胞。微服务则根据功能划分细胞。找到正确的边界或确定细胞的合适大小总是具有挑战性。细胞架构的早期迭代通常速度较慢，无法快速扩展。

采用 池架构，我们扩展了细胞的概念。我们定义了一个简单的边界规则：每个客户端一个细胞。换句话说，每个客户端运行其专用的单体应用，并拥有预留的基础设施，允许根据其需求进行扩展。

池架构。

如果我继续使用这个比喻，每个客户现在可以拥有不同的水温，危险物种可以有自己的小水箱，而鲸鱼则可以拥有一个巨大的水箱。食物也不再是个问题，因为你可以选择填充哪个水箱。

使用经典的3层架构的服务：

池中的三层架构。

👍 优点

• 只在需要的地方花钱，按客户需求进行扩展。
• 如果客户流失，只需安全地移除其基础设施。
• 限制了故障的影响范围。一个池的崩溃只会影响该池。
• 增加了一层安全/隐私保护。客户数据从不与他人共享。
• 部署起来比微服务更简单，只需部署整个单体应用（复制粘贴你的Terraform配置）。
• 可以根据客户的时区部署更改，以避免任何停机时间。

什么是鲸鱼？ 🐳

鲸鱼是一个需要专用池的大客户。这可能是技术标准：

• 运行给定阈值请求的客户端
• 执行慢或昂贵请求的客户端。（上传与下载，读取与写入）

这也可能是业务标准

• 一个支付溢价费用的客户
• 一个有合规要求的客户

迁移

大多数初创公司在早期阶段会选择优化开发速度和工程成本。这就是为什么很多公司会选择采用单体架构。但是随着公司的发展，一些客户开始扩展并成为重度用户，这会影响共享的基础设施。

将用户从共享基础设施迁移到专用基础设施并不是一个简单的任务。一个迁移的例子：

• 步骤 1：迁移网络层：为用户分配一个指向旧基础设施的专用DNS。
• 步骤 2：迁移计算层：让他们在专用实例上运行，但继续使用共享数据库。
• 步骤 3：迁移数据层：将所有数据从共享数据库移动到他们自己的数据库中。

最后一步，根据经验，是最复杂的部分。你想要提取给定用户的所有数据并将其复制到另一个数据库中。这通常需要复杂的查询来加载你所需要的数据。如果涉及到索引或组合键，情况会更加复杂。

步骤0. 大家使用相同的基础设施。

步骤 1 和 2. 设置新的计算层，仍然指向旧的数据库。

步骤 3. 停止流量，复制数据库并切换流量。

在某些方面，它看起来像是拆分一个单体应用。在他的书中，Sam Newman 提到了将单体应用迁移到微服务时使用的技术。这些技术都需要一些代码修改和复杂的业务逻辑变更。而池架构迁移通常成本较低，因为它们主要依赖于编写基础设施即代码。

👎 坑点

我谈到了池架构的好处，但如果不提到一些潜在的问题，这篇文章就不完整。

1. 专用基础设施不是定制代码
   所有客户应该共享相同的代码。请注意，池架构并不是按每个客户定制代码的方法。当你部署一个修复时，应该为所有客户部署。从长远来看，如果你试图为每个客户维护多个代码库，这将使你的生活变得困难。由于代码保持不变，你可以使用数据库或环境变量来满足特定需求，例如DNS名称。不要将CSS放入数据库以实现不同的外观和感觉。你不是在构建一个CMS。

2. 更难维护
   日志和监控不再集中化。你需要多个账户来连接到每个客户环境并找出问题所在。你不再有跨客户的分析数据。

3. 尽早迁移
   尽管这可能很有诱惑力，但池架构的实施需要大量的工作。你需要工具。例如，你需要Terraform脚本来确保基础设施作为代码进行维护。因此，当你进行更改时，每个客户都可以轻松部署。

4. 初期成本更高
   为每个客户设置特定基础设施的成本在初期会很高。两个小数据库的初始成本比一个中型数据库更高。

结论

虽然池架构提供了一种有吸引力的替代方案，以应对无处不在的微服务方法，但必须承认，并不存在一种适合所有情况的解决方案。开发人员和架构师在跳上最新趋势之前必须谨慎行事。

就像我们在水族箱类比中提到的那样，我们为服务构建的生态系统必须仔细平衡。对 B2C 平台有益的方案可能对 B2B 服务没有同样的效果。我们必须考虑我们客户的个体需求。

因此，以一种既充满创新热情又带有健康怀疑态度的方式去接触任何新的架构模式。提出正确的问题：它能节省资源吗？现在是合适的时机吗？迁移的成本是多少？

为了获得更多的实用见解，一定要关注。保持信息灵通，保持怀疑精神，并继续负责任地构建。