为什么80%的码农都做不了架构师？>>> 
（1）网站可用性的度量与考核
1.网站可用性度量
网站不可用也被称作网站故障，业界通常用多少个9来衡量网站的可用性。
2.网站可用性考核
可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面，可用性指标是网站或者产品的整体考核指标。
（2）高可用的网站架构
网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。
实现上述高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。
（3）高可用的应用
应用层主要处理网站应用的业务逻辑，因此有时也称作业务逻辑，应用的一个显著特点是应用的无状态性。
所谓无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。
1.通过负载均衡进行无状态服务的失效转移。负载均衡，顾名思义，主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载处理能力。目前，不管是负载均衡软件还是硬件，都提供失效转移功能。
2.应用服务器集群的Session管理。Web应用中将这些多次请求修改使用的上下文对话称作会话(Session)，单机情况下，Session可由部署在服务器上的Web容器（如JBoss）管理。在使用负载均衡的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。
集群环境下，Session管理主要有以下几种手段：
a.Session复制。应用服务器开启Web容器的Session复制功能，在集群的几台服务器之间同步Session对象，让每台服务器都保存所有用户的Session信息。但当集群规模较大时，集群服务器之间需要大量的通信进行Session复制，占用服务器和网络的大量资源，系统不堪重负。而且由于所有用户的Session信息在每台服务器上都有备份，在大量用户访问的情况下，甚至会出现服务器内存不够Session使用的情况。而在大型网站的核心应用集群就是数千台服务器，同时在线用户可达千万，因此并不适用这种方案。
b.Session绑定。Session绑定可以利用负载均衡的源地址 Hash 算法来实现，负载均衡服务器总是将源于同一IP的请求分发到同一台服务器上。这样在整个会话期间，用户的所有请求都在同一台服务器上处理，即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。这种方法又被称作会话黏滞。但是Session绑定的方案显然不符合我们对系统高可用的要求，因为一旦某台服务器宕机，那么该机器上的Session也就不存在了，用户请求切换到其他机器后因为没有Session而无法完成业务处理。所以虽然大部分负载均衡服务器都提供源地址负载均衡算法，但很少有网站利用这个算法进行Session管理。
c.利用Cookie记录Session。优点：Cookie简单易用，可用性高，支持应用服务器的线性伸缩。缺点：受Cookie大小限制，能记录的信息有限；每次请求响应都需要传输Cookie，影响性能；如果用户关闭Cookie，访问就会不正常。
d.Session服务器。利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。
（4）高可用的服务
1.分级管理。
重要的核心的应用优先使用更好的机器；在服务部署上也进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至部署在不同地域的数据中心。
2.超时限制。
由于服务器宕机、线程死锁等原因，可能导致应用程序对服务端的调用失去响应，进而导致用户请求长时间得不到响应，同时还占用应用程序的资源，不利于及时将访问请求转移到正常的服务器上。
在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。
3.异步调用。
应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。也不是所有服务调用都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。对于那些必须确认服务调用成功才能继续下一步操作的应用也不适合使用异步调用。
4.服务降级
在网站访问高峰期，服务可能因为大量的并发调用而性能下降，严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务及关闭服务。
拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节约资源，让另一部分请求得以成功，避免要死大家一起死的惨剧。
关闭功能：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源。淘宝在每年的“双十一”促销中就使用这种方法，在系统最繁忙的时段关闭“评价”、“确认收货”等非核心服务，以保证核心交易服务的顺利完成。
5.幂等性设计
应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这是服务是一个转账操作，就会产生严重后果。
服务重复调用时无法避免的，应用层也不需要关心服务是否真的失败，只要没有收到调用成功的响应，就可以认为调用失败，并重试服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。
有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置多少次，结果都一样。但是对于转账交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服务调用有效性校验，只有有效操作才能继续执行。
（5）高可用的数据
保存数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。而失效转移机制则保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。
关于缓存服务的高可用。对于缓存服务器集群中的单机宕机，如果缓存缓存服务器集群规模较大，那么单机宕机引起的缓存数据丢失比例和数据库负载压力变化都较小，对整个系统影响也较小。扩大缓存服务器集群规模的一个简单手段就是整个网站共享同一个分布式缓存集群，单独的应用和产品不需要部署自己的缓存服务器，只需要向共享缓存集群申请缓存资源即可。并且通过逻辑或物理分区的方式将每个应用的缓存部署在多台服务器上，任何一台服务器宕机引起的缓存失效都只影响应用缓存的一小部分，不会对应用性能和数据库负载造成太大影响。
1.CAP原理
在讨论高可用数据服务架构之前，必须先讨论的一个话题是，为了保证数据的高可用，网站通常会牺牲另一个也很重要的指标：数据一致性。
高可用的数据有如下几个层面的含义。
a.数据持久性。保证数据可持久存储，在各种情况下都不会出现数据丢失的问题。为了实现数据的持久性，不但在写入数据时需要写入持久性存储，还需要将数据备份一个或多个副本，存放在不同的物理存储设备上，在某个存储故障或灾害发生时，数据不会丢失。
b.数据的可访问性。在多份数据副本分别存放在不同的存储设备的情况下，如果一个数据存储设备损坏，就需要将数据访问切换到另一个数据存储设备上，如果这个过程不能很快完成（终端用户几乎没有感知），或者在完成过程中需要停止终端用户访问数据，那么这段时间数据是不可访问的。
c.数据一致性。在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就会造成多个副本之间数据的不一致，数据内容冲突。实践中，导致数据不一致的情形有很多种，表现形式也多种多样，比如数据更新返回失败，事实上数据在存储服务器已经更新成功。数据一致性又分为三点：数据强一致性、数据用户一致、数据最终一致。
CAP原理认为，一个提供数据服务的存储系统无法同时满足数据的一致性(Consistency)、数据可用性(Availibility)、分区忍受性(Patition Tolerance,系统具有跨网络分区的伸缩性）这三个条件。
在大型网站应用中，数据规模不断扩张，所以P必不可少。规模变大后，机器需要增加，这是网络和服务器会频繁出现故障，所以得保证HA。所以通常会选择强化分布式存储系统的可用性(A)和伸缩性(B),而在某种程度放弃一致性(C)。
2.数据备份
数据备份分为冷备份和热备份。热备份又分为同步热备和异步热备。
3.失效转移
若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器所在的读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫失效转移。
失效转移由三部分组成：失效确认、访问转移、数据恢复。
a.失效确认，判断服务器是否宕机。有两种手段：心跳检测以及应用程序访问失败报告。对于应用程序访问失败报告，控制中心还需要再一次发送心跳检测进行确认，以免误判。
b.访问转移。一台服务器宕机后，应用程序根据配置直接切换到对等服务器上。如果存储不对等，需重新计算路由，选择存储服务器。
c.数据恢复。因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机时，就可能出现无法访问转移（所有副本的服务器都宕机了），数据永久丢失的情况。所以系统需要从健康的服务器复制数据，将数据副本数目恢复到设定值。
（6）高可用网站的软件质量保证
1.网站发布。
发布过程中，每次关闭集群中一小部分的服务器，发布完之后立即可用。直到集群中所有的服务器全部发布完，发布完成。
2.自动化测试。
3.预发布验证。
在网站发布时，并不是直接把测试通过的代码发布到线上服务器，而是先发布到预发布服务器，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。
4.代码控制。
a.主干开发，分支发布。代码修改都在主干(trunk)上进行，需要发布的时候，从主干拉一个分支(branch)发布，该分支即成为一个发布版本，如果该版本发现Bug，继续在该分支上修改发布，并将修改合并(merge)回主干，直到下次主干发布。
b.分支开发，主干发布。任何修改都不得在主干上直接进行，需要开发一个新功能或者修复一个Bug时，从主干拉一个分支进行开发，开发完成且测试通过后，合并回主干，然后从主干进行发布，主干上的代码永远是最新发布的版本。
这两种方式各有优缺点：主干开发，分支发布：主干代码反应目前整个应用的状态，一目了然，便于管理和控制，也利于持续集成；分支开发，主干发布：各个分支独立进行，互不干扰，可以使不同发布周期的开发在同一应用中进行。
5.自动化发布。
6.灰度发布。将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。
灰度发布也常用于用户测试，即在部分服务器上发布新版本，其余服务器保持老版本（或者发布另一版本），然后监控用户操作行为，收集用户体验报告，比较用户对两个版本的满意度，以确定最终的发布版本。这个手段也称作AB测试。
（7）网站运行监控
1.监控数据采集。
a.用户行为日志收集：服务端日志收集、客户端浏览器日志收集。
b.服务器性能监控。收集服务器性能指标，如系统Load、内存占用、磁盘IO、网络IO等对尽早做出故障预警，及时判断应用状况，防患于未然，将故障扼杀在萌芽时期非常重要。此外根据性能监控数据，运维工程师可以合理安排服务器集群规模，架构师及时改善系统性能及调整系统伸缩性策略。
c.运行数据报告。
2.监控管理。
a.系统报警。
b.失效转移。
c.自动优雅降级。
