簡介： 今年雙11，整個雲原生更新幫助考拉減少了250台伺服器，并沉澱出一套完整的 IaaS + PaaS 上雲落地實踐方案。
前言
考拉海購的整個雲化改造是從 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 的實作又有兩個階段，兩個階段我們采用了不同的Access模式，通過在不同的階段，采用不同的支援方式，達到業務穩定快速接入的目标。
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社群”等新功能也相繼上線。
随着雲原生改造的持續發展，雲原生帶來的紅利也越來越顯著。當業務跟基礎設施進一步解耦，我相信有一天會達到與基礎設施無關，業務研發隻需要關心自己的業務，再也不用為運作環境而苦惱，進而在運研效率上獲得巨大的提升。
原文連結：https://developer.aliyun.com/article/780763?
版權聲明： 本文内容由阿裡雲實名注冊使用者自發貢獻，版權歸原作者所有，阿裡雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿裡雲開發者社群使用者服務協定》和《阿裡雲開發者社群知識産權保護指引》。如果您發現本社群中有涉嫌抄襲的内容，填寫侵權投訴表單進行舉報，一經查實，本社群将立刻删除涉嫌侵權内容。