全球化技術(shù)根植于全球化業(yè)務(wù)，經(jīng)過五個階段的演進(jìn)，逐漸發(fā)展成為阿里巴巴集團(tuán)內(nèi)相對獨(dú)立的技術(shù)體系。本文會首先重點(diǎn)講解全球化基礎(chǔ)設(shè)施層的挑戰(zhàn)和技術(shù)實(shí)踐。

一、業(yè)務(wù)發(fā)展歷程

1.1 業(yè)務(wù)背景

從1999年阿里公司創(chuàng)立，阿里集團(tuán)的全球化即已開始，公司的第一個業(yè)務(wù)單元Alibaba.com即是全球化業(yè)務(wù)，后續(xù)在09年公司成立10周年之際AliExpressBeta版本上線，標(biāo)志著阿里的全球化走向TO C時代，再后來16年提出“接下來的20年，阿里巴巴集團(tuán)要服務(wù)20億消費(fèi)者、創(chuàng)造1億就業(yè)機(jī)會，幫助1000萬家中小企業(yè)盈利”，公司也陸續(xù)收購Lazada（東南亞6國）、Daraz（南亞5國）、Trendyol（土耳其）等海外電商公司，由此正式拉開了全球化作為阿里集團(tuán)三大戰(zhàn)略（消費(fèi)、云計(jì)算、全球化）之一的大航海時代。

 2016年阿里全球化相關(guān)業(yè)務(wù)收購陸續(xù)完成后，阿里集團(tuán)的全球化業(yè)務(wù)布局初步形成：

1. 上圖展示了當(dāng)前阿里全球化業(yè)務(wù)重點(diǎn)覆蓋的國家/地區(qū)，可以看到業(yè)務(wù)重點(diǎn)國家/地區(qū)橫跨亞、歐、美三大洲，業(yè)務(wù)訴求差異導(dǎo)致技術(shù)方案差異明顯，一套端到端的技術(shù)方案不可能完美支持所有的國家/地區(qū)，但是差異化的層次組合/定制被實(shí)踐證明可行，這對我們【系統(tǒng)的標(biāo)準(zhǔn)化】提出了要求；

2. 粗放收割的時代已經(jīng)過去，在精細(xì)化運(yùn)營時代，應(yīng)對用戶體驗(yàn)/合規(guī)監(jiān)管，更靠近用戶的技術(shù)方案部署，是本地體驗(yàn)構(gòu)筑的基礎(chǔ)，這又對我們【系統(tǒng)的輕量化】提出了要求；

3. 隨著數(shù)字化時代的日益深入，數(shù)字化/智能化正越來越深刻地影響和改變著人類社會的方方面面。作為全球化業(yè)務(wù)，不論我們的用戶來自發(fā)達(dá)國家還是發(fā)展中國家，讓數(shù)字/智能助力用戶生活更美好，永遠(yuǎn)是我們堅(jiān)持的目標(biāo)，而這也對我們【系統(tǒng)的智能化】提出了要求。

1.2 全球化技術(shù)體系迭代過程

 為應(yīng)對上述業(yè)務(wù)訴求，全球化技術(shù)體系正式從集團(tuán)技術(shù)體系中孵化出來，并經(jīng)過五個階段的演進(jìn)逐漸發(fā)展成為阿里巴巴集團(tuán)內(nèi)相對獨(dú)立的技術(shù)體系。

1.  階段一，基于國內(nèi)淘寶、天貓、搜推等團(tuán)隊(duì)的系統(tǒng)，在6個月的時間搭建了全套支持Lazada的新電商內(nèi)核系統(tǒng)。

2. 階段二，在這套電商內(nèi)核系統(tǒng)上進(jìn)行相應(yīng)定制，搭建了全套支持Daraz的新電商系統(tǒng)。

3. 階段三，將這套電商內(nèi)核和AE系統(tǒng)進(jìn)行了深度融合，同時引入了淘寶、天貓等團(tuán)隊(duì)的優(yōu)秀系統(tǒng)解決方案，形成了可同時支持本地+跨境交易模式的國際化中臺的雛形。

4. 階段四，以上述融合版本為基礎(chǔ)，合并Lazada、Daraz、天貓?zhí)詫毢Ｍ?，完成國際化中臺技術(shù)分支的4合1動作，最終形成了現(xiàn)在1個中臺支撐N個站點(diǎn)的全球化新架構(gòu)。

5. 階段五，國際化中臺開源策略開始落地，歷時1年多到2021年11月完成中臺全鏈路開源，全球化業(yè)務(wù)和中臺各自閉環(huán)迭代局面形成。

6.   階段六，未來已來，敬請期待。

接下來，我們會用一個系列文章，為大家講清楚全球化技術(shù)體系的挑戰(zhàn)和應(yīng)對。在本文中，我們會首先和大家分享下全球化基礎(chǔ)設(shè)施層的挑戰(zhàn)和技術(shù)實(shí)踐。

 二、全球化基礎(chǔ)設(shè)施層面面臨的挑戰(zhàn)

從電商網(wǎng)站服務(wù)買賣家客戶和網(wǎng)站經(jīng)營兩方面去分析，在全球范圍內(nèi)除了要滿足用戶訪問網(wǎng)站的性能、可用性等基本要求外，全球化背景下還新增了全球部署、法律合規(guī)、數(shù)據(jù)隔離等要求，這些要求使我們的基礎(chǔ)設(shè)施建設(shè)遇到了全新的挑戰(zhàn)，下面做一下舉例說明：

• 全球部署：無論是考量用戶體驗(yàn)，還是考量監(jiān)管合規(guī)，將基礎(chǔ)設(shè)施進(jìn)行全球化部署都是全球化業(yè)務(wù)必須要建設(shè)的基礎(chǔ)能力，全球部署的基礎(chǔ)設(shè)施也直接決定了全球化技術(shù)體系的很多具體架構(gòu)形態(tài)，同時全球部署的基礎(chǔ)設(shè)施本身的建設(shè)維護(hù)也是巨大的挑戰(zhàn)。
• 性能：這里說的性能指用戶請求處理的時延，用戶從發(fā)起請求到接收到響應(yīng)的延時越短，代表性能越好。而全球互聯(lián)網(wǎng)服務(wù)在延時上有天然的挑戰(zhàn)，即物理距離更長，機(jī)房可能在美國，而用戶可能在澳大利亞。我們測試數(shù)據(jù)顯示美國用戶請求美國互聯(lián)網(wǎng)服務(wù)一般的網(wǎng)絡(luò)RTT是10ms以內(nèi)，而俄羅斯用戶請求美國西部機(jī)房的RTT在150ms到300ms之間不等，這直接導(dǎo)致用戶的全屏加載時間會多出1秒鐘，而1秒鐘會造成轉(zhuǎn)化率下降，甚至是用戶流失。
• 可用性：服務(wù)全球用戶還有成本上的挑戰(zhàn)，這個挑戰(zhàn)會同時帶來系統(tǒng)可用性上的挑戰(zhàn)。如果僅從本地視角保障可用性，則我們需要在每個本地都建設(shè)雙機(jī)房保障高可用，但這樣就無法利用其它區(qū)域機(jī)房的閑置資源，整體成本也會非常高昂。而我們7*24小時的可用性要求建立在全球視角上，因此，如果能做到全球范圍的異地容災(zāi)，就可以在成本可接受的范圍內(nèi)，較好地兼顧用戶的可用性。
• 數(shù)據(jù)一致性：數(shù)據(jù)一致性挑戰(zhàn)是指當(dāng)有數(shù)據(jù)被全球多地用戶共享且多地用戶都會進(jìn)行讀寫時，如何確保數(shù)據(jù)一致？舉例：全球買全球賣的場景，買家在本地?cái)?shù)據(jù)中心創(chuàng)建訂單，賣家在其本地?cái)?shù)據(jù)中心維護(hù)訂單，如果是同一筆訂單且買家與賣家在不同的數(shù)據(jù)中心，如何保證多地讀寫一致？當(dāng)全球數(shù)據(jù)中心之間相互災(zāi)備時，也會存在多地讀寫的情況，如何保證數(shù)據(jù)一致。

另外近幾年隨著全球化部署架構(gòu)的升級，存量機(jī)房逐步往云機(jī)房遷移，新業(yè)務(wù)的擴(kuò)展以及合規(guī)的部署架構(gòu)都以云做為基礎(chǔ)設(shè)施，全球化業(yè)務(wù)都已經(jīng)運(yùn)行在了云上，同時云也提供了更豐富、靈活、無限的基礎(chǔ)設(shè)施能力。在云基礎(chǔ)設(shè)施之上，我們實(shí)踐了適用于海外的多模式部署以及容災(zāi)架構(gòu)，用于解決用戶的體驗(yàn)、可用性、數(shù)據(jù)一致性問題；并通過定義合規(guī)架構(gòu)，充分地滿足了各國法律對于業(yè)務(wù)合規(guī)的要求；與此同時，通過云原生的架構(gòu)理念定義了如何用云產(chǎn)品重塑軟件研發(fā)的過程。

下面將結(jié)合全球化面臨的挑戰(zhàn)，從海外部署和容災(zāi)架構(gòu)、數(shù)據(jù)合規(guī)、云原生架構(gòu)實(shí)戰(zhàn)三個角度詳細(xì)說明全球化出海以及合規(guī)的實(shí)踐。

三、基于云的出海落地實(shí)踐

3.1 海外部署和容災(zāi)實(shí)戰(zhàn)

3.1.1 阿里云基礎(chǔ)設(shè)施

• IAAS層：依托于阿里云全球一致的基礎(chǔ)設(shè)施，我們搭建了涉及全球6大區(qū)域、13個物理機(jī)房、17個邏輯機(jī)房(AZ)的海外數(shù)字商業(yè)的基礎(chǔ)設(shè)施，在享受彈性資源能力的同時卻無需在多個國家/地區(qū)部署和維護(hù)數(shù)據(jù)中心。
• PAAS層：依托于阿里云各類中間件/云產(chǎn)品進(jìn)行全球部署，從而自上而下地解決全球化的一系列技術(shù)挑戰(zhàn)。

3.1.2 全球化部署架構(gòu)

基于本對本和跨境兩種業(yè)務(wù)模式，我們有異地和同城兩種部署架構(gòu)，同時在一個區(qū)域機(jī)房內(nèi)我們往往需要部署多國家多站點(diǎn)的業(yè)務(wù)，從而衍生出了多租戶架構(gòu)，下面將詳細(xì)介紹我們在異地多活、同城雙活、單區(qū)域多租戶上的實(shí)踐。

區(qū)域化異地多活

AliExpress的核心需求是電商的全球買&全球賣，此外還要考慮到用戶就近訪問的網(wǎng)絡(luò)延時、容災(zāi)場景等。在這種多區(qū)域部署的場景以及核心需求的制約下，區(qū)域化部署的總體原則就很明確了，即不同于Amazon以及Lazada的本地站點(diǎn)模式，不同區(qū)域之間必須保障數(shù)據(jù)的一致性。比如當(dāng)來自不同區(qū)域的買賣家進(jìn)行交易時，需要保障共享數(shù)據(jù)的一致性；當(dāng)異地容災(zāi)時，用戶區(qū)域進(jìn)行遷移后，也需要保障不同區(qū)域服務(wù)統(tǒng)一用戶的一致性。

• 網(wǎng)絡(luò)層：用戶根據(jù)DNS就近解析到最近的機(jī)房IDC，到達(dá)該機(jī)房的統(tǒng)一接入層。
• 接入層：需要橋接一個統(tǒng)一路由層來對用戶歸屬進(jìn)行強(qiáng)一致性糾偏，即在接入層調(diào)用路由服務(wù)，查詢用戶的歸屬并實(shí)現(xiàn)跨機(jī)房調(diào)度，來達(dá)到用戶跨機(jī)房跳轉(zhuǎn)的目的。
• 服務(wù)層：對于強(qiáng)一致性數(shù)據(jù)，例如支付、交易等，需要對統(tǒng)一路由層的用戶歸屬進(jìn)行保障性兜底，即如果統(tǒng)一路由層路由錯誤，那么MSE層也需要將服務(wù)跨機(jī)房調(diào)用回用戶正確歸屬的機(jī)房進(jìn)行消費(fèi)；同時針對共享型數(shù)據(jù)的一致性問題，需要拓展出中心讀寫的跨機(jī)房服務(wù)調(diào)用功能；簡而言之，在MSE層需要實(shí)現(xiàn)根據(jù)用戶歸屬或者中心機(jī)房消費(fèi)的跨機(jī)房調(diào)用功能。
• 數(shù)據(jù)庫層：我們通過擴(kuò)展其插件，實(shí)現(xiàn)了禁寫功能，同樣是對于用戶歸屬錯誤和數(shù)據(jù)強(qiáng)一致性保障的兜底，即用戶歸屬區(qū)域如果和實(shí)際調(diào)用區(qū)域不一致，我們將會對其禁寫保護(hù)，來避免不同區(qū)域之間的數(shù)據(jù)臟寫。
• 數(shù)據(jù)同步層：中心機(jī)房和區(qū)域機(jī)房之間數(shù)據(jù)進(jìn)行雙向同步，保障異地容災(zāi)的數(shù)據(jù)一致性，避免用戶區(qū)域更改后的數(shù)據(jù)缺失情況。

本對本同城雙活

不同于AliExpress的全球買賣業(yè)務(wù)，Lazada/Daraz業(yè)務(wù)更聚焦在東南亞地區(qū)，采用的是本地買賣Local to Local模式，因此采用的是本對本同城雙活部署架構(gòu)。 

同城雙活容災(zāi)建設(shè)顧名思義在一個城市內(nèi)的兩個IDC進(jìn)行災(zāi)備建設(shè)，目標(biāo)是在一個IDC出現(xiàn)故障后能夠快速切換至另外一個IDC上，保證業(yè)務(wù)可用。采用雙單元部署架構(gòu)，借助單元化來實(shí)現(xiàn)單元內(nèi)流量自閉環(huán)隔離，數(shù)據(jù)庫使用RDS三節(jié)點(diǎn)企業(yè)版來保障其高可用性。一旦發(fā)現(xiàn)故障災(zāi)備，可以從入口流量、統(tǒng)一接入層等快速切換至另外一個IDC上，保障業(yè)務(wù)可用。

多租戶架構(gòu)

全球化業(yè)務(wù)的基本特點(diǎn)是多區(qū)域、多幣種、多語言，為了實(shí)現(xiàn)經(jīng)營策略精細(xì)化執(zhí)行，基于這幾個維度，可以確定業(yè)務(wù)經(jīng)營單元，為了實(shí)現(xiàn)每個經(jīng)營單元間的隔離和經(jīng)營地域元數(shù)據(jù)標(biāo)準(zhǔn)化，需要提出面向業(yè)務(wù)經(jīng)營區(qū)域的租戶概念，而在技術(shù)架構(gòu)層面需要提供統(tǒng)一的面向多區(qū)域的租戶架構(gòu)標(biāo)準(zhǔn)。每個經(jīng)營單元的業(yè)務(wù)體量、業(yè)務(wù)形態(tài)都存在一定的差異，所以從部署架構(gòu)上可以提供租戶的物理隔離和邏輯隔離兩種形態(tài)，在技術(shù)架構(gòu)上需要提供配置隔離、數(shù)據(jù)隔離、流量隔離能力，在租戶定義上需要保持統(tǒng)一的租戶模型。基于統(tǒng)一的租戶建立經(jīng)營單元和技術(shù)架構(gòu)之間的映射關(guān)系，從而能夠以租戶實(shí)現(xiàn)經(jīng)營單元維度的開發(fā)、測試、部署、運(yùn)維等研發(fā)活動，降低研發(fā)活動過程中經(jīng)營單元之間的耦合，提升經(jīng)營單元的獨(dú)立性。

基于多租戶架構(gòu)設(shè)計(jì)理念，運(yùn)行態(tài)內(nèi)部的工作原理分為如下幾個核心部分：

• 【流量染色】端上請求識別，確定是什么租戶的流量，并對流量進(jìn)行染色
• 【精確選址】基于流量染色，以及接入網(wǎng)關(guān)層的服務(wù)路由能力，精確選址到租戶所在物理集群
• 【鏈路透傳】集群單個服務(wù)實(shí)例內(nèi)部，需要解決租戶標(biāo)的透傳問題，以及跟上下游同步、異步交互過程中租戶信息的透傳
• 【資源隔離】在內(nèi)部業(yè)務(wù)邏輯執(zhí)行過程中，對任何資源的操作，都需要考慮隔離性問題，比如配置，數(shù)據(jù)，流量等

3.1.3 全球容災(zāi)解決方案

Region級和網(wǎng)絡(luò)不可用：機(jī)房級不可用，外網(wǎng)入口無法抵達(dá)物理機(jī)房或者各個物理機(jī)房之間無法互通。

服務(wù)級不可用：外網(wǎng)/內(nèi)網(wǎng)連通性正常，服務(wù)不可用。

數(shù)據(jù)層不可用：DB/緩存不可用。

網(wǎng)絡(luò)容災(zāi)：用戶的第一跳網(wǎng)絡(luò)路由之外（如小區(qū)網(wǎng)絡(luò)異常我們基本沒有什么操作空間），在接下來的第2->N跳，我們分別可以建設(shè)網(wǎng)絡(luò)運(yùn)營商切換能力（多CDN廠商互切），機(jī)房鏈路切換能力（Region級別互切），機(jī)房入口運(yùn)營商切換能力（IDC網(wǎng)絡(luò)團(tuán)隊(duì)互切）等各種手段來嘗試進(jìn)行災(zāi)難恢復(fù)。

接入層容災(zāi)：在流量抵達(dá)阿里云機(jī)房，進(jìn)入內(nèi)部網(wǎng)關(guān)路由層后，按照用戶粒度級別、Api粒度級別等多維度進(jìn)行實(shí)時流量糾偏，秒級生效。在網(wǎng)絡(luò)以及網(wǎng)關(guān)產(chǎn)品無異常的情況下，接入層容災(zāi)是日常態(tài)被應(yīng)用、演練次數(shù)最多的容災(zāi)方案。

服務(wù)層容災(zāi)：對于某些強(qiáng)中心服務(wù)，例如庫存、營銷等單區(qū)域扣減服務(wù)，也需要建設(shè)其災(zāi)備能力。

數(shù)據(jù)層容災(zāi)：對于多活架構(gòu)，在確保數(shù)據(jù)單一Master的基礎(chǔ)上，確保容災(zāi)過程中數(shù)據(jù)不會臟寫。對于合規(guī)場景，考慮某些Region不具備敏感數(shù)據(jù)，實(shí)現(xiàn)有限定場景下的合規(guī)容災(zāi)能力。

3.2 全球數(shù)據(jù)合規(guī)實(shí)戰(zhàn)

3.2.1 全球合規(guī)領(lǐng)域介紹

對于互聯(lián)網(wǎng)電商平臺，整體風(fēng)險合規(guī)領(lǐng)域非常寬泛，風(fēng)險以及合規(guī)領(lǐng)域的差別，各自的內(nèi)容大致如上圖所示。合規(guī)一般主要涉及以下內(nèi)容：數(shù)據(jù)合規(guī)、知識產(chǎn)權(quán)侵權(quán)、商品內(nèi)容安全、交互內(nèi)容安全、技術(shù)出口合規(guī)、APP合規(guī)等，這些內(nèi)容也是當(dāng)下監(jiān)管關(guān)注的重點(diǎn)，除數(shù)據(jù)合規(guī)外，其他合規(guī)問題主要集中在個別業(yè)務(wù)場景，例如知產(chǎn)侵權(quán)、商品內(nèi)容安全主要存在于商品域，交互內(nèi)容安全則主要存在于買賣家溝通、直播等場景。

合規(guī)工作的重點(diǎn)是數(shù)據(jù)合規(guī)，幾乎貫穿電商平臺的所有場景，凡是涉及到數(shù)據(jù)處理的問題，都可以和數(shù)據(jù)合規(guī)相關(guān)，同時數(shù)據(jù)合規(guī)由于其監(jiān)管的敏感性，對于平臺來說屬于業(yè)務(wù)熔斷性風(fēng)險。

3.2.2 數(shù)據(jù)合規(guī)要求與部署架構(gòu)

 根據(jù)個人數(shù)據(jù)封閉范圍，跨境業(yè)務(wù)一般分為區(qū)域化架構(gòu)方案、隱私數(shù)據(jù)封閉方案和個人數(shù)據(jù)封閉方案三種。本對本業(yè)務(wù)則采用獨(dú)立單元封閉方案。

業(yè)務(wù)模式	方案	數(shù)據(jù)范圍
跨境業(yè)務(wù)	1. 區(qū)域化架構(gòu)	無針對性數(shù)據(jù)隔離，針對區(qū)域機(jī)房進(jìn)行按需過濾
	2. 隱私數(shù)據(jù)封閉	各區(qū)域隱私數(shù)據(jù)隔離，中心機(jī)房無區(qū)域非脫敏隱私數(shù)據(jù)
	3. 個人數(shù)據(jù)封閉	各區(qū)域個人數(shù)據(jù)隔離，中心機(jī)房無區(qū)域非脫敏隱私數(shù)據(jù)
本對本業(yè)務(wù)	4. 獨(dú)立單元封閉	類似全數(shù)據(jù)隔離，數(shù)據(jù)本地獨(dú)立單元隔離，本地完成業(yè)務(wù)部署

3.2.3 本地存儲解決方案

數(shù)據(jù)合規(guī)層面經(jīng)常會面臨一個直接的監(jiān)管訴求：數(shù)據(jù)本地存儲（不允許離境 or 本地留存?zhèn)洳椋?。甚至某些敏感業(yè)務(wù)存在更高的監(jiān)管要求，會存在不允許使用公有云或者公有云資源高安全獨(dú)立的情況。為此我們需要具備自建完整基礎(chǔ)設(shè)施以滿足合規(guī)建站需求的能力。

3.3 應(yīng)用架構(gòu)云原生化

云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API等。這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段，云原生技術(shù)使工程師能夠輕松地對系統(tǒng)作出頻繁和可預(yù)測的重大變更。

對于全球化技術(shù)研發(fā)而言，除了將業(yè)務(wù)運(yùn)行在云上，也需要進(jìn)一步從自身業(yè)務(wù)研發(fā)的挑戰(zhàn)以及痛點(diǎn)出發(fā)，結(jié)合云原生的技術(shù)以及相關(guān)的架構(gòu)理念來解決業(yè)務(wù)研發(fā)、運(yùn)維本身的效率問題。

3.3.1傳統(tǒng)應(yīng)用架構(gòu)面臨的挑戰(zhàn)

圖 傳統(tǒng)應(yīng)用架構(gòu)模式

上圖描述了傳統(tǒng)應(yīng)用架構(gòu)下的軟件交付過程。從這整個過程中看，應(yīng)用扮演了研發(fā)態(tài)的對象、交付態(tài)的載體、運(yùn)行態(tài)的容器，軟件能力所期望的所有能力都是通過在應(yīng)用源碼中聲明式的引用，并且通過統(tǒng)一構(gòu)建完成軟件整體性交付，這個過程可以叫做軟件的富應(yīng)用（Fat Application）交付。

由于全球化平臺最初是從實(shí)際的業(yè)務(wù)系統(tǒng)演進(jìn)而來的（交易、營銷、支付.....），所以平臺也不例外，延續(xù)了傳統(tǒng)的應(yīng)用架構(gòu)模式。但隨著平臺自身逐漸演進(jìn)，以及平臺之上的業(yè)務(wù)多樣性發(fā)展，不管是從組織架構(gòu)還是業(yè)務(wù)架構(gòu)上都帶來了很大的沖擊，主要面臨著如下三方面挑戰(zhàn)：

應(yīng)用架構(gòu)不可持續(xù)：富應(yīng)用交付模式下，在軟件生產(chǎn)過程中，始終存在一個單點(diǎn)——應(yīng)用，當(dāng)應(yīng)用所支撐的內(nèi)容逐漸龐大和復(fù)雜的時候，那么它將是影響研發(fā)效率的關(guān)鍵點(diǎn)，也是影響整個國際化平臺架構(gòu)的可持續(xù)性的最大挑戰(zhàn)。

研發(fā)交付不確定性：全球化平臺和業(yè)務(wù)分層的研發(fā)模式在目的和變更節(jié)奏是不一致的。為解決這兩者的差異，會導(dǎo)致應(yīng)用自身逐漸臃腫和腐蝕，于是給日常研發(fā)迭代帶來很大的不確定性和不可預(yù)見性。

運(yùn)維能力缺乏標(biāo)準(zhǔn)：隨著應(yīng)用自身的復(fù)雜度增加，與之匹配的運(yùn)維能力也會隨之增加，而當(dāng)前提倡的DevOps理念，也衍生出很多相關(guān)的產(chǎn)品和工具，但這些產(chǎn)品和工具的標(biāo)準(zhǔn)不統(tǒng)一，進(jìn)而造成零散繁雜、無統(tǒng)一產(chǎn)品入口的現(xiàn)象，導(dǎo)致運(yùn)維效率和理解成本不斷增加。

針對上面的挑戰(zhàn)，云原生技術(shù)提供給我們新的解題思路：

容器編排技術(shù)：通過云原生的容器編排技術(shù)將傳統(tǒng)的軟件交付過程演進(jìn)為各個容器編排組合式交付，將單個應(yīng)用交付拆分成多個模塊靈活編排交付，從而推動全球化應(yīng)用交付體系的演進(jìn)。

交付物鏡像化：應(yīng)用不再是研發(fā)的唯一對象，而是打造鏡像研發(fā)體系，基于鏡像的不變性來確保交付內(nèi)容的確定性，并實(shí)現(xiàn)平臺能力鏡像化，具有獨(dú)立穩(wěn)定的研發(fā)體系。

統(tǒng)一運(yùn)維標(biāo)準(zhǔn)：借助云原生IaC/OAM等GitOps理念，通過統(tǒng)一的模式去收斂并定義云原生下的應(yīng)用運(yùn)維標(biāo)準(zhǔn)。并重新定義業(yè)務(wù)組織的SRE，通過統(tǒng)一視角去查詢、分析、度量應(yīng)用的運(yùn)維能力現(xiàn)狀和資源使用情況。

3.2 全球化云原生架構(gòu)實(shí)踐

3.2.1 基于云原生的應(yīng)用架構(gòu)

結(jié)合上文提到的云原生解題思路，我們對整體的全球化研發(fā)交付過程進(jìn)行了抽象，用于支撐更廣義的全球化應(yīng)用架構(gòu)升級。這個過程中，我們也充分結(jié)合了云原生中先進(jìn)的技術(shù)，并應(yīng)用到全球化的場景中：

IaC：提供統(tǒng)一研發(fā)基礎(chǔ)設(shè)施聲明范式。為了將平臺對業(yè)務(wù)依賴進(jìn)行更好的解耦，降低平臺認(rèn)知成本，我們對站點(diǎn)應(yīng)用的IaC進(jìn)行了分層抽象標(biāo)準(zhǔn)定義，圍繞全球化場景定義基礎(chǔ)設(shè)施標(biāo)準(zhǔn)，從規(guī)格、日志采集、探針、hook、發(fā)布策略等進(jìn)行統(tǒng)一收斂，降低業(yè)務(wù)接入IaC成本。

OAM：提供統(tǒng)一應(yīng)用模型的定義。依托于OAM開發(fā)和運(yùn)維關(guān)注點(diǎn)分離、平臺無關(guān)與高可擴(kuò)展、模塊化應(yīng)用部署和運(yùn)維等特點(diǎn)，我們對業(yè)務(wù)和平臺面向應(yīng)用的標(biāo)準(zhǔn)進(jìn)行規(guī)范定義，從而更好地鏈接應(yīng)用開發(fā)者、運(yùn)維人員、應(yīng)用基礎(chǔ)設(shè)施，讓云原生應(yīng)用交付和管理流程更加連貫一致。

GitOps：提供業(yè)務(wù)研發(fā)持續(xù)交付能力?；谠圃鶪itOps聲明式理念，可以將外部依賴組件從能力集成到運(yùn)維管控統(tǒng)一聲明在工程之中，進(jìn)而只需要基于統(tǒng)一的GitOps標(biāo)準(zhǔn)進(jìn)行依賴能力的聲明和定義，從而將組件能力的交付和管控交給底層的GitOps引擎，提升整個軟件系統(tǒng)的完整性和可持續(xù)性。

ACK：提供資源統(tǒng)一調(diào)度引擎。我們基于阿里云的ACK容器服務(wù)，使用其提供的強(qiáng)大的容器編排、資源調(diào)度、和自動化運(yùn)維等能力，實(shí)現(xiàn)對不同環(huán)境交付不同的業(yè)務(wù)模塊功能，并且基于上層的流量調(diào)度，實(shí)現(xiàn)業(yè)務(wù)按需部署，按需調(diào)度。

容器編排：通過ACK容器靈活編排技術(shù)成功的將全球化應(yīng)用架構(gòu)再升級，將業(yè)務(wù)邏輯和基礎(chǔ)設(shè)施、平臺能力、公共富客戶端在研發(fā)態(tài)進(jìn)行完全隔離，在運(yùn)行態(tài)業(yè)務(wù)進(jìn)程和運(yùn)維進(jìn)程通過輕量化容器做到相對徹底的隔離，提升整體應(yīng)用研發(fā)交付效率和業(yè)務(wù)形態(tài)的穩(wěn)定性。

圖 應(yīng)用架構(gòu)在容器態(tài)的集成

這里重點(diǎn)強(qiáng)調(diào)一下容器編排的實(shí)踐。在全球化應(yīng)用架構(gòu)升級的過程中一共衍生出了三大類容器，如上圖所示：

基礎(chǔ)設(shè)施容器（Base Container），其中就包含運(yùn)維容器、網(wǎng)關(guān)容器等應(yīng)用所依賴的基礎(chǔ)設(shè)施的能力；

臨時容器（Temporary Container），該容器不具備任何生命周期，其作用就是為了將自身的研發(fā)產(chǎn)物通過Pod下的共享目錄集成到主應(yīng)用容器和業(yè)務(wù)容器內(nèi)，完成整個能力的集成和被使用，主要由平臺容器構(gòu)成；

業(yè)務(wù)容器（Business Container），該容器和主應(yīng)用容器一樣，具備完整的生命周期，且通過gRPC完成和主應(yīng)用的通信，主要由類目、多語等富客戶端容器構(gòu)成。

3.2.2 基于云原生的運(yùn)維體系

 

圖 全球化應(yīng)用架構(gòu)中的運(yùn)維體系

結(jié)合著應(yīng)用架構(gòu)的升級，全球化也對應(yīng)用的運(yùn)維體系進(jìn)行了升級。借助云原生架構(gòu)體系與IaC標(biāo)準(zhǔn)的聲明式引用, 全球化統(tǒng)一了多種應(yīng)用運(yùn)維能力的使用，并且通過基礎(chǔ)設(shè)施的強(qiáng)大能力實(shí)現(xiàn)了效率提升, 包括但不限于：

• 應(yīng)用發(fā)布: 智能發(fā)布決策、原地升級、滾動升級、分批發(fā)布
• 彈性容量: 自動彈性、定時彈性、CPUShare
• 批量運(yùn)維：應(yīng)用容器的原地重啟、容器置換、日志清理、JavaDump
• 輕量化容器: 運(yùn)維容器獨(dú)立、Sidecar編排
• 多容器交付部署: 端口沖突、進(jìn)程沖突、文件目錄共享
• 可觀測與穩(wěn)定性: 應(yīng)用生命周期、啟動異常診斷、白屏化、容器視角監(jiān)控

圖 云資源BaaS化

 在這個運(yùn)維體系中，全球化也引入了云原生的BaaS能力。BaaS提供一整套面向終態(tài)的、關(guān)注點(diǎn)分離(Application、Infrastructure)的解決方案，打通了阿里云及中間件資源的生產(chǎn)、計(jì)量計(jì)費(fèi)、身份授權(quán)、消費(fèi)流程，將IaC作為入口提供端到端的使用體驗(yàn)。全球化通過引入BaaS能力, 實(shí)現(xiàn)了SRE對應(yīng)用云資源使用的統(tǒng)一度量管理, 同時研發(fā)人員可以通過BaaS實(shí)現(xiàn)多種資源的一致性聲明式使用, 大大降低了使用成本。

圖 Java進(jìn)程生命周期規(guī)范化

為了提升云原生環(huán)境下的應(yīng)用自愈能力, 我們也統(tǒng)一了Java應(yīng)用在K8sPod中的生命周期規(guī)范，將應(yīng)用啟動、運(yùn)行(存活與就緒)、停服等不同階段進(jìn)行標(biāo)準(zhǔn)化定義, 并通過IaC和SDK的模式開放給業(yè)務(wù)使用，實(shí)現(xiàn)Java應(yīng)用生命周期和容器生命周期的一致性綁定。

四、總結(jié)與展望

技術(shù)服務(wù)于業(yè)務(wù)，全球化技術(shù)根植于全球化業(yè)務(wù)，在“讓天下沒有難做的生意”的業(yè)務(wù)方向上，我們還有很多事情沒有做好。同樣，雖然歷經(jīng)多年建設(shè)，全球化技術(shù)體系也還有非常多不完善的地方，也還有非常多技術(shù)挑戰(zhàn)待克服，我們依然在路上。