小结-后端系统的稳定性

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

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

稳定性.png

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

架构阶段

• 异地容灾目前只做到读多活，写还未支持（存储方案还不成熟）
• 异步化结合前端效果对系统的可用性有非常大的提升。这里要注意异步消费的幂等性，另外“丢”事件的回放消费做的不够标准
• 隔离性往往容易被忽视，真正当出了大问题才会被引起重视。重要的业务要在资源、部署上做物理隔离
• 避免单点，往往要求service服务做到无状态，有状态的要靠中间件（中间件一般比业务的稳定性要好很多）

编码阶段

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

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