滴滴如何做服务精壮性的？

曹乐是滴滴的高级技术总监，负责业务平台技术相关工作，之前在百度做分布式存储中间件相关工作，是一个标准技术出身的高管。930滴滴订单量达到了新高，但是滴滴的技术平台也因为高流量导致了一定的事故，导致了订单没有闯到最高。之后滴滴内部技术对930技术做了复盘，曹乐在内网发了一篇关于系统稳定性和精壮性的文章，技术群里有同学分享了文章，今天春哥叨叨就基于美团外卖解决流量高峰和曹乐讲的系统精壮性文章做一些评论。

930事故里好几个服务都被高峰流量打趴下了，看表象是以为流量预估不到位，机器资源不够，但其实背后是有深层次原因的，就是服务本身不够健壮，服务节点在短暂过载之后发生雪崩，进而引发重试风暴，如果这些服务是主流程服务的话，那么核心服务就会全系统的崩溃，也就是930事故的现象。

比如这种：

那条红色的横向的线是整个服务的一个可靠负载边界，但是由于网络抖动，造成了客户端的重试，进而造成了一波重试流量的流量高峰，别看这一点小的流量高峰，可能就是压垮骆驼的最后一根稻草，一个服务挂掉，进而流量负载到正常节点，这些节点流量继续增加节点宕机，最后一批节点不可用宕机，进而整个服务不可用宕机。

外卖这两年也出现过由于流量洪峰导致的比较严重的事故，逻辑类似，重试流量打的整个集群起不来，只能限流掉后续流量，但是限流是有损的，这个case是必然的了，就看最后损失有多少了。但是外卖好的一点是，这两年做了单元化，这样不会因为一个集群的宕机导致全部服务不可用，也就是可以保证3/4的流量是不会因为雪崩受影响的。

有的朋友说了，可以做多机房容灾啊？对的，这确实是个方案，但是实现远没有你提出这个问题那么简单，因为这个是系统而又精密的服务治理层面的事情。