中通快递的云原生改造之路
Posted 架构头条
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了中通快递的云原生改造之路相关的知识，希望对你有一定的参考价值。
2019 年 11 月 12 日，中通快递迎来了 2019 年的第 100 亿件快递订单，成为中国乃至全球第一家年业务量破百亿的快递企业。彼时，中通快递股份有限公司董事长赖梅松向全网发出内部信，表示要将 100 亿归零为新的起点。并告诫中通人要保持艰苦奋斗的创业精神和清醒的头脑。
一年后的 9 月，中通快递赴港二次上市引起业内热议，在残酷的价格战竞争中，其净利润依然是“四通一达”（中通、圆通、申通、百世汇通和韵达）之首。如此业绩，在招股书中归结为降本增效和业务增长的功劳。其中降本增效包括“提升高运力自有车辆的使用率、数据化管理运营能力... 通过数据分析，提高了路线规划效率，缩短了运货时间... 提升自动化水平来提高工作效率、降低返工成本”等举措。可见，降本增效措施的背后不仅仅是密集的劳动力和车辆的堆砌，更多是运用了众多成熟的科技能力。
其实，早在 2017 年，中通就提出了要做容器化基础设施的构想，并且专门从 IBM 挖来了当时 IBM/EMC 的云计算大牛黄凯（目前云平台技术总监）主持容器化改造。时至今日，中通的技术平台已经从单纯的容器化改造升级到云原生改造，并取得了诸多业内领先的实践成果。
近期，InfoQ QCon 北京站邀请了中通云高级架构师 杨小飞 出席演讲。小编趁此机会做了主题为 “中通的云原生改造之路” 的专访，一窥快递业巨头的数字化转型方法论与实践探索。
InfoQ：作为行业巨头，中通快递云原生落地的负责人，您在网络上的资料很少，先请您介绍一下自己吧？
杨小飞： 我叫杨小飞，曾在华云，新致云等公司任职架构师。2019 年加入中通，在 DevOps 团队，现任中通云高级架构师。从 2014 年开始，我就一直专注于云计算和周边技术的研究，积累了大量 IaaS 和 PaaS 层的实战经验。同时，对 AI，边缘计算等领域有深刻理解。
目前在中通负责云服务平台 IaaS 与容器以及边缘计算相关的产品设计与规划。关注云原生架构在亿级业务系统的落地与实施，以及整体转型，尤其对 ServiceMesh 以及 Istio 等颠覆架构的发展感兴趣。
InfoQ：云原生是当下的热门话题，但各路玩家对云原生的理解不同。中通快递怎么定义云原生？
杨小飞： 很多人把云原生简单地理解为采用开源（K8s+Docker）进行容器化，但这是偏狭隘了。我认为云原生其实是继 SOA/ESB 数据总线、SpringBoot 等微服务架构之后，在架构领域的第三次革命。
之前轰轰烈烈的云计算是基于 IaaS 实现的虚拟化，虽然从灵活性和可维护性上已经比上一代提高了一个等级，但这些对业务架构都是不透明的，那么非运维团队就不敏感。
自从引入了容器化架构之后，整个架构的思考方向彻底变了。嵌套在臃肿的 SDK 或者框架中的诸如日志、监控、压测等组件瞬间解放出来，整个业务系统变“轻”了很多，DevOps 真正从概念走进了现实生活。
工程师们发现应用的发布、迭代、迁移再也不需要借助各种流程、制度、规范来控制，运维也完全摆脱了平台绑定。敏捷发布、蓝绿持续迭代和运维自动化，甚至 AIOPS，瞬间起飞。再有底层 IaaS 云平台的虚拟化加持，弹性伸缩、动态调度、热点打散等等，原先需要资深架构师苦思冥想、精雕细琢的设计一下子走入了“民间”。
中通快递，对于云原生的需求其实是非常迫切的。首先，我们有上百个业务系统，海量微服务，支撑着亿万级的交易量。中通的开发、运维同事每天无不是如履薄冰，因为稍有不慎就是 F1 故障，一个发布不当或者小小 BUG 带来的就是数十万的损失。所以，我们从高层领导往下，一开始就坚定地走云原生升级的道路，无论什么困难和理由，都不会让步。
之所以做这样的抉择，首先我们认为这是一劳永逸的事情。之前的一些历史包袱（例如 SDK 存在多个版本，升级困难），也可以通过架构升级彻底甩掉。另外，通过云原生改造，我们享受到了容器的高密度部署和智能化调度所带来的好处，资源利用率在不断提升，包括刚才说的开发效率出现了质的飞跃。
InfoQ：对于快递行业而言，有哪些典型场景适合云原生落地？
杨小飞： 可以说，云原生的概念直接击中了快递行业的每个痛点。首先，我们整个研发中心是以业务系统为重心的，不可能像互联网企业那样招募很多技术大牛，开发专属的技术中台和大神级框架，但是，我们的业务量又是海量，高峰时期的流量丝毫不弱于互联网企业，而且我们的终端类型涵盖了软硬件，业务形态从线下到线上，很多业务高峰还是半夜，可以说是“没有公主的命，却得了公主病”，云原生平台恰好可以很大程度上缓解这个矛盾，。
打个比方，我们的中台业务，订单轨迹，开放接口等都是海量 QPS，大起大落也很常见。往往碰到大促或者突发事件，我们的架构师都要提前 1-2 月做流量预估、版本降级预案和服务器冗余待命。而在云平台上，都是根据监控自动扩容缩容，蓝绿发布也非常轻松，架构师不用带着黑眼圈上班了。同时一些辅助部门，例如安全、测试，原来想要做一些网络策略或者压测，协调起来非常麻烦，需要到各个业务线求爷爷告奶奶升级或者打包到各个业务系统代码 SDK 中，或者安装 agent，现在他们通过 CNI 和 Sidecar，可以无感知地植入。还有就是边缘计算业务，也可以平行升级自己的模组，这不就是云原生本来的样子嘛！最后，我们几万个网点，很多当地的架构还是集中式的，这一块也是非常适合使用容器平台作为底座的。
InfoQ：云原生的提出已经快 10 年时间了，中通快递什么时候开始探索云原生实践？当时基于怎样的背景？
杨小飞： 其实我们的 CTO 早在 2017 年就提出了要做容器化基础设施的构想，也专门从 IBM 挖来了当时 IBM/EMC 的云计算大牛黄凯（目前云平台技术总监）主持容器化改造。但是当时因为业务高速发展，我们很多精力都投入到业务系统建设中去了。
现在，我们的各条业务线逐步成熟，K8s 的周边生态也丰富了很多，而且前面各大互联网公司（蚂蚁金服、美团、携程……）也探索了一套完整的云原生方法论，技术风险降低了很多，于是研发中心决定快速跟进，全面拥抱云原生。
回头来看，当时保持观望的策略是对的。当时一些同行采用了 Swarm、OpenShift 的方案，现在又要推翻转到 K8s，反而是起了个大早赶了个晚集。而且，真正的云原生架构拼图是 2020 年上半年才初具原型，例如 Cilium、Istio 等都要内核在 4.10 以上，K8s 在 1.20 以上才基本具备生产投放的成熟度。这些在当时都还不成熟，很多公司做的事情仅仅是架构容器化，跟得太早，精力全被用在填坑了，出来的东西也是四不像。
InfoQ：刚开始探索云原生落地实践时，中通快递对云原生的落地收益有怎样的期望？
杨小飞： 其实当时我们的初心蛮简单的，就是把虚拟化改成轻量级的容器，也算做一个技术尝试，更多的是为了配合 DevOps，把我们的发布系统做得敏捷一点。但是，后来发现"It's bigger than bigger"，我们的格局还是小了。
首先越来越多的部门找到我们，想把自己原来的东西“外包”到云平台上，一来二去，我们发现，咦，这不就是外面说的云原生吗？于是我们索性单独成立了一个“云平台”部门，就专心整云原生这点事。其他部门的一些研发和架构，也经常向我们讨教这块的知识，我们也在内部做了好几期培训。
说到整体收益，我们其实并没有一个很量化的目标。但是例如整体产研效率提高、通过容器化部署节约物理机资源用量、和多环境快速生成，这些都是水到渠成的事情，我们埋头做事就是了。我们更关注的，是基于我们的人员水平和架构现状，定制出一套适合中通研发体系的方法论，不光是框架，还包括流程、制度、标准、甚至组织架构……容器平台仅仅是这辆车的四个轮子而已。从集团来看，最好是能 1 个人 2 天完成以前 2 个人要做 3 天事。这一点要求，我觉得是可以期待的
InfoQ：实际落地过程中，中通快递利用云原生解决了怎样的业务需求？具体场景有哪些？
杨小飞： 首先当然是解决产研效率问题，落地到像 QPS 波动比较大的场景，比如订单轨迹，消息推送等，然后整体上云是趋势，中通这块相比其他物流公司也要保持竞争力。
InfoQ：中通快递落地云原生的过程中都遇到过哪些困难？如何克服的？
杨小飞： 困难分技术内的，和技术外的。
首先，在技术层面，我们的系统内核，稳定性和安全性是第一要求，所以 Linux 和 Docker 的版本都偏老，许多新的特性，一时半会无法应用（例如 Istio），那我们就要做一些折中方案，不能一直等。另外，就是我们的网络环境，因为一些历史因素，比较复杂，不能按照理想的架构搭建，有时要兜几个弯，当然这个随着数据中心迁移会慢慢地解决。
此外，我们的业务同事，会提出一些反模式的需求，例如固定 IP，热点集中，和 IPVS 延后上线，这些其实多多少少和云原生的倡议是背道而驰的，但是因为人员的知识水平以及管理方式所限，我们还不得不对我们的 K8s 平台修修补补，让鱼与熊掌都可兼得。
技术之外，就是云原生的技术发展太快，而团队和公司知识水平跟不上。现在市面上对云架构师的需求很迫切，我们云平台的成员都已经这块的专家了，但是还是要一边不停地学习、不停地配合架构师做实施，恨不得可以分身。
我们不像互联网企业，可以养一个庞大的基础架构团队。就只能在有限的编制内，通过逼迫自己一专多能，同时借助社区力量，来跟上技术的步伐。另外，整套 DevOps 流程，是环环相扣的，我们也要时不时停一下，等等其他部门的管理框架跟进。
InfoQ：目前中通快递落地云原生产生了哪些收益？是否有意外惊喜？
杨小飞： 预期的人和机器效率提升都实现了，同时创造了更多云原生技术方案，也跟社区走的更近，跟外界互动更加频繁，提高了团队整体的学习能力和速度。
意外的惊喜，就是我们在做边缘计算的时候，发现可以和数据中心采用同一套 K8s 平台，这大大节省了我们的设计成本和管理成本。另外就是，我们的 CPU 集群和 GPU 集群的管理具备很大的同构性，未来大一统的集群平台非常可期。这也要感谢我们自己前几年在微服务上花的大力气，让云原生有了比较好的启动基础，所谓“行百里者半九十”。
InfoQ：未来，中通快递还有哪些落地云原生的计划？
杨小飞： 我们的第一步是要把生产环境中的无状态应用全部实现容器化，应该今年就可以完成。接下来我们会逐渐把中间件数据库等一些有状态的服务也容器化、例如 Spark、TiDB 等，它们都已经发布了容器化的版本，只是现在还没有大面积铺开。
另外，我们以前自研了很多调度系统（甚至包含 Hadoop）也可逐步使用 K8s 统一调度。最后就是边缘场景，目前也在结合我们自研的 ZCLOUD-NANO 的 KVM 方案逐步使用容器来做分布式调度。
总之，未来想象的空间很大，每个场景都等着我们落地，但是我们团队人手太少了，我们只能把最重要、最易于实施的先做起来。
InfoQ：有人提到云原生的未来主要看 K8s，Service Mesh 和 Serverless 的发展，最终将从资源云化到业务云化，您怎么看？
杨小飞：K8s 的确是划时代的一个产品，ServiceMesh 也是大势所趋。不过 Serverless 我们还要观望一段时间。但我基本认同最终都会走向服务网格，按业务切微服务，寻求最佳语言实现。剩下的事情交给业务云。我们现在就是多语言环境，多套 SDK，未来一定会做到语言无关 /SDK 无关。
InfoQ：近两年快递行业涌现了不少黑马，如极兔、安能等，这些公司的在技术方面是否有可圈可点之处？
杨小飞： 极兔是黑马还是野马，这个要时间来证明，技术这种东西，是需要有积累的，即便是用公有云，架构上也要全盘考虑，有些时候抄捷径并不能走得很远。
安能和韵达最近牵手比较紧密，技术方面会不会有一些整合目前不太清楚。三通一达里面，我们对自己的信心还是很大的，因为我们从一开始就走自力更生的自主研发路线，虽然不是走得最快的，但是我们的技术底蕴会越来越深，可以支撑业务系统做得更大，走得更远，而且我们团队的成员也是各个独当一面。
8 月 20-21 日，InfoQ 首场 PCon 全球产品创新大会落地北京。大会共设置 10 个专题，涵盖优秀产品及运营发展所需了解的管理、运营、设计、能力培养等多个方向相关内容，还包括现象级产品背后的精彩故事，以及产品经理成长过程中的经验分享，值得希望未来在产品道路上更好前进的你了解学习。
目前大会 8 折报名优惠阶段，点击 「阅读原文」 查看更多大会信息。有兴趣的同学欢迎联系票务小姐姐：17310043226（微信同号）。
点个在看少个 bug 以上是关于中通快递的云原生改造之路的主要内容，如果未能解决你的问题，请参考以下文章