图解大型网站架构
对于大部分前端同学来说，后台服务或者整个网站架构是个黑盒，前端工程师所看到所接触的业务只是冰山一角。
本文，从一个前端人的视角，以一张大型网站架构图开始，将这个潘多拉的魔盒打开……只是概述性的介绍，提纲式的分析讲解。
来自李智慧老师《大型网站技术架构-核心原理与案例分析》第一章的图示。
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，单表可以存储海量数据，可线性扩充；
- 搜索引擎服务器：也是一种非关系数据库，主要用于搜索；
如有错漏之处，望指正。