使用“app”db 节点”分片的优点/缺点与单独对数据库进行分片并对应用程序服务器进行负载平衡
我们正准备扩展 API 密集型 Web 应用程序的 API 端。我的（精通技术的）客户对此提出了一种相当非常规的方法：他希望我们：
- “对应用程序服务器进行分片”，将应用程序服务器代码和db 在每个物理服务器上，以便应用程序服务器仅连接到自己的数据库分片；
- 让应用程序服务器在需要访问其他分片时相互通信（而不是直接与另一个分片的数据库通信）；
- 让 API 客户端自行选择一个应用程序分片（在客户端，基于一些稳定的哈希值）并直接与其对话。
根本原因是，这是最自然的事情，并且这将使我们能够在未来迁移到多站点分布式系统。
（该堆栈是 MySQL 上的 PHP + Node.js，尽管此时也考虑了向 MongoDB 的过渡。）
现在，我没有看到它现成的巨大问题。编写这些服务器到服务器交互的代码可能会有点麻烦，但它肯定有其自身的好处。基本上我不知道这是否是一个好主意。
您想到什么优点和缺点？我在这里寻找技术问题和优势。谢谢！
We are preparing to scale the API side of an API-heavy web application. My (technically savvy) client proposes a rather unconventional approach to this: instead of balancing the load to several app servers, which would talk to a sharded database, he wants us to:
- “shard the app servers”, putting both app server code and db on each physical server, so that the app server only connects to its own db shard;
- have the app servers talk to each other when they need to access other shards (instead of talking to another shard's DB directly);
- have the API client pick an app shard itself (on the client side, based on some stable hash) and talk directly to it.
The underlying reasoning is that this is the most natural thing to do it, and that this would allow us to move to a multisite distributed system in the future.
(The stack is PHP + Node.js on MySQL, although at this point a transition to MongoDB is considered too.)
Now, I don't see huge problems with it off the shelf. It might get somewhat cumbersome to code these server-to-server interactions, but then it will surely have its own benefits. Basically I'm at a loss on whether this is a good idea or not.
What pros and cons come to your mind? I'm looking for technical issues and advantages here. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于多种原因，这实在是太糟糕了。
我讨厌以这种方式争论我的观点，但很多非常聪明的人以前都处理过这些问题，而我从未听说过这种类型的架构。这可能是有原因的。更不用说有很多技术和资源可以帮助您处理应用程序和数据库服务器的传统分片和负载平衡。如果您采用客户建议的架构，那么您就只能靠自己了。
This is just plain bad for many reasons.
I hate to argue my point this way, but a lot of very smart people have dealt with these problems before and I've never heard of this type of architecture. There's probably a reason for it. Not to mention there's a lot of technology and resources out there that can help you handle traditional sharding and load balancing of app and database servers. If you go with your client's suggested architecture you're on your own.