每个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作。
模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用。
网站架构有一些共同的模式，通过对这些模式的学习，可以掌握大型网站的一般思路和解决方案，以指导我们的架构设计。
2.1 网站架构模式
目标：实现网站高性能、高可用、易伸缩、可扩展、安全等
2.1.1 分层
横向纬度切分成几个部分，每个部分负责单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
分层架构举例：网络分层协议，计算机组成也是分层架构。
大型网站架构中，将网站软件分为应用层、服务层、数据层。
分层的优势：
1、便于分工合作和开发、维护
2、各层之间具有一定独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。
分层的挑战：
必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次调用(应用层直接调用数据层)及逆向调用。
实践中，各层还可以继续划分：
应用层可以分为视图层和业务逻辑层
服务层可以细分为数据接口层(适配各种输入和输出的数据格式)和逻辑处理层。
在网站很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对。
2.1.2 分割
纵向方面对软件进行切分，根据业务功能不同进行模块化分割。
将不同的功能和服务分割开来，包装成高内聚低耦合地模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
2.1.3 分布式
分布式的好处：
能够处理的并发访问和数据量大，进而能够为更多的用户提供服务。
分布式的挑战：
1、服务调用必须通过网络，可能会对性能造成比较严重的影响
2、服务器越多，宕机概率越大，网站可用性可能降低
3、分布式事务难保证，对网站业务正确性和业务流程有可能造成很大影响
4、可能导致网站依赖错综复杂，开发管理维护困难
在网站应用中，常用的分布式方案有一下几种：
1、分布式应用和服务
将分层和分割后的应用和服务模块分布式部署，除了可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗外；
还可以使不同应用复用共同的服务，便于业务功能扩展。
2、分布式静态资源
静态资源分布式部署可以减轻应用服务器的负载压力；
通过独立域名加快浏览器并发加载的速度；
由负责用户体验的团队进行开发维护有利于网站分工合作，使不同技术工种术业有专攻
3、分布式数据和存储
4、分布式计算
支持网站线上服务器配置实时更新的分布式配置；
分布式环境下实现和并发协同的分布式锁；
支持云存储的分布式文件系统
2.1.4 集群
对用户访问集中的模块，采用集群化部署。
提供更好的并发性
失效转移机制，保障服务高可用
2.1.5 缓存
缓存就是将数据存放在距离计算最近的位置以加快处理速度。
常见的缓存系统：
CDN:内容分发网络，部署在最近的网络服务商，可以将热点数据存放在CDN
反向代理：网站前端架构的一部分，一般缓存了网站的静态资源
本地缓存：应用服务器本地缓存热点数据
分布式缓存：大型网站必用
使用缓存的两个前提条件：
1、数据访问热点不均衡，将频繁访问的数据放在缓存中
2、数据在某个时间段内有效，不会很快过期，否则会产生脏读，影响结果的正确性。
缓存的优势：
1、加快数据访问速度
2、减轻后端应用和数据存储的负载压力
2.1.6 异步
什么是异步？
业务之间的消息传递，分成多个阶段，每个阶段通过数据共享的方式异步执行进行协作。
单一服务器内部，可以通过多线程共享内存队列的方式实现异步
分布式系统中，多个服务器集群通过分布式消息队列实现异步。
异步架构是典型的生产者消费者模式，对网站扩展新功能非常便利(模式匹配订阅模式可以扩展新功能)。
异步消息队列还有如下特性：
1、提高系统可用性
消费者服务器发生故障，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体表现无故障。
消费者服务器恢复后，继续处理消息队列中的数据。
消息队列满了怎么办？如何在线扩容？
2、加快网站响应速度
处在业务处理前端的生产者服务器在处理完业务请求后，将数据写入消息队列，不需要等待消费者服务器处理就可以返回，响应延迟减少。
3、消除并发访问高峰
应对突发流量，使用消息队列将突然增加的访问请求放入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力。
使用异步处理方式，可能会对用户体验、业务流程造成影响，需要网站产品设计方面的支持。
2.1.7 冗余
通过冗余实现高可用，一旦服务器宕机，可以将其上的服务和数据访问转移到其他机器上。
数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。
某些大型网站为了应对自然灾害等不可抗力，还在不同的地域有灾备数据中心。网站数据实时同步到多个数据中心。
2.1.8 自动化
通过减少人为干预，使发布过程自动化可有效减少故障。
自动代码管理：
代码版本空hi、代码分支创建合并等过程自动化，开发工程师只要提交自己参与开发的产品代号，系统就会自动为其创建开发分支，后期会自动进行代码合并
自动化测试：
代码开发完成，提交测试后，系统自动将代码部署到测试环境，启动自动化测试用例进行测试，向相关人员发送测试报告，向系统反馈测试结果
自动化安全检测：
安全检测工具通过对代码进行静态代安全扫描及部署到安全测试环境进行安全攻击测试，评估其安全性
自动化部署：
将工程代码自动部署到线上生产环境。
自动化监控线上环境：
对服务器进行心跳检测，并监控其各项指标和应用程序的关键数据指标。
如果发现异常，超出预设的阈值，就进行自动化报警，向相关人员发送报警信息，警告故障可能会发生。
在检测到故障发生后，系统会进行自动化失效转移，将失效的服务器从集群中隔离出去，不再处理系统中的应用请求。
待故障消除后，系统进行自动化失效恢复，重新启动服务，同步数据保证数据的一致性。
在网站遇到访问高峰，超出网站最大处理能力时，为了保证网站的整体安全可用，还会进行自动化降级，通过拒绝部分请求及关闭部分不重要的服务将系统负载降至一个安全的水平，
必要时，还需要自动化分配资源，将空闲资源分配给重要的服务，扩大其部署规模。
2.1.9 安全
通过密码和手机验证码进行身份认证；
登录、交易等操作需要对网络通信进行加密，
网站服务器上存储的敏感数据如用户信息等进行加密处理；
为了防止机器人程序滥用网络资源攻击网站，使用验证码进行身份识别；
对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等相应处理；
对于垃圾信息、敏感信息进行过滤；
对交易转账等重要操作根据交易模式和交易信息进行风险控制。
2.2 架构模式在新浪微博的应用
系统架构分为三个层次
最下层是基础服务层，提供数据库、缓存、存储、搜索等数据服务，以及其他一些基础技术服务，这些服务支撑了新浪微博海量数据和高并发访问，是整个系统的技术基础。
中间层是平台服务和应用服务层，新浪微博的核心是微博、关系和用户，它们是新浪微博业务大厦的支柱。
这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成新浪微博的业务基础。
最上层是API和新浪微博的业务层，各种客户端和三方应用，通过调用API集成到新浪微博的系统中，共同构成一个生态系统。
分布式
分层分割后，业务模块和基础技术模块分布式部署，每个模块都部署在一组独立的服务器集群上，通过远程调用的方式进行依赖访问。
虚拟机上部署
微博发布
后来改用异步推拉结合的模式，用户发微博后系统将微博写入消息队列后立即返回，用户相应迅速，消息队列消费者任务将微博推送给所有当前在线性粉丝的订阅列表中，非在线用户登录后再根据关注列表拉取微博订阅列表。
多级缓存
由于微博频繁刷新，使用多级缓存策略，热门微博和明星用户的微博缓存在所有的微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群中，对于微博操作中最常见的"刷微博"操作，几乎全部在缓存访问操作，可以获得很好的系统性能。
多数据中心
为了提高系统的整体可用性和性能，新浪微博启用了多个数据中心。加快访问速度，减少后台服务压力，改善系统性能
同时也是数据冗余复制的灾备中心，所有的用户和微博通过远程消息系统在不同的数据中心之间同步，提高系统可用性。
自动化
自动化监控、自动化发布、自动化故障修复，这些自动化工具还在持续开发中，以改善运维水平提高系统可用性。
安全
使用一些常见的安全策略，
在开放平台上使用多级安全审核的策略以保护系统和用户。
2.3 小结
正确使用模式可以更好地利用业界和前人的思想和实践，用更少的时间开发出更好的系统，使设计者的水平也达到更高的境界。
但是模式受其场景限制，对系统的要求和约束也很多，不恰当的使用模式只会画虎不成反类犬，不但没有解决原来的老问题，反而带来了更棘手的新问题。
好的设计绝对不是模仿，不是生搬硬套某个模式，而是对问题深刻理解之上的创造与创新，即使是“微创新”，也是让人耳目一新的似曾相识。山寨与创新的最大区别不在于是否抄袭，是否模仿，而在于对问题和需求是否真正理解与把握。