拆解交易系统--服务稳定性

交易系统承担了整个交易链路上的所有交易相关的流量，同时交易系统上时常会组织一些营销，大促相关的活动，所以需要面对着因大促造成的瞬时流量激增的情况。

所以如何做好服务拆分后的交易系统稳定性也就尤为重要。

主要方式一般是：自动预案，限流保护。

当我们对系统进行了微服务拆分之后，服务之间有了良好的边界，可以有效的进行服务故障隔离，防止因雪崩造成的系统崩溃。

而针对于流量激增情况时，系统会有什么表现呢？

流量激增时会伴随着因激增流量造成的系统CPU / Load的飙高，机器告警频繁。

一些热点商品缓存可能会被击穿，如果系统依赖于MQ进行通信，可能伴随着消息积压，处理延迟。

限流是面对瞬时流量激增的通用方案，在商业大促和社会化爆点新闻相关的系统中都会用到，同时也是系统常态下有效的保护手段，在因系统面对大于自己所能处理的流量时，先拒绝为敬。

在进行限流操作之前，我们需要考虑限流的目的是什么？是采用单机限流，还是集群限流？限流的资源有哪些，网关？应用？DB？水位线怎么来的？限流阈值是多少？

拒绝处理上有两种方式，主动拒绝，或者降级到请求队列，总之是防止因为超预期的流量将系统打垮。

限流可以保护服务永远处理自己承受范围之内的流量，起到自我保护作用。

但是在一个链路过长的交易系统中，势必会有一些系统因各种原因不能很好的服务于链路请求，这种情况可以依据系统优先级，在系统稳定性受到挑战时进行降级，而确保核心路径不受影响。

系统对于降级常见的处理方式有两种：手动降级，自动降级。

手动降级一般是配置一个降级开开关，在需要的时候进行降级开关的操作。

为了可以更好或是更有效的控制系统降级，建议还是采用自动降级方案，因为他更有效，更适合于链路上的真实情况。

自动降级是基于熔断手段，采集时间窗口内服务的调用情况，调用失败 / 成功次数，依照失败率而操作是否进行自动降级。

做降级处理之前，我们需要考虑，系统接口之间的依赖关系，是强依赖还是弱依赖？哪些功能，服务可以降级掉？是否需要通知PM制定一定的话术？采用自动熔断还是手动熔断？哪些服务在降级之后需要做兜底操作？如何做兜底？

所以限流是一种主动干预流量，防止系统打挂，熔断降级是防止因运行时各种不稳定因素造成的系统超时等待，指标飙高，防止故障级联传导的防御措施。

当然具体系统或是业务中哪些环节，哪些接口需要做降级处理，是需要提前梳理的，千万不要轻易对核心流程做降级，因为毕竟是有损的。

在设置了降级措施之后，需要做相应的压测或故障注入，以确保降级，限流策略有效，而不至于真实情况发生时防御策略失效，造成系统可怕的结果。

系统可用性中很重要的一个点就是防止单点。

单点的系统永远存在可用性风险，小到主从数据库，数据多副本，多无状态服务，多机房，异地容灾，如果要求登记很高的金融场景，比如支付宝，则需要做到三地五中心的异地多活架构。

为什么要搞异地多活呢？业界无外乎以下原因：

一个成熟的互联网架构体系，需要具备多层次，多维度，端到端的完备的监控体系。

健康检查是监控体系中很重要的一个环节。

主要实现方式可以是服务端轮询和客户端主动上报两种方式。

两者各有优缺点，Mysql服务这种无法主动上报，除非借助于三方代理，但是主动的端口健康检查也很难识别进程假死的情况。

健康体系，谷歌提出来四项黄金指标：

云原生时代监控体系的实现往往是通过应用 / 节点暴露端点，监控服务采用pull方式采集指标，比如prometheus监控系统最近比较火。也可以借助前面文章中提到的agent上报到服务端。

监控能力提升之后，告警系统能力也很重要，在阈值配置之后，告警触发极其灵敏度就很重要，阈值太高太低都不合适。

为了有效进行故障定位和快速处理，对现有服务依赖进行梳理就显得尤为重要。

好的服务依赖关系可以帮助我们快速定位问题，快速进行容量评估，减少资源浪费，友好的链路追踪。

如果服务之间，在其中一个可用性受到威胁时，传递到另一个系统上，并影响其可用性，则两个服务之间就是强依赖。

如果其中一个故障，另一个不影响主流程或核心流程，则两者是弱依赖。

梳理好系统之间的强弱依赖，可以更好的配置降级，限流阈值。针对于弱依赖的服务可以直接降级掉，或者返回兜底默认值。

上面说了系统稳定性的宏观层次，限流，熔断，降级，以及单点问题。其实稳定性很大一部分程度是需要在工作流程和工作方式上展开的。

比如你的代码或者新需求，是否可以做到快速回滚，快速应急处理降低损失。

简单总结下来可以从下面几个角度分析：

反推回来，我们需要在团队执行上落地一些做法和手段，比如：

0 人点赞