建设银行360网站登录不了,建立网站需要多长钱,app平台开发定制软件,wordpress取消作者随着海量请求、节假日峰值流量和与日俱增的系统复杂度出现的#xff0c;很有可能是各种故障。在分析以往案例时我们发现#xff0c;如果预案充分#xff0c;即使出现故障#xff0c;也能及时应对。它能最大程度降低故障的平均恢复时间#xff08;MTTR#xff09;#xf… 随着海量请求、节假日峰值流量和与日俱增的系统复杂度出现的很有可能是各种故障。在分析以往案例时我们发现如果预案充分即使出现故障也能及时应对。它能最大程度降低故障的平均恢复时间MTTR进而让系统可用程度SLA维持在相对较高的水平将故障损失保持在可控范围内。但是经过对2016全年酒店后台研发组所有面向C端系统的线上事故分析后发现在许多情况下由于事故处理预案的缺失或者预案本身的不可靠以及开发人员故障处理经验的缺失造成大家在各种报警之中自乱了阵脚从而贻误了最佳战机。 正如上面所讲由“上游流量”和“依赖”导致的故障数量占了全年故障的45%。 一个经典的case 2016年3月10日Tair集群因流量过大挂掉导致酒店后台某组一个ID生成器的功能失效无法获取ID插入数据库失败。 值班同学找到相应的开发同学执行之前的预案切换到基于数据库的ID生成器发现不能解决当前问题有主键冲突。 值班同学经过分析临时修改数据库中的字段值修复问题。 从上面的例子可以看出业务方针对系统可能出现的异常情况虽然一般设有预案但是缺乏在大流量、有故障情况下的演练所以往往在故障来临时需要用一些临时手段来弥补预案的不足。 综上所述我们要有一套常态化的“故障演练”机制与工具来反复验证从而确保我们的服务能在正常情形下表现出正常的行为在异常状况下也要有正确、可控的表现。 这个服务或是工具能执行 容量与性能评估。故障演练进而进行依赖梳理、预案验证保证服务柔性可用。这样才能够做到在节假日与大促时心中有数在提高系统服务能力的同时增加开发人员应对与处理故障的经验。 下面以酒店后台switch研发组开发的“Faultdrill”系统为例向大家介绍一下我们在这方面的经验。 在压力测试以下简称“压测”和故障演练方面业界已有很多种实践。 压测 压测有单模块压测和全链路压测两种模式。 阿里双11、京东618和美团外卖都有过线上全链路压测的分享美团外卖的分享参见美团点评技术沙龙第6期回顾。 全链路压测有几点明显的优势 基于线上环境测出的性能数据准确相较于线下测试环境完备不存在单点、低配置等问题线上环境有完备的监控报警系统。但与此同时全链路压测也有较高的实践成本 需要有明显的波谷期需要清理压测数据或者申请资源构建影子存储真实流量难构造需要准备虚拟商家和虚拟用户需要有完备的监控报警系统。酒店业务模式和外卖/购物类的业务模式不太一样。首先没有明显的波峰波谷夜里也是订房高峰期你懂的因为没有明显的波峰波谷所以清理数据/影子表也会带来额外的影响。真实流量的构造也是一个老大难问题需要准备N多的虚拟商家和虚拟用户。 所以酒店最早推的是单业务模块级别的压力测试和故障演练大家先自扫门前雪。 美团点评内部的通信协议以Thrift为主业界的相关压力测试工具也有很多 JMeter作为老牌的压力测试工具通常作为HTTP协议的测试也可以通过自定义插件的方式实现Thrift协议的测试。TCPCopy的方式主要是关注“真实流量”。loading_test是美团点评内部的压力测试工具。|工具|使用方式|支持Thrift协议|流量来源|最小粒度| |-|-|-|-|-|-| |loading_test|在代码中依赖VCR包手动上传参数日志。需要loading依赖服务方的jar后重新发布|支持|真实copy线上流量|method级别| |JMeter|编写Thrift插件针对于接口|支持|需要自己构造|method级别| |TCPCopy|安装TCPCopy|支持|真实流量|端口级别所有流量全copy过来|-| 这几种方式都不满足我们的要求我们的要求是真实流量、method级别控制、操作简单。 所以我们准备自己造个轮子 :) 需求业务方低成本接入流量在集群级别AppKey级别AppKey相当于同样功能集群的唯一标识比如订单搜索集群的AppKey为xx.xx.xx.order.search以最低成本进行复制、分发以及最重要的在这个过程中的安全可控等等都是对测试工具、框架的潜在要求。 基于以上我们开发了流量复制分发服务。它的核心功能是对线上真实流量进行实时复制并按配置分发到指定的机器来实现像异构数据迁移一样进行流量定制化的实时复制与迁移。 借助流量复制分发服务进行功能和系统级别的测试以达到 容量规划。在稳定与性能保证的基础上尽可能的节约资源。核心链路梳理强弱依赖区分并做到服务之间松耦合。系统瓶颈。在真实请求流量加倍下暴露服务瓶颈点。故障独立容灾降级等等。故障演练 如果要演练故障首先要模拟故障我们不可能真跑去机房把服务器炸了。自动化的故障模拟系统业界已有实践如Netflix的SimianAmy阿里的MonkeyKing等。 美团点评内部也有类似的工具casekiller等等。 SimianAmy和casekiller设计思路相仿都是通过Linux的一些“tc”、“iptables”等工具模拟制造网络延时、中断等故障。这些工具都是需要root权限才可以执行。美团点评的服务器都需要使用非root用户来启动进程所以这种思路暂不可行。 这些工具都有一定要求比如root权限比如需要用Hystrix来包装一下外部依赖。比如我想制造一个表的慢查询、想制造Redis的某个操作网络异常就有些麻烦。 所以我们准备自己造个轮子 :) 需求业务方低成本接入流量以最低成本进行故障的“制造”和“恢复”无需发布、对代码无侵入就可以在后台界面上进行故障的场景配置、开启与停止。 基于以上我们开发了故障演练系统。它是一个可以针对集群级别AppKey级别的所有机器随意启停“故障”的故障演练平台。可以在无需root权限的前提下构造任意method级别的延时或者异常类故障。 我们的设计思路是 复制线上流量到影子集群。通过对同样配置影子集群的压测获得系统抗压极值。制造针对外部接口/DB/Cache/MQ等方面的故障在影子集群上测试降级方案、进行演练。 流量复制系统 架构设计中参考了DubboCopy的系统设计增加了一个SDK解除了对TCPCopy的依赖。 形成以下的流程 ① 需要压测方先依赖我们的SDK包在需要压测的具体实现方法上打上注解Copy并注明采样率simplingRate默认采样率为100%。 Copy(attribute CopyMethodAttribute.READ_METHOD, simplingRate 1.0f)
public Result toCopiedMethod() {
}② 正式流量来时异步将流量发往copy-server。 ③ copy-server根据流量中的信息interface、method、serverAppKey来获取压测配置影子集群的AppKey需要放大几倍。 ④ 根据压测配置对影子集群按照放大倍数开始发包。 协议分析 Thrift原生协议情况下如果你没有IDL或者注解式的定义你根本无法知道这条消息的长度是多少自然做不到在没有IDL的情况下对报文进行解析转发。感谢基础组件同学做的统一协议方面的努力让ThriftCopy这个事情有了可行性 :) 除了公网RPC接口使用HTTP协议以外美团点评内部RPC协议都统一为一种兼容原生Thrift协议的“统一协议”。 total length指定其后消息的总长度包含2B的header length消息头的长度消息体的长度可能的4B的校验码的长度。header length指定其后消息头的长度。 header里的内容有TraceInfo和RequestInfo等信息里面有clientAppKey、interfaceName、methodName等我们需要的信息。 client功能 应用启动时 客户端启动时首先获取copyServer的IP list异步起定时任务不断刷新这些IP列表。建立相应的连接池。初始化对Copy做切面的AOP类。 RPC请求到来时 命中切面先同步处理业务逻辑。异步处理下面的逻辑通过采样率判定本次请求参数是否需要上报到copyServer。通过当前的JoinPoint找到method和args再通过method找到相应的Thrift生成代码中的send_xx方法对连接池中的一个TSocket发送数据。以上便可进行流量的复制与分发在服务设计上Client端尽量做到轻量高效对接入方的影响最小接入成本低并且在整个流量复制的过程中安全可控。另外在Client当前针对美团点评使用的Thrift协议进行 流量染色。对原请求在协议层重写染色其中的clientAppKey和requestMethodName分别重写为”“和”${rawMethodName}_copy”在请求接收方可以调用特定方法即可判断请求是否是由“流量复制分发服务”的转发请求。读写标记。通过在注解上attribute属性标记转发接口为读还是写接口为后续的流量分发做好准备。负载均衡。支持服务端的横向扩展。采样控制。对流量复制/采样进行控制最大限度的定制复制行为。server功能 应用启动时 读取数据中存住的压测配置fromAppKey、targetAppKey、放大倍数。根据targetAppKeys去分别获取IP list异步起定时任务不断刷新这些IP列表。建立相应的连接池。 流量到来时 根据“统一通信协议”解包获取fromAppKey、interfaceName、methodName等我们要的信息。异步处理下面的逻辑根据流量中的信息interface、method、serverAppKey来获取压测配置影子集群的AppKey需要放大几倍。寻找相应的连接池。根据放大倍数n循环n次发送收到的ByteBuf。故障演练系统 我们的需求是可以集群级别AppKey级别而不是单机级别轻松的模拟故障。 模拟什么样的故障呢 |类型|故障表现| |-|-| |Thrift RPC |延时xxx ms或者直接抛出Exception| |mybatis mapper中的任意method|延时xxx ms或者直接抛出Exception| |Redis/Tair中的任意method|延时xxx ms或者直接抛出exception| |Kafka消息控制|模拟环境可能需要关闭消息生产/消费| |ES|延时xxx ms或者直接抛出exception| 我们调研了很多种实现方式 |方案|备注| |-|-| |基于各种Linux指令模拟故障网络/IO/Load|无法精细化模拟故障可操作性差并且受限于root权限很多操作无法进行或者无法自动化| |基于HystrixCommand|只能针对接入了Hystrix的接口且无法精确控制实现复杂| |基于AOP拦截|对象内部调用无法拦截非容器对象也无法拦截| |字节码注入|可以对各种目标进行注入扩展性高可以精细化模拟实现方案有基于classloader替换/Spring LTW/javaagent| 经过调研对比选定了基于javaagent进行字节码注入来实现对个目标对象的拦截并注入演练逻辑。 client功能 应用启动时 需要修改启动时的JVM参数-javaagent:WEB-INF/lib/hotel-switch-faultdrill-agent-1.0.2.jar 加载client包对RedisDefaultClient、MapperRegistry、DefaultConsumerProcessor、DefaultProducerProcessor、MTThriftMethodInterceptor、ThriftClientProxy等类进行改造。从远程获取设定好的相应的script比如“java.lang.Thread.sleep(2000L);”比如“throw new org.apache.thrift.TException(“rpc error”)”会有异步任务定时更新script列表。根据script的AppKey和faultType生成一个md值做为key。根据script的文本内容动态生成一个类再动态生成一个method固定名称为invoke把script的内容insertBefore进来。然后实例化一个对象做为value。将上面的key和value放入一个Map。目标类比如RedisDefaultClient的特定method执行之前先执行map里对应的object中的invoke方法。方法执行时 1. 执行之前查找当前的策略map中的对应object如果没有就跳过。 2. 如果有就先执行object中的invoke方法。起到“java.lang.Thread.sleep(2000L);”比如“throw new org.apache.thrift.TException(“rpc error”);”等作用。 server的功能 server的功能就比较简单了主要是存储用户的设置以及提供给用户操作故障启停的界面。 举个例子 |测试服务|sourceAppKey|targetAppKey|加压倍数|采样率| |-|-|-|-|-| |hotel-swtich-api|com.sankuai.hotel.sw.api.beta03|com.sankuai.hotel.sw.api.beta04|5|1.0| 本机单测调用beta03集群上的服务接口distributeGoodsService.queryPrepayList 5000次。 在目标集群beta04上收到此接口的25000次转发过来的请求。 多次请求观察CAT美团点评开发的开源监控系统参考之前的博客报表其中Receive为接收到的需要转发的次数Dispatch为实际转发数量。 开始模拟故障Redis故障、MTThrift故障。 请求接口控货的filter接口访问缓存故障前、后响应时间对比图 客户端设置超时1s接收到请求都超。 开启Thrift接口故障演练接口com.meituan.hotel.goods.service.IGoodsService.queryGoodsStrategyModel延时3s设置接口超时6s。 故障前后响应时间对比 这样就完成了一次加压情况下的故障演练过程随后就可以让团队成员按照既定预案针对故障进行降级、切换等操作观察效果。定期演练缩短操作时间降低系统不可用时间。 “故障演练系统”目前具备了流量复制和故障演练两方面的功能。希望能通过这个系统对酒店后台的几个关节模块进行压测和演练提高整体的可用性为消费者、商家做好服务。 后续“故障演练系统”还会继续迭代比如把忙时流量存起来等闲时再回放还有如何收集response流量进而把抽样的request和response和每天的daily build结合起来如何在故障演练系统中模拟更多更复杂的故障等等。会有更多的课题等待我们去攻克希望感兴趣的同学可以一起参与进来和我们共同把系统做得更好。 分布式会话跟踪系统架构设计与实践美团点评技术博客.基于TCPCopy的Dubbo服务引流工具-DubboCopy.从0到1构建美团压测工具美团点评技术博客.javassit.曾鋆2013年加入美团点评就职于美团点评酒旅事业群技术研发部酒店后台研发组之前曾在人人网、爱立信、摩托罗拉工作过。 海智2015年校招加入美团点评就职于美团点评酒旅事业群技术研发部酒店后台研发组。 亚辉2015年加入美团点评就职于美团点评酒旅事业群技术研发部酒店后台研发组。 孟莹2014年校招加入美团点评就职于美团点评酒旅事业群技术研发部酒店后台研发组。 最后发个广告美团点评酒旅事业群技术研发部酒店后台研发组长期招聘Java后台、架构方面的人才有兴趣的同学可以发送简历到xuguanfeimeituan.com。
