小结-后端系统的稳定性

“五一”五天假期可够长了，闲暇之际，想想写点东西。我负责的社区和一些平台项目，对系统的稳定性要求特别高（去年也是出了几次小的事故），今天总结下近一年的稳定性这块工作。

宏观上，从研发的流程上去看稳定性。

稳定性.png

整体思路是这样，分别就几个阶段谈一下痛点和心得。

架构阶段

• 异地容灾 实现了机房级的容灾。目前只做到读多活，写还未支持（存储方案还不成熟）
• 异构降级 对于非常重要的功能，防止空窗，可以考虑异构实现去降级，比如把整个请求kv存起来。对大多数互联网业务是能满足基本体验要求的。
• 异步化结合前端效果对系统的可用性有非常大的提升。首先异步化的前提条件当然是不要求强一致，在涉及金钱等业务可能不适合。举个例子，发评论依赖内容过滤、依赖主库，那么异步化后可以满足延迟写入但不丢失。前端提交后本地显示，用户无感。这里要注意异步消费的幂等设计，另外，出现Error后的重试和补偿机制也要注意。
• 隔离性往往容易被忽视，真正当出了大问题才会被引起重视。重要的业务要在资源、部署上做物理隔离
• 避免单点，往往要求service服务做到无状态，有状态的要靠中间件（中间件比业务的稳定性要好很多）

编码阶段

• 最最重要的一点是，“对95%的研发同学来说，能不要自己实现的，尽量走统一的框架或者lib”。我们实现了很多通用的lib或者sdk，比如缓存代码、并发调用、job merge等等。当然这里如果有必要是需要提供新的service服务的。
• 分布式限流 对于网关来说，一般做到按业务去配限流额度。对于资源的限流控制粒度有时候比较繁琐，比如mysql的访问，如果要做到sql级限流是比较麻烦的。
• 依赖治理也是个挑战，Everything fails。这块一般会非常业务，需要项目研发owner主动去梳理并且理解业务。套用老板的一句话，“别人都炸了你要还能活下来”，这样的标准去思考、去治理依赖、去容错。
• 熔断 熔断是指下游依赖业务出现系统负载，应对减少访问流量、慢慢恢复流量，避免雪崩。不然系统很容易被“打”的起不来。
• 超时 之前的文章也提到过，合理的超时配置配合降级，才能不容易出现“木桶短板”

其他几个阶段就不细谈了。只简单说下对线上的问题case，研发人员要求追根究底，才能防微杜渐，更是一次实战提升技术的好机会。举一反三，则是更上一层的要求了，怎么后续规避，如何从框架层、规范标准、协议等层面去解决。也有的时候是反推产品。