3
0男生: 哈喽大家好欢迎收听，我们的播客。呃今天要聊的呢是关于广告推荐系统高可用改造的那些事啊包括我们怎么去。识别技术债务，怎么去解决他，以及怎么去避免他，再次发生。
女生: 听起来很有料，那我们就直接开始吧，直接进入主题，看看这个到底是怎么一回事。
男生: 第一个问题啊咱们先来聊一聊就是，广告推荐系统在改造之前啊，怎么去梳理？技术债务。
女生: 嗯，这个其实是非常关键的一步就是，我们在改造之前，嗯哼，我们的技术债务其实。主要集中在三个层面，一个就是架构设计上面的，服务之间的耦合非常严重。第二个就是代码层面的，有百分之四十的代码都是重复的。啊，比如说广告投放的规则在十二个不同的模块里面都有实现。然后还有就是配置层面的，就是广告位的参数是硬编码在二十多个文件里面的。有一次我们就是因为漏改了三处。就导致了一次百万级的广告曝光的排版错乱。
男生: 听起来确实挺触目惊心的，那这些问题都是怎么被揪出来的呢？
女生: 这个就是我们当时是发动了全团队的力量，嗯哼，就是开发，去检查代码里面的缺陷。然后测试呢，去跑我们的流程，看看有没有什么断点。运维呢，去排查我们部署上面的一些隐患。最终我们是梳理出来了七十八项技术债务。我们又用这种，热力图的方式。标出来了其中二十一项是高危的，我们就有了这个，就像是我们的病历本一样的，我们的问题清单，我们就可以有针对性的去解决他们。
男生: 这些技术债务，具体是怎么被消除掉的呢？
女生: 架构上面的我们就是，用了一个老商场改造的一个策略。就是我们先搭建了一个 API 网关，嗯哼，作为我们的这个流量的入口。然后呢我们再一点一点的去拆分我们的模块。啊，这个过程当中我们是有一些原则的，比如说我们不会一下子就拆的特别细。我们会用百分之一的流量去验证我们的这个核心链路有没有问题。我们也会保证我们的用户体验是不会降级的，比如说我们的响应时间。一定要控制在一百毫秒以内，等等吧。我们也有一些，别的团队就是因为拆的太激进了，导致他们的广告加载时间从一百毫秒。延长到了五百毫秒，用户投诉直接翻了一倍。
男生: 看来这个架构改造还是挺有挑战的，那配置和代码层面呢？
女生: 配置层面的我们就是引入了分布式配置中心。嗯哼，然后把我们两百多个广告的参数全部都统一管理起来了。啊，这个其中有一个核心的业务就是广告的尺寸。这个参数我们之前是散落在四十个文件里面的。我们光梳理这个映射关系就花了三天的时间。但是做完了之后呢我们的这个参数更新。从原来的四个小时的人工操作。缩短到了秒级，同时我们的错误率也从百分之十五。降到了百分之零点三。代码层面的就是我们提取了公共的组件库。我们也在我们的 CI/CD 的流程里面加了一些检查。如果你的新增代码里面重复代码超过了百分之五。你是没有办法提交的，就通过这种方式来，防止我们的代码质量下滑。
男生: 怎么能够保证这个广告推荐系统，不会再出现类似的这些技术债务，或者说不会再出现一些潜在的问题呢？
女生: 这个就是我们会每个月去做一些故障演练。嗯哼，比如说我们会，故意的去拔掉我们服务器的网线。然后我们会有一个，故障四步法。就是发现，止损。根因，优化。我们会有这么一个四步法，比如说我们之前有遇到过缓存雪崩。这样的问题，那我们后来就是通过这种。随机化过期时间，加上热点数据永不过期。这样的一个策略彻底的解决了这个问题，那我们在演练的过程当中就会去验证这些策略是不是还生效。
男生: 这个广告推荐系统，经过这次改造之后，具体都有哪些成果呢？
女生: 我们的系统可用性从百分之九十九点五。提升到了百分之九十九点九八。嗯哼，然后我们全年的故障时间从七点五小时。减少到了四点三小时。最重要的是我们团队从一个天天救火的。状态变成了一个可以去做长期规划的状态。大家又重新变成了架构师。
男生: 那今天我们就聊了这么多关于广告推荐系统，是如何通过梳理技术债务。然后进行架构解耦，配置治理和代码重构，建立了这种长效的保障机制。最终实现了这个高可用的改造的这样一个全过程。
女生: 以上就是这期播客的全部内容啦，然后感谢大家的收听，咱们下期再见拜拜！
