2019 年 11 月 12 日，中通快递迎来了 2019 年的第 100 亿件快递订单，成为中国乃至全球第一家年业务量破百亿的快递企业。彼时，中通快递股份有限公司董事长赖梅松向全网发出内部信，表示要将 100 亿归零为新的起点。并告诫中通人要保持艰苦奋斗的创业精神和清醒的头脑。
一年后的 9 月，中通快递赴港二次上市引起业内热议，在残酷的价格战竞争中，其净利润依然是“四通一达”（中通、圆通、申通、百世汇通和韵达）之首。如此业绩，在招股书中归结为降本增效和业务增长的功劳。其中降本增效包括“提升高运力自有车辆的使用率、数据化管理运营能力... 通过数据分析，提高了路线规划效率，缩短了运货时间... 提升自动化水平来提高工作效率、降低返工成本”等举措。可见，降本增效措施的背后不仅仅是密集的劳动力和车辆的堆砌，更多是运用了众多成熟的科技能力。
其实，早在 2017 年，中通就提出了要做容器化基础设施的构想，并且专门从 IBM 挖来了当时 IBM/EMC 的云计算大牛黄凯（目前云平台技术总监）主持容器化改造。时至今日，中通的技术平台已经从单纯的容器化改造升级到云原生改造，并取得了诸多业内领先的实践成果。
近期，InfoQ QCon 北京站邀请了中通云高级架构师 杨小飞 出席演讲。小编趁此机会做了主题为“中通的云原生改造之路”的专访，一窥快递业巨头的数字化转型方法论与实践探索。
1
云原生是继数据总线，微服务之后的架构领域的第三次革命
InfoQ作为行业巨头，中通快递云原生落地的负责人，您在网络上的资料很少，先请您介绍一下自己吧？
杨小飞我叫杨小飞，曾在华云，新致云等公司任职架构师。2019 年加入中通，在 DevOps 团队，现任中通云高级架构师。从 2014 年开始，我就一直专注于云计算和周边技术的研究，积累了大量 IaaS 和 PaaS 层的实战经验。，对 AI，边缘计算等领域有深刻理解。
目前在中通负责云服务平台 IaaS 与容器以及边缘计算相关的产品设计与规划。关注云原生架构在亿级业务系统的落地与实施，以及整体转型，尤其对 ServiceMesh 以及 Istio 等颠覆架构的发展感兴趣。
InfoQ云原生是当下的热门话题，但各路玩家对云原生的理解不同。中通快递怎么定义云原生？
杨小飞很多人把云原生简单地理解为采用开源（K8s+Docker）进行容器化，但这是偏狭隘了。我认为云原生其实是继 SOA/ESB 数据总线、SpringBoot 等微服务架构之后，在架构领域的第三次革命。
之前轰轰烈烈的云计算是基于 IaaS 实现的虚拟化，虽然从灵活性和可维护性上已经比上一代提高了一个等级，但这些对业务架构都是不透明的，那么非运维团队就不敏感。
自从引入了容器化架构之后，整个架构的思考方向彻底变了。嵌套在臃肿的 SDK 或者框架中的诸如日志、监控、压测等组件瞬间解放出来，整个业务系统变“轻”了很多，DevOps 真正从概念走进了现实生活。
工程师们发现应用的发布、迭代、迁移再也不需要借助各种流程、制度、规范来控制，运维也完全摆脱了平台绑定。敏捷发布、蓝绿持续迭代和运维自动化，甚至 AIOPS，瞬间起飞。再有底层 IaaS 云平台的虚拟化加持，弹性伸缩、动态调度、热点打散等等，原先需要资深架构师苦思冥想、精雕细琢的设计一下子走入了“民间”。
中通快递，对于云原生的需求其实是非常迫切的。，我们有上百个业务系统，海量微服务，支撑着亿万级的交易量。中通的开发、运维同事每天无不是如履薄冰，因为稍有不慎就是 F1 故障，一个发布不当或者小小 BUG 带来的就是数十万的损失。所以，我们从高层领导往下，一开始就坚定地走云原生升级的道路，无论什么困难和理由，都不会让步。
之所以做这样的抉择，我们认为这是一劳永逸的事情。之前的一些历史包袱（例如 SDK 存在多个版本，升级困难），也可以通过架构升级彻底甩掉。，通过云原生改造，我们享受到了容器的高密度部署和智能化调度所带来的好处，资源利用率在不断提升，包括刚才说的开发效率出现了质的飞跃。
2
云原生是盘大棋，最终是为了定制一套适合中通研发体系的方法论
InfoQ对于快递行业而言，有哪些典型场景适合云原生落地？
杨小飞可以说，云原生的概念直接击中了快递行业的每个痛点。，我们整个研发中心是以业务系统为重心的，不可能像互联网企业那样招募很多技术大牛，开发专属的技术中台和大神级框架，，我们的业务量又是海量，高峰时期的流量丝毫不弱于互联网企业，而且我们的终端类型涵盖了软硬件，业务形态从线下到线上，很多业务高峰还是半夜，可以说是“没有公主的命，却得了公主病”，云原生平台恰好可以很大程度上缓解这个矛盾，。
打个比方，我们的中台业务，订单轨迹，开放接口等都是海量 QPS，大起大落也很常见。往往碰到大促或者突发事件，我们的架构师都要提前 1-2 月做流量预估、版本降级预案和服务器冗余待命。而在云平台上，都是根据监控自动扩容缩容，蓝绿发布也非常轻松，架构师不用带着黑眼圈上班了。一些辅助部门，例如安全、测试，原来想要做一些网络策略或者压测，协调起来非常麻烦，需要到各个业务线求爷爷告奶奶升级或者打包到各个业务系统代码 SDK 中，或者安装 agent，现在他们通过 CNI 和 Sidecar，可以无感知地植入。还有就是边缘计算业务，也可以平行升级自己的模组，这不就是云原生本来的样子嘛！，我们几万个网点，很多当地的架构还是集中式的，这一块也是非常适合使用容器平台作为底座的。
InfoQ云原生的提出已经快 10 年时间了，中通快递什么时候开始探索云原生实践？当时基于怎样的背景？
杨小飞其实我们的 CTO 早在 2017 年就提出了要做容器化基础设施的构想，也专门从 IBM 挖来了当时 IBM/EMC 的云计算大牛黄凯（目前云平台技术总监）主持容器化改造。当时因为业务高速发展，我们很多精力都投入到业务系统建设中去了。
现在，我们的各条业务线逐步成熟，K8s 的周边生态也丰富了很多，而且前面各大互联网公司（蚂蚁金服、美团、携程……）也探索了一套完整的云原生方法论，技术风险降低了很多，于是研发中心决定快速跟进，全面拥抱云原生。
回头来看，当时保持观望的策略是对的。当时一些同行采用了 Sarm、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 方案逐步使用容器来做分布式调度。
，未来想象的空间很大，每个场景都等着我们落地，我们团队人手太少了，我们只能把最重要、最易于实施的先做起来。
3
认可 K8s 和 Service Mesh 是未来趋势，但 Serverless 还不确定
InfoQ有人提到云原生的未来主要看 K8s，Service Mesh 和 Serverless 的发展，最终将从资源云化到业务云化，您怎么看？
杨小飞K8s 的确是划时代的一个产品，ServiceMesh 也是大势所趋。不过 Serverless 我们还要观望一段时间。但我基本认同最终都会走向服务网格，按业务切微服务，寻求最佳语言实现。剩下的事情交给业务云。我们现在就是多语言环境，多套 SDK，未来一定会做到语言无关 /SDK 无关。
InfoQ近两年快递行业涌现了不少黑马，如极兔、安能等，这些公司的在技术方面是否有可圈可点之处？
杨小飞极兔是黑马还是野马，这个要时间来证明，技术这种东西，是需要有积累的，即便是用公有云，架构上也要全盘考虑，有些时候抄捷径并不能走得很远。
安能和韵达最近牵手比较紧密，技术方面会不会有一些整合目前不太清楚。三通一达里面，我们对自己的信心还是很大的，因为我们从一开始就走自力更生的自主研发路线，虽然不是走得最快的，我们的技术底蕴会越来越深，可以支撑业务系统做得更大，走得更远，而且我们团队的成员也是各个独当一面。