横向扩展：分工还是冗余？
这是我一直想知道的事情。我知道水平扩展就是添加更多机器。但我可以想到两种方法。假设我有 20 台要使用的服务器（加上一个数据库）。我可以：
- 让所有 20 台服务器都作为应用程序服务器运行。
- 让不同的服务器执行任务的不同部分。例如，让一组服务器处理请求，然后让另一组服务器应用业务逻辑，然后让另一组服务器进行数据库调用。
第 1 种似乎更常见且更容易理解，但第 2 种似乎被认为是“最佳实践”（因为它主要是一个 n 层架构）。这两种型号之间该如何选择呢？每种方法的优缺点是什么？
This is something I've always wondered about. I understand that horizontal scaling is about adding more machines into the mix. But I can think of two approaches to this. Suppose I have 20 servers I want to use (plus a database). I can:
- Make all 20 servers run as application servers.
- Make different servers do different parts of a task. For instance, have one set of servers handle the request, then another set to apply business logic, and then another to make the database call.
Number 1 seems to be more common and easier to understand, but number 2 seems to be considered "best practice" (as it's mostly an n-tier architecture). How does one choose between these two models? And what are the pros and cons of each approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于任务以及您的瓶颈是什么。
几乎无一例外，您将需要至少两种服务器：1) 应用程序和 2) 数据库。如果您分布应用程序服务器，您仍然需要在它们之间同步数据，使其中一台服务器（或单独的服务器）成为您的数据库服务器。
如果您知道数据库不会受到太多流量的影响（例如：您正在运行一个基于实时聊天的站点，并且没有太多数据被永久存储或同步），那么选择只创建应用程序服务器可能会很好。
然而，对于大多数站点来说，选择#2 更好，特别是如果您事先不知道哪些服务器将成为瓶颈。如果您不允许每种服务器类型进行扩展，那么您将不得不在意外增长期间重写源代码。然后，您将不得不做出艰难的决定，例如“我们应该禁用哪些功能，以便网站在我们进行扩展时仍然可以运行？”
但老实说，我不会花太多时间担心可扩展性。一旦您的服务器负载变得过高，您将能够负担一些源代码重写的费用。要么通过新发现的资金来源，要么通过网站外的直接利润。 举个例子：Twitter 仍然表现出色。
It depends on the task, and what would be your bottlenecks.
Almost without exception, you're going to need at least two kinds of server: 1) Application and 2) Database. If you distribute the application servers, you still need to synchronize data between them, making one of those servers (or a separate server) be your database server.
If you know the database will not be hit with much traffic (e.g.: you are running a live chat-based site, and not much data is permanently stored or synchronized) then the choice of making nothing but application servers might be fine.
Choice #2 is better, however, for a majority of sites, especially if you don't know in advance which servers will become bottlenecks. If you don't allow for each server type to scale, then you'll be stuck having to rewrite source code during unexpected growth spurts. Then you'll have to make difficult decisions like "Which features should we disable so the site can still function while we work on scaling?"
Honestly, though, I wouldn't spend too much time worrying about scalability. Once you reach a point where your server loads are becoming too high, you will be able to afford some source rewrites. Either through newly discovered sources of funding, or through direct profits off the site. Case in point: Twitter is still doing great.