解析大型电商网站系统架构分层设计

DevOps 人员需要了解公司的网站架构设计，如果牵涉了具体的高流量高并发的场景，那么，此时也需要提供实际的解决方案，所以了解网站的分层系统架构设计是非常有必要的。网站架构一般分成网页缓存层、负载均衡层、Web 服务器层、文件服务器层及数据库层这五层。

1、网页缓存层

网页缓存层，比如 CDN 的租赁，专业 CDN 公司的 Cache 缓存服务都是自研的（底层开发一般是 C 语言），还需要区分磁盘缓存或内存缓存，另外还有针对小文件所做的优化，其效果比公司自行部署 Squid、Varnish 更好、更专业，Bind View 也需要精准细分，而且价格相当低廉，所覆盖的边缘节点也比较多，所以这里推荐采用 CDN 租赁的方式。

很多企业喜欢尝试自建 CDN，这是一个比较吃力不讨好的活儿，未必能够达到预期目标，关于这点，架构师在架设网站初期就应该规划好，而不要等到网站流量及压力巨大时才去规划。

2、负载均衡层

建议将负载均衡分成两级来处理，一级是流量四层分发，二级是应用层面七层转发（即业务层面）。首先我们可以通过 LVS 或 HAProxy 将流量转发给二层负载均衡（一般为 Nginx），即实现了流量的负载均衡，此处可以使用如轮询、权重等调度算法来实现负载的转发；然后二层负载均衡会根据请求特征再将请求分发出去。此处为什么要将负载均衡分为两层呢？

1）第一层负载均衡应该是无状态的，方便水平扩容。我们可以在这一层实现流量分组（内网和外网隔离、爬虫和非爬虫流量隔离）、内容缓存、请求头过滤、故障切换（机房故障切换到其他机房）、限流、防火墙等一些通用型功能，无状态设计，可以水平扩容。

2）二层 Nginx 负载均衡可以实现业务逻辑，或者反向代理到如 Tomcat，这一层的 Nginx 与业务相关联，可以实现业务的一些通用逻辑。如果可能的话，这一层也应尽量设计成无状态，以方便水平扩容。

3、Web 服务器层

Web 服务器层压力比较大，大的网站现在都选择将 Nginx 作为 Web 主要应用服务器，事实上，Nginx 在抗并发能力和稳定性方面确实超过了预期。另外，Linux 集群还有一个优势，那就是它的高扩展性，特别是水平（横向）扩展。就算网站的并发连接数有 10 万以上，也无非是多加 Web 机器（廉价的 PC Server 也是可行的），或者通过 Nginx+lua 这种高性能的 Web 应用服务器来承担压力。在进行实际的线上维护时发现在高峰期间，实际上每台 Web 的并发并不算特别大，所以网站的压力在这一层也能通过技术手段加以克服。

4、文件服务器层

现在生产服务器使用的一般是如下的方案。

• 单 NFS 作为文件服务器，这样做的好处是维护方便，但存在单点故障的问题，NFS 机器出现故障时需要人为手动干预。

• NFS 分组，虽然这样可以分摊压力，但这样做也会存在单点故障的问题，NFS 机器出现故障时需要人为手动干预。

• DRBD+Heartbeat+NFS 高可用文件服务器，维护方便，也不存在单点故障的问题，但随着访问量的增大，后期一样也会存在压力过大的情况。

• 采用分布式文件系统。

对于静态内容，如 CSS、JS、HTML 还有图片文件，可以通过租赁 CDN 的方式来进行处理，将图片服务器独立出来，并分配独立域名。

5、数据库层

数据库的压力，网站的 PV、UV、QPS 和并发连接数增加以后，数据库这块的压力就是最大的，归根结底还是磁盘的 I/O 压力大。

首先应在业务逻辑上将数据分离。很多读写频繁的业务数据，比如 ip list 和频繁读取的配置等信息都没有必要使用 MySQL 数据库来保存，我们完全可以利用 redis 分布式缓存来保存这些数据，这样读取速度也能得到保证，后端 MySQL 数据库的压力也可以得到缓解。

电子商务网站一般的场景包括签到、商品的订单系统等，这些在技术层面很容易实现；另外还有一种常见的场景—秒抢红包，像这种用户在瞬间涌入产生高并发请求的场景，这个时候我们需要引入消息中间件，例如 RabbitMQ，此时 RabbitMQ 机器数量将视实际的应用而定。

场景中的红包定时领取是一个高并发的业务，活动用户会在到点的时间大量涌入，DB（即后端的 MySQL 层，这次简写为 DB）瞬间就会受到一记暴击，支撑不住就会宕机，然后影响整个业务。

希望大家能够根据上文对网站进行的五层分解，结合自己网站的情况，了解每一层在网站设计中的作用和重要性，找出网站瓶颈并加以优化，将自己的网站打造成高可用、高可扩展性的网站。