演讲高朋简介：
信海龙(花名沧龙)，十余年的互联网开拓履历，2013年加入阿里巴巴，深耕于电商、社区干系运用开拓与架构。同时也是多个开源项目的开拓者和掩护者。代表开源作品，tclip，基于人脸识别的图片裁剪扩展。
本次直播视频精彩回顾，戳这里！
直播回顾：https://yq.aliyun.com/live/965
PPT分享：https://yq.aliyun.com/download/3530
以下内容根据演讲高朋视频和PPT分享整理而成。
本次的分享紧张环绕以下三个方面：
稳定性的主要性保障策略架构篇保障策略流程篇稳定性的主要性对很多企业来说做事稳定性非常主要，首先稳定性问题会对企业带来直接的经济丢失。举例来说，亚马逊的“Prime Day”当天涌现的一个故障，给亚马逊带来了高达9900万美元的丢失。这一个故障丢失就可能是其它小公司市值的几倍。以是做事稳定性对公司影响是特殊大的。而对付个人来说，做事不稳定性会影响员工的绩效，乃至影响个人出路。
保障策略架构篇
从架构层面保障稳定性，常见的策略包括限流，降级，隔离，超时，重试和集群等。
1.限流
限流目的
限流的目的紧张有两点，第一点是防止系统高负荷运行，第二点是有效利用做事器资源。为什么要做限流？如果不封锁要求，可能会导致做事器报警，如果平时做事器只能处理100个要求，溘然多出两个要求做事器或许勉强能够处理，但溘然多了500个要求的话，后面的400个要求只处在积压状态，等做事器处理到第500个要求的时候，用户等待韶光就会过长，而且末了积压部分的要求可能根本便是无效的处理，由于用户早已流失落。
限流算法
常见限流的算法包括漏桶算法和令牌桶算法。漏桶算法如下图，图中的例子有个小桶，桶下面有个孔，每流一滴水就可以认为是一个要求进去。滴水的速率是一样的，孔的高度也是固定的。漏桶算法能担保每个要求的负载时长，即确定每秒能处理的要求数量。
漏痛算法实现如下图，可以设定桶的高度是5个，每秒漏两个。实行效果中前面5次结果都是true，之后中间一次结果是false，这解释桶已经装满，之后又漏了两滴水，由于false的时候sleep了一秒，以是下面又有两个true出来。
令牌桶算法
如下图，令牌桶算法也是有一个桶，但是桶不漏，桶里面放了一些令牌，每来一个要求就在桶里拿一个令牌，如果没有令牌它就可以等待，令牌满了就不再往里面加令牌。这样方法基本上也可以达到一个限流的目的。令牌桶算法和漏桶算法的一个显著差异是漏桶算法在后端取要求量时，基本上漏的速率是一样的，但是令牌桶算法中后端部分可以有突发要求，如果桶满了，可以将桶里所有令牌都拿走。
下图是令牌桶算法lua代码实现部分，当然读者还可以利用Nginx，Java脚本或者php脚本来实现。
2.降级
社区降级案例
一样平常情形下，系统上线之后总会碰着一些不稳定情形，比如redis挂掉，乃至后端数据库My SQL挂掉。当涌现不稳定情形之后，系统如何担保连续供应这些做事。以社区案例为例，即便是My SQL挂掉，也要能够担保社区为用户供应基本的可读做事。个中一个策略是将一些热点数据，即用户常常浏览的信息或者最新的信息缓存起来，当后端做事不可用的时候，把这些数据展现给用户。大概流程如下图，数据存储部分后端会有一个脚本去剖析Nginx里面的日志，然后去要求Vanish，Vanish再去要求后端，这样的话Vanish会有一个有效期，能够担保Vanish存进去的数据都是用户常常访问的一些数据。第二步，如何担保后端数据库挂掉的数据时候能迁过去？下图可以看到，Nginx中利用lua脚本进行实现，它会检测后端做事返回的一些状态，利用计数器打算失落败次数，如果频繁的达到一定程度的失落败次数，就切换到从Vanish获取数据，末了推送给用户。这样能担保即便是后真个数据库挂掉，乃至即便所有的php进程都挂掉的时候，社区也能给用户供应一些基本的做事。
降级目的
降级的目的比较大略，第一个是保障做事器基本可用，第二个是保障做事的核心做事可用。降级是怎么一个思路呢？一样平常降级的每个策略都是针对一个场景，预想特定场景下须要要办理什么问题；然后再梳理在这个场景下须要保留哪些核心基本做事；末了才选定技能方案，系统化的进行实现。大略讲便是先确定须要达到什么目的，再去理解是什么样的情形，末了制订策略或者操持。比如，系统会调用第三方做事，而第三方做事有可能挂掉，这是一种范例的场景。再比如，系统本身调用推举行事，但是推举行事也会挂掉，这种场景下不能够由于没有推举数据就不显示数据，还是须要展示一些数据，这是一种基本的核心做事。每年的双11或者一些大型活动中基本都会存在降级。降级不仅仅是存在于资源故障场景下，资源不足用时也可能会须要降级，由于资源不足用须要关注重点。如大匆匆活动中，须要先担保交易做事正常运行，其它花费资源的做事（如对账）可往后续再去处理。
3.超时
超时案例
社区对外供应接口做事，对方的反馈是接口做事较慢。接口部分流程是查一段数据，然后将数据反响过去，其问题点在于系统中超时时间设置过长。比如调用Memcache，但是Memcache已经挂掉，由于超时设置过长，数据须要等到超时时间结束往后再返回，导致接口一贯在等待。那如何设置超时时间才合理？要把稳超时时间并不是固定的值，而是须要针对全体业务，根据特定场景设置超时时间值。
如何设置超时时间
大体的思路如下图。第一步，识别业务须要的做事相应韶光。比如，须要100毫秒去相应数据，之后统计业务里面可能须要调多少做事。第二步，统计做事日常的相应韶光。第三步，分清主次，即分出哪些是核心做事。由于核心做事一旦失落败，全体链路便不可用，以是可以对核心做事的韶光设置的宽松一些。如果一些做事调不通，但又不影响全体链路，可以对它的韶光设置的相对严格。
设置完超时之后须要验证，借助仿照手段封端口（如下图），仿照故障，然后检讨数据返回韶光是否在指定的韶光内。
4.隔离
隔离案例
下2013年旁边，手机客户端开始逐渐升级起来，很多项目既有PC端也有客户端，以是同一个做事即要为PC端又要为客户端供应API接口。一旦碰着大型活动或者须要手机推送，做事会碰着不稳定情形，做事的不稳定会导致PC端也受影响，以是须要将做事进行物理隔离，从原来耦合到一块的做事器分到不同的机器组。隔离目的非常大略，要限定住不稳定成分导致的风险，停滞传播。
隔离形式
隔离的常见形式包括几种。第一是秒杀场景，秒杀场景一个高并发的场景，可能带来的问题也比较多，在高并发场景下秒杀的时候，须要和一些正常的业务区分开来，不建议一台机器既供应秒杀也供应进程做事。其余，秒杀的时候会产生热点数据，如售卖数据。数据库更新比较频繁，从数据库层面也可以进行隔离，将热点部分和正常做事部分从资源上隔离。第二个场景是慢SQL隔离，一个资源隔离。一条慢SQL会导致全体做事不稳定。每要求一次线程，慢SQL会一贯耗着当前哨程，以是资源占用非常大。第三个场景是机房隔离。一样平常大公司都会做多机房支配，其目的便是确保稳定性。确保稳定性时不要做跨机房调用，否则耦合度会比较高，如果A调B，B挂掉，A做事也会受影响。一样平常确保稳定性都是做本机房的调用。而且本机房的调用性能也比较快。末了一个场景是进程隔离，由于进程比线程更加稳定。
5.集群
对小公司而言，一台机器就供应一个做事，如果机器挂掉做事规复就会成为一个问题。一样平常办理方法是做一个集群，从原来的一台机器供应做事变为可以用多台机器供应做事。集群的目的是为理解决单点的问题。集群的形式紧张有主备，即同时只有一台机器供应全体做事，可以有一台或者多台供应备份，备份不仅要包含代码层面，全体做事运行所依赖的资源都要有备份。其余一个形式是主从。主是供应一个完全的做事，从是供应部分的做事。还有一种是多主，多主指的是每一台机器的决策是对等的，都会对外供应一些做事。随着集议论势的不同，对代码编写的并发性上有一定哀求。主备只须要考虑单机的并发掌握，主从是考虑同时供应做事的部分。比如加锁，主备上只要加一个本地的技能锁就可以，主从或者多主则须要加分布式锁。
担保策略流程篇
担保稳定性策略的流程方面上分为下图中四个点，code review, 压测，灰度和监控。
1.Code review
code review目的是在项目上线前及时创造一些问题。履历比较丰富的人可以将履历进行分享。code review基本经由三个阶段。第一个阶段是头脑风暴式，一群开拓职员围着代码做code review，虽然韶光本钱较高，效果也不太空想，但是这种办法也有好处，在前期可以将大家的见地进行整理，制订code review的规范。第二种code review形式是演讲式，专家事先把代码做一下review，整理一些点，然后进行分享。演讲式可以按照轮岗制，相敌人脑风暴式大大节约了韶光。目前常见的code review 形式是结对式，由一个或者两个专家结对，相互review，韶光上比较灵巧，也不须要霸占会议室资源。
2.压测
压测目的
压测的目的，第一是担保系统稳定性。在高并发的时候，检测系统是否稳定，由于一些问题在流量比较低的时候创造不了，只有在高并发的时候才能创造这个问题。第二是检测性能的抗压能力，检讨系统能承受多大的QPS。
压测关注点
首先，压测机器和被压测做事在同一网段，只管即便避免由于网络缘故原由导致压测的结果不准确。第二点是关注做事器的负载，把稳不要把做事器压到100%，做事器快要崩的时候，得到的值意义不大。该当是做事器负载达到60%~70%的时候，看QPS是多少。其余，压测并发数据是逐步递增的过程，到一个点的时候，并发数据越多代表QPS越低。末了，根据测试环境的压测结果估算线上的承载能力。估算的公式是线上QPS = 单机QPS 机器数 0.7。后面会乘以一个系数（0.7）是由于线上put上去的时候总会存在一些损耗。
全链路压测
但有一些测试在测试环境下无法实现压测，以是现在发展成了全链路压测。全链路压测大概分成三个核心关注点。第一个是数据模型的布局。全链路压测是仿照线上真正的数据模型，比如说访问详情页的人数，下单的人数，人数比例，上岸人数等等参数，只管即便按照真实数据仿照，构建仿真模型，这样才能真正的创造线上的一些问题。把稳全链路压测不是在测试环境下实现，而是在线上压测。第二个是压测工具构建。可以是借助开源的压测工具，阿里自建了压测平台，根据数据模型提升流量。第三点是流量的隔离。对流量增加标识，担保不影响线上的数据，将全链路测试流量放到测试的存储中。比如天生一个订单order表，同时也会天生一个影子表test_order。如果创造是来自于全链路压测的流量，就把这个数据写到影子表test_order里面，这样能够担保存储。无论是缓存还是数据库存储都能够进行流量隔离。
3.灰度
灰度目的是小范围试错，只管即便创造问题。灰度的策略大概有以下几种，第一个策略是只让某一个地区的人先访问最新的特性，碰着问题的话用户及时反馈，问题也只会影响特定地区。其余一个策略是基于用户属性，如一个推举系统，要求过来的时候能区分新老用户，它对新老用户的推举的策略可能是不一样的，从而来验证策略的准确性和有效性。第三种策略是基于数据，从一批用户中选取几个用户进行处理。比如，对供应链的供应商的数据做处理，但是一样平常情形下不敢担保代码上线之后100%没问题。这时先选择一个供应商处理，验证数据，确保没问题再全量处理所有的供应商。末了是基于平台，一样平常都发生在客户端场景下。客户端与做事端不同，做事端一样平常是针对这个平台，先指挥这个平台先发布新版本，反馈不错再推到全体全面平台。对付客户真个灰度技能的实现如下图，给客户端集中一个Cookie，要求到了之后在Nginx中去检讨Cookie，根据不同的Cookie把情趣转到不同的组。比如组A有新特性，组B是老版本，根据不同的Cookie转到不同组，担保只有一部分人可以看到新的特性。
4.监控
监控把稳点
监控的目的是可以自动化及时创造问题。监控须要把稳几点问题，第一是全方面监控，系统和做事全部都要监控。第二是报警分级，监控报警的系数设置的要合理。末了一点是在真实环境下做数据网络。比如，A和B做事器，只在B做事器做监控。如果A做事器My SQL数据库网络出问题后，由于在监控上B做事器是正常的，监控不会报警。以是要在运用做事器上做监控才会报警详细哪台机器哪个做事涌现故障等信息。
自研监控系统
下图是阿里自研的监控系统。首先确定对哪些指标进行监控。将全体指标的数据绘制出来，查看指标数据颠簸。一旦碰着问题，可以很方便的进行比拟。其余要确定影响，将所有干系的指标聚合起来。比如供应商的团队操控系统常常会发生仓库操作卡顿，有很多成分都会导致卡顿，如PC端调用其它接口较慢，做事器load比较高档。仓库职员无法关注详细的细节，他们在影响界面查看指标影响值，一眼就可以知道是哪项指标不合格导致的卡顿。之后对造成的影响进行相应的处理，目前一样平常的行为有效报警或短信报警。
作者：PHP小好手
