忘记微服务！池体架构的无与伦比的好处

微服务因为允许每个功能独立发展而受到赞扬。虽然它们在B2C世界中表现出色，其中每个用户的流量都是均匀的，但B2B在用户之间的流量差异方面常常面临困扰。

本文将介绍一种更简单的解决方案，称为池体架构（pool architecture），旨在为每个客户定制适合的扩展！

让我们以这个水族馆为例。有很多小鱼与鲸鲨共享同一个水槽。不要担心，尽管它们的名字是鲸鲨，但它们只吃浮游生物。它们与珊瑚礁鱼和平共处。然而，食物分配仍然存在问题。

服务就像一个鱼缸

想象一下，服务就像这个鱼缸。每个客户都是一条鱼，它们都共享同样的基础设施（水和食物）。你无法单独为每条鱼喂食。

唯一的选择是将食物倒入鱼缸。如果不放足够的食物，鲸鲨可能会在小鱼之前吃光一切，导致它们挨饿。

如果放太多食物，每个物种将吃它们所需要的，但有些剩余食物将被浪费。这正是CPU发生的情况。如果一个客户密集地使用你的服务，他可能会对其他客户发起DDoS攻击（吃掉所有食物）。如果有太多实例，只是在浪费资源。

例如，AWS资源是在客户之间共享的。这意味着您可能与Netflix使用同一个数据中心内的相同CPU。当他们发布新节目时，您可能会竞争资源。一个基础设施共享的服务将如下所示。

一条鱼，一个鱼缸

单元化架构的理念是将系统分为单元：“一组从设计和实现到部署的组件集合。单元是可以独立部署、管理和观察的”。

领域驱动设计（DDD）根据领域将单元分为不同的部分。微服务根据功能将单元分割。找到正确的边界或合适的单元大小总是具有挑战性的。单元化架构的第一个迭代通常很慢，无法快速扩展。

使用池体架构，我们扩展了单元的概念。我们为边界定义了一个简单的规则：每个客户一个单元。换句话说，每个客户都运行自己的专用单体架构，拥有保留的基础设施，可以根据其需求进行扩展。

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

使用经典的3层服务架构，池体架构带来以下好处：

好处

只在需要的地方花费资金，按客户进行扩展。
如果一个客户流失，只需安全地删除其基础设施。
限制故障的半径传播。崩溃只影响一个池体。
增加安全/隐私层。客户数据永远不会与其他人共享。
部署比微服务更容易，只需部署整个单体架构。
可以根据客户的时区部署更改，以避免任何停机时间。

什么是鲸鱼？

鲸鱼是指需要专用池体的大客户。这可能是技术条件：

运行一定数量的请求的客户
执行缓慢或昂贵请求的客户（上传 vs 下载，读取 vs 写入）

也可能是业务条件：

支付溢价费用的客户
具有合规要求的客户

迁移

大多数初创公司选择优化开发速度和工程成本。这就是为什么有这么多单体架构的原因。但随着它们的发展，一些客户规模扩大，成为重度用户，对共享基础设施产生影响。

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

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

根据经验，最后一步是最复杂的部分。希望提取给定用户的所有数据并将其复制到另一个数据库中。通常需要复杂的查询来仅加载所需内容。使用索引或复合键更加复杂。

在某些方面，它看起来像是将单体架构拆分。Sam Newman在他的书中提到了将单体架构迁移到微服务的技术。它们都需要一些代码修改和复杂的业务逻辑更改。与此相比，池体架构的迁移往往更便宜，因为它们主要依赖于编写基础设施即代码。

陷阱

我谈到了池体架构的好处，但是这篇文章如果不提及一些陷阱就不完整。

专用基础设施并非定制代码

所有客户都应共享相同的代码。请注意，池体架构不是为了根据客户定制代码。当你部署修复时，应该为所有客户进行部署。从长远来看，如果你尝试维护多个客户代码库，这将变得困难。由于代码保持不变，你可以使用数据库或环境变量来满足特定需求，例如DNS名称。不要将CSS放入数据库以实现不同的外观和感觉。不是在构建内容管理系统（CMS）。