使用“app+db 节点”分片与单独分片 db 和负载平衡应用服务器的优缺点答案

【问题标题】：Pros/cons of sharding using "app+db nodes" vs. separately sharding the db and load-balancing the app servers使用“app+db 节点”分片与单独分片 db 和负载平衡应用服务器的优缺点
【发布时间】：2011-07-08 06:33:52
【问题描述】：

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

“shard the app servers”，将app server code和db都放在每个物理服务器上，这样app server只连接自己的db shard；
让应用服务器在需要访问其他分片时相互通信（而不是直接与另一个分片的数据库通信）；
让 API 客户端自己选择一个应用分片（在客户端，基于一些稳定的哈希）并直接与其对话。

根本原因是这样做是最自然的事情，这将使我们能够在未来迁移到多站点分布式系统。

（堆栈是 MySQL 上的 PHP + Node.js，尽管此时也考虑过渡到 MongoDB。）

现在，我认为现成的它没有什么大问题。对这些服务器到服务器的交互进行编码可能会有些麻烦，但它肯定会有自己的好处。基本上我不知道这是否是个好主意。

你想到了什么优点和缺点？我在这里寻找技术问题和优势。谢谢！

【问题讨论】：

标签： scaling sharding

【解决方案1】：

这很糟糕，原因有很多。

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

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

【讨论】：

嘿！感谢您的回答。不幸的是，“很多非常聪明的人以前都处理过这些问题”这种推理不适用于我的客户。不过，我确实喜欢这些技术原因。
@Andrey：是的，使用这个论点很难卖。充其量你可以说有很多资源可以实现“传统”分片方法。这一点非常重要，因为如果您遇到问题（无论您选择哪种架构，问题总是会发生），您需要知道有资源可以帮助您。