简单的 Web 应用架构概览

一个 Web 应用通过功能分割，可以分为不同组件。本文以一个 Rails 应用为例，列出各个常用组件。

简单 Web 架构

1. 负载均衡：Nginx

使用 Nginx 作为负载均衡服务，Nginx 将请求平衡、分摊给多个 Web 服务。

2. Web 应用服务：Puma

Web 应用服务根据客户端的请求执行业务流程，然后返回格式为 HTML 或 JSON 之类的响应。这个过程会跟很多服务通信：从数据库取记录、将耗时操作发给异步任务服务等等。

3. 数据库：PostgreSQL

用数据库来定义数据结构，根据业务规则对数据增删改查。比如一个商城应用，它需要创建商品、创建购物车条目、修改订单状态等等。

4. 缓存服务：Redis

Redis 是一个 in-memory 数据库，提供了一种简单的键值对，使得存取数据的时间复杂度为 O(1)。通过缓存服务，我们可以存储运算成本比较高的结果，然后以后快速取得这些内容。

比如在权限系统中，在用户访问资源前，需要检查用户的权限。而用户的权限列表需要从访问好几个数据库表才能构建出来。

• 我们在第一次检查权限时把构建好的权限列表存到缓存中。
• 下次检查权限时，就不必从数据库加载记录了，可以直接从缓存中读取。

要注意的是，每次写缓存时，都要考虑在什么条件下进行失效处理。对于权限列表，我们应该在用户权限更改时，将它删除。

5. 任务队列：Sidekiq

Sidekiq 是一个基于 Redis 的异步任务服务。当我们创建一个任务时，Sidekiq 将任务存进 Redis，Sidekiq 服务根据调度规则不断从 Redis 获取任务，然后处理。对于一些我们不关心其返回结果或者比较耗时的操作，我们可以异步处理这些操作。

比如用户注册成功后，系统会发一封欢迎邮件给该用户，发送邮件这个操作不必在注册接口中执行，就可以不阻塞用户的注册动作。

6. 消息队列：Active Mq

消息队列有许多好处：平衡流量高峰、解耦。消息列队有 2 个角色：发布者、消费者。他们不关心消息从哪里来，到哪里去，只关心消息内容，从而达到解耦的目的。

比如在一个酒店管理系统下， A 系统修改房间状态后发布了一条消息出去，B 系统收到这条消息，它再根据内容做其他事情，这个过程中，A 不用担心有哪些系统要监听这个消息，也不必关心消息是否被成功处理。

作为消费者，需要启动一个进程来专门接收消息，Ruby 应用可以使用 Stomp 作为 ActiveMq 的消费者。

7. 搜索引擎：ElasticSearch

使用搜索引擎，我们可以快速给应用添加这些功能：实时查询、聚合数据、全文搜索。

8. CDN

存储静态资源文件，比如图片、Javascript、HTML、CSS 等等。

• CDN 服务会将文件存储在世界各地的服务器上，可以让各个地方的用户快速访问资源。
• 而且这些流量不用经过我们的 Web 服务器，为应用服务器分担负载。

参考文章：

• https://engineering.videoblocks.com/web-architecture-101-a3224e126947