順豐作為物流龍頭，公司在 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 年開始實施場地的標準化，自動化的管理，大大提高了效率，其中邊緣計算功不可沒。

我這里分享兩個邊緣計算的案例：

第一個案例是我們的分揀系統的分布式管理的案例；分揀系統是我們中轉最核心的系統，考慮網絡延遲和網絡的可用性，它是典型的總分結構的系統，在總部有一個中央系統，然后在幾百個中轉場有分支。以發版本為例，之前的方式是給區域下發包，區域負責部署驗證，傳統發布需要一周左右的時間，而且回滾困難。為了解決這個問題，我們把總部的 CICD 和 K8S 的解決方案做了一個向邊緣的延伸，對區域的服務器做了基于 K8S 的標準化，打通了總部的 DevOps 一體化平臺和區域的 K8S 集群，實現了按需發布和回滾，單場地分鐘級發布，自動化率達到 100%;運營監控也同時收斂，大大提高效率。

第二個案例是我們的慧眼慧眼神瞳系統。順豐對用戶體驗的追求是極致的，大家用順豐的快遞，如果有破損，順豐是有能力做整個鏈條追溯，找到破損的來源的，我們是怎么做到的呢，靠的就是慧眼神瞳。慧眼神瞳通過實時圖片和視頻數據采集，運用 AI 視覺分析算法，能夠及時的做暴力分揀，安全風險等場景的分析。

慧眼神瞳是典型的端，邊，云架構的系統。 端側設備主要是攝像頭，采集數據，邊緣是基于 GPU 的服務器，主要解決圖片處理和模型的判斷，邊緣上數據是巨大的，主要是圖像和視頻數據，一個場地達到上 T 數據量的規模，邊端與云端鏈接網絡條件差，容易斷網。云端主要是用于訓練模型，然后把模型推到邊緣，用于實時業務判斷。我們以 K8S Edge 為核心，構筑起云與端的堅實橋梁。

在終端側，會有海量的圖片與視頻需要進行識別處理，如果直接都在云端計算，則需要的帶寬和算力是不可估量的。我們首先利用順豐云便捷的 CICD 服務進行應用研發、模型訓練，通過 Egde 服務進行云邊的協調發布，實現了邊緣側斷網、弱網情況下的異構容器生命周期管理，保證了邊緣端應用的快速更新和穩定運行。實現了圖片視頻信息在邊緣端進行處理和裁剪，再傳輸回云端的端邊云通路。另一方面，以 AIoT 場景為例，未來我們通過 Edge 服務的設備孿生特性，把海量的終端設備元數據化，在邊緣云上對終端設備進行數字化管理。另外我們也將基于 Edge 服務構建統一的消息通道，云邊端的所有設備都可以訂閱消費，形成業務聯動。對于順豐來說，邊緣實踐還僅僅是開始，其他的場景還有很多，如無人機，無人車等。

DevOps 一體化 —— 工具平臺端

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

如圖是我們 2018 年研發流程的情況，工作流中存在斷點，人工干預多，研發的流暢度不好。比如申請環境需要兩天資源才能到位，安全測試沒有集成，發版管控嚴格，每周發一次等。DevOps 一體化平臺徹底改變了這些。我們主要做了如下幾個方面的突破： 1、需求側：需求管理從傳統的流程層層審批的模式轉化成了扁平的產品管理方式。

一開始我們的需求是要提交電子流，通過業務代表，業務主管的層層審批，然后再到我們的產品經理，然后再由產品經理分配給研發，這種方式需求到研發需要很長的時間，很難適應業務快速發展的訴求。通過產品空間，用戶可以直接跟產品提需求，產品經理和業務的代表基于統一的需求看板，做需求評估和優先級排序。

2、研發側：

構建了一站式流水線平臺，流水線集成了研發腳手架，CICD，測試能力，安全能力等，基本實現全程自動化，減少人工干預。

3、運維側：

我們構建了全景監控解決方案，以應用系統的視角，聚合了業務監控，基礎監控，日志，全鏈路監控，用戶行為監控等監控數據。我們基于應用系統，建設了四個監控大屏來幫助支撐快速定位解決問題（用戶行為和業務影響，全鏈路監控，系統架構和報警信息，變更和發布記錄）。

4、研發真正也能做 Ops 的事情，所有的 Ops 工具權限都是可以對研發開放的，只要業務研發通過 DevOps 工程師的培訓，研發就可以上崗做運維。

總結下我們建設流水線的基本原則就是自動化，提升研發工作的流暢性。 無異常就不觸發人工流程，我們有兩種情況會觸發人工流程，一是需求升級決策，產品經理不知道該不該做，跟業務代表之間有不同意見，這時需要升級到中心負責人做決策；第二是研發質量出問題或者產品生產環境的缺陷比較多，觸發質量紅線，不能自動發版本，這時也需要中心負責人做決策，發版流程才能走下去。

通過一站式的 DevOps 一體化的建設，我們為研發提供了類似高鐵的通行服務，研發的流程效率提升 80%以上，大大促進研發的敏捷轉型。 我們的需求交付周期從之前的 1 個多月到 2 周，發版速度從原來需要 1 天到現在的 20 分鐘，發版自動化率達到 100%，同時生產異常自動發現比例達到 70%左右。

綜上，我基本就講完了我們架構升級鐵三角的方案和效果，順豐有一個非常重要的基因，就是速度非常快，我們用三年的時間，實現了整個順豐的架構升級，我們用實際行動證明鐵三角協同是非常有效的。

未來展望

最后講一下未來，順豐業務增長速度很快，同時在開篇講到順豐的業務不僅僅是快遞和物流，順豐其實是一家科技公司，我們新的愿景是“獨立第三方行業解決方案數據科技服務公司”，我們對科技的追求是堅定而有力量的。

適配集團戰略，在科技也提出了基建 2025 的遠景目標，我們希望基于云，大數據，AI 和 5G，構建云，邊，端一體化的現代基礎設施。

我們從如下四個方面來牽引我們的技術追求：高可用，適用速度，安全合規和成本低廉。

以高可用為例，我們目標是核心業務系統都實現異地多活，同時我們的故障解決時間控制在分鐘級別。

以適應速度為例，我們強調的是科技驅動業務成長的速度，如 5G 技術在場地的應用；我們研發實現業務需求的速度，如 DevOps 的升級；我們運維解決異常的速度，如 AIOPS 的應用。

同時順豐是非常重視用戶的隱私安全的，順豐正大力拓展國際市場，也要滿足海外各國的隱私安全保護的要求，如 GDPR 等，我們正在進行隱私計算能力的研究；

在成本方面，科技致力于在綠色環保，更智能的資源調度，場地的無人化等，來整體降低集團的運營成本。