为了解决大型网站面临的高并发访问、海量数据处理、高可靠运行等一系列问题与挑战，大型互联网公司在时间中提出了许多解决方案，以实现网站高性能、高可用、易伸缩性、可扩展、安全等各种技术架构目标。
最常见的架构模式，将系统在横向维度上切分成几个部分，每个部分单一职责。然后通过上层对下层的依赖和调用组成一个完成的系统。网站一般分为三个层次：应用层、服务层和数据层，其具体结构如下图所示：
通过分层，一个庞大系统切分成不同部分，便于分工合作和维护。各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化而不需要其他层必须做出相应的调整。
但是，分层架构也有一些挑战：
（1）必须合理规划层次边界和接口；
（2）禁止跨层次的调用及逆向调用。
分层架构时逻辑上的，在物理部署上，三层结果可以部署在同一个物理机器上，但锁着业务的发展，必然需要多已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，使网站拥有更多的计算资源以应对越来越多的用户访问。
分割是在纵向方面对软件进行切分->将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，有助于软件开发和维护，还便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
大型网站分割的粒度可能会很小。比如在应用层，将不同业务进行分割，例如将购物、论坛、搜索、广告分割成不同的应用，部署在不同的服务器上。
对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，资源也就也多，能够处理的并发访问和数据量就越大。
但分布式在解决网站高并发访问的同时也带来了问题：
（1）分布式意味着服务调用必须通过网络，这可能会对性能造成比较严重的影响；
（2）服务器越多，服务器宕机的概率也就越大，一台服务器宕机造成的服务不可用可能会导致很多应用不可访问，使网站可用性降低；
（3）数据在分布式的环境中保持数据一致性也非常困难，分布式事务难以保证，这对网站业务正确性和业务流程有可能造成很大的影响；
（4）分布式还导致网站依赖错综复杂，开发管理维护困难。
在网站应用中，常用的分布式方案有以下几种：
（1）分布式应用和服务
应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗，还可以使不同应用复用共同的服务，便于业务功能扩展；
（2）分布式静态资源
JS、CSS、LOGO图片等资源独立部署，采用独立域名->动静分离。好处是可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度；由负责用户体验的团队进行开发维护有利于网站分工合作，使不同技术术业有。
（3）分布式数据和存储
传统RDBMS分布式部署和NoSQL产品；
（4）分布式计算
Hadoop及其MapReduce分布式计算框架，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。
还有如下的方案：
（5）分布式配置
支持网站线上服务器配置实时更新；
（6）分布式锁
分布式环境下实现并发和协同；
（7）分布式文件系统
支持云存储。
多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。当某台服务器发生故障，负载均衡设备或者系统的失效转移机制将请求转发到集群中的其他服务器上，提高系统的可用性，即所谓的HA（高可用性）。
所以，在网站应用中，即使是访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小集群。
缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段。在复杂的软件设计中，缓存几乎无处不在。
大型网站架构设计在很多方面都是用了缓存设计：
（1）CDN
内容分发网络，部署在距离终端用户最近的网络服务商，用户的网络请求总是先到达的网络服务商那里，在这里缓存网站的一些静态资源（较少变化的数据），可以就近以最快速度返回给用户，如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN；
（2）反向代理
部署在网站的前端，当用户请求到达网站的数据中心时，最先访问到的就是反向代理服务器，这里缓存网站的静态资源，无需将请求继续转发给应用服务器就能返回给用户；
（3）本地缓存
在应用服务器本地缓存热点数据，应用程序可以在本机内存中直接访问数据，无需访问数据库；
（4）分布式缓存
由于大型网站的数据量十分大，即使只缓存一小部分，需要的内存空间也不是单击能承受的，所以除了本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据；
使用缓存有两个前提条件：
（1）数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；
（2）数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性。
网站应用中，缓存除了可以加快数据访问速度，还可以减轻后端应用和数据存储的负载压力。这一点对网站数据库架构十分重要，网站数据库几乎都是按照有缓存的前提进行负载能力设计的。
计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了分层、分割、分布等，还有一个重要的手段就是异步。
业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。
在单一服务器内部可以通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看做内存队列的分布式部署。
异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化而不互相影响，这对网站扩展新功能非常便利。
除此之外，异步消息队列还有如下的特性：
（1）提高系统可用性
消费者服务器发生故障，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体表现无故障。消费者服务器恢复正常后，继续处理消息队列中的数据。
（2）加快网站响应速度
处在业务处理前段的生产者服务器在处理完业务请求后，将数据写入消息队列，不需要等待消费者服务器处理就可以返回，响应延迟减少。
（3）消除并发访问高峰
用户访问网站是随机的，存在访问高峰和低谷，即使网站按照一般访问高峰进行规划和部署，也依然会出现突发事件，比如购物网站的促销活动，都会造成网站并发访问突然增大，这可能会造成整个网站负载过重，响应延迟，严重时甚至出现服务宕机的情况。使用消息队列将突然增加的访问请求数据加入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力。
特别注意：
使用异步方式处理业务可能会对用户体验、业务流程造成影响，需要网站产品设计方面的支持。
要想保证在服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上。
访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的就是通过冗余实现服务高可用。
数据库除了定期备份存档保存实现冷备份之外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。
在无人值守的情况下，网站可以正常运行，一切都可以自动化是网站的理想状态。目前大型网站的自动化架构设计主要集中在发布运维方面。
（1）发布部署过程自动化
许多网站故障出在发布环节，通过减少人为干预，使发布过程自动化可有效减少故障；
（2）自动化代码管理
代码版本控制、代码分支创建合并等过程自动化，开发只要提交自己参与开发的产品代号，系统就会自动为其创建开发分支，后期会自动进行代码合并；
（3）自动化测试
代码开发完成，提交测试后，系统自动将代码部署到测试环境，启动自动化测试用例进行测试，向相关人员发送测试报告，向系统反馈测试结果；
（4）自动化安全监测
安全检测工具通过对代码进行静态安全扫描及部署到安全测试环境进行安全攻击测试，评估其安全性；
（5）自动化部署
最后将进行自动化部署，将工程代码自动部署到线上生产环境。
此外，网站在运行过程中可能会遇到各种问题：服务器宕机、程序Bug、存储空间不足、突然爆发的访问高峰，为解决这些问题，可以通过如下的措施进行解决：
（1）自动化监控
需要对线上生产环境进行自动化监控，对服务器进行心跳检测，并监控其各项性能指标和应用程序的关键数据指标；
（2）自动化报警
如果发现异常、超出预设的阀值，就会机型自动化报警，向相关人员发送报警信息；
（3）自动化失效转移
在检测到故障发生后，系统会进行自动化失效转移，将失效的服务器从集群中隔离出去，不再处理系统中的应用请求；
（4）自动化失效恢复
待故障消除后，系统将自动化失效恢复，重新启动服务，同步数据保证数据的一致性；
（5）自动化降级
在网站遇到访问高峰，超出网站最大处理能力时，为了保证整个网站的安全可用，还会进行自动化降级，通过拒绝部分请求关闭部分不重要的服务将系统负载降至一个安全的水平；
（6）自动化分配资源
必要时，还需要自动化分配资源，将空闲资源分配给重要的服务，扩大其部署规模。
（1）通过密码和手机校验码进行身份验证；
（2）对登录、交易等操作进行加密；
（3）使用验证码进行识别；
（4）对于常见的XSS攻击、SQL注入、编码转换等进行防范；
（5）对垃圾或敏感信息进行过滤；
（6）对交易转账等操作进行风险控制；
十二、案例分析：新浪微博架构模式
新浪微博的初始架构为：LAMP（Linux+Apache+MySQL+PHP）。应用程序使用PHP开发，所有的数据，包括微博、用户、关系都存储在MySQL数据库中。
随着业务的发展，目前新浪微博的系统架构如下：
分析：
系统分为三个层次：基础服务层、中间层、API和业务层
（1）基础服务层（最下层）
提供数据库、缓存、存储、搜索等数据服务，以及其他一些基础技术服务，这些服务支撑了新浪微博的海量数据和高并发访问，是整个系统的技术基础；
（2）中间层
中间层是平台服务和应用服务层，新浪微博的核心服务是微博、关系和用户，它们是新浪微博业务大厦的支柱。这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成新浪微博的业务基础；
（3）API和业务层（最上层）
各种客户端（包括Web网站）和第三方应用，通过调用API集成到新浪微博的系统总，共同组成一个生态系统。
这些被分层和分割后的业务模块与基础技术模块分布式部署，每个模块都部署在一组独立的服务器集群上，通过远程调用的方式进行依赖访问。
新浪微博在早起使用过一种叫做MPSS（MultiPort Single Server，单服务器多端口）的分布式集群部署方案，在集群中的多台服务器上，每台都部署多个服务，每个服务使用不同的端口对外提供服务，通过这种方式使得有限的服务器可以部署更多的服务实例，改善服务的负载均衡和可用性。
在新浪微博的早起架构中，微博发布使用同步推模式，用户发表微博后系统会立即讲这条微博插入到数据库所有粉丝的订阅列表中，当用户量比较大时，特别是明星用户发布微博时，会引起大量的数据库写操作，超出数据库负载，系统性能急剧下降，用户响应延迟加剧。后来新浪微博改用异步推拉结合的模式，用户发布微博后系统将微博写入消息队列后立即返回，用户影响迅速，消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中，非在线用户登录后再根据关注列表拉取微博订阅里列表。
由于微博频繁刷新，新浪微博使用多级缓存策略，热门微博和明星用户微博缓存在所有的微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群中，对于微博操作中最常见的“刷微博”操作，几乎全部都是缓存访问操作，可以获得很好的系统性能。
好的设计绝对不是模仿，不是生搬硬套某个模式，而是对问题深刻理解之上的创造与创新，即使是“微创新”，也是让人耳目一新的似曾相识。山寨与创新的最大区别不在于是否抄袭，是否模仿，而在于对问题和需求是否真正理解与把握。
本文出自 “Lee” 博客，谢绝转载！
原文地址：http://leexide.blog.51cto.com/6459431/1641753
