美团点评智能支付核心交易系统的可用性实践

ver就会拒绝服务，对应到Nginx上返回就是502。如果你的服务是QPS较高的服务，那基本上这种场景下，你的服务也会跟着被拖垮。如果你的上游也没有合理的设置超时时间，那故障会继续向上扩散。这种故障逐级放大的过程，就是服务雪崩效应。解决方法：首先要调研被依赖服务自己调用下游的超时时间是多少。调用方的超时时间要大于被依赖方调用下游的时间。统计这个接口99%的响应时间是多少，设置的超时时间在这个基础上加50%。如果接口依赖第三方，而第三方的波动比较大，也可以按照95%的响应时间。重试次数如果系统服务重要性高，则按照默认，一般是重试三次。否则，可以不重试。1.4解决慢查询慢查询会降低应用的响应性能和并发性能。在业务量增加的情况下造成数据库所在的服务器CPU利用率急剧攀升，严重的会导致数据库不响应，只能重启解决。关于慢查询，可以参考我们技术博客之前的文章《MySQL索引原理及慢查询优化》。解决方法：将查询分成实时查询、近实时查询和离线查询。实时查询可穿透数据库，其它的不走数据库，可以用Elasticsearch来实现一个查询中心，处理近实时查询和离线查询。读写分离。写走主库，读走从库。索引优化。索引过多会影响数据库写性能。索引不够查询会慢。DBA建议一个数据表的索引数不超过4个。不允许出现大表。MySQL数据库的一张数据表当数据量达到千万级，效率开始急剧下降。1.5熔断在依赖的服务不可用时，服务调用方应该通过一些技术手段，向上提供有损服务，保证业务柔性可用。而系统没有熔断，如果由于代码逻辑问题上线引起故障、网络问题、调用超时、业务促销调用量激增、服务容量不足等原因，服务调用链路上有一个下游服务出现故障，就可能导致接入层其它的业务不可用。下图是对无熔断影响的鱼骨图分析：解决方法：自动熔断：可以使用Netflix的Hystrix或者美团点评自己研发的Rhino来做快速失败。手动熔断：确认下游支付通道抖动或不可用，可以手动关闭通道。1.发生频率要低之自己不作死自己不作死要做到两点：第一自己不作，第二自己不死。2.1不作关于不作，我总结了以下7点：1不当小白鼠：只用成熟的技术，不因技术本身的问题影响系统的稳定。2职责单一化：不因职责耦合而削弱或抑制它完成最重要职责的能力。3流程规范化：降低人为因素带来的影响。4过程自动化：让系统更高效、更安全的运营。5容量有冗余：为了应对竞对系统不可用用户转而访问我们的系统、大促来临等情况，和出于容灾考虑，至少要保证系统2倍以上的冗余。6持续的重构：持续重构是确保代码长期没人动，一动就出问题的有效手段。7漏洞及时补：美团点评有安全漏洞运维机制，提醒督促各个部门修复安全漏洞。2.2不死关于不死，地球上有五大不死神兽：能在恶劣环境下停止新陈代谢的“水熊虫”；可以返老还童的“灯塔水母”；在硬壳里休养生息的“蛤蜊”；水、陆、寄生样样都成的“涡虫”；有隐生能力的“轮虫”。它们的共通特征用在系统设计领域上就是自身容错能力强。这里“容错”的概念是：使系统具有容忍故障的能力，即在产生故障的情况下，仍有能力将指定的过程继续完成。容错即是Fault Tolerance，确切地说是容故障(Fault)，而并非容错误(Error)。1.发生频率要低之不被别人搞死3.1限流在开放式的网络环境下，对外系统往往会收到很多有意无意的恶意攻击，如DDoS攻击、用户失败重刷。虽然我们的队友各个是精英，但还是要做好保障，不被上游的疏忽影响，毕竟，谁也无法保证其他同学哪天会写一个如果下游返回不符合预期就无限次重试的代码。这些内部和外部的巨量调用，如果不加以保护，往往会扩散到后台服务，最终可能引起后台基础服务宕机。下图是对无限流影响的问题树分析：解决方法：通过对服务端的业务性能压测，可以分析出一个相对合理的最大QPS。流量控制中用的比较多的三个算法是令牌桶、漏桶、计数器。可以使用Guava的RateLimiter来实现。其中SmoothBurstry是基于令牌桶算法的，SmoothWarmingUp是基于漏桶算法的。核心交易这边采用美团服务治理平台OCTO做thrift截流。可支持接口粒度配额、支持单机/集群配额、支持指定消费者配额、支持测试模式工作、及时的报警通知。其中测试模式是只报警并不真正节流。关闭测试模式则超过限流阈值系统做异常抛出处理。限流策略可以随时关闭。可以使用Netflix的Hystrix或者美团点评自己研发的Rhino来做特殊的针对性限流。1.故障范围要小之隔离隔离是指将系统或资源分割开，在系统发生故障时能限定传播范围和影响范围。服务器物理隔离原则① 内外有别：内部系统与对外开放平台区分对待。② 内部隔离：从上游到下游按通道从物理服务器上进行隔离，低流量服务合并。③ 外部隔离：按渠道隔离，渠道之间互不影响。线程池资源隔离Hystrix通过命令模式，将每个类型的业务请求封装成对应的命令请求。每个命令请求对应一个线程池，创建好的线程池是被放入到ConcurrentHashMap中。注意：尽管线程池提供了线程隔离，客户端底层代码也必须要有超时设置，不能无限制的阻塞以致于线程池一直饱和。信号量资源隔离开发者可以使用Hystrix限制系统对某一个依赖的最高并发数，这个基本上就是一个限流策略。每次调用依赖时都会检查一下是否到达信号量的限制值，如达到，则拒绝。1.故障恢复要快之快速发现发现分为事前发现、事中发现和事后发现。事前发现的主要手段是压测和故障演练；事中发现的主要手段是监控报警；事后发现的主要手段是数据分析。5.1全链路线上压测你的系统是否适合全链路线上压测呢?一般来说，全链路压测适用于以下场景：① 针对链路长、环节多、服务依赖错综复杂的系统，全链路线上压测可以更快更准确的定位问题。② 有完备的监控报警，出现问题可以随时终止操作。③ 有明显的业务峰值和低谷。低谷期就算出现问题对用户影响也比较小。全链路线上压测的目的主要有：① 了解整个系统的处理能力② 排查性能瓶颈③ 验证限流、降级、熔断、报警等机制是否符合预期并分析数据反过来调整这些阈值等信息④ 发布的版本在业务高峰的时候是否符合预期⑤ 验证系统的依赖是否符合预期全链路压测的简单实现：① 采集线上日志数据来做流量回放，为了和实际数据进行流量隔离，需要对部分字段进行偏移处理。② 数据着色处理。可以用中间件来获取和传递流量标签。