什么是模式？
每个模式描述了一个不断重复发生的问题及该问题的解决方案的核心，这样就能多次使用该方案而不必做重复工作。模式的关键在于可重复性。
一、网站架构模式
1.分层
常见架构模式之一，将系统横向维度上切分为几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整系统。
通过分层，可以更好地将一个庞大的软件系统切分为不同部分。便于分工合作和维护；各层之间有一定独立性，只要调用接口不变，各层可以独立演化发展。
需要合理规划层次边界和接口，开发中严格遵循分层架构约束，禁止跨层次调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或服务层调用应用层）。
实践中，大的分层结构内部还可以继续分层，如应用层可以再细分为视图层和业务逻辑层；服务层也细分为数据接口层（适配各种输入和输出的数据格式）和逻辑处理层。
在物理部署上，参考第一章。
分层架构模式最初目的是规划软件清楚的逻辑结构便于开发维护，但分层结构对网站支持高并发向分布式方向发展至关重要。因此在网站规模很小时就应该采用分层架构。
2.分割
分割是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理种类也越多，将这些不同功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件开发和维护：另一方面。便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
4.分布式
对于大型网站，分层和分割一个主要目的是为了切分后的模块便于分布式部署，通过远程调用协同工作。分布式意味着可以使用更多计算机，计算机越多，CPU、内存、存储资源就越多，能处理的并发访问和数据量就越大，进而能提供更好服务。
但是，分布式意味着服务调用必须通过网络，这可能对性能造成影响；服务器越多，服务器宕机的概率就越大，一台服务器宕机造成服务不可用可能会导致很多应用不可访问，可用性降低。
另外，数据在分布式的环境中保持数据一致性也困难，分布式事务难以保证，对业务正确性和流程可能造成影响；分布式还导致网站依赖复杂，维护困难。
常用的分布式方案：
分布式应用和服务
分布式静态资源：网站的静态资源如JS、CSS、Logo等资源独立分布式部署，采用独立域名，即动静分离。这样可以减轻应用服务器负载压力；通过使用独立域名加快浏览器并发加载速度。
分布式数据和存储
分布式计算：目前网站普遍使用Hadoop及其MapReduce分布式计算框架进行批处理计算，特点是移动计算，将程序分发到数据所在位置以加速计算和分布式计算。
此外，还有分布式配置，分布式锁，分布式文件系统等。
4.集群
对于用户访问集中的模块（如网站首页），还需要将独立部署的服务器集群化，及多台服务器部署相同应用构成一个集群，通过负载均衡设备对外提供服务。
因为服务器集群有更多服务器提供相同服务，因此可以提供更好的并发特性。同时，某台服务器故障时，负载均衡设备或系统的失效转移机制将请求转发到集群的其他服务器，使得可用性提高。所以，即使访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小集群。
5.缓存
缓存就是将数据放在离计算最近的位置以加快处理速度。
CDN：即内容分发网络，部署在距离终端用户最近的网络服务提供商，网络请求总是先到达其网络服务商，在此缓存网站的一些静态资源（较少变化的数据），可以快速的返回给用户，如视频网站和门户网站将用户大量访问的热点内容存在CDN。
反向代理：属于前端架构一部分，当应用请求到达网站数据中心时，最先访问的是反向代理服务器，这里缓存静态资源，无需将请求继续转发就能返回给用户。
本地缓存：在应用服务器本地缓存着热点数据，无需访问数据库。
分布式缓存：将数据缓存到一个专门的分布式缓存集群中。
使用缓存有两个前提条件，一是数据访问热点不均衡，热点数据放在缓存中；而是数据在某个时间段内有效，不会很快过期，否则会因为缓存数据失效而产生脏读，影响正确性。
6.异步
系统解耦手段除了前面提到的分层、分割、分布等，还有异步，业务之间消息传递不是同步调用，而是将业务操作分为多个阶段，每个阶段之间通过共享数据方式异步执行进行协作。
在单一服务器内部可通过多线程共享内存队列方式实现异步，处在业务操作前面的线程将输出写入队列，后面的线程从队列中读取数据进行处理。
在分布式系统中，多个服务器集群通过分布式消息队列实现异步。
异步架构是典型的生产者消费者模式，两种不存在直接调用。使用异步消息队列特性：
通过系统可用性：消费者服务器发生故障，数据会在消息队列服务器中存储，生产者服务器可以继续业务请求，系统整体表现无故障。
加快网站响应速度：生产者服务器将数据写入消息队列，不需要等待消费者服务器返回。
消除并发访问高峰
7.冗余
数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上。
访问和负载很小的访问也必须部署至少两台服务器构成集群，目的是通过冗余实现服务高可用。
数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。
8.自动化
无人值守时网站可以正常运行，一切都可以自动化是网站理想状态。目前大型网站的自动化架构设计主要集中在发布和运维方面。
通过减少人为干预，使发布过程自动化可有效减少故障。发布过程包括许多环节。
自动化代码管理，代码版本控制、代码分支创建合并等过程自动化；
自动化测试，提交测试后，系统自动将代码部署到测试环节，启动自动化测试用例进行测试，向相关人员发生测试报告，向系统反馈测试结果；
自动化安全测试，安全检查工具通过对代码进行静态安全扫描及部署到安全测试环境进行安全攻击测试，评估安全性；
自动化部署，将工程自动部署到线上生产环境。
网站运行过程中可能会遇到各种问题：宕机、Bug、存储空间不足、访问高峰。网站需要对线上环境进行自动化监控，对服务器进行心跳检测，并监控其各项性能指标和应用程序的关键数据指标。
若发现异常、超出预设阈值，进行自动化报警。在检测到故障发生后，进行自动化失效转移，将失效服务器从集群隔离出去。故障消除后，系统自动化失效恢复，重启服务，同步数据保证数据一致性。在访问高峰，超出网站最大处理能力时，会自动化降级，通过拒绝部分请求及关闭部分不重要服务将系统负载降至一个安全水平，必要时自动化分配资源，将空闲资源分配给重要服务。
9.安全
1.通过密码和手机校验码进行身份认证；
2.登录、交易等操作需对网络通信进行加密，服务器存储的敏感数据也进行加密；
3.使用验证码防止机器人程序攻击网站；
4.对于常见的XSS攻击、SQL注入、进行编码转换等相应处理；
5.对于垃圾信息、敏感信息进行过滤；
6.对交易转账等操作根据交易模式和信息进行风险控制。
二、架构模式在新浪微博应用
从开始的LAMP架构到现在的架构：
系统分三个层次，最下层是基础服务层，这些服务支撑其海量数据和高并发访问。
中间层是平台服务和应用服务层，这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成新浪微博业务基础。
最上层是API和业务层，包括客户端和第三方应用，通过调用API集成到系统。
这些被分层和分割的业务模块与基础技术模块分布式部署，每个模块都被部署到一组独立服务器集群，通过远程调用方式进行依赖访问。早期还使用过一种叫MPSS（MultiPort Single Server，单服务器多端口）的分布式集群部署方案。
早期架构中，微博发布使用同步推模式，当用户量特别大时，会引起大量数据库写操作，超出数据库负载，系统性能下降，用户延迟加剧。
后改用异步推拉结合模式，用户发表微博后系统将微博写入消息队列后立即返回，消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中，非在线用户登录后再根据关注列表拉取微博订阅列表。
由于微博刷新频繁，新浪微博使用多级缓存策略，热门微博和明星用户的微博缓存在所有微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群中，对于微博操作中最常见的“刷微博”操作，几乎都是缓存访问操作。
为了提高系统的可用性和性能，启用了多个数据中心。这些数据中心既是地区用户访问中心，也是数据冗余复制的容灾设备。
新浪微博还开发了一系列自动化工具，包括自动化监控，自动化发布，自动化故障修复等。