逆风前行阶段

架构优化的事情先不提单说说容器化，借着这次技术架构的调整，容器化终于有了明确性的开展方向，6个月将公司一个最核心业务系统重构完毕，并支撑生产 100% 的业务量。可以说机遇与挑战并存，性能是否会成为瓶颈？业务理解是否会出现出入？平台自身是否会出现灵异事件？



你踩的每一个坑都是当年决策时脑子进的水

决策一：linkerd

说起 linkerd 可能现在有些落寞了，但是早在2017~2018年，那也是一款风生水起的产品，因为 linkerd 的出现开启了 service mesh 的篇章，当时我们选择 linkerd 更多的是看中 linkerd 当时作为服务网络的智能路由算法，以及其熔断的能力，经过反复测试发现虽然 CPU 占用较大，但是性能还是有一定保障的。就这样将其上线了，可正式上线后经过长时间的业务积累发现，为了保障 linkerd 的服务稳定，必须定期的重启 linkerd，经过详细排查发现 linkerd 底层使用 finagle 框架存在内存泄露的 bug，按我们当时的业务量大约每个月都要重启一遍，定位了故障，这也倒不算大问题，而真正抑郁的是公司一直以来使用的调用链 APM 组件 pinpoint 并不支持 linkerd，经常在延迟排查过程中在调用链中看到有 gap，但是无法定位是业务应用延迟还是 linkerd 延迟导致的，每次出现故障，必须我们这些熟悉平台的人员配合排查调用链出现 gap 过长时，linkerd 的 cpu、内存等资源情况，以此来类推是否是受到 linkerd 的影响导致的延迟。可以说这个决策当时是一个很大的设计失误。