图解大型网站架构

对于大部分前端同学来说，后台服务或者整个网站架构是个黑盒，前端工程师所看到所接触的业务只是冰山一角。

本文，从一个前端人的视角，以一张大型网站架构图开始，将这个潘多拉的魔盒打开……只是概述性的介绍，提纲式的分析讲解。

来自李智慧老师《大型网站技术架构-核心原理与案例分析》第一章的图示。

distributed service.png

1. 接收请求

反向代理服务器接受请求，根据具体内容路由到不同的服务器。

如果浏览器请求的是资源文件，比如HTML文件，JavaScript或样式表……

第三方静态资源：路由到CDN（内容分发网络）服务器上。因为静态资源不经常改动（比如，第三方依赖库，样式表，字体文件等等），所以很适合存储在CDN上。
普通静态资源：由反向代理服务器直接返回。

如果浏览器请求动态资源，比如REST请求，那么路由到“负载均衡调度服务器”，再由后台应用服务器集群处理。

2. 将业务拆分为多个服务，服务协作完成请求

传统方式是后台只有一个服务，包罗万象。随着项目越来越复杂，以“高内聚，低耦合”的思想，将业务拆分为独立模块，分别部署。这就是图中的“B应用服务器1”，“A应用服务器1”……

那么，如何拆分业务？

根据业务属性进行垂直切分，比如：产品子系统，购物子系统，支付子系统，评论子系统，客服子系统，接口子系统（对接如进销存，短信等外部系统）。
根据业务子系统进行等级定义，分为核心系统和非核心系统。比如：核心系统：产品子系统，购物子系统，支付子系统；非核心：评论子系统，客服子系统，接口子系统。

业务经过拆分，每个子系统可由专门的团队和部门负责，解决模块之间耦合以及扩展性问题；每个子系统单独部署，避免集中部署导致一个应用挂了，全部应用不可用的问题。

下一步，如何组织子业务完成某一具体任务？

举例，用户下单流程：

用户下单后，写入消息队列，后直接返回客户端；
库存子系统：读取消息队列信息，完成减库存；
配送子系统：读取消息队列信息，进行配送；

这个过程，利用“消息队列服务器”异步调度所需的服务，协同完成业务。

3. 部署分布式服务

为了提高高并发处理能力，可将请求分发到应用服务器集群中的任何一台服务器上。也就是说，将同样的服务部署到N台服务器上，让他们一起处理用户请求，这样最大程度上减少每个服务的压力。

可用到的负载均衡算法：

轮询：所有请求被依次发到每台应用服务器上；
加权轮询：在轮询基础上，按照配置的权重将请求分发到每个服务器；
随机：请求被随机分发到应用服务器上；
最少连接：记录每个应用服务器正在处理的连接数，将请求分发到最少连接的服务器上；
源地址散列：根据请求来源的IP进行Hash计算，对应到某台应用服务器，这样，来自同一个IP的请求总会被同一台应用服务器处理；

4. 利用缓存

缓存分为本地缓存和远程缓存。

本地缓存和应用服务共享内存，所以，它的数量不应该太多，适合存储读取最频繁且不易变动的数据。
远程缓存部署在专门的服务器上，可以使一台也可以是多台。如是多台集群，则称为分布式缓存服务器，优点是存储量大，缺点是读取比本地缓存慢。

分布式缓存服务器是将缓存数据分在N台服务器上存储，利用服务器数量的递增而扩大存储容量。

为什么需要分布式缓存？

利用分布式缓存，可以实现单点登录。比如，登录www.site1.a.com之后，希望再访问www.site2.a.com，www.site3.a.com时，无需再次登录。这时，就不应该将与登录相关的session信息存放在本地服务器缓存中（因为各个服务器的session信息不共享），而应该将session存放于分布式缓存，并提供统一访问模块-session服务器。session服务器用于为其他所有应用服务提供session读写功能。

5. 处理数据

处理数据就必须访问存储数据的容器，此容器不仅仅包括常见的关系数据库，比如MySQL，SQL Server，还包括非关系数据库，比如NoSQL，等等。

参考图示和“统一数据访问模块”交互的数据服务器：

分布式缓存服务器：缓存服务器集群；
分布式文件服务器：多台服务器存储文件，可线性扩充；
分布式数据库服务：只有单表规模非常庞大的时候才使用，将大量数据分库分表存储；并将不同业务的数据部署在不同的物理服务器上。
另外，为了进一步减轻数据库负载压力，可以采用“读写分离”模式：配置多台数据库，一台master，只用于写数据；多台slave，只用于读数据。主数据库master的数据实时同步到slave数据库上。
NoSQL服务器：非关系数据库，如HBase，单表可以存储海量数据，可线性扩充；
搜索引擎服务器：也是一种非关系数据库，主要用于搜索；

如有错漏之处，望指正。

更多高阶内容，可移步《小专栏-娜姐聊前端》。