親歷者說 | 完整記錄一年多考拉海購的雲原生之路

做者 | 張洪簫（花名：伏見）阿里巴巴新零售高級技術專家
來源|阿里巴巴雲原生公衆號

前言

考拉海購的整個雲化改造是從 2019 年 10 月份開始的，當時的惟一目標就是短期內快速完成遷移。在不到 4 個月的時間裏，考拉團隊惟一考慮的是如何以最快的速度完成使命，雲原生是咱們選擇的最合適的一條路。

實踐歷程

本篇主要從第三階段的雲產品接入和第四階段運研模式的升級來談談考拉海購的實踐過程。

雲產品接入

1. 雲原生產品定義

雲原生本質上是一套技術體系和方法論。隨着容器技術、可持續交付、編排系統等技術的發展，同時在開源社區、分佈式微服務等理念的帶動下，應用上雲已是不可逆轉的趨勢。真正的雲化不只僅是基礎設施和平臺的變化，應用自己也須要作出改變。在架構設計、開發方式、應用運維等各個階段基於雲的特色，面向開源和標準化，建設全新的雲化的應用，即雲原生應用。

雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。根據 CNCF 的定義，雲原生的表明技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。阿里雲提供了消息隊列產品，如消息隊列 RocketMQ 版、消息隊列 Kafka 版等，應用實時監控服務 ARMS，微服務引擎 MSE，應用高可用服務 AHAS，性能測試 PTS，函數計算 FC 等中間件雲原生產品，爲考拉海購從傳統應用向雲原生應用演進，打下了堅實的基礎。

2. 心路歷程

咱們在雲產品的接入過程當中， 大體在心態上經歷了三個階段。

1）第一階段：很好、很強大，接入效率槓槓的

這部分主要是在 2019 年 10 月 - 2020 年 3 月以前，那時候接入的都是數據庫、Redis，以及 ASI 這種產品，相對用戶比較多，總體比較穩定，與開源產品基本上徹底兼容，遷移工具及周邊建設都比較完善，因此遷移起來很是平穩，基本上改動一部分點就能夠了。

2）第二階段：雲產品真豐富，要啥都有

之前不少組件仍是咱們本身維護的，可是隨着鏈接實例的增長，讀寫的次數多了，時不時出現宕機。那時候據說微服務引擎 MSE 很好用，它提供一站式微服務能力加持，包括微服務依賴組件託管、無侵入的微服務治理，更快捷、穩定、低成本的運行微服務。咱們找了下 MSE 的兄弟，他們拍着胸口說沒問題，產品運行以後真的就沒出現過那些問題了。

像這樣的例子還不少，那時候的感覺是，只有真正體系化地去使用雲原生產品，你纔會對雲原生的價值有更深入的感覺。

3）第三階段：磨合適應

隨着考拉海購開始接入集團的業務平臺，供應鏈也開始和集團進行融合，咱們也進一步開展雲化的歷程。過程當中也有挑戰，不過在克服重重困難後，咱們如期完成了各項的改造，而且很是平穩的度過了幾回大促，雲原生產品很是好地支撐了考拉海購業務的增加。

3. 接入的過程

1）接入策略

因爲雲產品和考拉海購自建的產品有必定的能力差別，因此咱們創建了一整套產品評估和接入試驗田機制來保證整個接入的有序及功能的可遷移性，正是這套機制的良好運行，咱們整個的穩定性獲得了保障，在整個基礎大變更中都沒有出現大的故障。

咱們的整個保障流程以下圖:

2）權限方案

接入雲產品面臨的第一個問題是，雲帳號，雲產品資源權限怎麼管理？阿里雲自己提供了 RAM 產品，做爲管理用戶身份與資源訪問權限的服務。那麼 RAM 帳號如何何員工身份關聯？

• 是爲每一個產品申請一個子帳號，所用人共用該子帳號？

• 仍是爲每一個人申請一個 RAM 子帳號，單獨爲每一個人管理資源權限？

• 或者爲應用申請一個子帳號，經過員工的應用權限來和子帳號的資源權限作關聯？

考拉海購有幾百人，方案2和3都面臨着很高的子帳號生命週期以及資源權限的管理成本，因此咱們初期在使用這些中間件雲產品時，出於簡單考慮，都採用了第一個方案——申請一個子帳號，開發一塊兒用。

其帶來的問題就是資源權限粒度太粗，好比使用任務調度（SchedulerX) ,  登陸到控制檯就能夠操做全部應用的全部任務，這對於安全生產來講，自己就是一件很危險的事情。因此爲了應用安全，咱們向中間件雲產品提的第一個需求，基於 RAM 提供按應用粒度作資源受權的能力。

考拉海購用戶在登陸雲控制檯時，感知不到 RAM 帳號。在基於 RAM 雲產品  STS（Security Token Service） 的能力，封裝了一層簡單的雲控制檯跳轉臨時受權，在生成 STS Token 時，根據 BUC 獲取當前用戶，並生成和指定一個額外的權限策略，限制該用戶操做雲資源（應用）的權限。登陸頁面以下圖：

SchedulerX 也基於 STS 的能力，經過 RoleSessionName 來和員工身份關聯，完成權限管理操做。固然，這個只是暫時的方案，能幫考拉海購解決一部分問題，最終的解決方案仍是要靠全局來解，這部分之後咱們再談。

3）消息方案

遷移目標：

考拉海購消息體系基於消息隊列 Kafka、消息隊列 RabbitMQ，在其上自研了事務消息中心和延遲消息產品知足業務豐富的消息需求。通過調用雲上消息隊列 RocketMQ 產品，發現其能完美的兼容、支持考拉海購現有的完整的消息體系，可以提供足夠的性能保障、穩定行保障，而且額外提供支持了消息軌跡和消息查詢的功能，對業務使用上更加友好。

實施過程：

總體遷移涉及考拉海購上百工程，沒法進行統一時間上的安排改造，因此針對考拉海購的場景，制定了橫跨數月的遷移方案。並研發 SDK，實現了消息雙寫、topic 映射，支持壓測消息等多項考拉海購特有的功能場景。讓業務同窗無需投入大量人力。升級 SDK 增長几行配置就能夠實現消息的雙寫。

• 階段一：全部業務進行消息雙寫改造。
• 階段二：全部業務進行消息雙讀改造。
• 階段三：進行消息整體收尾階段，業務方切換成單獨單寫狀態，至此徹底剝離考拉海購原有的消息體系。

4）RPC 方案

RPC 主要涉及 RPC 框架以及服務註冊中心。考拉海購使用 RPC 框架 Dubbok (Dubbo 內部分支）+ Nvwa (考拉自研註冊中心），而集團使用 HSF + ConfigServer 。

因爲前期業務有和集團微服務互通的需求，基於 HSF 自己兼容 Dubbo 協議，阿里雲 EDAS 團隊爲咱們提供了 Dubbo ConfigServer 註冊中心的擴展，考拉應用在引入該擴展包以後，註冊 CS 以及從 CS 訂閱， 能夠很是方便快捷地和集團 HSF 應用相互調用。

緊接着，咱們開始使用 Dubbo3.0，基於 Dubbo 內核重構 HSF3.0，升級以後，原考拉 Dubbo 應用具有 HSF 的所有特性，能夠和集團服務無縫互通。可是做爲一個新的 SDK，在功能以及性能上必然面臨着很大的挑戰。咱們前期在考拉海購場景下，引入該 SDK 進行了長達一個月的功能測試，解決了近 40 個功能問題。同時也在壓測時，針對性能問題，解決了調用延時、註冊中心推送及緩存的問題。同時考拉海購 Dubbo 註冊中心擴展等也要去支持 Dubbo3.0，最終經歷了雙十一大規模驗證。

同時咱們採用雙註冊、雙訂閱的模式，也爲將來考拉海購自研註冊中心的遷移下線打下基礎。待所用應用升級以後，就能夠修改成只連 CS 的鏈接串，而後下線 Nvwa。同時，考拉海購也遷移到雲原生產品微服務引擎 MSE 上，特別感謝阿里雲 MSE 團隊爲對齊原考拉治理平臺 Dubbo 相關功能做出的支持。

5）SchedulerX 方案

挑戰：

雲上 ScheduleX 定時任務瓶體和考拉海購的 kschedule 定時任務平臺，經過調研比較，發現 ScheduleX 能夠說是 kschedule 的架構升級版，除了知足基礎的定時調度，分片調度以外，還支持了更大規模的任務調度。對於總體遷移來講，最大的難點在於如何遷移同步考拉海購 13000+ 的定時任務，期間每個任務都須要在代碼中進行手動改造，在平臺上進行配置。人力消耗巨大。

遷移方案：

• 自研同步工具進行 13000+ 定時任務同步以及報警信息同步，解決了業務同窗海量的人肉操做。
• 自研考拉海購雲原生管控平臺進行定時任務權限信息同步，保障數據遷移後的安全性。

6）環境隔離方案

微服務場景下，環境治理是一個比較大的問題，環境隔離本質上是爲了最大化利用測試環境的資源，提高需求測試的效率。考拉原來基於 Dubbo 的路由策略，開發了一套環境路由邏輯。思想是基於主幹環境加項目環境的策略，只須要部署需求涉及變動的應用，流量經過攜帶項目標籤，優先路由到項目環境，若是沒有部署，則複用主幹環境的服務和資源。所以主幹環境的穩定以及項目環境的路由是測試環境治理的重中之重。

遷移到阿里雲以後，阿里雲其實有一套相似的方案，基於 SCM 路由，達到一樣的效果，以下圖所示：

可是功能上 SCM 不支持考拉海購的 RPC 框架 Dubbok 以及消息框架 ，不過得益於 ARMS 優秀的插件包機制，咱們將 HSF 的 scm 插件經過代碼加強的方式打包成插件，移植到了 Dubbok 上，具有了 Aone SCM 方案的能力。經過 JVM 參數和發佈平臺結合，在前期充分測試以及和 QA 開發同步的基礎上，咱們在一週以內切換到集團的 SCM 方案上。後續考拉海購基本以主幹環境+項目環境的方式進行需求迭代開發。

7）高可用組件方案

AHAS 限流：

對於限流來講有三個關鍵點：一是接入，須要在應用代碼或者基礎組件中埋點，從而可以收集 metrics 以及進行相應限流操做；二是限流能力，規則配置與下發；三是監控與報警。

AHAS 和考拉海購原限流組件（NFC) 面向用戶使用層面基本一致，提供註解、API 顯示調用、Dubbo filter、http filter 等方式，在遷移時僅須要替換對應的 API 便可，因爲組件 API 相對簡單，所以接入成本仍是比較低的。同時 AHAS 也提供了 JavaAgent 接入能力，不需修改代碼便可接入。

在能力方面，AHAS 比原考拉的的組件更加完善，提供了基於系統負載的保護以及熔斷降級。本來有個需求是集羣限流的功能，AHAS 團隊很給力，在 618 以前上線了該功能讓咱們用了起來。在監控報警方面提供了實時的秒級監控，TopN 接口展現等功能，很完善。也有流控自動觸發報警，經過釘釘的方式。

AHAS 故障演練：

考拉海購應用部署在 ASI，Ahas-Chaos 經過 K8s 對外提供的 Operator 能力，在業務無感的狀況完成了接入，並順利的參與到了集團 527 聯合演練當中。

8）壓測鏈路改造方案

考拉本來已經有了一套全鏈路壓測的影子方案。其核心主要分爲兩個部分：

• 全鏈路壓測標透傳

• 流量攔截以實現影子路由、服務 Mock 等

遷移第一步是要先接入應用實時監控服務 ARMS；遷移第二步則是接入性能測試 PTS，支持 ARMS 和考拉組件，接管考拉原有的影子路由邏輯。

ARMS 和 PTS 自己都是使用 JavaAgent 的方式，經過字節碼加強來完成對各個基礎組件的埋點，這種操做的好處是接入成本低，業務感知小。最終咱們順利完成了全鏈路壓測的改造。

9）同城雙活方案

考拉海購在遷移到集團機房後，一段時間內還存在自建、雲產品和集團組件三者共存的狀況，基於現狀，咱們設計了一套自有的雙活及 SPE 方案。

線上正常狀態：

基於 DNS 和 Vipserver 的同機房優先，既能支持平常的流量隨機，也能支持單機房流量隔離。

單機房壓測下狀態：

基礎設施即代碼 (IaC)

1. 什麼是 IaC

Infrastructure as Code ——基礎設施即代碼，是一種使用新的技術來構建和管理動態基礎設施的方式。它把基礎設施、工具和服務以及對基礎設施的管理自己做爲一個軟件系統，採納軟件工程實踐以結構化的安全的方式來管理對系統的變動。

個人理解就是，經過將軟件的運行環境、軟件的依賴，及軟件的代碼進行一致化的管理（變動，版本等），並提供相似 BaaS 化的解耦方式，使得軟件不被某個特定環境綁定，能夠在任意環境快速複製運行。

2. 實踐內容

1）構建部署體系

咱們在考拉原有的應用 DevOps 體系之上，結合 IaC & GitOps 理念，對應用的構建、部署、配置加載、平常運維等方面基於 AppStack & IaC 作了改造，相關的構建、部署、應用靜態配置所有遷移到應用 git 源碼中。藉助於 git 對應用全部相關配置進行託管，配置的版本迭代相對於以前的模式更加的清晰，同時也能頗有效的保證應用源碼、構建配置、容器配置、靜態配置的版本一致性。

2）輕量化容器

以本次雲原生改造爲契機，咱們將考拉原有的容器鏡像體系與集團標準進行了對標改造，比較大的變化就是將原有的啓動用戶從 AppOps 修改成了 admin。

另外一方面，咱們引入了輕量化容器。做爲雲原生的基礎之一，容器層的隔離能力是一大賣點。考拉海購總體進行了切換，完成了輕量化容器的改造，總體將 pod 分紅了應用容器、運維容器，以及自定義容器幾類，整個部署變得更加的輕量級，也更加易於掌控。

改造後的部署形態見下圖。

3）CPU-share

上圖的模式是 CPU-set，即容器會綁定一部分 CPU，運行時也只會使用綁定的 CPU，這種方式在正常的宿主機上運行的效率是最高的，由於減小了 CPU 的切換。考拉海購的部署所有切換到了 CPU-share 模式，即在同一個 NUMA chip 下，該容器可使用該 chip 下全部的 CPU（ CPU 時間片總數不會超過 limit 配置），這樣只要該 chip 下有空閒的 CPU，就會使搶佔不會太激烈，能大大提升運行的穩定性。

最終在大促峯值壓測的驗證中，神龍機的 CPU 在 55% 如下都能保持一個比較穩定的運行狀態，進而保證了總體服務的穩定性，資源也獲得了更充分的利用。

4）鏡像配置分離

鏡像配置分離指的是將應用的容器鏡像和應用依賴的配置（靜態配置、發佈配置）隔離開獨立存放。這樣作的目的是可以最大程度地複用應用鏡像，減小應用鏡像的構建次數提升構建部署效率；同時，遷移到 AppStack 後應用代碼回滾時也會自動回滾靜態配置，不須要業務手動去靜態配置中心回滾靜態配置，極大下降了業務回滾的風險。

另外當鏡像和配置分離後，鏡像能夠在任何環境進行部署，而沒必要依賴對應環境的配置。這樣的話，咱們發佈流程就能夠從面向變動，調整爲面向製品，上線的便是測試的鏡像。

3. 實施策略

1）自動化

IaC 遷移中任務較重的是配置遷移，環境遷移及總體標準化，提升遷移效率將極大加快 IaC 遷移的速度，也會給業務開發遷移過程當中的心態帶來積極影響。

• 構建發佈配置存放在考拉舊有的部署平臺上，靜態配置存放在自研的配置中心上。舊有部署平臺首先打通考拉的配置中心和集團 gitlab 代碼倉庫，再根據標準化的 service.cue 模板自動將舊有的部署中心和配置中心的各種配置直接建立到業務的代碼中，自動完成 IaC 配置遷移工做，大大節約了業務遷移時間提升了遷移效率。

• 咱們沉澱出了一套雲原生環境的 API，具有了雲原生環境以及雲原生流水線的自動化建立、修改以及刪除能力，也提升了業務接入效率。

IaC 自動化遷移功能上線後，平均每一個應用大約只須要 1 分鐘的時間就能夠完成各種配置的遷移、雲原生環境、雲原生流水線的建立，全程無需業務接入。在完成上述的配置映射及重建後，應用只須要簡單的進行構建發佈，而後解決部分因爲兼容問題致使的啓動不正常，即完成了 IaC 的遷移，總體成本比較低。

2）接入支持

IaC 的接入不一樣於中間件的升級，涉及到應用的整個發佈、部署體系的變化，而且當前階段 AppStack 的穩定性不算特別高，因此咱們採起的接入策略是項目室封閉接入，全程提供技術支持，保證業務可以第一時間解決問題，提升業務參與度和幸福感，也能在第一時間收集問題，助力咱們優化接入流程，好比前期業務須要手動建立流水線，到後面咱們經過 API 自動給須要遷移的業務建立對應的流水線。

而業務遷移 IaC 的實現又有兩個階段，兩個階段咱們採用了不一樣的接入模式，經過在不一樣的階段，採用不一樣的支持方式，達到業務穩定快速接入的目標。

雙十一以前：

• 項目組出一人常駐項目室支持
• 每週一到週五，都有不一樣部門的開發到會議室專一遷移
• 天天上午培訓相關知識，下午、晚上進行應用切換

雙十一以後：

• 項目組出三人常駐項目室支持
• 每週只遷移固定的部門，由部門派出固定的人完成該周的所有遷移工做
• 培訓放在每週一上午

二者的差別主要是前期平臺的穩定程度，及業務研發的熟悉度比較低，因此接入相對比較謹慎，更多的是以一種驗證，及推廣的心態來，後續相對穩定以後，總體就是以平推的模式來進行接入。

成果

1. 無重大故障發生

考拉海購的雲原生改造週期很長，無論是 618 和 雙11 這樣的大促，或是每個月的會員日等普通大促，在項目組成員的通力協做下，沒有由於雲原生改造引發的重大故障發生。

2. 融合成績喜人

• 解決考拉海購和集團應用部署的差別，徹底兼容當前集團的模式，在部署層面與集團技術體系完成對齊。
• 解決考拉海購內部調用和集團調用的差別。
• 完成 SPE 和雙活建設，容災體系進一步和集團對齊。

3. 效能提高、成本節約

• 遷移有狀態容器，每批次部署減小 100 秒，解決 IP 變動致使的啓動失敗問題。
• 配置和代碼作到了強綁定，後續回滾的時候不再須要關係靜態配置的回滾。
• 從平常容量到大促容量從各個應用分別擴容，到 0.5 人日完成全站擴容到基準水位。
• 服務器數量減小 250 臺。

4. 完善雲產品功能

• 推進解決雲產品易用性、穩定性問題，豐富雲上中間件產品的場景豐富度。
• 推進雲原生過程當中的安全生產、帳號等問題的解決。

將來，Mesh 是發力方向之一

技術下沉是互聯網發展的大趨勢。在微服務時代，Service Mesh 應運而生。雖然引入 Mesh 代理，會帶來必定性能損耗和資源開銷，以及 Mesh 服務實例的運維和管理成本。可是其屏蔽了分佈式系統的諸多複雜性，讓開發者能夠迴歸業務，聚焦真正的價值：

1. 專一業務邏輯，經過 Mesh 屏蔽分佈式系統通訊的複雜性(負載均衡、服務發現、認證受權、監控追蹤、流量控制等)。
2. 語言無關，服務能夠用任何語言編寫。
3. 解耦基礎設施，對應用透明，Mesh 組件能夠單獨升級，基礎設施能夠更快的升級迭代。

考拉海購這一年來一直在堅決的進行雲原生化改造，雖然過程當中碰到了很是多的挑戰，可是咱們從未懷疑過這一方向的正確性，並在每一次解決問題以後收穫到了更多的業務價值。今年 雙11，整個雲原生升級幫助考拉減小了 250 臺服務器，並沉澱出一套完整的 IaaS + PaaS 上雲落地實踐方案。考拉在雲上的研發效率也有了大幅提高，例如使用阿里雲直播中心服務，考拉快速完成了海外直播服務從 0 到 1 的搭建。此外，「爬樹 TV」、「Like 社區」等新功能也相繼上線。

隨着雲原生改造的持續發展，雲原生帶來的紅利也愈來愈顯著。我相信當業務跟基礎設施進一步解耦，有一天會實現業務與基礎設施無關，業務研發只須要關心本身的業務，不再用爲運行環境而苦惱，進而在運研效率上得到巨大的提高。

做者簡介

張洪簫（花名：伏見）阿里巴巴新零售高級技術專家，擁有 10 年開發測試運維經驗，在基礎架構和研發效能領域有很是豐富的經驗，積極的擁抱雲原生，推崇持續、快速、高質量的軟件交付方式。