为什么要构建可伸缩的Web应用？
想象一下，你的营销活动吸引了很多用户，在某个时候，应用必须同时为成千上万的用户提供服务，这么大的并发量，服务器的负载会很大，如果设计不当，系统将无法处理。
接下来发生的就是，随机错误、缓慢的内容加载、无休止的等待、连接断开、服务不可用等问题。
辛辛苦苦吸引来的用户变成了系统的攻击者，把服务器资源耗尽，应用程序崩溃。
你的大多数用户将丢失，产品评级将降低，市场将充满负面评论。
所以， 可伸缩性 已经成为Web应用程序的DNA。
可伸缩应用架构简介
可伸缩架构的两个主要原则：
- 关注点分离
- 水平扩展
关注点分离
每个类型的任务都应该有一个独立的服务器。
有时，应用程序是由一台服务器完成全部工作：处理用户请求，存储用户文件等。
它完成的工作通常应由几台单独的服务器完成。
因此，当服务器过载时，整个应用程序将受到影响：页面无法打开，图像无法加载等。
为避免这种情况，需要确保关注点分离。
例如，API server 处理需要即时回复的 client-server 请求。
假设某个用户更改其个人资料图像，上载图像后，通常会对其进行一定的处理：调整图像大小、分析显式内容、保存在存储中 ……
显然，这个过程复杂而耗时，而且用户不需要等待处理完成。因此，这个任务的优先级较低，因为它不需要一个实时的结果回复。
这是为什么它不应该放在 API server。
关注点分离对于可伸缩的应用架构至关重要，不仅因为它能够在专用服务器之间分配不同类型的任务，而且它是水平扩展的基础。
水平缩放
水平缩放的思想是在多台服务器之间分配负载。
每个服务器都会运行应用，并根据当前负载来启用或禁用服务器。
负载均衡器控制着所需的服务器数量，保证系统的平滑处理。
负载均衡器知道有多少台服务器在工作、多少在闲置，当发现服务器已经满负荷，并且请求的数量在增加，那么他就会激活其他的服务器，重新分配请求负载。
当请求数量降低的时候，他会停用不需要的服务器。
他还会去做服务器的健康检查，在健康的服务器当中分配请求。
负载均衡器有多种分配请求的算法，例如轮询、随机、延迟最小、流量最小等等。这些算法可以考虑诸如地理位置（用户请求定向到最近的服务器）、每个服务器的工作能力等因素。
水平缩放不需要缩放整个应用，例如，当 API server 达到临界点时，负载平衡器将激活更多 API server，而不会影响其他服务器。
这就是关注点分离对于水平缩放如此重要的原因之一。
现在，让我们看看关注点分离和水平缩放如何协同工作。
构建可伸缩的应用
这个示例中，有用于不同类型任务的服务器：
- API server
- 数据库集群
- 静态存储服务器
- Worker，做复杂的、不需要实时反馈结果的任务
每个服务器仍可能是潜在的瓶颈。让我们一个个地研究它们，看看如何避免它们每个可能出现的可伸缩性问题。
API server
API server 处理主要功能相关的请求，其数量随着用户量的增加而增加，
关键点是：不要存储任何的用户数据，需要无状态化。
假设用户上传图片的请求是 A 服务器处理的，A 把图片保存到了本地，下次用户读取图片的请求是 B 处理的，那么就读不到图片了。
还有，负载均衡器随时可以终止或暂停它们中的每一个。
静态存储服务器
静态存储服务器与 CDN 配合使用。
CDN 称为内容交付网络，是一种缓存服务器，可以将内容立即交付给用户。
假设你在 YouTube 上观看了一个有趣的视频，该视频存储在加利福尼亚的静态存储服务器中。
你在群聊中发布该链接，如果所有同事同时打开该链接，则服务器压力山大。
有了CDN后，首次打开视频时，它将被上传到最近的CDN服务器。
因此，如果您与朋友共享链接，则他们将从CDN，而不是直接从静态存储服务器请求该链接。
这样防止了静态存储服务器过载，用户还可以享受超快的视频加载速度。
Worker
并非所有用户请求都需要服务器的即时答复。
他们可能需要更多的时间才能完成，这些任务可以在用户忙于其他事情时在后台运行。
例如，上传视频，用户不会坐下来等视频处理完毕。
这些任务由 Workers 和 Message Queue 处理。
Worker 在独立服务器上运行，就像API服务器一样，可以根据负载强度进行扩展。
Message Queue 就像 API服务器和 Worker 之间的任务管理器。
任务首先到达 Message Queue，当 Worker 不忙时，从队列中取出并进行处理。如果 Worker 由于某种原因失败，则任务将保留在队列中，直到 Worker 恢复或由其他 Worker 处理。
