前言
考拉海購的整個雲化改造是從 2019年10月份開始的，當時的唯一目標就是短時間內快速完成遷移。在不到 4 個月的時間裡，我們唯一考慮的是如何以最快的速度完成使命，雲原生恰巧是我們選擇的一條路。
實踐歷程
本篇主要從第三階段的雲產品的接入和第四階段運研模式的升級來談談考拉海購的實踐過程。
雲產品接入
雲原生產品定義
雲原生本質上是一套技術體系和方法論。隨著容器技術、可持續交付、編排系統等技術的發展，同時在開源社區、分佈式微服務等理念的帶動下，應用上雲已經是不可逆轉的趨勢。真正的雲化不僅僅是基礎設施和平臺的變化，應用本身也需要做出改變。在架構設計、開發方式、應用運維等各個階段基於雲的特點，面向開源和標準化，建設全新的雲化的應用，即雲原生應用。
雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。根據 CNCF 的定義，雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。阿里雲提供了消息隊列產品，如消息隊列 RocketMQ 版、消息隊列 Kafka 版等，應用實時監控服務 ARMS，微服務引擎 MSE，應用高可用服務 AHAS，性能測試 PTS，函數計算 FC 等中間件雲原生產品，為考拉海購從傳統應用向雲原生應用演進，打下了堅實的基礎。
心路歷程
我們在雲產品的接入過程中， 大致在心態上經歷了三個階段。
- 第一階段：很好、很強大，接入效率槓槓的
這部分主要是在 2019年10月-2020年3月之前，那時候接入的都是數據庫、Redis，以及 ASI 這種產品，相對用戶比較多，整體比較穩定，與開源產品基本上完全兼容，遷移工具及周邊建設都比較完善，所以遷移起來非常平穩，基本上改動一部分點就可以了。
- 第二階段：雲產品真豐富，要啥都有
以前很多組件還是我們自己維護的，但是隨著連接實例的增加，讀寫的次數多了，時不時出現宕機。那時候聽說微服務引擎 MSE 很好用，它提供一站式微服務能力加持，包括微服務依賴組件託管、無侵入的微服務治理，更快捷、穩定、低成本的運行微服務。我們找了下 MSE 的兄弟，他們拍著胸口說沒問題，產品運行之後真的就沒出現過那些問題了。
像這樣的例子還很多，那時候的感受是，只有真正體系化地去使用雲原生產品，你才會對雲原生的價值有更深刻的感受。
- 第三階段：磨合適應
隨著考拉海購開始接入集團的業務平臺，供應鏈也開始和集團進行融合，我們也進一步開展雲化的歷程。過程中也有挑戰，不過在克服重重困難後，我們如期完成了各項的改造，並且非常平穩的度過了幾次大促，雲原生產品非常好地支撐了考拉海購業務的增長。
接入的過程
1. 接入策略
由於雲產品和考拉海購自建的產品有一定的能力差異，所以我們建立了一整套產品評估和接入試驗田機制來保證整個接入的有序及功能的可遷移性，正是這套機制的良好運行，我們整個的穩定性得到了保障，在整個基礎大變動中都沒有出現大的故障。
我們的整個保障流程如下圖:
2. 權限方案
接入雲產品面臨的第一個問題是，雲賬號，雲產品資源權限怎麼管理？阿里雲本身提供了 RAM 產品，作為管理用戶身份與資源訪問權限的服務。那麼 RAM 賬號如何何員工身份關聯？
- 是為每個產品申請一個子賬號，所用人共用該子賬號？
- 還是為每個人申請一個 RAM 子賬號，單獨為每個人管理資源權限？
- 或者為應用申請一個子賬號，通過員工的應用權限來和子賬號的資源權限做關聯？
考拉海購有幾百人，方案2和3都面臨著很高的子賬號生命週期以及資源權限的管理成本，所以我們初期在使用這些中間件雲產品時，出於簡單考慮，都採用了第一個方案——申請一個子賬號，開發一起用。
其帶來的問題就是資源權限粒度太粗，比如使用任務調度（SchedulerX) , 登錄到控制檯就可以操作所有應用的所有任務，這對於安全生產來說，本身就是一件很危險的事情。所以為了應用安全，我們向中間件雲產品提的第一個需求，基於 RAM 提供按應用粒度做資源授權的能力。
考拉海購用戶在登錄雲控制檯時，感知不到 RAM 賬號。在基於 RAM 雲產品 STS（Security Token Service） 的能力，封裝了一層簡單的雲控制檯跳轉臨時授權，在生成 STS Token 時，根據 BUC 獲取當前用戶，並生成和指定一個額外的權限策略，限制該用戶操作雲資源（應用）的權限。登錄頁面如下圖：
SchedulerX 也基於 STS 的能力，通過 RoleSessionName 來和員工身份關聯，完成權限管理操作。當然，這個只是暫時的方案，能幫考拉海購解決一部分問題，最終的解決方案還是要靠全局來解，這部分以後我們再談。
3. 消息方案
1）遷移目標
考拉海購消息體系基於消息隊列 Kafka、消息隊列 RabbitMQ，在其上自研了事務消息中心和延遲消息產品滿足業務豐富的消息需求。經過調用雲上消息隊列 RocketMQ 產品，發現其能完美的兼容、支持考拉海購現有的完整的消息體系，能夠提供足夠的性能保障、穩定行保障，並且額外提供支持了消息軌跡和消息查詢的功能，對業務使用上更加友好。
2）實施過程
整體遷移涉及考拉海購上百工程，無法進行統一時間上的安排改造，所以針對考拉海購的場景，制定了橫跨數月的遷移方案。並研發 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 方案
1）挑戰
雲上 ScheduleX 定時任務瓶體和考拉海購的 kschedule 定時任務平臺，通過調研比較，發現 ScheduleX 可以說是 kschedule 的架構升級版，除了滿足基礎的定時調度，分片調度之外，還支持了更大規模的任務調度。對於整體遷移來說，最大的難點在於如何遷移同步考拉海購 13000+ 的定時任務，期間每一個任務都需要在代碼中進行手動改造，在平臺上進行配置。人力消耗巨大。
2）遷移方案
- 自研同步工具進行 13000+ 定時任務同步以及報警信息同步，解決了業務同學海量的人肉操作
- 自研考拉海購雲原生管控平臺進行定時任務權限信息同步，保障數據遷移後的安全性。
6. 環境隔離方案
微服務場景下，環境治理是一個比較大的問題，環境隔離本質上是為了最大化利用測試環境的資源，提升需求測試的效率。考拉原來基於 Dubbo 的路由策略，開發了一套環境路由邏輯。思想是基於主幹環境加項目環境的策略，只需要部署需求涉及變更的應用，流量通過攜帶項目標籤，優先路由到項目環境，如果沒有部署，則複用主幹環境的服務和資源。因此主幹環境的穩定以及項目環境的路由是測試環境治理的重中之重。
遷移到阿里雲之後，阿里雲其實有一套類似的方案，基於 SCM 路由，達到同樣的效果，如下圖所示：
但是功能上 SCM 不支持考拉海購的 RPC 框架 Dubbok 以及消息框架 ，不過得益於 ARMS 優秀的插件包機制，我們將 HSF 的 scm 插件通過代碼增強的方式打包成插件，移植到了 Dubbok 上，具備了 Aone SCM 方案的能力。通過 JVM 參數和發佈平臺結合，在前期充分測試以及和 QA 開發同步的基礎上，我們在一週之內切換到集團的 SCM 方案上。後續考拉海購基本以主幹環境+項目環境的方式進行需求迭代開發。
7. 高可用組件方案
1）AHAS 限流
對於限流來說有三個關鍵點：一是接入，需要在應用代碼或者基礎組件中埋點，從而能夠收集 metrics 以及進行相應限流操作；二是限流能力，規則配置與下發；三是監控與報警。
AHAS 和考拉海購原限流組件（NFC) 面向用戶使用層面基本一致，提供註解、API 顯示調用、Dubbo filter、http filter 等方式，在遷移時僅需要替換對應的 API 即可，由於組件 API 相對簡單，因此接入成本還是比較低的。同時 AHAS 也提供了 JavaAgent 接入能力，不需修改代碼即可接入。
在能力方面，AHAS 比原考拉的的組件更加完善，提供了基於系統負載的保護以及熔斷降級。原本有個需求是集群限流的功能，AHAS 團隊很給力，在 618 之前上線了該功能讓我們用了起來。在監控報警方面提供了實時的秒級監控，TopN 接口展示等功能，很完善。也有流控自動觸發報警，通過釘釘的方式。
2）AHAS 故障演練
考拉海購應用部署在 ASI，Ahas-Chaos 通過 K8s 對外提供的 Operator 能力，在業務無感的情況完成了接入，並順利的參與到了集團 527 聯合演練當中。
8. 壓測鏈路改造方案
考拉原本已經有了一套全鏈路壓測的影子方案。其核心主要分為兩個部分：
1）全鏈路壓測標透傳
2）流量攔截以實現影子路由、服務 Mock 等
遷移第一步是要先接入應用實時監控服務 ARMS；遷移第二步則是接入性能測試 PTS，支持 ARMS 和考拉組件，接管考拉原有的影子路由邏輯。
ARMS 和 PTS 本身都是使用 JavaAgent 的方式，通過字節碼增強來完成對各個基礎組件的埋點，這種操作的好處是接入成本低，業務感知小。最終我們順利完成了全鏈路壓測的改造。
9. 同城雙活方案
考拉海購在遷移到集團機房後，一段時間內還存在自建、雲產品和集團組件三者共存的情況，基於現狀，我們設計了一套自有的雙活及 SPE 方案。
1）線上正常狀態
基於 DNS 和 Vipserver 的同機房優先，既能支持日常的流量隨機，也能支持單機房流量隔離。
2）單機房壓測下狀態
基礎設施即代碼 (IaC)
什麼是 IaC
Infrastructure as Code ——基礎設施即代碼，是一種使用新的技術來構建和管理動態基礎設施的方式。它把基礎設施、工具和服務以及對基礎設施的管理本身作為一個軟件系統，採納軟件工程實踐以結構化的安全的方式來管理對系統的變更。
我的理解就是，通過將軟件的運行環境、軟件的依賴，及軟件的代碼進行一致化的管理（變更，版本等），並提供類似 BaaS 化的解耦方式，使得軟件不被某個特定環境綁定，可以在任意環境快速複製運行。
實踐內容
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 後應用代碼回滾時也會自動回滾靜態配置，不需要業務手動去靜態配置中心回滾靜態配置，極大降低了業務回滾的風險。
另外當鏡像和配置分離後，鏡像可以在任何環境進行部署，而不必依賴對應環境的配置。這樣的話，我們發佈流程就可以從面向變更，調整為面向製品，上線的即是測試的鏡像。
實施策略
1. 自動化
IaC 遷移中任務較重的是配置遷移，環境遷移及整體標準化，提高遷移效率將極大加快IaC 遷移的速度，也會給業務開發遷移過程中的心態帶來積極影響。
1） 構建發佈配置存放在考拉舊有的部署平臺上，靜態配置存放在自研的配置中心上。舊有部署平臺首先打通考拉的配置中心和集團 gitlab 代碼倉庫，再根據標準化的 service.cue 模板自動將舊有的部署中心和配置中心的各類配置直接創建到業務的代碼中，自動完成 IaC 配置遷移工作，大大節約了業務遷移時間提高了遷移效率。
2） 我們沉澱出了一套雲原生環境的 API，具備了雲原生環境以及雲原生流水線的自動化創建、修改以及刪除能力，也提高了業務接入效率。
IaC 自動化遷移功能上線後，平均每個應用大約只需要 1 分鐘的時間就可以完成各類配置的遷移、雲原生環境、雲原生流水線的創建，全程無需業務接入。在完成上述的配置映射及重建後，應用只需要簡單的進行構建發佈，然後解決部分由於兼容問題導致的啟動不正常，即完成了 IaC 的遷移，整體成本比較低。
2. 接入支持
IaC 的接入不同於中間件的升級，涉及到應用的整個發佈、部署體系的變化，並且當前階段 AppStack 的穩定性不算特別高，所以我們採取的接入策略是項目室封閉接入，全程提供技術支持，保證業務能夠第一時間解決問題，提高業務參與度和幸福感，也能在第一時間收集問題，助力我們優化接入流程，比如前期業務需要手動創建流水線，到後面我們通過 API 自動給需要遷移的業務創建對應的流水線。
而業務遷移 IaC 的實現又有兩個階段，兩個階段我們採用了不同的接入模式，通過在不同的階段，採用不同的支持方式，達到業務穩定快速接入的目標。
1） 雙十一之前
- 項目組出一人常駐項目室支持
- 每週一到週五，都有不同部門的開發到會議室專注遷移
- 每天上午培訓相關知識，下午、晚上進行應用切換
2） 雙十一之後
- 項目組出三人常駐項目室支持
- 每週只遷移固定的部門，由部門派出固定的人完成該周的全部遷移工作
- 培訓放在每週一上午
兩者的差異主要是前期平臺的穩定程度，及業務研發的熟悉度比較低，所以接入相對比較謹慎，更多的是以一種驗證，及推廣的心態來，後續相對穩定之後，整體就是以平推的模式來進行接入。
成果
無重大故障發生
考拉海購的雲原生改造週期很長，不管是 618 和雙 11 這樣的大促，或是每月的會員日等普通大促，在項目組成員的通力協作下，沒有因為雲原生改造引起的重大故障發生。
融合成績喜人
- 解決考拉海購和集團應用部署的差異，完全兼容當前集團的模式，在部署層面與集團技術體系完成對齊；
- 解決考拉海購內部調用和集團調用的差異；
- 完成 SPE 和雙活建設，容災體系進一步和集團對齊。
效能提升、成本節約
- 遷移有狀態容器，每批次部署減少 100 秒，解決 IP 變更導致的啟動失敗問題；
- 配置和代碼做到了強綁定，後續回滾的時候再也不需要關係靜態配置的回滾；
- 從日常容量到大促容量從各個應用分別擴容，到 0.5 人日完成全站擴容到基準水位；
- 服務器數量減少 250 臺。
完善雲產品功能
- 推動解決雲產品易用性、穩定性問題，豐富雲上中間件產品的場景豐富度。
- 推動雲原生過程中的安全生產、賬號等問題的解決。
未來，Mesh是發力方向之一
技術下沉是互聯網發展大的趨勢。在微服務時代，Service Mesh 應運而生。雖然引入 Mesh 代理，會帶來一定性能損耗和資源開銷，以及 Mesh 服務實例的運維和管理成本。但是其屏蔽了分佈式系統的諸多複雜性，讓開發者可以迴歸業務，聚焦真正的價值：
- 專注業務邏輯，通過 Mesh 屏蔽分佈式系統通信的複雜性(負載均衡、服務發現、認證授權、監控追蹤、流量控制等)；
- 語言無關，服務可以用任何語言編寫；
- 解耦基礎設施，對應用透明，Mesh 組件可以單獨升級，基礎設施可以更快的升級迭代。
考拉海購這一年來一直在堅定的進行雲原生化改造，雖然過程中碰到了非常多的挑戰，但是我們從未懷疑過這一方向的正確性，並在每一次解決問題之後收穫到了更多的業務價值。今年雙 11，整個雲原生升級幫助考拉減少了 250 臺服務器，並沉澱出一套完整的 IaaS + PaaS 上雲落地實踐方案。考拉在雲上的研發效率也有了大幅提升，例如使用阿里雲直播中心服務，考拉快速完成了海外直播服務從 0到 1的搭建。此外，“爬樹TV”、“Like社區”等新功能也相繼上線。
隨著雲原生改造的持續發展，雲原生帶來的紅利也越來越顯著。當業務跟基礎設施進一步解耦，我相信有一天會達到與基礎設施無關，業務研發只需要關心自己的業務，再也不用為運行環境而苦惱，進而在運研效率上獲得巨大的提升。
掃碼瞭解更多技術內容與客戶案例：
