Why build scalable Web applications?
Imagine your marketing campaign to attract a lot of users, at some point, the application must also provide thousands of other services, such a large amount of concurrent, server load will be great, if not properly designed, the system will not deal with.
What happened next is that random errors, slow loading content, endless waiting, disconnected, service is not available and other issues.
Hard to attract users to the attacker into a system, the server resources are exhausted, the application crashes.
Most of your users will be lost, the product will reduce the rating, the market will be filled with negative comments.
So, scalability has become the DNA Web applications.
Scalable Application Architecture Overview
Scalable architecture of two main principles:
- Separation of Concerns
- Horizontal expansion
Separation of Concerns
Each type of task should have a separate server.
Sometimes, the application of all the work is done by a server: processing user requests, storing user files.
It completed work normally be several separate server to complete.
Therefore, when the server is overloaded, the entire application will be affected: the page can not be opened, and so the image could not be loaded.
To avoid this situation, the need to ensure separation of concerns.
For example, API server client-server processing request requires immediate reply.
Suppose a user to change their profile image, after uploading images, often subjected to certain treatment: adjust the image size, analysis explicit content, stored in the storage ......
Obviously, this process is complex and time-consuming, and users do not need to wait for the process to complete. Therefore, the lower priority task because it does not require a real-time results reply.
This is why it should not be placed API server.
Separation of concerns for scalable application architecture is crucial, not only because of its ability to assign different types of tasks between the dedicated server, and it is the basis of the level of expansion.
Zoom level
Horizontal scaling idea is to distribute the load among multiple servers.
Each server will run the application, and to enable or disable the server based on the current load.
Load balancer controls the number of servers required to ensure smooth processing system.
The load balancer know how many servers at work, how much idle servers have been found when at full capacity, and the number of requests is increasing, then he will activate other servers, load reallocation request.
When reducing the number of requests, he will deactivate unneeded servers.
他还会去做服务器的健康检查，在健康的服务器当中分配请求。
负载均衡器有多种分配请求的算法，例如轮询、随机、延迟最小、流量最小等等。这些算法可以考虑诸如地理位置（用户请求定向到最近的服务器）、每个服务器的工作能力等因素。
水平缩放不需要缩放整个应用，例如，当 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 处理。
翻译整理自：
https://medium.com/swlh/how-to-build-scalable-and-highly-available-web-applications-f1d7e7a415be
推荐阅读：
