《大型网站技术架构.核心原理与案例分析》
一.概述
1.大型网站架构演化
1.1 大型网站软件系统的特点
高并发，大流量；高可用；海量数据；用户分布广泛，网络情况复杂；安全环境恶劣；需求快速变更，发布频繁；渐进式发展
1.2 大型网站架构师演化发展历程
1.2.1 初始阶段的网站架构：应用程序、数据库和文件等一体在一台服务器上
1.2.2 应用服务和数据服务分离：应用、数据、文件等分开部署
1.2.3 使用缓存改善网站性能：添加缓存程序，减轻数据库压力
1.2.4 使用应用服务器集群改善网站的并发处理能力：应用程序集群化
1.2.5 数据库读写分离：数据库主从模式
1.2.6 使用反向代理和CDN加速网站响应
1.2.7 使用分布式文件系统和分布式数据库系统
1.2.8 使用NoSQL和搜索引擎
1.2.9 业务拆分
1.2.10 分布式服务
1.3 大型网站架构演化的价值观
1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对
1.3.2 驱动大型网站技术发展的主要力量是网站的业务发展
1.4 网站架构设计误区
1.4.1 一味追求大公司的解决方案
1.4.2 为了技术而技术
1.4.3 企图用技术解决所有问题
2.大型网站架构模式
2.1 网站架构模式
2.1.1 分层：从业务、网络、逻辑、物理等方面横向切分，简化系统复杂性。
2.1.2 分割：从同一层级纵向切分细化。
2.1.3 分布式：将不同模块部署在不同的服务器上，通过远程调用协同工作，从而获取到更多的计算资源(比如：CPU,内存,磁盘等)。
分布式应用和服务：将分层和分割后的应用和服务模块分布式部署。
分布式静态资源：将静态资源(如：js,css,图片等)独立分布式部署。
分布式数据和存储：采用NoSQL等分布式存储方式处理海量数据。
分布式计算：将大规模计算使用分布式计算框架进行批处理计算，其特点是移动计算而不是移动数据。
2.1.4 集群：将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
2.1.5 缓存：将数据存放在距离计算最近的位置以加快处理速度。
CDN：即内容分发网络，部署在距离终端用户最近的网络服务商。
反向代理：反向代理属于网站前端架构的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问到的就是反向代理服务器。
本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库。
分布式缓存：将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。
使用缓存的两个前提：一是数据访问热点不均衡；二是数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读。
2.1.6 异步：是各步通过共享数据的方式实现异步执行协作，典型的例子是生产者消费者模式。
特点：提供系统可用性，加快网站响应速度，消除并发访问高峰。
2.1.7 冗余：一定程度的服务器冗余运行，数据冗余备份。服务器至少两台构成一个集群，数据库定期冷备份，实时同步热备份，建立灾备数据中心。
2.1.8 自动化
发布过程自动化：自动化代码管理，自动化测试，自动化安全检测，自动化部署，自动化监控，自动化报警，自动化失效转移，自动化失效恢复，自动化降级，自动化分配资源。
2.1.9 安全：密码验证，手机校验码，加密通信，验证码，敏感信息过滤，风险控制。
2.2 架构模式在新浪微博的应用
3.大型网站核心架构要素
3.1 性能：优化手段有，缓存、CDN、前端优化、后端优化、代码层优化、数据库优化、集群化、分布式等。
3.2 可用性：7*24可用，主要手段是冗余。
3.3 伸缩性：主要标准是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器，新加的服务器是否可以提供和原来服务器无差别的服务，集群中可容纳的总服务器数量是否有限制。
3.4 扩展性：主要标准是是否可以透明无影响添加新业务产品，不同产品之间是否很少耦合。主要手段有事件驱动架构和分布式服务。
3.5 安全性：是针对现存和潜在的各种攻击与窃取手段，是否有可靠的对应策略。
二.架构
4.瞬时响应：网站的高性能架构
4.1 网站性能测试
4.1.1 不同视角下的网站性能
1.用户视角的网站性能：是用户在浏览器上直观感受到的网站响应速度。可以采用前端优化手段改善，页面、异步加载、缓存、CDN、反向代理等。
2.开发人员视角的网站性能：主要是应用程序本身及其相关子系统的性能。可以采用缓存、异步、集群、代码优化等。
3.运维人员视角的网站性能：主要是基础设施性能和资源利用率。可以采用优化骨干网、使用定制服务器、利用虚拟化技术优化资源利用等。
4.1.2 性能测试指标
1.响应时间：指应用执行一个操作需要的时间。
2.并发数：指系统能够同时处理请求的数目，这个指标也反应了系统的负载。
3.吞吐量：指单位时间内系统处理的请求数量，体现系统的整体处理能力。
4.性能计数器：指服务器或者操作系统性能的一些数据指标，包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。
4.1.3 性能测试方法：性能测试、负载测试、压力测试、稳定性测试。
性能测试：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。
负载测试：对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值。
压力测试：超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。
稳定性测试：在特定硬件、软件、网络环境下，给测试系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。
4.1.4 性能测试报告：反应系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息。
4.1.5 性能优化策略
1.性能分析：排查性能瓶颈，定位问题。主要因素是内存、磁盘、网络、CPU还是代码问题、架构设计不合理、系统资源不足。
2.性能优化：分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化3大类。
4.2 Web前端性能优化：指网站业务逻辑之前的部分。
4.2.1 浏览器访问优化：1.减少http请求；2.使用浏览器缓存；3.启用压缩；4.CSS放在页面最上面，JavaScript放在页面最下面；5.减少Cookie传输
4.2.2 CDN(Content Distribute Network 内容分发网络)加速：本质是缓存一些静态资源在网络运营商机房。
4.2.3 反向代理：具有保护网站安全、缓存资源、负载均衡的功能。
4.3 应用服务器性能优化：指处理网站业务的服务器，优化手段主要有缓存、集群、异步等。
4.3.1 分布式缓存：网站性能优化第一定律：优先考虑使用缓存优化性能
1.缓存的基本原理：指将数据存储在相对较高访问速度的介质中，以供系统处理。一是减少数据访问时间，二是缓存的数据是经过计算处理，减少计算时间。缓存主要用来存放那些读写比很高、很少变化的数据。
2.合理使用缓存：使用缓存应避免频繁修改的数据、没有热点的访问、数据不一致与脏读、缓存可用性、缓存预热、缓存穿透。
3.分布式缓存架构：指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务。
4.Mencached特点：简单的通信协议、丰富的客户端程序、高性能的网络通信、高效的内存管理、互不通信的服务器集群架构。
4.3.2 异步操作：使用消息队列将调用异步化，可改善网站的扩展性。任何可以晚点做的事情都应该晚点再做。
4.3.3 使用集群：使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，将并发访问请求分发到多台服务器上处理。
4.3.4 代码优化
1.多线程：解决线程安全的主要手段有：将对象设计为无状态对象、使用局部对象、并发访问资源时使用锁。
2.资源复用：尽量减少开销很大的系统资源的创建和销毁(比如：数据库连接，网络通信连接，线程，复杂对象等)。主要手段有单例和对象池。
3.数据结构：在不同场景中合理使用恰当的数据结构，灵活组合各种数据结构改善数据读写和计算特性可极大优化程序的性能。
4.垃圾回收：理解垃圾回收机制有助于程序优化和参数调优，以及编写内存安全的代码。JVM内存主要分为堆(heap)和堆栈(stack)。堆栈用于存储线程上下文信息，如方法参数、局部变量等。堆则是存储对象的内存空间，对象的创建和释放、垃圾回收就在这里进行。
4.4 存储性能优化
4.4.1 机械硬盘 vs. 固态硬盘
4.4.2 B+树 vs. LSM树
B+树是一种专门针对磁盘存储而优化的N叉排序树，以树节点为单位存储在磁盘中，从根开始查找所需数据所在的节点编号和磁盘位置，将其加载到内存中然后继续查找，直到找到所需的数据。
LSM树可以看作是一个N阶合并树。许多NoSQL产品采用LSM树作为主要数据结构。
4.4.3 RAID vs.HDFS
RAID(廉价磁盘冗余阵列)技术主要是为了改善磁盘的访问延迟，增强磁盘的可用性和容错能力。
RAID0 数据在从内存缓存区写入磁盘时，根据磁盘数量将数据分成N份，将数据同时并发写入N块磁盘，使得数据整体写入速度是一块磁盘的N倍。读取也是一样。但是未做备份。
RAID1 在写入磁盘时，将一份数据同时写入两块磁盘，提高了可靠性。
RAID10 将所有磁盘平均分成两份，数据同时在两份磁盘写入，结合RAID0和RAID1两种方案。
RAID3 在数据写入磁盘时，将数据分成N-1块，并发写入N-1块磁盘，并在第N块磁盘记录校验数据，任何一块磁盘损坏，都可以利用其它N-1块磁盘的数据修复。
RAID5 在数据写入磁盘时，将数据分成N-1块，并发写入N-1块磁盘，并将检验数据螺旋式的写入所有磁盘中，防止校验磁盘频繁写入。
RAID6 与RAID5类似，但是数据只写入N-2块磁盘，并螺旋式地在两块磁盘中写入校验信息。
HDFS 以块(Block)为单位管理文件内容，一个文件被分割成若干个Block，每写完一个Block，HDFS就将其自动复制到另外两台机器上，保证Block有三个副本。
5.万无一失：网站的高可用架构
5.1 网站可用性的度量与考核
5.1.1 网站可用性度量 网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点
网站年度可用性指标=(1-网站不可用时间)*100%
5.1.2 网站可用性考核 故障分=故障时间(分钟)*故障权重
5.2 高可用的网站架构：主要目的是保证服务器硬件故障时服务依然可用、数据依然保存并能狗被访问。主要手段是数据和服务的冗余备份及失效转移。
5.3 高可用的应用：应用层主要处理网站应用的业务逻辑，具有无状态性。
5.3.1 通过负载均衡进行无状态服务的失效转移
5.3.2 应用服务器集群的Session管理：1.Session复制；2.Session绑定；3.利用Cookie记录Session；4.Session服务器
5.4 高可用的服务：1.分级管理；2.超时设置；3.异步调用；4.服务降级；5.幂等性设计
5.5 高可用的数据：主要手段是数据备份和失效转移机制。数据备份是保证数据有多个副本。
高可用的数据具备：数据持久性、数据可访问性、数据一致性、
5.5.1 CAP原理：一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availibility)、分区耐受性(PartitionTolerance)这个三个条件。
数据一致性又分：数据强一致、数据用户一致、数据最终一致。
5.5.2 数据备份
冷备份：优点是简单和廉价，成本和技术难度都较低。缺点是不能保证数据最终一致。
异步热备份：指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本。
同步热备份：指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功。
5.5.3 失效转移：1.失效确认；2.访问转移；3.数据恢复。
5.6 高可用网站的软件质量保证
5.6.1 网站发布
5.6.2 自动化测试
5.6.3 预发布验证
5.6.4 代码控制：1.主干开发、分支发布(Git)；2，分支开发、主干发布(SVN).
5.6.5 自动化发布：周四作为发布日，一周前三天准备发布，最后一天验证发布。
5.6.6 灰度发布：指在部分服务器上发布新版本，其余服务器保持老版本，然后监控用户操作行为，收集验证，以确定最终的发布版本。也称作AB测试。
5.7 网站运行监控：不允许没有监控的系统上线。
5.7.1 监控数据采集
1.用户行为日志收集：指用户在浏览器上所做的所有操作及其所在的操作环境，包括用户操作系统与浏览器版本信息，IP地址。页面访问路径、页面停留时间等。
服务器端日志收集，客户端浏览器日志收集(嵌入专门的JavaScript脚本收集用户真实的操作行为).
2.服务器性能监控：指收集如系统Load、内存占用、磁盘IO、网络IO等对尽早做出故障预警，及时判断应用状况防患于未然。
3.运行数据报告：指监控一些与具体业务场景相关的技术和业务指标，如缓存命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等。
5.7.2 监控管理：系统报警、失效转移、自动优雅降级。
6.永无止境：网站的伸缩性架构
网站的伸缩性：指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
6.1 网站架构的伸缩性设计
网站的伸缩性设计可分为两类：一类是根据功能进行物理分离实现伸缩；二类是单一功能通过集群实现伸缩。
6.1.1 不同功能进行物理分离实现伸缩
纵向分离(分层后分离)：将业务处理流程上的不同部分分离部署，实现系统伸缩性。
横向分离(业务分割后分离)：将不同的业务模块分离部署，实现系统伸缩性。
6.1.2 单一功能通过集群规模实现伸缩
6.2 应用服务器集群的伸缩性设计：采用负载均衡服务器控制请求分发
6.2.1 HTTP重定向负载均衡：方案简单，但是需要浏览器两次请求才能完成一次访问，性能较差。
6.2.2 DNS域名解析负载均衡：根据负载均衡算法计算一个不同的IP地址返回对应的真实服务器地址。
6.2.3 反向代理负载均衡：将请求根据负载均衡算法转发到不同的Web服务器上。Web服务器处理完成的响应也需通过反向代理服务器返回给用户。反向代理服务器转发请求在HTTP协议层面。
6.2.4 IP负载均衡：在网络层通过修改请求目标地址进行负载均衡。操作系统内核进程获取网络数据包，根据负载均衡算法计算得到一台真实Web服务器地址，将数据目的IP地址修改为真实Web服务器地址，返回时再将数据包源地址修改为自身的IP地址发送给用户。
6.2.5 数据链路层负载均衡：指在通信协议的数据链路层修改mac地址进行负载均衡。分发过程中不修改IP地址，只修改目的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的。
6.2.6 负载均衡算法：1.根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址；2.将请求数据发送到该地址对应的Web服务器上。
常见算法：轮询(Round Robin,RR):依次分发到每天服务器上，请求数目平均。
加权轮询(Weighted Round Robin,WRR):按照配置的权重将请求分发到每个服务器，权重重的分配更多请求。
随机(Random):请求被随机分配到各个应用服务器。
最少连接(Least Connections):记录每个应用服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上。
源地址散列(Source Hashing):根据请求源IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，实现会话粘滞。
6.3 分布式缓存集群的伸缩性设计：新加入缓存服务器后应使整个缓存服务器集群中的已缓存数据尽可能还被访问到。
6.3.1 Memcached分布式缓存集群的访问模式
路由算法负责根据应用程序输入的缓存数据(Key)计算得到应该将数据写入到哪台服务器或者应该从哪台服务器读数据。
6.3.2 Memcached分布式缓存集群的伸缩性挑战：新的缓存服务器加入导致缓存命中率下降。
6.3.3 分布式缓存的一致性Hash算法：通过一致性Hash环的数据结构实现Key到缓存服务器的Hasee映射。
算法：先构造一个长度为2的32次幂的整数环，根据节点名称的Hash值(其分布范围为[0,2的32次幂-1])将缓存服务器节点放置在这个Hash环上。再根据缓存的数据的Key值计算得到其Hash值，在环上顺时针查找对应的服务器节点。
6.4 数据存储服务器集群的伸缩性设计：必须保证数据的可靠存储，保证数据的可用性和正确性。分为关系数据库集群和NoSQL数据库的伸缩性设计。
6.4.1 关系数据库集群的伸缩性设计：数据库主从读写分离，也可以业务分割分离实现数据分库。数据库分片产品有：Amoeba和Cobar。
6.4.2 NoSQL数据库的伸缩性设计：实现高可用性和可伸缩性，主要有HBase，Redis，MongoDB。
NoSQL主要指非关系的、分布式的数据库设计模式。
7.随需应变：网站的可扩展架构
扩展性(Extensibility):指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。
伸缩性(Scalability):指系统能够通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。
7.1 构建可扩展的网站架构：核心思想是模块化，并降低模块间的耦合性，提高模块的复用性。
模块分布式部署以后具体聚合方式主要有分布式消息队列和分布式服务。
7.2 利用分布式消息队列降低系统耦合性
7.2.1 事件驱动架构(Event Driven Architecture):在低耦合模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间的合作。
7.2.2 分布式消息队列：采用队列数据结构，实现消息分布式异步调用。
7.3 利用分布式服务打造可复用的业务平台
大型系统存在的问题：1.编译、部署困难；2.代码分支管理困难；3.数据库连接耗尽；4.新增业务困难。
解决方案：核心思想是拆分，将模块独立部署，降低系统耦合性。
纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，就直接将其设计部署为一个独立的Web应用系统。
横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体模块代码，而模块内业务逻辑变化时，只要接口保持一致就不会影响业务程序和其他模块。
7.3.1 WebService与企业分布式服务
WebService缺点：1.臃肿的注册与发现机制；2.低效的XML序列化手段；3.开销相对较高的HTTP远程通信；4.复杂的部署与运维手段。
7.3.2 大型网站分布式服务的需求与特点
负载均衡，失效转移，高效的远程通信，整合异构系统，对应用最少侵入，版本管理，实时监控。
7.3.3 分布式服务框架设计：服务消费者程序通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地代码块，也可以是远程服务，因此对应用较少侵入，应用程序只需要调用服务接口，服务框架根据配置自动调用本地或远程实现。
7.3.4 可扩展的数据结构：NoSQL数据库的动态列设计。
7.5 利用开放平台建设网站生态圈
开放平台是网站内部和外部交互的接口，外部需要面对众多的第三方开发者，内部需要面对网站内诸多的业务服务。
API接口：是开放平台暴露给开发者使用的一组API，其形式可以是RESTful、WebService、RPC等各种形式。
协议转换：将各种API输入转换成内部服务可以识别的形式，并将内部服务的返回封装成API的格式。
安全：需要设置身份识别、权限控制等，开放平台还需要分等级的访问宽带限制。
审计：记录第三方应用的访问情况，并进行监控、计费等。
路由：将开放平台的各种访问路由映射到具体的内部服务。
流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用。
8.固若金汤：网站的安全架构
8.1 道高一尺魔高一丈的网站应用攻击与防御
8.1.1 XSS攻击(跨站点脚本攻击Cross Site Script):指黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。
消毒：对HTML进行过滤和消毒处理，即对某些html危险字符转义防止恶意脚本攻击。
HttpOnly：即浏览器禁止页面JavaScript访问带有HttpOnly属性的Cookie。
8.1.2 注入攻击：注入攻击有两种，SQL注入攻击和OS注入攻击。SQL注入攻击原理是在HTTP请求中注入恶意SQL语句，服务器用请求参数构造数据库SQL命令时，恶意SQL被一起构造并在数据库中执行。
SQL注入获取数据库表结构手段：开源软件，错误回显，盲注。
防御SQL注入手段：消毒(请求参数消毒，过滤请求数据);参数绑定(使用预编译手段，实现SQL预编译和参数绑定).
8.1.3 CSRF攻击(CrossSiteRequestForgery,跨站点请求伪造)：通过跨站请求，以合法用户的身份进行非法操作。核心是利用浏览器Cookie或Session。
CSRF防御手段：表单Token，验证码，Referer check。
8.1.4 其他攻击和漏洞：ErrorCode，HTML注释，文件上传，路径遍历。
8.1.5 Web应用防火墙：ModSecurity，SiteShell。
8.1.6 网站安全漏洞扫描：不定期地对网站的服务器进行漏洞扫描，查漏补缺。对代码定期做安全检测和代码漏洞检查。
8.2 信息加密技术及密钥安全管理：单向散列加密、对称加密、非对称加密。
8.2.1 单向散列加密：指通过对不同输入长度的信息进行散列计算，得到固定长度的输出，这个散列计算过程是单向的，即不能对固定长度的输出进行计算从而获得输入信息。
8.2.2 对称加密：指加密和解密使用的密钥是同一个密钥。优点是算法简单，加解密效率高，系统开销小，
8.2.3 非对称加密：指加密和解密使用的密钥不是同一密钥。其中一个对外界公开的公钥，另一个只有所有者知道的私钥。
8.2.4 密钥安全管理：一种是把密钥和算法放在一个独立的服务器上，一种是将加解密算法放在应用系统中，密钥则放在独立服务器上。
8.3 信息过滤与反垃圾
8.3.1 文本匹配：主要解决敏感词过滤
8.3.2 分类算法：采用贝叶斯分类算法进行概率统计分类。
8.3.3 黑名单：将信息在黑名单列表中查找匹配，如果查找成功，则过滤该信息。
8.4 电子商务风险控制
8.4.1 风险：存在着账户风险、买家风险、卖家风险、交易风险。
8.4.2 风控：1.规则引擎。2.统计模型。
三.案例
9.淘宝网的架构演化案例分析:从最初的开源框架到采用资深专业技术，最后回到开源框架，并独立开发开源系统。
Linux+Apache+MySQL+PHP-->Linux+Weblogic+Oracle+Java-->Linux+JBoss+Oracle+Java+Spring-->Linux+JBoss+MySQL+Java+Spring-->独立开发框架系统
10.维基百科的高性能架构设计分析：Linux+Apache+MySQL+PHP
Wikipedia架构主要组成：GeoDNS(域名服务器),LVS(负载均衡服务器),Squid(反向代理服务器),Lighttpd(应用服务器),PHP,Memcached(分布式缓存系统),Lucene(搜索引擎),MySQL(数据库).
11.海量分布式存储系统Doris的高可用架构设计分析
11.1 分布式存储系统的高可用架构
系统整体分为三部分：应用程序服务器,是存储系统的客户，对系统发起数据操作请求。
数据存储服务器,是存储系统的核心，负责存储数据、响应应用服务器的数据操作请求。
管理中心服务器，由两台机器组成的主-主热备集群，负责集群管理，对数据存储集群进行健康心跳检测，集群扩容、故障恢复管理，对应用程序服务器提供集群地址配置信息服务等。
11.2 不同故障情况下的高可用解决方案
11.2.1 分布式存储系统的故障分类：瞬时故障，临时故障，永久故障。
11.2.2 正常情况下系统访问结构：写数据时，将数据写入集群全部服务器。读数据时，从任意一台服务器读取。
11.2.3 瞬时故障的高可用解决方案：是一种严重性较低的故障，一般系统经过较短暂的时间即可自行恢复。
11.2.4 临时故障的高可用解决方案：是将发生故障的服务器写数据操作转移到临时存储服务器。
11.2.5 永久故障的高可用解决方案：从其他序列中正常的服务器中复制全部数据才能恢复正常状态。
永久故障是指服务器上的数据永久丢失，不能恢复。
12.网购秒杀系统架构设计案例分析
12.1 秒杀活动的技术挑战
1.对现有网站业务造成冲击。 2.高并发下的应用、数据库负载。 3.突然增加的网络及服务器带宽。 4.直接下单。
12.2 秒杀系统的应对策略
1.秒杀系统独立部署。 2.秒杀商品页面静态化。 3.租借秒杀活动网络带宽。 4.动态生成随机下单页面URL。
12.3 秒杀系统架构设计：1.购买按钮只有在秒杀活动开始的时候才可点击。2.下单表单也尽可能简单，配置用户默认设置。
1.如何控制秒杀商品页面购买按钮的点亮：秒杀页面设计为静态页面，缓存在CDN、反向代理服务器上，使用内嵌脚本控制秒杀商品页面的展示。
2.如何只允许第一个提交的订单被发送到订单子系统：控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接进入秒杀结束页面。
13.大型网站典型故障案例分析
13.1 写日志也会引发故障
故障现象：服务器报警，硬盘可用空间低于警戒值。
原因分析：服务器硬盘容量太小，应用服务器集群日志打印过多，没有及时清除。
经验教训：应用程序自己的日志输出配置和第三方组件日志输出分别配置。
检查log配置文件，日志输出级别至少为Warn，并检查log输出代码调用是否符合真实日志级别。
13.2 高并发访问数据库引发的故障
故障现象：应用发布后，数据库Load居高不下。
原因分析：检查数据库，发现某条SQL频繁执行。
经验教训：首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。
首页最好是静态的。
13.3 高并发情况下锁引发的故障
故障现象：应用服务器不定时地响应超时而报警，但是很快又超时解除。
原因分析：程序中某个单例中多处使用了synchronized(this)，高并发下容易出现排队等待现象。
经验教训：使用锁操作要谨慎，代码提交必须检视。
13.4 缓存引发的故障
故障现象：没有发布新应用，但是数据库服务器Load飙升，并失去响应。
原因分析：缓存服务器集群全部被关闭。
经验教训：缓存服务器的管理和其他应用服务器一样重要。新手操作必须经过导师检查。
13.5 应用启动不同步引发的故障
故障现象：发布应用后，服务器立即崩溃。
原因分析：应用程序Web环境使用Apache+JBoss模式，用户请求通过Apache转发JBoss。发布时Apache和JBoss同时启动，由于JBoss启动时需加载很多应用并初始化，花费时间较长，结果JBoss还没有完全启动，Apache就已经启动开始接收用户请求，大量请求阻塞在JBoss进程中，导致JBoss崩溃。
经验教训：检查各应用环节启动时间，合理衔接各部分程序。
13.6 大文件读写独占磁盘引发的故障
故障现象：图片上传非常慢，有时等待服务器超时。
原因分析：图片存储服务器有几个文件非常大。
经验教训：存储的使用需要根据不同文件类型和用途进行管理。
13.7 滥用生成环境引发的故障
故障现象：监控发现某个时段内，应用突然变慢，内部网络访问延迟非常厉害。
原因分析：发现有工程师在线上生成环境进行性能压力测试。
经验教训：规范线上生成环境操作规范，预防不当操作。
13.8 不规范的流程引发的故障
故障现象：应用发布后，数据库Load迅速飙升，回滚后发布报警消失。
原因分析：发现访问缓存的代码被注释了，为了测试方便，注释后提交时忘记修改。
经验教训：代码提交前使用diff进行比较，确认没有提交不该提交的代码。加强CodeReview.
13.9 不好的编程习惯引发的故障
故障现象：应用更新某功能后，有少量用户投诉无法正常访问。
原因分析：用户第一次使用该功能，历史记录为空，构造了一个空对象。
经验教训：程序在输入数据时，必须做必要检查；程序在调用其他方法时，输入对象尽量保证不是null，必要时构造空对象。
四.架构师
14.架构师领导艺术
架构师职责：架构设计，软件开发等技术工作，规划产品路线、估算人力资源和时间资源、安排人员职责分工、确定计划里程碑点、指导工程师工作、过程风险评估与控制等。
14.1 关注人而不是产品：寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。
14.2 发掘人的优秀：是事情成就了人，而不是人成就了事。
发掘一个人的优秀远比发掘一个优秀的人更有意义。
14.3 共享美好蓝图
蓝图应该是表述清楚的：产品要做什么、不做什么、要达到什么业务目标，都需要描述清楚。
蓝图应该是形象的：产品能为用户创造什么价值、能实现什么样的市场目标、产品最终会长什么样，都需要形象地想象出来。
蓝图应该是简单的：不管内部还是外部沟通，都能一句话说明白：我们在做什么。
14.4 共同参与架构
1.不要只有架构师一个人拥有架构
2.让其他人维护框架与架构文档
14.5 学会妥协
14.6 成就他人：通过工作的挑战发掘自我的潜能，重新认知自我和世界。
15.网站架构师职场攻略
15.1 发现问题寻找突破
15.2 提出问题，寻求支持
提出问题Tips：1.把“我的问题”表述成“我们的问题”。2.给上司提封闭式问题，给下属提开放式问题。3.指出问题而不是批评人。4.用赞同的方式提出问题。
15.3 解决问题，达成绩效
解决问题Tips：1.在解决我的问题之前，先解决你的问题。2.适当的逃避问题。
16.漫画网站架构师
大型网站架构技术一览：
1.前端架构：浏览器优化技术、CDN、动静分离，静态资源独立部署、图片服务、反向代理、DNS。
2.应用层架构：开发框架、页面渲染、负载均衡、Session管理、动态页面静态化、业务拆分、虚拟化服务器。
3.服务层架构：分布式消息、分布式服务、分布式缓存、分布式配置。
4.存储层架构：分布式文件、关系数据库、NoSQL数据库、数据同步。
5.后台架构：搜索引擎、数据仓库、推荐系统。
6.数据采集与监控：浏览器数据采集、服务器业务数据采集、服务器性能数据采集、系统监控、系统报警。
7.安全架构：Web攻击、数据保护。
8.数据中心机房架构：机房架构、机柜架构、服务器架构。
备注：
作者：Shengming Zeng
博客：http://www.cnblogs.com/zengming/
本文是原创，欢迎大家转载；但转载时必须注明文章来源，且在文章开头明显处给明链接。
<欢迎有不同想法或见解的同学一起探讨，共同进步>
