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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 单机房容量受到了限制

2. 机房单点问题，造成系统可用性问题，进而造成经济损失

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

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

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

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

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

1. 延迟：响应时间

2. 流量：请求量，QPS

3. 错误：错误数，错误率

4. 饱和度：资源利用率

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

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

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

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

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

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

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

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

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

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

1. 新功能是否可回滚 / 是否可快速减少损失

2. 新功能是否可灰度，在技术角度和运营角度进行灰度

3. 是否可监控，包括技术指标，告警和运营指标，收益

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

1. 做好业务分析，需求评审，系统设计，容量规划，避免风险，SQL审核（是否加索引了）

2. 指定上线，发版的sop，做好流程制约和控制，提升自动化工具进行风险代码的扫描和检查

3. 做好code review，减少风险上线

4. 自动化用例覆盖，防止改新影响老业务

5. 提高自动化，工具化，避免人肉