前言

考拉海購的整個雲化改造是從 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 配置遷移工作，大大節約了業務遷移時間提高了遷移效率。

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社群”等新功能也相繼上線。

隨著雲原生改造的持續發展，雲原生帶來的紅利也越來越顯著。當業務跟基礎設施進一步解耦，我相信有一天會達到與基礎設施無關，業務研發只需要關心自己的業務，再也不用為執行環境而苦惱，進而在運研效率上獲得巨大的提升。