第2章 大型网站架构模式

2.1 网站架构模式

为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能，高可用，易伸缩，可扩展，安全等各种技术架构目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。

2.1.1 分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。

分层结构在计算机世界中无处不在，网络的7层通信协议是一种分层结构；计算机硬件，操作系统，应用软件也可以看作是一种分层结构。在大型网站中也采用分层结构，将网站软件系统分为应用层，服务层，数据层，如下：
应用层：负责具体业务和视图展示，如网站首页及搜索输入和结果展示；
服务层：为应用层提供服务支持，如用户管理服务，购物车服务等；
数据层：提供数据存储访问服务，如数据库，缓存，文件，搜索引擎等；

通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。

但是分层架构也有一些挑战，就是必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。

分层的架构是逻辑上的，在物理部署上，三层结构可以部署在同一个物理机器上，但是随着网站业务的发展，必须需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，使网站拥有更多的计算资源以应对越来越多的用户访问。

2.1.2 分割

如果说分层是将软件在横向方面进行切分，那么分割就是在纵向方面对软件进行切分。

网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

大型网站分割的粒度可能会很小。比如：在应用层，将不同业务进行分割，如：购物，论坛，搜索，广告分割成不同的应用，由独立的团队负责，部署在不同的服务器上；

2.1.3 分布式

对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协调工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU，内存，存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

但分布式在解决网站高并发问题的同时也带来了其他问题。如下：
（1）分布式意味着服务调用必须通过网络，这可能会对性能造成比较严重的影响；
（2）服务器越多，服务宕机的概率也就越大，一台服务器宕机造成的服务不可用可能会导致很多应用不可访问，使网站可用性降低；
（3）数据在分布式的环境中保持数据一致性也非常困难，分布式事务也难以保证，这对网站业务正确性和业务流程有可能造成很大影响；
（4）分布式还导致网站依赖错综复杂，开发管理维护困难；

在网站应用中，常用的分布式方案有以下几种：
分布式应用和服务：将分层和分割后的应用和服务模块分布式部署，除了可以改善网站性能和并发性，加快开发和发布速度，减少数据库连接资源消耗外；还可以使不同应用复用共同的服务，便于业务功能扩展。

分布式静态资源：网站的静态资源如JS，CSS，Logo图片等资源独立部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度；由负责用户体验的团队进行开发维护有利于网站分工合作，使不同技术工种术业有专攻。

分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据需要分布式部署。除了对传统的关系数据库进行分布式部署外，为网站应用而生的各种NoSQL产品几乎都是分布式的。

分布式计算：严格说来，应用，服务，实时数据处理都是计算，网站除了要处理这些在线业务，还有很大一部分用户没有直观感受的后台业务要处理，包括搜索 引擎的索引构建，数据仓库的数据分析统计等。这些业务的计算规模非常庞大，目前网站普遍使用Hadoop及其MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。

此外，还有可以支持网站线上服务器配置实时更新的分布式配置；分布式环境下实现并发和协同的分布式锁；支持云存储的分布式文件系统等。

2.1.4 集群

多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

因为服务器集群有更多服务器提供相同服务，因此可以提供更好的并发特性，当有更多用户访问的时候，只需要向集群中加入新的机器即可。同是因为一个应用由多台服务器提供，当某台服务器发生故障时，负载均衡设备或者系统的失效转移机制会将请求转发到集群中其他服务器上，使服务器故障不影响用户使用。所以在网站应用中，即使是访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小的集群，目的就是提高系统的可用性。

2.1.5 缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善性能的第一手段。

CDN：即内容分发网络，部署在距离终端用户最近的网络服务商，用户的网络请求总是先到达他的网络服务商那里，在这里缓存网站的一些静态资源（较少变化的数据），可以就近以最快速度返回给用户。

反向代理：反向代理属于网站前端架构的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问到的就是反向代理服务器，这里缓存网站的静态资源，无需将请求继续转发给应用服务器就能返回给用户。

本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库。

分布式缓存：大型网站的数据量非常庞大，即使只缓存一小部分，需要的内存空间也不是单击能承受的，所以处理本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。

使用缓存两个前提条件：（1）数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；（2）数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性。

2.1.6 异步

在单一服务器内部可通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；
在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。

异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化而不互相影响。使用异步消息队列还有如下特性：提高系统可用性，加快网站响应速度，消除并发访问高峰（使用消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力）。

2.1.7 冗余

服务器冗余和数据冗余，访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的就是通过冗余实现服务高可用。数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。

2.1.8 自动化

大型网站的自动化架构设计主要集中在发布运维方面，分为两部分：
（1）在开发-测试-发布过程中，自动化如下：
自动化代码管理：代码版本控制，代码分支创建合并等过程自动化，开发工程师只要提交自己参与开发的产品代号，系统就会自动创建开发分支，后期会自动进行代码合并；
自动化测试：代码开发完成，提交测试后，系统自动将代码部署到测试环境，启动自动化测试用例进行测试，向相关人员发送测试报告，向系统反馈测试结果；
自动化安全检测：安全检测工具通过对代码进行静态安全扫描及部署到安全测试环境进行安全攻击测试，评估其安全性；
自动化部署：将工程代码自动部署到线上生产环境；
（2）在生产环境的自动化管理，自动化如下：
自动化监控：对服务器进行心跳检测，并监控各项性能指标和应用程序的关键数据指标；
自动化报警：如果发生异常，超出预设的阀值，向相关人员发送报警信息，警告故障可能会发生；
自动化失效转移：在检测到故障后，系统会自动将失效的服务器从集群中隔离出去，不再处理系统中的应用请求；
自动化失效恢复：待故障消除后，系统会自动重启服务，同步数据保证数据的一致性；
自动化降级：在网站遇到访问高峰，通过拒绝部分请求及关闭部分不重要的服务，将系统负载降至一个安全的水平；
自动化分配资源：将空闲资源分配给重要的服务，扩大其部署规模；

2.1.9 安全

（1）通过密码和手机校验码进行身份认证；
（2）登录，交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据，如用户信息等也进行加密处理；
（3）为了防止机器人程序滥用网络资源攻击网站，网站使用验证码进行识别；
（4）对于常见的用于攻击网站的XSS攻击，SQL注入，进行编码转换等相应处理；
（5）对于垃圾信息，敏感信息进行过滤；
（6）对交易转账等重要操作根据交易模式和交易信息进行风险控制；

2.2 架构模式在新浪微博的应用

新浪微博系统分为三个层次：
（1）最下层是基础服务层，提供数据库，缓存，存储，搜索等数据服务，以及其他一些基础技术服务，这些服务支撑了新浪微博的海量数据和高并发访问，是整个系统的技术基础。
（2）中间层是平台服务和应用服务层，新浪微博的核心服务是微博，关系和用户，它们是新浪微博业务大厦的支柱。这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成新浪微博的业务基础。
（3）最上层是API和新浪微博的业务层，各种客户端（包括WEB网站）和第三方应用，通过调用API集成到新浪微博的系统中，共同组成一个生态系统。

这些被分层和分割后的业务模块与基础技术模块分布式部署，每个模块都部署在一组独立的服务器集群上，通过远程调用的方式进行依赖访问。新浪微博早期还使用过一种叫MPSS（MultiPort Single Server，单服务器多端口）的分布式集群部署方案，在集群中的多台服务器上，每台都部署多个服务，每个服务使用不同的端口对外提供服务，通过这种方式使得有限的服务器可以部署更多的服务实例，改善服务的负载均衡和可用性。现在网站应用中常见的将物理机虚拟化成多个虚拟机后，在虚拟机之上部署应用的方案跟MPSS方案异曲同工，只是更加简单，还能在不同虚拟机上使用相同的端口号。