使用“app + db nodes”进行分片的优点/缺点与分别对数据库进行分片并对应用服务器进行负载均衡

Question

我们正在准备扩展API密集型Web应用程序的API端。我（精通技术的）客户提出了一种非常规的方法：不是将负载平衡到几个应用服务器，而是与分片数据库通信，他希望我们：

• “分享应用服务器”，将app服务器代码和db放在每个物理服务器上，以便app服务器只连接到自己的db shard;
• 让app服务器在需要访问其他分片时互相交谈（而不是直接与另一个分片的DB交谈）;
• 让API客户端选择一个应用程序分片本身（在客户端，基于一些稳定的哈希）并直接与它对话。

潜在的推理是，这是最自然的事情，并且这将允许我们将来转移到多站点分布式系统。

（堆栈是MySQL上的PHP + Node.js，虽然此时也考虑过转换到MongoDB。）

现在，我没有看到现成的巨大问题。编写这些服务器到服务器的交互可能有点麻烦，但它肯定会有自己的好处。基本上我不知道这是不是一个好主意。

你有什么利弊？我在这里寻找技术问题和优势。谢谢！

Answer 1

由于很多原因，这很简单。

• API客户端不应该知道要与哪个应用分片进行通信。这将限制你现在可能无法预见的方式，但可能/将来会成为一个问题。 API客户端应该播放愚蠢，以便您可以在应用服务器死亡，更改，再次分片等情况下适当地路由请求。
• 如果您的应用代码或数据库架构很慢，会发生什么？ （不是两个在同一时间，只有一个）。现在你有一个db shard减慢了应用程序分片的速度。
• 您的db + app分片需要在RAM中保留应用代码+内存和db代码+内存。这意味着CPU将花费更多时间来交换代码和内存来执行这两组任务。
• 我发现很难用言语表达，但这种类型的架构尖叫“坏耦合”和“没有关注点分离”（可能不是正确的术语，但我希望你理解我的意思）。您将两种截然不同的应用程序类型（应用程序服务器和数据库）放在一个盒子上。更新它们和绕失败实例路由的管理噩梦将非常困难。

我讨厌以这种方式论证我的观点，但很多非常聪明的人以前都处理过这些问题，而且我从来没有听说过这种类型的架构。这可能是有原因的。更不用说有很多技术和资源可以帮助您处理应用程序和数据库服务器的传统分片和负载平衡。如果你使用客户建议的架构，那就是你自己的。