1.2 大型网站架构演化发展历程
1.2.6 使用反向代理和CDN加速网站响应
要解决的问题是地域性网络不畅
CDN和反向代理的基本原理都是缓存，
CDN部署在网络提供商的网络机房，用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据
反向代理则部署在网站的中心机房，用户请求网站服务时，首先访问的时反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。
使用CDN和反向代理服务器的目的都是尽快返回数据给用户：
1、加快用户访问速度
2、减轻后端服务器负载压力
1.2.7 使用分布式文件系统和分布式数据库系统
分布式数据只有在单表数据规模非常庞大的时候才使用，不到不得已时，网站更常用的数据库拆分手段时业务分库，将不同业务的数据库部署在不同的物理服务器上。
1.2.8 使用NoSQL和搜索引擎
选型时选择伸缩性好的分布式的NoSQL和搜索引擎服务器。
另外应用服务器通过一个统一的数据访问模块访问各种数据库，减轻应用程序管理诸多数据源的麻烦。
1.2.9 业务拆分
通过分而治之的手段将整个网站业务分成不同的产品线，如淘宝网将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。
应用根据业务拆分，并部署在不同的服务器上，通过消息队列分发数据。或者通过访问同一个数据存储系统构成一个关联的完整系统。
业务服务器时无状态的，不存储调用上下文数据，一个事务经过多个应用服务器完成，比如订单系统和库存系统，下单成功就是将下单的数据成功的放到消息队列，消息队列要保证可伸缩、高可用、高性能，库存系统在Redis服务器上减库存，库存系统订阅某种商品的下单topic，一旦有下单就会接收到，开始减库存逻辑，如果库存系统接收到消息后挂了，不确认消息，消息依然保留在消息队列，如果消息队列正常处理了消息，就手动确认这条消息消费了。
1.2.10 分布式服务
一些公共的业务模块，调用次数非常多，可以单独抽去出一个模块，独立部署。
业务系统只负责业务自身的逻辑，需要调用公用服务的数据，就去调用公用业务服务完成。
既然大型网站架构解决了海量数据的管理和高并发事务的处理，那么就可以把这些解决方案应用到网站自身以外的业务上去。
目前很多大型网站都开始建设自己的云计算平台，将计算作为一种基础资源出售，中小网站不需要再关心技术架构问题，只需按需付费，就可以使网站随着业务的增长逐渐获得更大的存储空间和更多的计算资源。
1.3 大型网站架构演化的价值观
1.3.1 大型网站架构技术的核心价值使随网站所需灵活应对
1.3.2 驱动大型网站技术发展的主要力量使网站的业务发展
业务成就了技术，事业成就了人，架构师应该努力提高技术回馈业务，才能在快速发展的互联网领域持续进步。
1.4 网站架构设计误区
1.4.1 一味追随大公司的解决方案
大公司的经验和成功模式固然重要，值得学习借鉴，但是盲从，失去坚持自我的勇气，在架构演化的道路上迟早会迷路。
1.4.2 为了技术而技术
应该根据自身实际业务发展进行技术选型，一味追求新技术，也会走向歧途。
1.4.3 企图用技术解决所有问题
技术使用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。
1.5 小结
现在经历这种架构演化的机会越来越少，但是网站架构师应该对这个过程深刻了解，理解已成熟的网站架构技术方案的来龙去脉和历史渊源，在技术选型和架构决策时才能有的放矢，直击要害。