内容梳理
模式定义：每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次的使用该方案而不必做重复的工作。
2.1 网站架构模式
解决大型网站高并发访问、海量数据处理、高可靠运行的问题，为实现大型网站高性能、高可用、易伸缩、可扩展、安全等目标提出的解决方案。
2.1.1 分层
将系统在横向维度上切分成几个部分，每个部分负责单一职责，通过上层对下层的依赖和调用组成完整系统。
各层之间独立，只要维持调用接口不变，各层根据具体问题独立演化发展而不影响其他层。开发时要严格遵循分层架构约束，禁止跨层调用和逆向调用。分层架构师逻辑上的，大的分层内部还可以继续分层。
2.1.2 分割
在纵向维度上对软件进行切分。 将不同的功能和服务进行分割，包装成高内聚低耦合的模块单元，便于开发、维护和部署，提高网站的并发处理能力和功能扩展能力。
不同模块在逻辑上还是物理部署上都可以是独立的，通过远程调用协作工作。
2.1.3 分布式
使用更多的计算机完成同样的功能，解决高并发问题。随着CPU、内存、存储资源的增多，处理的并发访问和数据量就越大。
分布式带来的其他问题：（1）通过网络调用服务，影响系统性能；（2）服务器个数增多，宕机概率增大，降低系统可用性；（3）难以保持数据一致性和分布式事务；（4）网站依赖错综复杂，开发管理维护困难。
常用的分布式方案：（1）分布式应用和服务：将各个模块分布式部署，提高网站性能和并发性、加快开发和发布速度、减少数据库连接等资源消耗，还能使不同应用复用共同的服务，便于业务功能扩展。
（2）分布式静态资源：动静分离，将JS/CSS等网站的静态资源独立分布式部署，采用独立域名访问。减轻应用服务器负载压力、加快浏览器并发加载速度、利于网站分工合作。
（3）分布式数据和存储：单机无法处理以P为单位的海量数据。将数据进行分布式存储，NoSQL应运而生。
（4）分布式计算：处理规模庞大的计算业务，移动计算，将计算程序分发到数据所在位置以加速计算和分布式计算。
（5）此外，还有支持服务器配置实时更新的分布式配置、实现并发和协同的分布式锁、支持云存储的分布式文件系统等。
2.1.4 集群
多台服务器上部署相同应用程序，通过负载均衡设备共同对外提供服务，有良好并发特性，提高系统可用性。
2.1.5 缓存
将数据存放在距离计算最近的位置来加快处理速度，是改善软降性能的第一手段。
CDN：部署在离用户最近的网络运营商。
反向代理：部署在网站前端，请求到达网站的数据中心时，最先访问反向代理服务器（缓存网站的静态资源）。
本地缓存：应用服务器本地缓存。
分布式缓存：将数据缓存在一个专门的分布式缓存集群中。
使用缓存前提条件：（1）数据访问不均衡；（2）数据在某时间段内有效
2.1.6 异步
将一个业务操作分成多阶段，每个阶段通过共享数据进行协作。单服务器内部通过多线程共享内存队列实现异步，分布式系统中通过分布式消息队列实现。
异步架构是典型的生产者-消费者模型，异步消息队列特征：（1）提高系统可用性；（2）网站响应速度；（3）消除并发访问高峰。
异步方式处理业务可能会对用户体验和业务流程造成影响。
2.1.7 冗余
服务器规模较大时，发生宕机是必然事件，通过冗余实现服务高可用。
方式：热备份、冷备份、灾备数据中心
2.1.8 自动化
减少人为干预，使发布过程自动化可有效减少故障。包括自动化代码管理、自动化测试、自动化安全监测、自动化部署。
对线上生产环境进行自动化监控，包括自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化资源分配。
2.1.9 安全
使用密码和手机校验码进行身份验证、对网络通信进行加密、验证码识别、编码转换、过滤、风险控制等手段。
2.2 架构模式在新浪微博中的应用
新浪微博已经发展成集社交、媒体、游戏、电商等多位一体的生态系统。
系统分为三个层次：
（1）最下层的基础服务层：提供数据库、缓存、存储、搜索等基础数据服务，是技术基础。
（2）中间层是平台服务和应用服务层：核心服务是微博、关系和用户，通过依赖调用和共享基础数据构成新浪微博的业务基础。
（3）最上层是API和业务层：客户端和第三方应用调用API。
新浪微博早期架构中，微博发布使用同步推模式，用户发表微博后系统将微博插入数据库所有粉丝订阅列表中，大量数据库写操作，降低系统性能。后来改为异步推拉结合模式，用户发表微博后系统将微博加入消息队列后立即返回，提高响应速度。消息队列消费者将微博推送给在线粉丝，非在线用户登录后根据关注列表拉取微博订阅列表。
“刷微博”使用多级缓存机制，通过使用数据冗余复制、开发自动化工具提高系统可用性。
本章结构
