作者 |?張洪簫（花名：伏見）阿里巴巴新零售高級(jí)技術(shù)專家
來源|阿里巴巴云原生公眾號(hào)

前言

考拉海購的整個(gè)云化改造是從 2019 年 10 月份開始的，當(dāng)時(shí)的唯一目標(biāo)就是短時(shí)間內(nèi)快速完成遷移。在不到 4 個(gè)月的時(shí)間里，考拉團(tuán)隊(duì)唯一考慮的是如何以最快的速度完成使命，云原生是我們選擇的最合適的一條路。

實(shí)踐歷程

本篇主要從第三階段的云產(chǎn)品接入和第四階段運(yùn)研模式的升級(jí)來談?wù)効祭Ｙ彽膶?shí)踐過程。

云產(chǎn)品接入

1. 云原生產(chǎn)品定義

云原生本質(zhì)上是一套技術(shù)體系和方法論。隨著容器技術(shù)、可持續(xù)交付、編排系統(tǒng)等技術(shù)的發(fā)展，同時(shí)在開源社區(qū)、分布式微服務(wù)等理念的帶動(dòng)下，應(yīng)用上云已經(jīng)是不可逆轉(zhuǎn)的趨勢。真正的云化不僅僅是基礎(chǔ)設(shè)施和平臺(tái)的變化，應(yīng)用本身也需要做出改變。在架構(gòu)設(shè)計(jì)、開發(fā)方式、應(yīng)用運(yùn)維等各個(gè)階段基于云的特點(diǎn)，面向開源和標(biāo)準(zhǔn)化，建設(shè)全新的云化的應(yīng)用，即云原生應(yīng)用。

云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。根據(jù) CNCF 的定義，云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API。阿里云提供了消息隊(duì)列產(chǎn)品，如消息隊(duì)列 RocketMQ 版、消息隊(duì)列 Kafka 版等，應(yīng)用實(shí)時(shí)監(jiān)控服務(wù) ARMS，微服務(wù)引擎 MSE，應(yīng)用高可用服務(wù) AHAS，性能測試 PTS，函數(shù)計(jì)算 FC 等中間件云原生產(chǎn)品，為考拉海購從傳統(tǒng)應(yīng)用向云原生應(yīng)用演進(jìn)，打下了堅(jiān)實(shí)的基礎(chǔ)。

2. 心路歷程

我們?cè)谠飘a(chǎn)品的接入過程中， 大致在心態(tài)上經(jīng)歷了三個(gè)階段。

1）第一階段：很好、很強(qiáng)大，接入效率杠杠的

這部分主要是在 2019 年 10 月 - 2020 年 3 月之前，那時(shí)候接入的都是數(shù)據(jù)庫、Redis，以及 ASI 這種產(chǎn)品，相對(duì)用戶比較多，整體比較穩(wěn)定，與開源產(chǎn)品基本上完全兼容，遷移工具及周邊建設(shè)都比較完善，所以遷移起來非常平穩(wěn)，基本上改動(dòng)一部分點(diǎn)就可以了。

2）第二階段：云產(chǎn)品真豐富，要啥都有

以前很多組件還是我們自己維護(hù)的，但是隨著連接實(shí)例的增加，讀寫的次數(shù)多了，時(shí)不時(shí)出現(xiàn)宕機(jī)。那時(shí)候聽說微服務(wù)引擎 MSE 很好用，它提供一站式微服務(wù)能力加持，包括微服務(wù)依賴組件托管、無侵入的微服務(wù)治理，更快捷、穩(wěn)定、低成本的運(yùn)行微服務(wù)。我們找了下 MSE 的兄弟，他們拍著胸口說沒問題，產(chǎn)品運(yùn)行之后真的就沒出現(xiàn)過那些問題了。

像這樣的例子還很多，那時(shí)候的感受是，只有真正體系化地去使用云原生產(chǎn)品，你才會(huì)對(duì)云原生的價(jià)值有更深刻的感受。

3）第三階段：磨合適應(yīng)

隨著考拉海購開始接入集團(tuán)的業(yè)務(wù)平臺(tái)，供應(yīng)鏈也開始和集團(tuán)進(jìn)行融合，我們也進(jìn)一步開展云化的歷程。過程中也有挑戰(zhàn)，不過在克服重重困難后，我們?nèi)缙谕瓿闪烁黜?xiàng)的改造，并且非常平穩(wěn)的度過了幾次大促，云原生產(chǎn)品非常好地支撐了考拉海購業(yè)務(wù)的增長。

3.?接入的過程

1）接入策略

由于云產(chǎn)品和考拉海購自建的產(chǎn)品有一定的能力差異，所以我們建立了一整套產(chǎn)品評(píng)估和接入試驗(yàn)田機(jī)制來保證整個(gè)接入的有序及功能的可遷移性，正是這套機(jī)制的良好運(yùn)行，我們整個(gè)的穩(wěn)定性得到了保障，在整個(gè)基礎(chǔ)大變動(dòng)中都沒有出現(xiàn)大的故障。

我們的整個(gè)保障流程如下圖:

2）權(quán)限方案

接入云產(chǎn)品面臨的第一個(gè)問題是，云賬號(hào)，云產(chǎn)品資源權(quán)限怎么管理？阿里云本身提供了 RAM 產(chǎn)品，作為管理用戶身份與資源訪問權(quán)限的服務(wù)。那么 RAM 賬號(hào)如何何員工身份關(guān)聯(lián)？

• 是為每個(gè)產(chǎn)品申請(qǐng)一個(gè)子賬號(hào)，所用人共用該子賬號(hào)？

• 還是為每個(gè)人申請(qǐng)一個(gè) RAM 子賬號(hào)，單獨(dú)為每個(gè)人管理資源權(quán)限？

• 或者為應(yīng)用申請(qǐng)一個(gè)子賬號(hào)，通過員工的應(yīng)用權(quán)限來和子賬號(hào)的資源權(quán)限做關(guān)聯(lián)？

考拉海購有幾百人，方案2和3都面臨著很高的子賬號(hào)生命周期以及資源權(quán)限的管理成本，所以我們初期在使用這些中間件云產(chǎn)品時(shí)，出于簡單考慮，都采用了第一個(gè)方案——申請(qǐng)一個(gè)子賬號(hào)，開發(fā)一起用。

其帶來的問題就是資源權(quán)限粒度太粗，比如使用任務(wù)調(diào)度（SchedulerX) , ?登錄到控制臺(tái)就可以操作所有應(yīng)用的所有任務(wù)，這對(duì)于安全生產(chǎn)來說，本身就是一件很危險(xiǎn)的事情。所以為了應(yīng)用安全，我們向中間件云產(chǎn)品提的第一個(gè)需求，基于 RAM 提供按應(yīng)用粒度做資源授權(quán)的能力。

考拉海購用戶在登錄云控制臺(tái)時(shí)，感知不到 RAM 賬號(hào)。在基于 RAM 云產(chǎn)品? STS（Security Token Service） 的能力，封裝了一層簡單的云控制臺(tái)跳轉(zhuǎn)臨時(shí)授權(quán)，在生成 STS Token 時(shí)，根據(jù) BUC 獲取當(dāng)前用戶，并生成和指定一個(gè)額外的權(quán)限策略，限制該用戶操作云資源（應(yīng)用）的權(quán)限。登錄頁面如下圖：

SchedulerX 也基于 STS 的能力，通過 RoleSessionName 來和員工身份關(guān)聯(lián)，完成權(quán)限管理操作。當(dāng)然，這個(gè)只是暫時(shí)的方案，能幫考拉海購解決一部分問題，最終的解決方案還是要靠全局來解，這部分以后我們?cè)僬劇?/p>

3）消息方案

遷移目標(biāo)：

考拉海購消息體系基于消息隊(duì)列 Kafka、消息隊(duì)列 RabbitMQ，在其上自研了事務(wù)消息中心和延遲消息產(chǎn)品滿足業(yè)務(wù)豐富的消息需求。經(jīng)過調(diào)用云上消息隊(duì)列 RocketMQ 產(chǎn)品，發(fā)現(xiàn)其能完美的兼容、支持考拉海購現(xiàn)有的完整的消息體系，能夠提供足夠的性能保障、穩(wěn)定行保障，并且額外提供支持了消息軌跡和消息查詢的功能，對(duì)業(yè)務(wù)使用上更加友好。

實(shí)施過程：

整體遷移涉及考拉海購上百工程，無法進(jìn)行統(tǒng)一時(shí)間上的安排改造，所以針對(duì)考拉海購的場景，制定了橫跨數(shù)月的遷移方案。并研發(fā) SDK，實(shí)現(xiàn)了消息雙寫、topic 映射，支持壓測消息等多項(xiàng)考拉海購特有的功能場景。讓業(yè)務(wù)同學(xué)無需投入大量人力。升級(jí) SDK 增加幾行配置就可以實(shí)現(xiàn)消息的雙寫。

• 階段一：所有業(yè)務(wù)進(jìn)行消息雙寫改造。
• 階段二：所有業(yè)務(wù)進(jìn)行消息雙讀改造。
• 階段三：進(jìn)行消息總體收尾階段，業(yè)務(wù)方切換成單獨(dú)單寫狀態(tài)，至此完全剝離考拉海購原有的消息體系。

4）RPC 方案

RPC 主要涉及 RPC 框架以及服務(wù)注冊(cè)中心。考拉海購使用 RPC 框架 Dubbok (Dubbo 內(nèi)部分支）+ Nvwa (考拉自研注冊(cè)中心），而集團(tuán)使用 HSF + ConfigServer 。

由于前期業(yè)務(wù)有和集團(tuán)微服務(wù)互通的需求，基于 HSF 本身兼容 Dubbo 協(xié)議，阿里云 EDAS 團(tuán)隊(duì)為我們提供了 Dubbo ConfigServer 注冊(cè)中心的擴(kuò)展，考拉應(yīng)用在引入該擴(kuò)展包之后，注冊(cè) CS 以及從 CS 訂閱， 可以非常方便快捷地和集團(tuán) HSF 應(yīng)用相互調(diào)用。

緊接著，我們開始使用 Dubbo3.0，基于 Dubbo 內(nèi)核重構(gòu) HSF3.0，升級(jí)之后，原考拉 Dubbo 應(yīng)用具備 HSF 的全部特性，可以和集團(tuán)服務(wù)無縫互通。但是作為一個(gè)新的 SDK，在功能以及性能上必然面臨著很大的挑戰(zhàn)。我們前期在考拉海購場景下，引入該 SDK 進(jìn)行了長達(dá)一個(gè)月的功能測試，解決了近 40 個(gè)功能問題。同時(shí)也在壓測時(shí)，針對(duì)性能問題，解決了調(diào)用延時(shí)、注冊(cè)中心推送及緩存的問題。同時(shí)考拉海購 Dubbo 注冊(cè)中心擴(kuò)展等也要去支持 Dubbo3.0，最終經(jīng)歷了雙十一大規(guī)模驗(yàn)證。

同時(shí)我們采用雙注冊(cè)、雙訂閱的模式，也為未來考拉海購自研注冊(cè)中心的遷移下線打下基礎(chǔ)。待所用應(yīng)用升級(jí)之后，就可以修改為只連 CS 的連接串，然后下線 Nvwa。同時(shí)，考拉海購也遷移到云原生產(chǎn)品微服務(wù)引擎 MSE 上，特別感謝阿里云 MSE 團(tuán)隊(duì)為對(duì)齊原考拉治理平臺(tái) Dubbo 相關(guān)功能作出的支持。

5）SchedulerX 方案

挑戰(zhàn)：

云上 ScheduleX 定時(shí)任務(wù)瓶體和考拉海購的 kschedule 定時(shí)任務(wù)平臺(tái)，通過調(diào)研比較，發(fā)現(xiàn) ScheduleX 可以說是 kschedule 的架構(gòu)升級(jí)版，除了滿足基礎(chǔ)的定時(shí)調(diào)度，分片調(diào)度之外，還支持了更大規(guī)模的任務(wù)調(diào)度。對(duì)于整體遷移來說，最大的難點(diǎn)在于如何遷移同步考拉海購 13000+ 的定時(shí)任務(wù)，期間每一個(gè)任務(wù)都需要在代碼中進(jìn)行手動(dòng)改造，在平臺(tái)上進(jìn)行配置。人力消耗巨大。

遷移方案：

• 自研同步工具進(jìn)行 13000+ 定時(shí)任務(wù)同步以及報(bào)警信息同步，解決了業(yè)務(wù)同學(xué)海量的人肉操作。
• 自研考拉海購云原生管控平臺(tái)進(jìn)行定時(shí)任務(wù)權(quán)限信息同步，保障數(shù)據(jù)遷移后的安全性。

6）環(huán)境隔離方案

微服務(wù)場景下，環(huán)境治理是一個(gè)比較大的問題，環(huán)境隔離本質(zhì)上是為了最大化利用測試環(huán)境的資源，提升需求測試的效率。考拉原來基于 Dubbo 的路由策略，開發(fā)了一套環(huán)境路由邏輯。思想是基于主干環(huán)境加項(xiàng)目環(huán)境的策略，只需要部署需求涉及變更的應(yīng)用，流量通過攜帶項(xiàng)目標(biāo)簽，優(yōu)先路由到項(xiàng)目環(huán)境，如果沒有部署，則復(fù)用主干環(huán)境的服務(wù)和資源。因此主干環(huán)境的穩(wěn)定以及項(xiàng)目環(huán)境的路由是測試環(huán)境治理的重中之重。

遷移到阿里云之后，阿里云其實(shí)有一套類似的方案，基于 SCM 路由，達(dá)到同樣的效果，如下圖所示：

但是功能上 SCM 不支持考拉海購的 RPC 框架 Dubbok 以及消息框架 ，不過得益于 ARMS 優(yōu)秀的插件包機(jī)制，我們將 HSF 的 scm 插件通過代碼增強(qiáng)的方式打包成插件，移植到了 Dubbok 上，具備了 Aone SCM 方案的能力。通過 JVM 參數(shù)和發(fā)布平臺(tái)結(jié)合，在前期充分測試以及和 QA 開發(fā)同步的基礎(chǔ)上，我們?cè)谝恢苤畠?nèi)切換到集團(tuán)的 SCM 方案上。后續(xù)考拉海購基本以主干環(huán)境+項(xiàng)目環(huán)境的方式進(jìn)行需求迭代開發(fā)。

7）高可用組件方案

AHAS 限流：

對(duì)于限流來說有三個(gè)關(guān)鍵點(diǎn)：一是接入，需要在應(yīng)用代碼或者基礎(chǔ)組件中埋點(diǎn)，從而能夠收集 metrics 以及進(jìn)行相應(yīng)限流操作；二是限流能力，規(guī)則配置與下發(fā)；三是監(jiān)控與報(bào)警。

AHAS 和考拉海購原限流組件（NFC) 面向用戶使用層面基本一致，提供注解、API 顯示調(diào)用、Dubbo filter、http filter 等方式，在遷移時(shí)僅需要替換對(duì)應(yīng)的 API 即可，由于組件 API 相對(duì)簡單，因此接入成本還是比較低的。同時(shí) AHAS 也提供了 JavaAgent 接入能力，不需修改代碼即可接入。

在能力方面，AHAS 比原考拉的的組件更加完善，提供了基于系統(tǒng)負(fù)載的保護(hù)以及熔斷降級(jí)。原本有個(gè)需求是集群限流的功能，AHAS 團(tuán)隊(duì)很給力，在 618 之前上線了該功能讓我們用了起來。在監(jiān)控報(bào)警方面提供了實(shí)時(shí)的秒級(jí)監(jiān)控，TopN 接口展示等功能，很完善。也有流控自動(dòng)觸發(fā)報(bào)警，通過釘釘?shù)姆绞健?/p>

AHAS 故障演練：

考拉海購應(yīng)用部署在 ASI，Ahas-Chaos 通過 K8s 對(duì)外提供的 Operator 能力，在業(yè)務(wù)無感的情況完成了接入，并順利的參與到了集團(tuán) 527 聯(lián)合演練當(dāng)中。

8）壓測鏈路改造方案

考拉原本已經(jīng)有了一套全鏈路壓測的影子方案。其核心主要分為兩個(gè)部分：

• 全鏈路壓測標(biāo)透傳

• 流量攔截以實(shí)現(xiàn)影子路由、服務(wù) Mock 等

遷移第一步是要先接入應(yīng)用實(shí)時(shí)監(jiān)控服務(wù) ARMS；遷移第二步則是接入性能測試 PTS，支持 ARMS 和考拉組件，接管考拉原有的影子路由邏輯。

ARMS 和 PTS 本身都是使用 JavaAgent 的方式，通過字節(jié)碼增強(qiáng)來完成對(duì)各個(gè)基礎(chǔ)組件的埋點(diǎn)，這種操作的好處是接入成本低，業(yè)務(wù)感知小。最終我們順利完成了全鏈路壓測的改造。

9）同城雙活方案

考拉海購在遷移到集團(tuán)機(jī)房后，一段時(shí)間內(nèi)還存在自建、云產(chǎn)品和集團(tuán)組件三者共存的情況，基于現(xiàn)狀，我們?cè)O(shè)計(jì)了一套自有的雙活及 SPE 方案。

線上正常狀態(tài)：

基于 DNS 和 Vipserver 的同機(jī)房優(yōu)先，既能支持日常的流量隨機(jī)，也能支持單機(jī)房流量隔離。

單機(jī)房壓測下狀態(tài)：

基礎(chǔ)設(shè)施即代碼 (IaC)

1. 什么是 IaC

Infrastructure as Code ——基礎(chǔ)設(shè)施即代碼，是一種使用新的技術(shù)來構(gòu)建和管理動(dòng)態(tài)基礎(chǔ)設(shè)施的方式。它把基礎(chǔ)設(shè)施、工具和服務(wù)以及對(duì)基礎(chǔ)設(shè)施的管理本身作為一個(gè)軟件系統(tǒng)，采納軟件工程實(shí)踐以結(jié)構(gòu)化的安全的方式來管理對(duì)系統(tǒng)的變更。

我的理解就是，通過將軟件的運(yùn)行環(huán)境、軟件的依賴，及軟件的代碼進(jìn)行一致化的管理（變更，版本等），并提供類似 BaaS 化的解耦方式，使得軟件不被某個(gè)特定環(huán)境綁定，可以在任意環(huán)境快速復(fù)制運(yùn)行。

2. 實(shí)踐內(nèi)容

1）構(gòu)建部署體系

我們?cè)诳祭械膽?yīng)用 DevOps 體系之上，結(jié)合 IaC & GitOps 理念，對(duì)應(yīng)用的構(gòu)建、部署、配置加載、日常運(yùn)維等方面基于 AppStack & IaC 做了改造，相關(guān)的構(gòu)建、部署、應(yīng)用靜態(tài)配置全部遷移到應(yīng)用 git 源碼中。借助于 git 對(duì)應(yīng)用所有相關(guān)配置進(jìn)行托管，配置的版本迭代相對(duì)于之前的模式更加的清晰，同時(shí)也能很有效的保證應(yīng)用源碼、構(gòu)建配置、容器配置、靜態(tài)配置的版本一致性。

2）輕量化容器

以本次云原生改造為契機(jī)，我們將考拉原有的容器鏡像體系與集團(tuán)標(biāo)準(zhǔn)進(jìn)行了對(duì)標(biāo)改造，比較大的變化就是將原有的啟動(dòng)用戶從 AppOps 修改為了 admin。

另一方面，我們引入了輕量化容器。作為云原生的基礎(chǔ)之一，容器層的隔離能力是一大賣點(diǎn)。考拉海購整體進(jìn)行了切換，完成了輕量化容器的改造，整體將 pod 分成了應(yīng)用容器、運(yùn)維容器，以及自定義容器幾類，整個(gè)部署變得更加的輕量級(jí)，也更加易于掌控。

改造后的部署形態(tài)見下圖。

3）CPU-share

上圖的模式是 CPU-set，即容器會(huì)綁定一部分 CPU，運(yùn)行時(shí)也只會(huì)使用綁定的 CPU，這種方式在正常的宿主機(jī)上運(yùn)行的效率是最高的，因?yàn)闇p少了 CPU 的切換。考拉海購的部署全部切換到了 CPU-share 模式，即在同一個(gè) NUMA chip 下，該容器可以使用該 chip 下所有的 CPU（ CPU 時(shí)間片總數(shù)不會(huì)超過 limit 配置），這樣只要該 chip 下有空閑的 CPU，就會(huì)使搶占不會(huì)太激烈，能大大提高運(yùn)行的穩(wěn)定性。

最終在大促峰值壓測的驗(yàn)證中，神龍機(jī)的 CPU 在 55% 以下都能保持一個(gè)比較穩(wěn)定的運(yùn)行狀態(tài)，進(jìn)而保證了整體服務(wù)的穩(wěn)定性，資源也得到了更充分的利用。

4）鏡像配置分離

鏡像配置分離指的是將應(yīng)用的容器鏡像和應(yīng)用依賴的配置（靜態(tài)配置、發(fā)布配置）隔離開獨(dú)立存放。這樣做的目的是能夠最大程度地復(fù)用應(yīng)用鏡像，減少應(yīng)用鏡像的構(gòu)建次數(shù)提高構(gòu)建部署效率；同時(shí)，遷移到 AppStack 后應(yīng)用代碼回滾時(shí)也會(huì)自動(dòng)回滾靜態(tài)配置，不需要業(yè)務(wù)手動(dòng)去靜態(tài)配置中心回滾靜態(tài)配置，極大降低了業(yè)務(wù)回滾的風(fēng)險(xiǎn)。

另外當(dāng)鏡像和配置分離后，鏡像可以在任何環(huán)境進(jìn)行部署，而不必依賴對(duì)應(yīng)環(huán)境的配置。這樣的話，我們發(fā)布流程就可以從面向變更，調(diào)整為面向制品，上線的即是測試的鏡像。

3. 實(shí)施策略

1）自動(dòng)化

IaC 遷移中任務(wù)較重的是配置遷移，環(huán)境遷移及整體標(biāo)準(zhǔn)化，提高遷移效率將極大加快 IaC 遷移的速度，也會(huì)給業(yè)務(wù)開發(fā)遷移過程中的心態(tài)帶來積極影響。

• 構(gòu)建發(fā)布配置存放在考拉舊有的部署平臺(tái)上，靜態(tài)配置存放在自研的配置中心上。舊有部署平臺(tái)首先打通考拉的配置中心和集團(tuán) gitlab 代碼倉庫，再根據(jù)標(biāo)準(zhǔn)化的 service.cue 模板自動(dòng)將舊有的部署中心和配置中心的各類配置直接創(chuàng)建到業(yè)務(wù)的代碼中，自動(dòng)完成 IaC 配置遷移工作，大大節(jié)約了業(yè)務(wù)遷移時(shí)間提高了遷移效率。

• 我們沉淀出了一套云原生環(huán)境的 API，具備了云原生環(huán)境以及云原生流水線的自動(dòng)化創(chuàng)建、修改以及刪除能力，也提高了業(yè)務(wù)接入效率。

IaC 自動(dòng)化遷移功能上線后，平均每個(gè)應(yīng)用大約只需要 1 分鐘的時(shí)間就可以完成各類配置的遷移、云原生環(huán)境、云原生流水線的創(chuàng)建，全程無需業(yè)務(wù)接入。在完成上述的配置映射及重建后，應(yīng)用只需要簡單的進(jìn)行構(gòu)建發(fā)布，然后解決部分由于兼容問題導(dǎo)致的啟動(dòng)不正常，即完成了 IaC 的遷移，整體成本比較低。

2）接入支持

IaC 的接入不同于中間件的升級(jí)，涉及到應(yīng)用的整個(gè)發(fā)布、部署體系的變化，并且當(dāng)前階段 AppStack 的穩(wěn)定性不算特別高，所以我們采取的接入策略是項(xiàng)目室封閉接入，全程提供技術(shù)支持，保證業(yè)務(wù)能夠第一時(shí)間解決問題，提高業(yè)務(wù)參與度和幸福感，也能在第一時(shí)間收集問題，助力我們優(yōu)化接入流程，比如前期業(yè)務(wù)需要手動(dòng)創(chuàng)建流水線，到后面我們通過 API 自動(dòng)給需要遷移的業(yè)務(wù)創(chuàng)建對(duì)應(yīng)的流水線。

而業(yè)務(wù)遷移 IaC 的實(shí)現(xiàn)又有兩個(gè)階段，兩個(gè)階段我們采用了不同的接入模式，通過在不同的階段，采用不同的支持方式，達(dá)到業(yè)務(wù)穩(wěn)定快速接入的目標(biāo)。

雙十一之前：

• 項(xiàng)目組出一人常駐項(xiàng)目室支持
• 每周一到周五，都有不同部門的開發(fā)到會(huì)議室專注遷移
• 每天上午培訓(xùn)相關(guān)知識(shí)，下午、晚上進(jìn)行應(yīng)用切換

雙十一之后：

• 項(xiàng)目組出三人常駐項(xiàng)目室支持
• 每周只遷移固定的部門，由部門派出固定的人完成該周的全部遷移工作
• 培訓(xùn)放在每周一上午

兩者的差異主要是前期平臺(tái)的穩(wěn)定程度，及業(yè)務(wù)研發(fā)的熟悉度比較低，所以接入相對(duì)比較謹(jǐn)慎，更多的是以一種驗(yàn)證，及推廣的心態(tài)來，后續(xù)相對(duì)穩(wěn)定之后，整體就是以平推的模式來進(jìn)行接入。

成果

1. 無重大故障發(fā)生

考拉海購的云原生改造周期很長，不管是 618 和 雙11 這樣的大促，或是每月的會(huì)員日等普通大促，在項(xiàng)目組成員的通力協(xié)作下，沒有因?yàn)樵圃脑煲鸬闹卮蠊收习l(fā)生。

2. 融合成績喜人

• 解決考拉海購和集團(tuán)應(yīng)用部署的差異，完全兼容當(dāng)前集團(tuán)的模式，在部署層面與集團(tuán)技術(shù)體系完成對(duì)齊。
• 解決考拉海購內(nèi)部調(diào)用和集團(tuán)調(diào)用的差異。
• 完成 SPE 和雙活建設(shè)，容災(zāi)體系進(jìn)一步和集團(tuán)對(duì)齊。

3. 效能提升、成本節(jié)約

• 遷移有狀態(tài)容器，每批次部署減少 100 秒，解決 IP 變更導(dǎo)致的啟動(dòng)失敗問題。
• 配置和代碼做到了強(qiáng)綁定，后續(xù)回滾的時(shí)候再也不需要關(guān)系靜態(tài)配置的回滾。
• 從日常容量到大促容量從各個(gè)應(yīng)用分別擴(kuò)容，到 0.5 人日完成全站擴(kuò)容到基準(zhǔn)水位。
• 服務(wù)器數(shù)量減少 250 臺(tái)。

4. 完善云產(chǎn)品功能

• 推動(dòng)解決云產(chǎn)品易用性、穩(wěn)定性問題，豐富云上中間件產(chǎn)品的場景豐富度。
• 推動(dòng)云原生過程中的安全生產(chǎn)、賬號(hào)等問題的解決。

未來，Mesh 是發(fā)力方向之一

技術(shù)下沉是互聯(lián)網(wǎng)發(fā)展的大趨勢。在微服務(wù)時(shí)代，Service Mesh 應(yīng)運(yùn)而生。雖然引入 Mesh 代理，會(huì)帶來一定性能損耗和資源開銷，以及 Mesh 服務(wù)實(shí)例的運(yùn)維和管理成本。但是其屏蔽了分布式系統(tǒng)的諸多復(fù)雜性，讓開發(fā)者可以回歸業(yè)務(wù)，聚焦真正的價(jià)值：

專注業(yè)務(wù)邏輯，通過 Mesh 屏蔽分布式系統(tǒng)通信的復(fù)雜性(負(fù)載均衡、服務(wù)發(fā)現(xiàn)、認(rèn)證授權(quán)、監(jiān)控追蹤、流量控制等)。

語言無關(guān)，服務(wù)可以用任何語言編寫。

解耦基礎(chǔ)設(shè)施，對(duì)應(yīng)用透明，Mesh 組件可以單獨(dú)升級(jí)，基礎(chǔ)設(shè)施可以更快的升級(jí)迭代。

考拉海購這一年來一直在堅(jiān)定的進(jìn)行云原生化改造，雖然過程中碰到了非常多的挑戰(zhàn)，但是我們從未懷疑過這一方向的正確性，并在每一次解決問題之后收獲到了更多的業(yè)務(wù)價(jià)值。今年 雙11，整個(gè)云原生升級(jí)幫助考拉減少了 250 臺(tái)服務(wù)器，并沉淀出一套完整的 IaaS + PaaS 上云落地實(shí)踐方案。考拉在云上的研發(fā)效率也有了大幅提升，例如使用阿里云直播中心服務(wù)，考拉快速完成了海外直播服務(wù)從 0 到 1 的搭建。此外，“爬樹 TV”、“Like 社區(qū)”等新功能也相繼上線。

隨著云原生改造的持續(xù)發(fā)展，云原生帶來的紅利也越來越顯著。我相信當(dāng)業(yè)務(wù)跟基礎(chǔ)設(shè)施進(jìn)一步解耦，有一天會(huì)實(shí)現(xiàn)業(yè)務(wù)與基礎(chǔ)設(shè)施無關(guān)，業(yè)務(wù)研發(fā)只需要關(guān)心自己的業(yè)務(wù)，再也不用為運(yùn)行環(huán)境而苦惱，進(jìn)而在運(yùn)研效率上獲得巨大的提升。

作者簡介

**張洪簫（花名：伏見）**阿里巴巴新零售高級(jí)技術(shù)專家，擁有 10 年開發(fā)測試運(yùn)維經(jīng)驗(yàn)，在基礎(chǔ)架構(gòu)和研發(fā)效能領(lǐng)域有非常豐富的經(jīng)驗(yàn)，積極的擁抱云原生，推崇持續(xù)、快速、高質(zhì)量的軟件交付方式。

想了解考拉 雙11 同款開源 & 云產(chǎn)品，歡迎參與 1 月 30 日 Spring Cloud Alibaba Meetup 廣州站，了解完美日記、虎牙是如何使用 SCA 全家桶賦能業(yè)務(wù)，落地微服務(wù)。

總結(jié)

以上是生活随笔為你收集整理的亲历者说 | 完整记录一年多考拉海购的云原生之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。