拜读《大型网站技术架》后，发现架构师一职所需要承担的职责不仅仅是那么简单，他肩负着一个网站的高可用、高并发等稳定职责。也让我受益匪浅，了解许多行内知识。
大型网站系统特点
- 高并发、大流量
- 高可用
- 海量数据
- 用户分布广泛，网络情况复杂
- 安全环境恶劣
- 需求快速变更、发布频繁
- 渐进式发展
大型网站架构演化及发展历程
初期网站
最终架构的大型网站
演化过程
- 应用服务器和数据服务器分离：应用有单独的应用服务器，数据有单独的数据服务器，文件有单独的文件服务器
- 添加缓存：增加本地缓存及分布式缓存，使得数据库查询的部分查询可以使用缓存查询
- 使用服务器集群：将单一服务器处理变成服务器集群处理，提升处理能力
- 数据库读写分离：主从数据库分别负责写、读功能，主数据库写入数据，主数据库服务器将数据写入从数据库
- 使用反向代理和CDN加速：CDN和反向代理的基本原理都是缓存，CDN可以使最近的机房提供给最近的用户，反向代理服务器若缓存过先前从中心机房给用户的数据，则将数据返回给用户
- 使用分布式文件管理系统及分布式数据库系统：分布式数据库及分布式文件是拆分网站最后不得已的手段，将不同业务存放在不同物理机上
- 使用NoSQL和搜索引擎：NoSQL和搜索引擎都是源自于互联网技术的手段，对于可伸缩的分布式特性有更好的支持
- 业务拆分：将不同业务分在不同产品线，每个应用独立部署
- 分布式服务：将不同服务的相同业务提取出来，将可复用的业务提供业务数据库连接及提供业务服务
网站架构误区
- 一味追求大公司解决方案：应针对自身业务提供解决方案，而非一味追求大公司解决方案
- 为了技术而技术：网站技术是为业务而存在的，除此之外毫无意义
- 企图用技术解决所有问题：技术是用来解决业务问题的，而业务问题也可以通过业务解决。例如12306，分时间抢票比同时间抢票更加技术上更容易实现，且系统更加稳定
大型网站架构模式
分层
大型网站中架构也分层，将网站软件系统氛围应用层、服务层、数据层。
分层架构的目的：规划软件清晰的逻辑结构便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向发展至关重要。因此应该在网站很小的时候采用分层架构
分层架构带来的挑战：必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）
分割
如果说分层是对软件的横向切割，那么分割是纵向切割
网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
大型网站分割的粒度可能会很小。比如在应用层，将不同业务进行分割，例如将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责，部署在不同的服务器上；在同一个应用内部，如果规模庞大业务复杂，会继续进行分割，比如购物业务，可以进一步分割成机票酒店业务、3C业务等
分布式
- 分布式应用和服务： 可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗外；还可以使不同应用复用共同的服务，便于业务功能扩展
- 分布式静态资源：网站的静态资源例如js、css、image等静态资源可以独立分布部署，并采用独立资源。可以减轻应用服务器压力
- 分布式数据及存储：单台机器无法提供海量存储
- 分布式计算：目前网站大部分使用Hadoop及其MapReduce分布式计算框架使用处理计算。
- 分布式配置，分布式锁，分布式文件等
集群
多台服务器可成一个集群，通过负载均衡对外提供服务，通过负载均衡新增或更替机器
缓存
缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段
- CDN：可以缓存一些较少变化数据，如视频文件等，可以就近迅速返还给用户
- 反向代理：当用户请求到达中心时，最先访问反向代理服务器，这里缓存的是静态资源，无需转应用服务器就可返回给用户
- 本地缓存：缓存着热点数据，无需访问数据库直接可以取到，相比缓存服务器更迅速
- 分布式缓存：网站数据十分庞大时，本地缓存无法解决问题。
使用缓存有两个前提条件，一是数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；二是数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性
异步
- 提高系统可用性：消费者服务器发生故障，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体表现无故障
- 加快网站响应速度：处理完业务数据请求后，不需要等待消费者服务器处理就可以返回，直接写入消息队列，响应延迟减少
- 消除并发高峰：将请求放入消息队列中依次处理，就不对对整个网站负载造成过大压力
冗余
网站应该实现数据的冷备份外，还有热备份。即定时保存和实时保存数据，以及灾备数据中心。避免由于单个服务器损坏后数据损坏。
自动化
网站发布应该具备以下环节
- 发布自动化
- 代码管理：版本控制
- 自动化测试：自动检测并发送检测报告
- 自动化安全检测：对代码进行静态安全扫描部署及攻击测试
- 自动化部署：自动部署到生产环境
- 自动化监控：监控服务器宕机，程序bug，存储空间不足，突然访问高峰
- 自动化报警：超出阈值发送邮件报警
- 自动化失效转移：将失效的服务器从集群隔离
- 自动化失效恢复：重新启动服务
- 自动化降级：访问高峰则关闭次要服务
- 自动化分配资源：将空闲资源合理分配给重要任务
安全
- 密码和手机校验
- 通信加密
- 验证码识别
- 敏感词汇过滤
- 风险信息控制
架构要素
通俗说法：最高层次的规划，难以改变的决定
一般说来，除了当前的系统功能需求外，软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素
- 性能：衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等
- 可用性：大型网站至少到99.99%，衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用
- 伸缩性：衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制
- 扩展性：衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品
- 安全性：衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略
网站的高性能架构
不同视角下的性能
- 用户视角的网站性能：从用户角度，网站性能就是用户在浏览器上直观感受到的网站响应速度快还是慢。用户感受到的时间，包括用户计算机和网站服务器通信的时间、网站服务器处理的时间、用户计算机浏览器构造请求解析响应数据的时间
- 开发人员角度的网站性能：是应用程序本身及其相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标。主要的优化手段有使用缓存加速数据读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善程序性能
- 运维角度的网站性能：关注基础设施性能和资源利用率，如网络运营商的带宽能力、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。主要优化手段有建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等
性能优化策略
- 性能分析：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是CPU，是代码问题还是架构设计不合理
- 性能优化：根据分层架构可分为web前端优化、应用服务器性能优化、存储服务器性能优化
前端优化策略
- 减少http请求
- 使用浏览器缓存
- 启动压缩
- css放在最上面，js放在页面最下面
- 减少cookie传输
CDN加速
CDN能够缓存的一般是静态资源，如图片、文件、CSS、Script脚本、静态网页等，但是这些文件访问频度很高，将其缓存在CDN可极大改善网页的打开速度
反向代理
传统代理服务器位于浏览器一侧，代理浏览器将HTTP请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求
缓存
- 基本原理： K-V形式存储
- 合理使用缓存：数据读写比2:1以上使用缓存才有意义
- 数据不一致与脏读：需要设置缓存时间，在缓存时间内可接受脏读
- 缓存可用性：数据库在面临缓存失效时容易出现访问过大导致宕机
- 缓存预热：提前加载缓存保证缓存可用
- 缓存穿透：将value为null的情况也加载在缓存中
代码优化
- 多线程：使用多线程处理IO与多cpu一般算法：多线程数=[任务执行时间/(任务执行时间-IO等待时间)]* cpu内核数量
- 将对象设计成无状态：在多并发时对象不会因多线程导致状态改变
- 使用局部对象：在方法内创建对象
- 并发访问使用锁：锁将并发操作转化为顺序操作
- 资源复用：使用单例模式和对象池
- 数据结构：使用数据结构+算法的形式优化代码可以极大的优化性能
- 垃圾回收：垃圾回收机制有利于性能提升
网站高可用架构
网站高可用性度量
网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度可用性指标=（1-网站不可用时间/年度总时间）×100%
对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。
网站可用性考核
故障分=故障时间（分钟）× 故障权重
高可用的服务
- 服务器分级：将服务器分不同级别，核心应用和服务优先使用更好的服务器
- 超时设置：由于宕机或死锁等其他情况，超时后可设置调度到其他服务器
- 异步调用：异步调用减少服务器压力
- 服务降级：高峰期使用服务器降级，拒绝服务（拒绝部分请求）或关闭服务（关闭非核心服务）
- 幂等性设计：服务层必须保证多次调用和一次调用结果一致
数据可用性
- 数据持久性： 多个副本，在某个存储出错后数据不会丢失
- 数据可访问性：切换数据源时用户无感知
- 数据一致性：不同副本保证数据一致
网站运行监控
不允许没有监控的系统上线
- 用户行为日志收集
- 服务器端日志收集
- 客户端浏览器日志收集
- 服务器性能监控
- 运行数据报告
