2023年底的技术瓜越来越多，一方面大厂互联网等降本增效去除了许多技术人，另一方面阿里云崩溃三个半小时，滴滴崩溃近七个小时。未来互联网与现实生活的重合度越来越高的背景下，还有再出现这种事情吗？
阿里云导致托管企业服务将无法使用，滴滴则导致超千万单和超4个亿的交易额损失。
滴滴的技术
在2023年10月份能看到滴滴官方公众号出了一篇文章《万字详解滴滴弹性云混部的落地历程》，文章描述了滴滴从2017年以来投入了云原生技术的怀抱，采用了混合云的方式，网传滴滴使用了 1.12 的k8s版本，那么可以认为滴滴在近乎一两年的时间内将混合云的基础架构搭建好，并且之后在版本号这一块就没有去变动。
没有无缘无故的爱，我猜想滴滴发了这么一篇文章，公司内部应该有相关的任务在进行中，结合降本增效的背景，很有可能是打算在技术架构的层面上也来上这么一招，现在现实狠狠打脸了。
详细地分析一下滴滴的架构，看出来在paas以下层做了一些优化。包括去性能干扰、重调度等。
阶段一，资源竞争
资源混部带来的第一个挑战是资源竞争，这里包括计算资源、网络资源等等的竞争，那么就会带来请求缓慢等一系列问题。
在集群上提供了两种机制来应对资源竞争的问题，一个是容器调度机制，一个是集群扩缩机制。当这两个机制同时存在并且运行了一段时间的动态变化后，我们会发现集群的单台主机之间承担的性能负载往往不均衡，容器调度机制往往是挑选node节点，两种机制都是对单个pod的处理调度机制，那么在整体上的性能一定会变得极端不均衡，明显缺少了一种定期的全局均衡调度方式。
因此滴滴引入了重调度服务，通过对集群定期巡检发现上述场景中不再合理的调度决策，触发调度器重新进行调度，从而使得集群整体的系统资源分配更合理。
在上图中可以看到通过监控获取集群整体的状态，使用kube-better计算调度策略，找到宿主机和pod容器，调用调度器进行对应的调度。
之后能够发现集群的 cpu 使用水平在 50% 左右，这是调度的结果意味着在任一节点上没有挂上过重的负载，而是所有的节点保持在一个平均的水水准。
阶段二，进一步压榨性能
滴滴的业务和性能明显呈现潮汐特征，为了更加利用低峰时期的节点性能，使用在离线混部方式。
增加了三个能力。一是单机的资源能力，在在线和离线业务都同时存在的情况下， 依然需要保障在线业务能够正常使用，如内核级机制的隔离策略选择以保障cpu的任务优先级等。二是构建出全局视图，能反映出全混部场景下的多个维度的资源情况。三是混部的调度能力，基于前二者和时间段进行调度作业。
此时的离线业务明显已经填补了低峰时刻业务的节点负载。
阶段三，隔离集群压榨性能
隔离集群用于放置高敏感的业务。滴滴用同样的思路进行性能的进一步利用。
k8s升级
网传滴滴从k8s1.12到k8s1.20的升级导致了大量pod失败，在《滴滴弹性云基于 K8S 的调度实践》 一文中也提到了两种升级方式的对比，所以很显然升级计划在这篇文章中透漏无疑很有可能是滴滴内部计划从k8s1.12到k8s1.20的总结梳理。
在该文章中提及的内容，都是升级中需要重点考虑的内容。
因此我尝试下对分析了升级中需要的一些考虑事项。
事前
k8s的能力变更，比如网络策略、调度策略等是否兼容。
k8s1.12至k8s1.20的api特性变更，因此需要对chart、自研发的kube-better、kube-odin、画像计算等重调度这些服务都进行一定程度的兼容性改造。
单机的变更，由于容器技术不同等，可能需要对内核依赖进行调整。
事中
进行原地升级的流程方式也有挺多，如果选择的是直接逐个升级k8s master节点我感觉难度真的很大。
事后
备份方案B，如果升级出现失败的可能性的话，那么如何保证在线业务正常。
网传官方复盘
网传的复盘原因如下。
老实说如果是由于协议不兼容而导致这次故障，真是离大谱，那现实真的是魔幻。
如果这是真的那么至少反映出几个问题：
- 真懂技术的人缺少话语权。
- 不了解底层。
- 没有经过事先测试。
滴滴这么大的公司，这让我想起最近流行的一句话，“真的很多人很水的”，哈哈当然我也是其中之一。
对业务的影响和启示
滴滴的业务主要就是打车，根据微博反馈发现了如下问题：
- 网络加载异常，无法排单；
- 数据紊乱，一个订单被派到 4 个司机订单中；
- 数据展示、数据状态有误，订单取消、订单支付都出现问题；
- 排单逻辑出错，司机接单到 两千公里以外的单；
- 订单流水出错，8 公里显示收费 1540 元；
- 整体问题，连带滴滴、小桔充电、滴滴加油、青桔单车都出现问题；
- 滴滴内网问题，员工无法正常使用内网相关服务；
服务故障短期来看最直接导致的影响就是年交易量下降，产生大量支付上的问题。其中是否会有一些错误数据也不好说。
长期来看，除了滴滴之外的服务商则成为了受益者。
