顺丰科技架构升级之路-InfoQ

「如何实现流动式软件发布」线上课堂开课啦，快来报名参与课堂抽奖吧~ 了解详情 



 写点什么

顺丰作为物流龙头，公司在 2018 年面临业务多元化、快速发展的诉求和技术架构工具、平台落后的冲突。在 2018-2021 年期间，顺丰通过联动业务研发、基础设施和工具平台“铁三角”，实现架构的全面升级，支撑公司业务的快速发展和多元化。

本文主要分享了顺丰在架构升级方面的一些经验和体会，包括如何去联动应用架构、技术架构，如何和关键平台一起实现分布式架构升级等，还会分享一些个性化的技术解决方案。

顺丰概况

首先，为了让大家更清楚地理解这个议题，我先简单介绍下顺丰的情况。

顺丰从 1993 年建立至今，已经成为国内物流的 TOP 公司，目前致力于成为一家“第三方独立的行业解决方案数据科技服务公司”。

经过近 30 年的发展，顺丰建设了业界领先的天网、地网和信息网。我们目前有 75 架全货机在天上飞，有十几万辆车在地上跑，还有几十万快递小哥每天奔波为大家服务。顺丰是怎么协同调度人、车、货、场各种能力，这有赖于对技术的执着追求，以及强大技术团队的支撑。

顺丰科技目前有 4000+员工，其中 3000+的研发，1000+多人具有博士硕士学位。科技团队在支撑顺丰业务的同时，也基于业务场景孵化通用的产品方案，溢出到社会。

2018 年困境

要做架构升级，一定要了解企业之前的情况，知道“因”，才能更好地理解结果。

把时间线拉回到 2018 年。

2018 年，顺丰各业务 BU 发展多元化，很多业务异军突起，我们向“快运”、国际业务的拓展，进展迅速，各个业务线都组建了自己的运营和研发团队。但当时，整个应用架构缺乏统一规划和管理，系统交互交错综复杂。

同时业务要求提供更快的需求响应速度，希望科技能够驱动业务的快速成长，而底盘的技术体系相对传统， 主要基于虚拟机提供计算能力，Mesos 和 Docker 的建设刚起步，运维交付的自动化率约 30%左右，且并不是直接面向业务，给用户的资源交付周期以天记，弹性扩展暂没做起来。

另一个挑战是，整个工具链相对较杂乱，且很多断点。 各业务研发中心踊跃试点新的技术组件和工具，缺少统一的治理和规划；应用发版还趋于传统，每周发版时间固定，发版准备到发版完成约需 1 天时间。

战略突围

面临业务快速发展与科技能力相对落后，流程机制相对传统的矛盾，我们成立了架构委员会，并在架构委员会的驱动下，形成了以应用架构，基础设施和工具平台为核心的架构升级铁三角。

为什么是这三个方面呢？

首先谈下应用架构，我们认为应用架构是火车头，应用架构做得好，首先可以快速支撑好业务，其次可以减少研发人员数量，提升研发效能，第三应用架构做得好，可以大大减少后端资源的使用和降低运维的压力。

基于这样的理解，我们首先做应用架构的治理，并做了中台的实践。

在基础架构方面，我们在建设选择上有如下考虑：

1、集团在科技的投资大，管控要求高，传统的基础设施管理方法，无法做到数字化的精益运营，造成成本浪费。我们当时对成本结构并不清楚，需要借助云化，服务化和数字化的手段来解决问题。

2、业界的主流技术是基于 K8s 和微服务的解决方案，我们顺势选择了云原生的技术栈。

3、公有云是我们很好的补充，靠近业务端的部署可以提升用户体验，同时私有云要建设全量的服务成本太高，从用户体验和成本的角度出发，我们选择建设混合云。

4、顺丰是一个巨大的网络，有近 2 万个分点部和几百个中转、仓储场地，边缘设备的管理和运营的挑战越来越大，需要耗费大量的人力和物力，边缘云是我们的必然选择。

基于如上的考虑，我们启动了顺丰云的建设，并选择了云原生、私有云、混合云和边缘云的技术方向。

最后要讲一下工具平台，其实基于前面的背景，研发团队对工具平台的需求是很迫切的，很多研发开始自发式构建自己的工具平台能力，架构治理的复杂度正在升高。

当时迫切要解决的问题是研发发版的速度，所以我们就顺势而为，做了 DevOps 一体化的建设，重点搞定 DevOps 流水线、全景监控、APM、在线压测等标准能力。

架构升级铁三角

架构治理— 以人为本

铁三角策略定了后，怎么去实现呢？

架构委员会在其中的作用非常关键，搞定事，先要搞定人，我们秉着以人为本的理念，对公司的优秀人才进行盘点，并识别出来一批优秀架构师，形成了架构师梯队，并建立架构治理体系。

整个架构体系分为三层，第一层就是架构委员会，它是架构的决策层，由技术能力强的总监和顶级专家组成，负责顶层的架构设计，这批人掌握技术方向和人力资源，这一层人员的选择标准是有远见和有 POWER，能够洞见未来，并促进落地。

第二层是执行层，负责公司层架构治理决议的执行落地，这一层由各领域有影响力的优秀架构师组成，作为架构委员会的执行组织，能够联动架构委员会，同时推动应用研发和基础设施研发做架构落地;

第三层是架构人才池，是各个领域或者产品的架构师，负责具体产品的架构优化落地。三层架构很好的解决了架构战略制定到战略落地的问题，为后续整个转型的快速推进打下了基础。

以应用架构为例，讲一下架构委员会的运作，我们修订了各个业务域的架构蓝图，并跟业务部门培训，让业务部门跟科技有共识，基于统一的架构蓝图，我们推动了应用的架构整合和应用的下线，近 2 年我们每年推动 150+的应用系统的下线。

技术组件方面，2019 年开始，我们对所有的技术组件建立了技术标准，并通过流水线的质量卡点，来提升架构标准的遵从性。

中台探索 - 应用架构端

下面我会分三部分讲讲“铁三角”的方案和落地情况。

谈到应用架构，应用中台是不能不讲的实践，我们起初的战略是学习电商的中台去构建物流中台，希望低成本快速的满足业务需求，支撑业务的快速发展。

我们当时规划了产品中台、订单中台、履约中台、结算中台等，支撑速运，快运和国际等各个 BU。

先说下我们做得成功的，产品中台是我们觉得可为，并且现在看比较成功的，我们的做法是在现有的模块基础上做了一个聚合，对外先统一数据和接口能力。这个投入不多，但是效果还不错，2015 年规划产品变革，200+人切换实施耗时 3 个月，而 2021 年 4 月，我们产品体系升级切换， 60+人参与实施，成功在 1 天内完成。

再谈一下履约中台。关于履约中台，很多朋友可能不好理解，我解释下。假如你寄一个快件给你远方的父母，所谓履约就是指从你下完单，小哥到你家取件，到小哥把件送到你父母手上的过程。

顺丰对每一个订单都提供严格的 SLA 物流服务承诺，为了满足用户的体验，履约流程有太多的定制化，履约中台其实是缺乏业务基础的。

去年开始我们四网融通，业务实现了模块化，标准化，比如之前我们在速运的场地也处理大件和 NC 件，这样速运的场地功能和管理复杂，后面大件，NC 都在快运的场地处理，这样就能够简化速运的场地运作流程，可以做得更标准高效。在业务模块化和标准化的前提下，履约中台大有可为。

最后谈下订单中台，一开始我们期待用一套 OMS 支撑各个 BU 的业务，后来发现不可行。业务发展太快了，系统是否统一并非第一优先级，而且中台重构过程中，业务的需求响应速度会变慢；BU 有自己独立性的诉求，难以通过统一平台管控。所以这个 CASE，我们并没有很好的落地。

以上三个案例我们的体会是，建设应用中台要业务牵引，敢于投入，在迭代中不断进步。

全面云化 — 基础架构端

基础设施的建设，我们以顺丰云为战略蓝图，选择以 K8s 为中心，走云原生道路，基于 K8s 和云原生的生态，覆盖微服务、DevOps、边缘、混合云等解决方案。

如图是我们的服务蓝图。

2019 年我们一方面补充目前计算平台的能力短板，同时实现了 K8s 和 DevOps 流水线的 0-1 的建设，10%的系统实现了云化；我们 2020 年建设的多云方案，实现了 60%的系统上云，150+系统容灾在公有云上；今年我们计划实现所有核心系统上云，同时开始规模化试点边缘的解决方案。

我们近 700 套的业务系统，顺丰的云建设和应用上云的速度和节奏是惊人的，我们总共用三年的时间，实现云平台的建设，并实现所有应用的全面云化，这也是在架构转型铁三角下的协同效果。

这里讲几个案例，先讲混合云。

我们混合云的建设原则是：多云协同，成本最优，风险可控

多云协同：一是业务场景的需要，比如海外和国内的供应商很难用同一家; 有些流量入口需要选择指定的云厂商；二是，我们不希望绑定任何一家云厂家，我们的资源需求要做到全球范围内，按需调度。

成本最优： 我想很多跟我们一样，是有自己租赁或者建设的 IDC 的，不管你用不用，你的分摊成本是在的，同时我们做过严格的成本测算，当企业的服务器到一定的数量后，很多服务在私有云成本会更低。所以怎么使用公有云，是要基于场景的，我们一般用于用户体验的提高，应用的前端互联网入口，容灾和高峰应对等一些场景。

风险可控： 自主可控主要是指两方面，1、是技术能力始终是一线互联网公司适应变化的关键，企业要掌握核心的技术能力；2、信息安全和网络安全也是我们重点考虑的。

我今天讲混合云的应用场景：

第一个场景是：高峰弹性。 顺丰高峰一般跟电商的高峰是相关的，一般都在电商高峰后的几天，属于电商履约的部分。一般高峰的流量是平时的 2-3 倍，我们过去每年是按照峰值件量去准备常量资源的，如下图绿色线所示，我们现在开始以平均值（红色线）加一定的弹性来准备常量资源，如黄色线，从而可以大大降低高峰期间的资源成本。

如下图中的右图，要实现这个解决方案，技术上需要解决四个问题：

1、业务量可以按比例弹到公有云，我们的应用在网关上做分流。

2、基于容器化，统一标准。

3、通过专线连接，保证网络的稳定性，以保证应用性能和可靠性。

4、统一的云管平台，实现多云资源协同，分钟级别弹性扩容。我们这个方案 2020 年双十一高峰已经完成验证，2021 年我们会实现核心系统在双十一期间，高峰弹性采用公有云的资源。假设高峰的流量是平时的三倍，这个方案可以省日常 1.5 倍左右的成本。

第二个场景是容灾多活。

对于 CTO 来说，容灾体系建设都有三个困惑：1、使用率低，2、有了能不能有效切换，3，成本投入大。

我们平时关注容灾切换的 RPO，RTO 等指标，其实成本也是非常关键的，如左边图所示。在 2019 年之前，我们的容灾体系是相对传统的的冷备模式，生产跟容灾的资源比约 1:0.8，RTO 按天计。

我们在 2019 年底开始重新梳理容灾痛点，建立了新型的容灾解决方案，做应用的双活改造和容灾的自动化体系建设。在今年 3 月 27 日，我们做了第一次全面的容灾演练，在业务基本不受影响的情况下，我们总体容灾切换只用了 1 个小时 09 分钟，同时资源的使用率在提高，服务器的诉求在减少。

我们正在建设的目标是分钟级容灾体系，真正实现异地多活才能做到无感的容灾切换。 容灾是一个很复杂的过程，我们建立了完善的容灾体系和自动化容灾切换平台，自动化率达到 98%，公有云容灾是其中的一个部分。

公有云的容灾，我们目前主要在应用层，用在我们非关键系统上，这个方案目前证明是完全可行的，我们已经有 150+的系统容灾使用公有云。右图方案类似高峰的场景，区别在于多入口分流，智能 DNS 实现业务流量的转移。

边缘云

边缘云可以说天然就是适配顺丰的场景的，我们数以万计的分点部，几百的中转场，场地里面大量的摄像头、叉车、分拣机等等自动化设备，而且每年的增长都非常快。

这些场地多，而且分布全国各地，网络带宽紧张，网络延迟高；逐年建设的场地，标准化程度不够，基础设施和应用发布运营都很耗时耗力。

我们在 2020 年开始实施场地的标准化，自动化的管理，大大提高了效率，其中边缘计算功不可没。

我这里分享两个边缘计算的案例：

第一个案例是我们的分拣系统的分布式管理的案例；分拣系统是我们中转最核心的系统，考虑网络延迟和网络的可用性，它是典型的总分结构的系统，在总部有一个中央系统，然后在几百个中转场有分支。以发版本为例，之前的方式是给区域下发包，区域负责部署验证，传统发布需要一周左右的时间，而且回滚困难。为了解决这个问题，我们把总部的 CI/CD 和 K8s 的解决方案做了一个向边缘的延伸，对区域的服务器做了基于 K8s 的标准化，打通了总部的 DevOps 一体化平台和区域的 K8s 集群，实现了按需发布和回滚，单场地分钟级发布，自动化率达到 100%;运营监控也同时收敛，大大提高效率。

第二个案例是我们的慧眼慧眼神瞳系统。顺丰对用户体验的追求是极致的，大家用顺丰的快递，如果有破损，顺丰是有能力做整个链条追溯，找到破损的来源的，我们是怎么做到的呢，靠的就是慧眼神瞳。慧眼神瞳通过实时图片和视频数据采集，运用 AI 视觉分析算法，能够及时的做暴力分拣，安全风险等场景的分析。

慧眼神瞳是典型的端、边、云架构的系统。 端侧设备主要是摄像头，采集数据，边缘是基于 GPU 的服务器，主要解决图片处理和模型的判断，边缘上数据是巨大的，主要是图像和视频数据，一个场地达到上 T 数据量的规模，边端与云端链接网络条件差，容易断网。云端主要是用于训练模型，然后把模型推到边缘，用于实时业务判断。我们以 K8s Edge 为核心，构筑起云与端的坚实桥梁。

在终端侧，会有海量的图片与视频需要进行识别处理，如果直接都在云端计算，则需要的带宽和算力是不可估量的。我们首先利用顺丰云便捷的 CI/CD 服务进行应用研发、模型训练，通过 Egde 服务进行云边的协调发布，实现了边缘侧断网、弱网情况下的异构容器生命周期管理，保证了边缘端应用的快速更新和稳定运行。实现了图片视频信息在边缘端进行处理和裁剪，再传输回云端的端边云通路。

另一方面，以 AIoT 场景为例，未来我们通过 Edge 服务的设备孪生特性，把海量的终端设备元数据化，在边缘云上对终端设备进行数字化管理。另外我们也将基于 Edge 服务构建统一的消息通道，云边端的所有设备都可以订阅消费，形成业务联动。对于顺丰来说，边缘实践还仅仅是开始，其他的场景还有很多，如无人机，无人车等。

DevOps 一体化 —— 工具平台端

接下来分享下在 DevOps 一体化方面所做的工作。

如图是我们 2018 年研发流程的情况，工作流中存在断点，人工干预多，研发的流畅度不好。比如申请环境需要两天资源才能到位，安全测试没有集成，发版管控严格，每周发一次等。DevOps 一体化平台彻底改变了这些。我们主要做了如下几个方面的突破：

1、需求侧：需求管理从传统的流程层层审批的模式转化成了扁平的产品管理方式。

一开始我们的需求是要提交电子流，通过业务代表，业务主管的层层审批，然后再到我们的产品经理，然后再由产品经理分配给研发，这种方式需求到研发需要很长的时间，很难适应业务快速发展的诉求。通过产品空间，用户可以直接跟产品提需求，产品经理和业务的代表基于统一的需求看板，做需求评估和优先级排序。

2、研发侧：

构建了一站式流水线平台，流水线集成了研发脚手架，CI/CD，测试能力，安全能力等，基本实现全程自动化，减少人工干预。

3、运维侧：

我们构建了全景监控解决方案，以应用系统的视角，聚合了业务监控、基础监控、日志、全链路监控、用户行为监控等监控数据。我们基于应用系统，建设了四个监控大屏来帮助支撑快速定位解决问题（用户行为和业务影响，全链路监控，系统架构和报警信息，变更和发布记录）。

4、研发真正也能做 Ops 的事情，所有的 Ops 工具权限都是可以对研发开放的，只要业务研发通过 DevOps 工程师的培训，研发就可以上岗做运维。

总结下我们建设流水线的基本原则就是自动化，提升研发工作的流畅性。 无异常就不触发人工流程，我们有两种情况会触发人工流程，一是需求升级决策，产品经理不知道该不该做，跟业务代表之间有不同意见，这时需要升级到中心负责人做决策；第二是研发质量出问题或者产品生产环境的缺陷比较多，触发质量红线，不能自动发版本，这时也需要中心负责人做决策，发版流程才能走下去。

通过一站式的 DevOps 一体化的建设，我们为研发提供了类似高铁的通行服务，研发的流程效率提升 80%以上，大大促进研发的敏捷转型。 我们的需求交付周期从之前的 1 个多月到 2 周，发版速度从原来需要 1 天到现在的 20 分钟，发版自动化率达到 100%，同时生产异常自动发现比例达到 70%左右。

综上，我基本就讲完了我们架构升级铁三角的方案和效果，顺丰有一个非常重要的基因，就是速度非常快，我们用三年的时间，实现了整个顺丰的架构升级，我们用实际行动证明铁三角协同是非常有效的。