交易流程容灾及测试策略

　　首先来梳理下什么是系统容灾。 互联网上容灾的概念解释很多，我们来看看百度百科里的解释：

　　从其对系统的保护程度来分，可以将容灾系统分为：数据容灾和应用容灾 。

　　数据容灾就是指建立一个异地的数据系统，该系统是本地关键应用数据的一个实时复制。

　　应用容灾是在数据容灾的基础上，在异地建立一套完整的与本地生产系统相当的备份应用系统（可以是互为备份），在灾难情况下，远程系统迅速接管业务运行。数据容灾是抗御灾难的保障，而应用容灾则是容灾系统建设的目标。

　　其实，上面指的容灾已经由我们的数据仓储和运维团队一直在很好的进行着。而且该容灾工作的目的主要是为了预防一些不可预料的意外，比如火灾、地震、紧急硬件故障等等。

　　为了保障系统的稳定性和可用性，作为业务团队的我们， 我们的容灾主要做什么呢？ 谷歌了下一直没有找到和我们所做的事情相似的概念，索性自己取了个名字叫业务容灾。 这里只讨论基于互联网的web业务系统，业务容灾主要就是指使用一定的技术手段，在极端访问量的情况下，牺牲一小部分非主要业务功能或者一小部分用户体验， 保障整体系统的稳定以及提供的主要功能，以保障绝大部分的用户需求和体验。我们的容灾工作，预防发生的场景是可以预见的，比如今年的双11、双12大促。

　　现在我们主要分析总结下我们的业务容灾主要包括哪些内容。

　　业务容灾手段

　　目前在集市交易系统中使用的业务容灾手段主要有以下几种，下面一一分析。需要说明的是，开关本身不是一种容灾方式，它只是容灾手段中便于人为操作而使用的某种方式，大部分容灾的手段都可以使用开关来达到目的。

　　业务降级

　　1、提前降级：

　　在极端访问的情况下，为了减少对系统的压力，对于一些用户量很小或者对用户体验影响极小的业务可以进行提前关闭。可以使用到时间点自动关闭的方式实现，也可以使用开关提前人为的关闭。这里如果选择使用开关进行人为关闭，需要考虑到不同应用系统之间对同一个业务的协调和时间差，尽可能做到平稳的过渡，让用户完全没有感知。

　　2、应急降级：

　　应急降级主要是针对重要性稍低的业务提前完成预备降级的工作，并提供开关以备不时之需。在系统稳定的情况下正常提供功能，紧急情况下可以人为临时关闭，以保障系统最高优先级的核心功能的可用性和系统整体的稳定性。

　　数据备份

　　为了解决数据读取的问题，我们可以对数据进行提前备份，并在当老数据读取出现异常的紧急情况下，临时切换到新的存储系统进行读取。需要完成的研发功能有：新存储的数据备份功能；紧急切换开关；历史数据的复制。

　　自动流控/限流

　　自动流控主要是指，当系统中对某些二方应用系统访问的线程数超过一定阀值的时候，进行自动限流，防止因为二方应用响应超时太多，拖垮我们的应用。 实现上可以直接抛异常，用户会感觉某功能不可用；也可以直接忽略，让流程继续往下走，用户不会有任何感知。

　　当然，限流后是应该抛异常还是直接忽略，这个不能直接凭用户体验来，不是说用户感知不到就一定是最好的。这里一定要根据具体功能点的设计来决定。比如如果查询库存的线程被限流了，那么就一定要抛异常让下单失败，否则会引起宝贝超卖，这个对于卖家是绝对不能接受的。

　　对于不同应用请求的流控的阀值的设置也需要再三斟酌，设置高了可能会导致极端情况下流控还没生效，我们的系统已经被拖跨了；设置低了可能会资源浪费，导致系统还未达到自己的最大承受临界点之前就已经牺牲了部分功能和用户体验。所以流控阀值的设置，需要平时在生产系统多观察，不断调整阀值以求达到一个最合适的值。并提供阀值调整开关以备不时之需。

　　备注：系统中不是对所有的二方应用的访问都有自动流控，这个是需要单独添加的。对于一些重要性非常高的应用一般不做自动流控。

请求拦截

　　请求拦截是指当我们的系统压力比较大的时候， 牺牲掉对我们系统访问的一部分重要性稍低的请求，直接对请求进行拦截，减少系统压力，保障系统的稳定性。具体拦截哪些业务方的请求，什么接口，或者接口允许访问的最大QPS是多少，这些最好能做成可配置化，在紧急情况下可以灵活调整。

　　强弱依赖设计

　　在系统设计时，需要考虑所有系统内部访问的其他系统接口为强依赖还是弱依赖。比如对于某个功能点，内部需要调用其他系统的接口A和B，如果A出现异常则该功能不可用，而B出现异常，不会影响该功能的整体可用性，那么我们需要将A设计为强依赖，B设计为弱依赖。

　　强弱依赖的设计对于系统整体的可用性非常重要，特别是在极端访问量的情况下。我们要尽可能的保证系统功能不受弱依赖系统的影响。 并且强弱依赖需要独立的测试场景来持续保障，以防强弱依赖的设计因为代码的不断改动而发生意料之外的改变。

　　容灾测试方法

　　业务降级、数据备份、以及请求的拦截这类的容灾场景一般都会有自己独立的业务测试方法，也会有对应的开关去控制，只需将开关设置到对应状态，使用和普通业务测试相同的方法即可。

　　对于自动流控的测试，可以将阀值调整的开关设置为最低值，即等同于业务的降级测试；也可以将阀值设置为一个较低的值，并模拟依赖系统的请求变慢，再进行业务测试来达到触发流控的条件。

　　对于强弱依赖的测试可以直接模拟和依赖系统之间的网络不通，或者网络变慢，从而模拟依赖系统返回的请求超时或者变慢的场景，再进行业务测试观察系统各功能点的可用性。具体模拟网络不通或者变慢超时的方式如下：

　　模拟网络不通

　　1、使用iptbables直接模拟系统和某系统之间的网络不通：

　　sudo iptables -A OUTPUT -o eth0 -d <依赖系统的IP>  -j DROP

　　这个命令需要在我们被测系统上执行，并且将需要模拟的依赖系统的IP替换掉。它的主要作用是将我们被测机器往依赖系统这个IP上发送的所有的网络包给丢弃掉，依赖系统接收不到任何我们发送的包，自然也不会做任何回应。相当于系统接口的调用没有返回。

　　2、使用iptables直接模拟系统的某个端口不通

　　sudo iptables -A OUTPUT -o eth0 -p tcp  --dport <端口号> -j DROP

　　这个命令同样需要在被测系统上执行。它的主要作用是将我们被测机器通过这个端口发送的所有的包给丢弃掉。

　　3、清除所有设置的iptables规则：iptables –F

　　4、查看当前设置的所有iptables规则：iptables –L

　　模拟应用变慢和超时

　　添加对某个依赖系统的流量控制，下面的命令需要按照顺序执行：

　　1、使用ifconfig查看默认的网卡信息，一般默认为eth0

　　2、使用tc流量控制命令将eth0网口过来的数据包延迟1000ms

　　sudo tc qdisc add dev eth0 root handle 1: prio
　　sudo tc qdisc add dev eth0 parent 1:3 handle 30: tbf rate 20kbit buffer 1600 limit  3000
　　sudo tc qdisc add dev eth0 parent 30:1 handle 31: netem delay 1000ms 10ms distribution normal

　　3、添加从某ip过来的流控规则(替换**.**.**.**为需要流控的ip)

　　sudo tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:3

　　查看已经设置的限流规则: sudo tc filter list dev eth0 parent 1:0

　　删除已经设置的所有的限流规则: sudo tc filter del dev eth0 parent 1:0 prio 3 u32

删除已经设置的从某ip过来的流控规则（直接替换添加流控规则命令中的add为del即可）：

　　sudo tc filter del dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:3

　　注：

　　linux tc流量控制是个非常复杂的工具，这次容灾测试也只是粗浅的了解。

　　希望深入了解的同学可以进入这里进一步学习：http://feisky.diandian.com/post/2011-11-13/15494559

　　容灾项目特点

　　1、项目需求无法提前计划：所有容灾的设计都是在不断优化和测试的过程中不断发现新的需求。

　　2、项目研发涉及到的业务场景覆盖广，涉及研发人员多，测试数据准备工作量大

　　3、项目测试环境依赖多，复杂度高

　　4、容灾测试点相互交错复杂，并行测试难度高，测试效率低

　　5、测试难度较其他普通业务项目要求高，需要同步根据日志定位所有的测试场景出现原因

　　容灾项目测试策略

　　针对以上容灾项目独立的特点，测试也需要一定的测试策略来应对容灾的测试工作

　　1、测试计划的敏捷安排

　　容灾项目测试因为需求不确定、涉及业务广等原因导致前期测试计划较难做，需要有个非常敏捷的流程来应对各种需求的测试。 我们需要能够在项目期间的任意一个时间点随意的添加删减测试人员，这就要求我们能够有一个人能通盘全局了解所有的容灾点，在任何时候能够对新人进行测试指导，并帮助容灾测试同学排除所有的外在干扰，让测试同学能够快速的开始具体的容灾测试。同时考虑容灾业务涉及广，为了避免业务测试场景上的遗漏，我们需要采取一人协调，多业务测试专员配合的模式来开展容灾测试。他们各自的职责有：

　　【总协调人员/测试PTM】：

　　- 配合开发人员，对系统整体的容灾点进行梳理和汇总

　　- 协调不同的业务测试同学进行各容灾点的测试

　　- 容灾测试的技术指导和工作review

　　- 各容灾测试环境的协调

　　- 帮助业务测试同学排除所有的外在干扰

　　【容灾测试执行人员】：

　　- 根据已梳理好的容灾点完成容灾测试

　　- Bug录入和跟进，并定时汇总给总协调人员

　　2、容灾测试的需求文档管理

　　容灾项目测试的需求一般会系统不断的优化、测试以及火花的碰撞而不断增加，涉及到的团队和人员也非常广，所以非常需要一个共享的方式来管理需求。本次容灾项目中，我们在中后期采取了百科共享的方式来管理所有的待做事项和容灾点，并进行了统一的分类，大大提高了沟通的效率。

3、容灾测试的数据准备

　　容灾测试的数据准备一定要全，不全的数据非常容易遗漏测试场景。可以结合不同的业务测试同学分别准备，既可以保证数据的准确和完整性，也保证了效率。

　　4、测试环境的协调

　　容灾项目的测试无法和普通的业务测试共用一套环境，需要准备独立的环境来进行。不同的测试同学在共用这一套环境时，切换不同的容灾开关需要及时知会到所有人，以防对他人造成影响。当然，如果条件允许，多备几套容灾测试环境自然更好，那样大家就可以完完全全的并行测试了。

　　5、容灾测试和普通业务项目测试的不同以及注意事项

　　- 测试容灾点时，需要同步分析日志。因为容灾一般都是测试的异常场景，我们的测试环境经常不稳定，出现各种异常，所以测试时一定要仔细结合日志分析，确认当前展示的结果是否是由于我们的容灾代码生效而出现的。

　　- 对于开发新增的业务代码要尤其注意，重视并配合开发一起做好新代码的容灾工作

　　- 不同系统之间的容灾设计、以及同一个系统中的不同容灾场景的设计需要仔细评估，对潜在可能相互关联的容灾点要重点测试，预防互相影响，导致在极端情况下，出现无法预料的结果。

　　6、代码review

　　容灾项目的代码review非常重要。因为测试工作量大，涉及点多且咋，测试会重点关注已知的容灾点测试，对于未知的场景，只有通过代码review来发现。比如本次的容灾项目中，研发同学通过代码review发现了我们的流控拦截代码将不该拦截的业务代码也给拦截了，而这个如果期望依靠测试来发现，成本将会高很多很多。

　　7、容灾测试的自动化

　　容灾测试的自动化工作是势在必行的。各种大促活动不断的涌入，每次大量的人力成本投入容灾测试着实一种资源浪费。思考了一下后期自动化开展的方式和问题，有待实践论证，这里简单列一下：

　　业务降级/数据备份/请求拦截/自动流控：可以直接选择Ruby自动化或者接口测试来实现，只需提前将对应的开关设置为相应状态即可。但是需要一套独立的环境，不能和正常的业务测试环境共用一套，会相互干扰。

　　强弱依赖设计：需要提前配置一套正确的环境，对环境要求非常高。并且不同的容灾场景无法连续执行，需要手工在机器上执行不同的命令以模拟断网或者流量控制。实现难度较大。远程执行脚本也许可以解决这个问题，有待具体实践。

　　8、容灾线上演练

　　容灾线上演练是容灾项目中特有的一个流程，在前期准备和演练过程中需要注意以下几点：

　　- 提前准备好所有的生产环境测试数据。因为演练一般从夜里凌晨开始，短短的几个小时时间需要演练较多的开关，测试数据准备的充分，可以大大提高演练的效率。

　　- 提前在测试环境做充分的测试，演练的效率才会高。

　　- 开关切换时间尽量短。虽然是在深夜，也依然有很多用户在使用我们的系统，所以每个开关的切换都要考虑到对当前用户的影响。开关生效时间尽量缩短。

　　- 每个开关切换后都一定要切回并再次验证。必要时演练结束后将所有系统全部重启。

　　- 不同系统之间的同业务的开关执行顺序需要提前沟通好。

　　业务容灾的测试在我产品线尝试已有两年之余，但是只有今年的容灾测试才开始趋于系统。经验尚浅，大家如有其他建议或异议，非常欢迎能多沟通交流，期望业务容灾的测试工作能在不断的实践和沟通过程中越来越完善。