全球化技術根植於全球化業務，經過五個階段的演進，逐漸發展成為阿里巴巴集團內相對獨立的技術體系。本文會首先重點講解全球化基礎設施層的挑戰和技術實踐。
一、業務發展歷程
1.1 業務背景
從1999年阿里公司創立，阿里集團的全球化即已開始，公司的第一個業務單元Alibaba.com即是全球化業務，後續在09年公司成立10週年之際AliExpressBeta版本上線，標誌著阿里的全球化走向TO C時代，再後來16年提出“接下來的20年，阿里巴巴集團要服務20億消費者、創造1億就業機會，幫助1000萬家中小企業盈利”，公司也陸續收購Lazada（東南亞6國）、Daraz（南亞5國）、Trendyol（土耳其）等海外電商公司，由此正式拉開了全球化作為阿里集團三大戰略（消費、雲端計算、全球化）之一的大航海時代。
2016年阿里全球化相關業務收購陸續完成後，阿里集團的全球化業務佈局初步形成：
- 上圖展示了當前阿里全球化業務重點覆蓋的國家/地區，可以看到業務重點國家/地區橫跨亞、歐、美三大洲，業務訴求差異導致技術方案差異明顯，一套端到端的技術方案不可能完美支援所有的國家/地區，但是差異化的層次組合/定製被實踐證明可行，這對我們【系統的標準化】提出了要求；
- 粗放收割的時代已經過去，在精細化運營時代，應對使用者體驗/合規監管，更靠近使用者的技術方案部署，是本地體驗構築的基礎，這又對我們【系統的輕量化】提出了要求；
- 隨著數字化時代的日益深入，數字化/智慧化正越來越深刻地影響和改變著人類社會的方方面面。作為全球化業務，不論我們的使用者來自已開發國家還是發展中國家，讓數字/智慧助力使用者生活更美好，永遠是我們堅持的目標，而這也對我們【系統的智慧化】提出了要求。
1.2 全球化技術體系迭代過程
為應對上述業務訴求，全球化技術體系正式從集團技術體系中孵化出來，並經過五個階段的演進逐漸發展成為阿里巴巴集團內相對獨立的技術體系。
1.階段一，基於國內淘寶、天貓、搜推等團隊的系統，在6個月的時間搭建了全套支援Lazada的新電商核心系統。
2.階段二，在這套電商核心系統上進行相應定製，搭建了全套支援Daraz的新電商系統。
3.階段三，將這套電商核心和AE系統進行了深度融合，同時引入了淘寶、天貓等團隊的優秀系統解決方案，形成了可同時支援本地+跨境交易模式的國際化中臺的雛形。
4.階段四，以上述融合版本為基礎，合併Lazada、Daraz、天貓淘寶海外，完成國際化中臺技術分支的4合1動作，最終形成了現在1箇中臺支撐N個站點的全球化新架構。
5.階段五，國際化中臺開源策略開始落地，歷時1年多到2021年11月完成中臺全鏈路開源，全球化業務和中臺各自閉環迭代局面形成。
6.階段六，未來已來，敬請期待。
接下來，我們會用一個系列文章，為大家講清楚全球化技術體系的挑戰和應對。在本文中，我們會首先和大家分享下全球化基礎設施層的挑戰和技術實踐。
二、全球化基礎設施層面面臨的挑戰
從電商網站服務買賣家客戶和網站經營兩方面去分析，在全球範圍內除了要滿足使用者訪問網站的效能、可用性等基本要求外，全球化背景下還新增了全球部署、法律合規、資料隔離等要求，這些要求使我們的基礎設施建設遇到了全新的挑戰，下面做一下舉例說明：
·全球部署：無論是考量使用者體驗，還是考量監管合規，將基礎設施進行全球化部署都是全球化業務必須要建設的基礎能力，全球部署的基礎設施也直接決定了全球化技術體系的很多具體架構形態，同時全球部署的基礎設施本身的建設維護也是巨大的挑戰。
·效能：這裡說的效能指使用者請求處理的時延，使用者從發起請求到接收到響應的延時越短，代表效能越好。而全球網際網路服務在延時上有天然的挑戰，即物理距離更長，機房可能在美國，而使用者可能在澳大利亞。我們測試資料顯示美國使用者請求美國網際網路服務一般的網路RTT是10ms以內，而俄羅斯使用者請求美國西部機房的RTT在150ms到300ms之間不等，這直接導致使用者的全屏載入時間會多出1秒鐘，而1秒鐘會造成轉化率下降，甚至是使用者流失。
·可用性：服務全球使用者還有成本上的挑戰，這個挑戰會同時帶來系統可用性上的挑戰。如果僅從本地視角保障可用性，則我們需要在每個本地都建設雙機房保障高可用，但這樣就無法利用其它區域機房的閒置資源，整體成本也會非常高昂。而我們7*24小時的可用性要求建立在全球視角上，因此，如果能做到全球範圍的異地容災，就可以在成本可接受的範圍內，較好地兼顧使用者的可用性。
·資料一致性：資料一致性挑戰是指當有資料被全球多地使用者共享且多地使用者都會進行讀寫時，如何確保資料一致？舉例：全球買全球賣的場景，買家在本地資料中心建立訂單，賣家在其本地資料中心維護訂單，如果是同一筆訂單且買家與賣家在不同的資料中心，如何保證多地讀寫一致？當全球資料中心之間相互災備時，也會存在多地讀寫的情況，如何保證資料一致。
另外近幾年隨著全球化部署架構的升級，存量機房逐步往雲機房遷移，新業務的擴充套件以及合規的部署架構都以雲做為基礎設施，全球化業務都已經執行在了雲上，同時雲也提供了更豐富、靈活、無限的基礎設施能力。在雲基礎設施之上，我們實踐了適用於海外的多模式部署以及容災架構，用於解決使用者的體驗、可用性、資料一致性問題；並通過定義合規架構，充分地滿足了各國法律對於業務合規的要求；與此同時，通過雲原生的架構理念定義瞭如何用雲產品重塑軟體研發的過程。
下面將結合全球化面臨的挑戰，從海外部署和容災架構、資料合規、雲原生架構實戰三個角度詳細說明全球化出海以及合規的實踐。
三、基於雲的出海落地實踐
3.1 海外部署和容災實戰
3.1.1 阿里雲基礎設施
·IAAS層：依託於阿里雲全球一致的基礎設施，我們搭建了涉及全球6大區域、13個物理機房、17個邏輯機房(AZ)的海外數字商業的基礎設施，在享受彈性資源能力的同時卻無需在多個國家/地區部署和維護資料中心。
·PAAS層：依託於阿里雲各類中介軟體/雲產品進行全球部署，從而自上而下地解決全球化的一系列技術挑戰。
3.1.2 全球化部署架構
基於本對本和跨境兩種業務模式，我們有異地和同城兩種部署架構，同時在一個區域機房內我們往往需要部署多國家多站點的業務，從而衍生出了多租戶架構，下面將詳細介紹我們在異地多活、同城雙活、單區域多租戶上的實踐。
區域化異地多活
AliExpress的核心需求是電商的全球買&全球賣，此外還要考慮到使用者就近訪問的網路延時、容災場景等。在這種多區域部署的場景以及核心需求的制約下，區域化部署的總體原則就很明確了，即不同於Amazon以及Lazada的本地站點模式，不同區域之間必須保障資料的一致性。比如當來自不同區域的買賣家進行交易時，需要保障共享資料的一致性；當異地容災時，使用者區域進行遷移後，也需要保障不同區域服務統一使用者的一致性。
·網路層：使用者根據DNS就近解析到最近的機房IDC，到達該機房的統一接入層。
·接入層：需要橋接一個統一路由層來對使用者歸屬進行強一致性糾偏，即在接入層呼叫路由服務，查詢使用者的歸屬並實現跨機房排程，來達到使用者跨機房跳轉的目的。
·服務層：對於強一致性資料，例如支付、交易等，需要對統一路由層的使用者歸屬進行保障性兜底，即如果統一路由層路由錯誤，那麼MSE層也需要將服務跨機房呼叫回使用者正確歸屬的機房進行消費；同時針對共享型資料的一致性問題，需要擴充出中心讀寫的跨機房服務呼叫功能；簡而言之，在MSE層需要實現根據使用者歸屬或者中心機房消費的跨機房呼叫功能。
·資料庫層：我們通過擴充套件其外掛，實現了禁寫功能，同樣是對於使用者歸屬錯誤和資料強一致性保障的兜底，即使用者歸屬區域如果和實際呼叫區域不一致，我們將會對其禁防寫，來避免不同區域之間的資料髒寫。
·資料同步層：中心機房和區域機房之間資料進行雙向同步，保障異地容災的資料一致性，避免使用者區域更改後的資料缺失情況。
本對本同城雙活
不同於AliExpress的全球買賣業務，Lazada/Daraz業務更聚焦在東南亞地區，採用的是本地買賣Local to Local模式，因此採用的是本對本同城雙活部署架構。
同城雙活容災建設顧名思義在一個城市內的兩個IDC進行災備建設，目標是在一個IDC出現故障後能夠快速切換至另外一個IDC上，保證業務可用。採用雙單元部署架構，藉助單元化來實現單元內流量自閉環隔離，資料庫使用RDS三節點企業版來保障其高可用性。一旦發現故障災備，可以從入口流量、統一接入層等快速切換至另外一個IDC上，保障業務可用。
多租戶架構
全球化業務的基本特點是多區域、多幣種、多語言，為了實現經營策略精細化執行，基於這幾個維度，可以確定業務經營單元，為了實現每個經營單元間的隔離和經營地域後設資料標準化，需要提出面向業務經營區域的租戶概念，而在技術架構層面需要提供統一的面向多區域的租戶架構標準。每個經營單元的業務體量、業務形態都存在一定的差異，所以從部署架構上可以提供租戶的物理隔離和邏輯隔離兩種形態，在技術架構上需要提供配置隔離、資料隔離、流量隔離能力，在租戶定義上需要保持統一的租戶模型。基於統一的租戶建立經營單元和技術架構之間的對映關係，從而能夠以租戶實現經營單元維度的開發、測試、部署、運維等研發活動，降低研發活動過程中經營單元之間的耦合，提升經營單元的獨立性。
基於多租戶架構設計理念，執行態內部的工作原理分為如下幾個核心部分：
·【流量染色】端上請求識別，確定是什麼租戶的流量，並對流量進行染色
·【精確選址】基於流量染色，以及接入閘道器層的服務路由能力，精確選址到租戶所在物理叢集
·【鏈路透傳】叢集單個服務例項內部，需要解決租戶標的透傳問題，以及跟上下游同步、非同步互動過程中租戶資訊的透傳
·【資源隔離】在內部業務邏輯執行過程中，對任何資源的操作，都需要考慮隔離性問題，比如配置，資料，流量等
3.1.3 全球容災解決方案
·Region級和網路不可用：機房級不可用，外網入口無法抵達物理機房或者各個物理機房之間無法互通。
·服務級不可用：外網/內網連通性正常，服務不可用。
·資料層不可用：DB/快取不可用。
·網路容災：使用者的第一跳網路路由之外（如小區網路異常我們基本沒有什麼操作空間），在接下來的第2->N跳，我們分別可以建設網路運營商切換能力（多CDN廠商互切），機房鏈路切換能力（Region級別互切），機房入口運營商切換能力（IDC網路團隊互切）等各種手段來嘗試進行災難恢復。
·接入層容災：在流量抵達阿里雲機房，進入內部閘道器路由層後，按照使用者粒度級別、Api粒度級別等多維度進行實時流量糾偏，秒級生效。在網路以及閘道器產品無異常的情況下，接入層容災是日常態被應用、演練次數最多的容災方案。
·服務層容災：對於某些強中心服務，例如庫存、營銷等單區域扣減服務，也需要建設其災備能力。
·資料層容災：對於多活架構，在確保資料單一Master的基礎上，確保容災過程中資料不會髒寫。對於合規場景，考慮某些Region不具備敏感資料，實現有限定場景下的合規容災能力。
3.2全球資料合規實戰
3.2.1 全球合規領域介紹
對於網際網路電商平臺，整體風險合規領域非常寬泛，風險以及合規領域的差別，各自的內容大致如上圖所示。合規一般主要涉及以下內容：資料合規、智慧財產權侵權、商品內容安全、互動內容安全、技術出口合規、APP合規等，這些內容也是當下監管關注的重點，除資料合規外，其他合規問題主要集中在個別業務場景，例如知產侵權、商品內容安全主要存在於商品域，互動內容安全則主要存在於買賣家溝通、直播等場景。
合規工作的重點是資料合規，幾乎貫穿電商平臺的所有場景，凡是涉及到資料處理的問題，都可以和資料合規相關，同時資料合規由於其監管的敏感性，對於平臺來說屬於業務熔斷性風險。
3.2.2 資料合規要求與部署架構
根據個人資料封閉範圍，跨境業務一般分為區域化架構方案、隱私資料封閉方案和個人資料封閉方案三種。本對本業務則採用獨立單元封閉方案。
3.2.3 本地儲存解決方案
資料合規層面經常會面臨一個直接的監管訴求：資料本地儲存（不允許離境 or 本地留存備查）。甚至某些敏感業務存在更高的監管要求，會存在不允許使用公有云或者公有云資源高安全獨立的情況。為此我們需要具備自建完整基礎設施以滿足合規建站需求的能力。
3.3 應用架構雲原生化
雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和執行可彈性擴充套件的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API等。這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。
對於全球化技術研發而言，除了將業務執行在雲上，也需要進一步從自身業務研發的挑戰以及痛點出發，結合雲原生的技術以及相關的架構理念來解決業務研發、運維本身的效率問題。
3.1傳統應用架構面臨的挑戰
圖 傳統應用架構模式
上圖描述了傳統應用架構下的軟體交付過程。從這整個過程中看，應用扮演了研發態的物件、交付態的載體、執行態的容器，軟體能力所期望的所有能力都是通過在應用原始碼中宣告式的引用，並且通過統一構建完成軟體整體性交付，這個過程可以叫做軟體的富應用（Fat Application）交付。
由於全球化平臺最初是從實際的業務系統演進而來的（交易、營銷、支付.....），所以平臺也不例外，延續了傳統的應用架構模式。但隨著平臺自身逐漸演進，以及平臺之上的業務多樣性發展，不管是從組織架構還是業務架構上都帶來了很大的衝擊，主要面臨著如下三方面挑戰
·應用架構不可持續：富應用交付模式下，在軟體生產過程中，始終存在一個單點——應用，當應用所支撐的內容逐漸龐大和複雜的時候，那麼它將是影響研發效率的關鍵點，也是影響整個國際化平臺架構的可持續性的最大挑戰。
·研發交付不確定性：全球化平臺和業務分層的研發模式在目的和變更節奏是不一致的。為解決這兩者的差異，會導致應用自身逐漸臃腫和腐蝕，於是給日常研發迭代帶來很大的不確定性和不可預見性。
·運維能力缺乏標準：隨著應用自身的複雜度增加，與之匹配的運維能力也會隨之增加，而當前提倡的DevOps理念，也衍生出很多相關的產品和工具，但這些產品和工具的標準不統一，進而造成零散繁雜、無統一產品入口的現象，導致運維效率和理解成本不斷增加。
針對上面的挑戰，雲原生技術提供給我們新的解題思路：
·容器編排技術：通過雲原生的容器編排技術將傳統的軟體交付過程演進為各個容器編排組合式交付，將單個應用交付拆分成多個模組靈活編排交付，從而推動全球化應用交付體系的演進。
·交付物映象化：應用不再是研發的唯一物件，而是打造映象研發體系，基於映象的不變性來確保交付內容的確定性，並實現平臺能力映象化，具有獨立穩定的研發體系。
·統一運維標準：藉助雲原生IaC/OAM等GitOps理念，通過統一的模式去收斂並定義雲原生下的應用運維標準。並重新定義業務組織的SRE，通過統一視角去查詢、分析、度量應用的運維能力現狀和資源使用情況。
3.2 全球化雲原生架構實踐
3.2.1 基於雲原生的應用架構
結合上文提到的雲原生解題思路，我們對整體的全球化研發交付過程進行了抽象，用於支撐更廣義的全球化應用架構升級。這個過程中，我們也充分結合了雲原生中先進的技術，並應用到全球化的場景中：
·IaC：提供統一研發基礎設施宣告正規化。為了將平臺對業務依賴進行更好的解耦，降低平臺認知成本，我們對站點應用的IaC進行了分層抽象標準定義，圍繞全球化場景定義基礎設施標準，從規格、日誌採集、探針、hook、釋出策略等進行統一收斂，降低業務接入IaC成本。
·OAM：提供統一應用模型的定義。依託於OAM開發和運維關注點分離、平臺無關與高可擴充套件、模組化應用部署和運維等特點，我們對業務和平臺面向應用的標準進行規範定義，從而更好地連結應用開發者、運維人員、應用基礎設施，讓雲原生應用交付和管理流程更加連貫一致。
·GitOps：提供業務研發持續交付能力。基於雲原生GitOps宣告式理念，可以將外部依賴元件從能力整合到運維管控統一宣告在工程之中，進而只需要基於統一的GitOps標準進行依賴能力的宣告和定義，從而將元件能力的交付和管控交給底層的GitOps引擎，提升整個軟體系統的完整性和可持續性。
·ACK：提供資源統一排程引擎。我們基於阿里雲的ACK容器服務，使用其提供的強大的容器編排、資源排程、和自動化運維等能力，實現對不同環境交付不同的業務模組功能，並且基於上層的流量排程，實現業務按需部署，按需排程。
·容器編排：通過ACK容器靈活編排技術成功的將全球化應用架構再升級，將業務邏輯和基礎設施、平臺能力、公共富客戶端在研發態進行完全隔離，在執行態業務程式和運維程式通過輕量化容器做到相對徹底的隔離，提升整體應用研發交付效率和業務形態的穩定性。
圖 應用架構在容器態的整合
這裡重點強調一下容器編排的實踐。在全球化應用架構升級的過程中一共衍生出了三大類容器，如上圖所示：
·基礎設施容器（Base Container），其中就包含運維容器、閘道器容器等應用所依賴的基礎設施的能力；
·臨時容器（Temporary Container），該容器不具備任何生命週期，其作用就是為了將自身的研發產物通過Pod下的共享目錄整合到主應用容器和業務容器內，完成整個能力的整合和被使用，主要由平臺容器構成；
·業務容器（Business Container），該容器和主應用容器一樣，具備完整的生命週期，且通過gRPC完成和主應用的通訊，主要由類目、多語等富客戶端容器構成。
3.2.2 基於雲原生的運維體系
圖 全球化應用架構中的運維體系
結合著應用架構的升級，全球化也對應用的運維體系進行了升級。藉助雲原生架構體系與IaC標準的宣告式引用, 全球化統一了多種應用運維能力的使用，並且通過基礎設施的強大能力實現了效率提升, 包括但不限於：
·應用釋出: 智慧釋出決策、原地升級、滾動升級、分批發布
·彈性容量: 自動彈性、定時彈性、CPUShare
·批量運維：應用容器的原地重啟、容器置換、日誌清理、JavaDump
·輕量化容器: 運維容器獨立、Sidecar編排
·多容器交付部署: 埠衝突、程式衝突、檔案目錄共享
·可觀測與穩定性: 應用生命週期、啟動異常診斷、白屏化、容器視角監控
圖 雲資源BaaS化
在這個運維體系中，全球化也引入了雲原生的BaaS能力。BaaS提供一整套面向終態的、關注點分離(Application、Infrastructure)的解決方案，打通了阿里雲及中介軟體資源的生產、計量計費、身份授權、消費流程，將IaC作為入口提供端到端的使用體驗。全球化通過引入BaaS能力, 實現了SRE對應用雲資源使用的統一度量管理, 同時研發人員可以通過BaaS實現多種資源的一致性宣告式使用, 大大降低了使用成本。
圖 Java程式生命週期規範化
為了提升雲原生環境下的應用自愈能力, 我們也統一了Java應用在K8s Pod中的生命週期規範，將應用啟動、執行(存活與就緒)、停服等不同階段進行標準化定義, 並通過IaC和SDK的模式開放給業務使用，實現Java應用生命週期和容器生命週期的一致性繫結。
四、總結與展望
技術服務於業務，全球化技術根植於全球化業務，在“讓天下沒有難做的生意”的業務方向上，我們還有很多事情沒有做好。同樣，雖然歷經多年建設，全球化技術體系也還有非常多不完善的地方，也還有非常多技術挑戰待克服，我們依然在路上。