2023阿里云原生架構(gòu)白皮書

TheCloud-nativeArchitectureWhitePaperbyAlibaba3

ServerlessServiceMesh產(chǎn)品家族 3主要云原生技 6云原生架構(gòu)實(shí)踐案 放應(yīng)用模型 ServiceMesh

（零售、公共云 案例五：TimingAppServerless4阿里巴巴云原生架構(gòu)設(shè) 7云原生架構(gòu)未來發(fā)展趨ACNA（AlibabaCloudServerless序WhitePaperbyAlibaba序IT也賦予了企業(yè)嶄新的增長機(jī)遇。正如集裝箱的出現(xiàn)加速了貿(mào)易全球化進(jìn)程，以容器為代表的云原生技術(shù)作為云計(jì)算的服務(wù)新界面加速云計(jì)算普及的同時(shí)，也在推動(dòng)著整個(gè)商業(yè)世界飛速演進(jìn)。上云成為企業(yè)持續(xù)發(fā)展的必然選擇，全面使用源技術(shù)、云服務(wù)構(gòu)建軟件服務(wù)的時(shí)代云原生技術(shù)在通過方法論、工具集和最佳實(shí)踐重塑整個(gè)軟件技術(shù)棧和生命周期，云原生架構(gòu)

ITIT希望所有的發(fā)者、架構(gòu)師和技術(shù)決策者 發(fā)展背 正如伴隨著x86硬件體系的成熟，很多應(yīng)用不再使用昂貴、臃腫的大中型機(jī)，轉(zhuǎn)而選擇價(jià)格更為低廉的以x86為主的硬件體系，也由此誕生了包括CORBA、EJB、RPC在內(nèi)的各類分布式架構(gòu)；后由于互聯(lián)網(wǎng)業(yè)務(wù)飛速發(fā)展，人們發(fā)現(xiàn)傳統(tǒng)IOE架構(gòu)已經(jīng)不能滿足海量業(yè)務(wù)規(guī)模的并發(fā)要求，于是又誕生了阿里巴Dubbo&RocketMQ、SpringCloudIDC（如微服務(wù)改造只是在云的時(shí)代不能充分利用云的強(qiáng)大能力，不能從云技術(shù)中獲得更高的可用性與可擴(kuò)展能力，也不能利用云提升發(fā)布和運(yùn)維的效率，是一件非常遺憾的事情?；仡櫧陙砩虡I(yè)世界的發(fā)展趨勢，數(shù)字化轉(zhuǎn)型的出現(xiàn)使得企業(yè)中越來越多的業(yè)務(wù)演變成數(shù)字化業(yè)務(wù)，數(shù)字化對于業(yè)務(wù)渠道、競爭格局、用戶體驗(yàn)等諸多方面都帶來更加嚴(yán)苛的要求，這就要求技術(shù)具備更快//大量數(shù)字化業(yè)務(wù)重構(gòu)了企業(yè)的業(yè)務(wù)流水線，企業(yè)要求這些業(yè)務(wù)不能有不可接受的業(yè)務(wù)中斷，否則會(huì)對客戶體驗(yàn)以及營收可能造成巨大影響。CIOITIT個(gè)應(yīng)用都相對獨(dú)立，如何管理與分配資源成了難題。大家都基于最底層IDC設(shè)施獨(dú)自向上構(gòu)建，都需要IaaSIaaS，CIOITIaaS所有這些問題都指向一個(gè)共同點(diǎn)，那就是云的時(shí)代需要新的技術(shù)架構(gòu)，來幫助企業(yè)應(yīng)用能夠更好地利用云計(jì)算優(yōu)勢，充分釋放云計(jì)算的技術(shù)紅利，讓業(yè)務(wù)更敏捷、成本更低的同時(shí)又可伸縮性更靈活，而這些正好就是云原生架構(gòu)專注解決的技術(shù)點(diǎn)。21 從技術(shù)的角度，云原生架構(gòu)是基于云原生技術(shù)的一組架構(gòu)原則和設(shè)計(jì)模式的集合，旨在將云應(yīng)用中的（傳統(tǒng)架 云原生架代 代

三部分中只有業(yè)務(wù)代碼是核心，是對業(yè)務(wù)真正帶來價(jià)值的，另外兩個(gè)部分都只算附屬物，但隨著軟件對發(fā)人員的技能要求也越來越。云原生架構(gòu)相比較傳統(tǒng)架構(gòu)進(jìn)了一大步，從業(yè)務(wù)代碼中剝離了大量非功能性特性（不會(huì)是所，比如易用性還不能剝離）到aaS和aaS中，從而減少業(yè)務(wù)代碼發(fā)人員的技術(shù)關(guān)注范圍，通過云廠商的專業(yè)性提升應(yīng)用的非功能性能力。此外，具備云原生架構(gòu)的應(yīng)用可以最大程度利用云服務(wù)和提升軟件交付能力，進(jìn)一步加快軟件發(fā)云原生架構(gòu)產(chǎn)生的最大影響就是讓發(fā)人員的編程模型發(fā)生了巨大變。今天大部分的編程語言中，都有文件、網(wǎng)絡(luò)、線程等元素，這些元素為充分利用單機(jī)資源帶來好處的同時(shí)，也提升了分布式編程的CPU在云的環(huán)境中，比如“如何獲取存儲(chǔ)”變成了若干服務(wù)，包括對象存儲(chǔ)服務(wù)、塊存儲(chǔ)服務(wù)和沒有隨機(jī)訪問的文件存儲(chǔ)服務(wù)。云不僅改變了發(fā)人員獲得這些存儲(chǔ)能力的界面，還在于云產(chǎn)品在這些penPI或者源SDK背后把分布式場景中的高可用挑戰(zhàn)、自動(dòng)擴(kuò)縮容挑戰(zhàn)、安全挑戰(zhàn)、運(yùn)維升級挑戰(zhàn)等都處理了，應(yīng)用的發(fā)人員就不用在其代碼中處理節(jié)點(diǎn)宕機(jī)前如何把本地保存的內(nèi)容同步到遠(yuǎn)端的問題，也不oday云把三方軟硬件的能力升級成了服務(wù)，發(fā)人員的發(fā)復(fù)雜度和運(yùn)維人員的運(yùn)維工作量都得到極大降低。顯然，如果這樣的云服務(wù)用得越多，那么發(fā)和運(yùn)維人員的負(fù)擔(dān)就越少，企業(yè)在非核心業(yè)務(wù)實(shí)現(xiàn)上從必須的負(fù)擔(dān)變成了可控支出。在一些發(fā)能力強(qiáng)的公司中，對這些三方軟硬件能力的處理往往是交給應(yīng)用框架（或者說公司內(nèi)自己的中間件）LA復(fù)雜的網(wǎng)絡(luò)技術(shù)……簡化讓業(yè)務(wù)發(fā)變得更敏捷、更快速！TheTheCloud-nativeArchitectureWhitePaperbyAlibaba任何應(yīng)用都提供兩類特性，功能性特性和非功能性特性。功能性特性是真正為業(yè)務(wù)帶來價(jià)值的代碼，業(yè)務(wù)字典管理、搜索等等也是緊貼業(yè)務(wù)需求的。非功能性特性是沒有給業(yè)務(wù)帶來直接業(yè)務(wù)價(jià)值，但通常又是必不可少的特性，比如高可用能力、容災(zāi)能力、安全特性、可運(yùn)維性、易用性、可測試性、灰度發(fā)布能力等等。TheCloud-nativeArchitectureWhite容器：有時(shí)應(yīng)用所在的物理機(jī)是正常的，只是應(yīng)用自身的問題（bug、資源耗盡等）對外提供服務(wù)。容器通過監(jiān)控檢查探測到進(jìn)程狀態(tài)異常，從而實(shí)施異常節(jié)點(diǎn)的下線、新節(jié)點(diǎn)上線和生產(chǎn)流量的切換等操作，整個(gè)過程自動(dòng)完成而無需運(yùn)維人員干預(yù)；云服務(wù)：如果應(yīng)用把“有狀態(tài)”部分都交給了云服務(wù)（如緩存、數(shù)據(jù)庫、對象存儲(chǔ)等），加上全局對象的持有小型化或具備從磁盤快速重建能力，由于云服務(wù)本身是具備極強(qiáng)的高可用能力，那么應(yīng)用本身MLoadBalancer軟件一旦發(fā)完成，需要在公司內(nèi)外部各類環(huán)境中部署和交付，以將軟件價(jià)值交給最終客戶。軟件交付的困難在于發(fā)環(huán)境到生產(chǎn)環(huán)境的差（公司環(huán)境到客戶環(huán)境之間的差異）以及軟件交付和運(yùn)維人員的技能差異，填補(bǔ)這些差異的是一大堆安裝手冊、運(yùn)維手冊和培訓(xùn)文檔。容器以一種標(biāo)準(zhǔn)的方式對軟件打包，容器及相關(guān)技術(shù)則幫助屏蔽不同環(huán)境之間的差異，進(jìn)而基于容器做標(biāo)準(zhǔn)化的軟件交付。服務(wù)化以后，往往被部署到成千上萬個(gè)節(jié)點(diǎn)上，如果系統(tǒng)不具備高度的自動(dòng)化能力，任何一次新業(yè)務(wù)的上線，都會(huì)帶來極大的工作量挑戰(zhàn)，嚴(yán)重時(shí)還會(huì)導(dǎo)致業(yè)務(wù)變更超過上線窗口而不可用。2 （MniSeric）架構(gòu)，通過服務(wù)化架構(gòu)把不同生命周期的模塊分離出來，分別進(jìn)行業(yè)務(wù)迭代，避免迭代頻繁模塊被慢速模塊拖慢，從而加快整體的進(jìn)度和穩(wěn)定性。同時(shí)服務(wù)化架構(gòu)以面向接口編程，服務(wù)內(nèi)部的功能高度內(nèi)聚，模塊間通過公共功能模塊的提取增加軟件的復(fù)用程度。（而非網(wǎng)絡(luò)流量）的控制策略，所以云原生架構(gòu)強(qiáng)調(diào)使用服務(wù)化的目的還在于從架構(gòu)層面抽象化業(yè)務(wù)模塊之間的關(guān)系，標(biāo)準(zhǔn)化服務(wù)流量的傳輸，從而幫助業(yè)務(wù)模塊進(jìn)行基于服務(wù)流量的策略控制和治理，不管這些服務(wù)是基于什么語言發(fā)的。重新調(diào)整也非常困難。彈性則是指系統(tǒng)的部署規(guī)模可以隨著業(yè)務(wù)量的變化自動(dòng)伸縮，無須根據(jù)事先的容量規(guī)劃準(zhǔn)備固定的硬件和軟件資源。好的彈性能力不僅縮短了從采購到上線的時(shí)間，讓企業(yè)不用操心額外軟硬件資源的成本支出（閑置成本T擴(kuò)張的時(shí)候，不再因?yàn)槠綍r(shí)軟硬件資源儲(chǔ)備不足而“說不”，保障了企業(yè)收益。TheCloud-nativeArchitectureWhitePaperbyAlibaba今天大部分企業(yè)的軟件規(guī)模都在不斷增長，原來單機(jī)可以對應(yīng)用做完所有調(diào)試，但在分布式環(huán)境下需SL、目前的故障影響哪些用戶、最近這次變更對哪些服務(wù)指標(biāo)帶來了影響等等，這些都要求系統(tǒng)具備更強(qiáng)的可觀測能力?？捎^測性與監(jiān)控、業(yè)務(wù)探活、APMAPP清晰可見，甚至可以下鉆到每次三方軟件調(diào)用、TheCloud-nativeArchitectureWhitePaperbyAlibaba當(dāng)業(yè)務(wù)上線后，最不能接受的就是業(yè)務(wù)不可用，讓用戶無法正常使用軟件，影響體驗(yàn)和收入。韌性代TheCloud-nativeArchitectureWhite硬件資源瓶頸（如CPU/網(wǎng)卡帶寬耗盡）、業(yè)務(wù)流量超出軟件設(shè)計(jì)能力、影響機(jī)房工作的故障和災(zāi)難、bug、黑客攻擊等對業(yè)務(wù)不可用帶來致命影響的因素。韌性從多個(gè)維度詮釋了軟件持續(xù)提供業(yè)務(wù)服務(wù)的能力，核心目標(biāo)是提升軟件的MTBF（MeanTmeBetweenFailure，平均無故障時(shí)間）反壓、主從模式、集群模式、AZregionDeOps、大量第三方組件的使用，在降低分布式復(fù)雜性和提升迭代速度的同時(shí)，因?yàn)檎w增大了軟件技術(shù)棧的復(fù)雜度和組件規(guī)模，所以不可避免地帶來了軟件easnnModel）、Kubernetesoperator和大量自動(dòng)化交付工I/CD自動(dòng)化，通過配置數(shù)據(jù)自描述和面向終態(tài)的交付過程，讓自動(dòng)化工具理解交付目標(biāo)和環(huán)境差異，實(shí)現(xiàn)整個(gè)軟件交付和運(yùn)維的自動(dòng)化。零信任安全針對傳統(tǒng)邊界安全架構(gòu)思想進(jìn)行了重新評估和審視，并對安全架構(gòu)思路給出了新建議。其//IP控制進(jìn)行了范式上的顛覆，引導(dǎo)安全體系架構(gòu)從“網(wǎng)絡(luò)中心化”走向“身份中心化”，其本質(zhì)訴求是以身份為中心進(jìn)行訪問控制。更是眾多（資源，服務(wù)，環(huán)境）隔離機(jī)制的基礎(chǔ)；在員工訪問企業(yè)內(nèi)部應(yīng)用的場景下，Identity今天技術(shù)和業(yè)務(wù)的演進(jìn)速度非常快，很少有一始就清晰定義了架構(gòu)并在整個(gè)軟件生命周期里面都適用，相反往往還需要對架構(gòu)進(jìn)行一定范圍內(nèi)的重構(gòu)，因此云原生架構(gòu)本身也應(yīng)該和必須是一個(gè)具備持續(xù)演進(jìn)能力的架構(gòu)，而不是一個(gè)封閉式架構(gòu)。除了增量迭代、目標(biāo)選取等因素外，還需要考慮組織（例如風(fēng)險(xiǎn)和到云上的遷入成本/風(fēng)險(xiǎn)，以及技術(shù)上通過微服務(wù)/應(yīng)用網(wǎng)關(guān)、應(yīng)用集成、適配器、服務(wù)網(wǎng)格、數(shù)據(jù)遷移、在線灰度等應(yīng)用3 服務(wù)化架構(gòu)是云時(shí)代構(gòu)建云原生應(yīng)用的標(biāo)準(zhǔn)架構(gòu)模式，要求以應(yīng)用模塊為顆粒度劃分一個(gè)軟件，以接口契約（ID）定義彼此業(yè)務(wù)關(guān)系，以標(biāo)準(zhǔn)協(xié)議（TTP、gPC）確保彼此的互聯(lián)互通，結(jié)合DD（領(lǐng)域模型驅(qū)動(dòng)）、D（測試驅(qū)動(dòng)發(fā)）、容器化部署提升每個(gè)接口的代碼質(zhì)量和迭代速度。服務(wù)化架構(gòu)的典型模式是微服務(wù)和小服務(wù)（MiniService）的服務(wù)的組合，這組服務(wù)會(huì)共享數(shù)據(jù)，小服務(wù)模式通常適用于非常大型的軟件系統(tǒng)，避免接口的顆粒度太細(xì)而導(dǎo)致過多的調(diào)用損耗（特別是服務(wù)間調(diào)用和數(shù)據(jù)一致性處理）和治理復(fù)雜度。通過服務(wù)化架構(gòu)，把代碼模塊關(guān)系和部署關(guān)系進(jìn)行分離，每個(gè)接口可以部署不同數(shù)量的實(shí)例，單獨(dú)擴(kuò)從而提升了整體的迭代效率。但也需要注意，服務(wù)拆分導(dǎo)致要維護(hù)的模塊數(shù)量增多，如果缺乏服務(wù)的自動(dòng)化能力和治理能力，會(huì)讓模塊管理和組織技能不匹配，反而導(dǎo)致發(fā)和運(yùn)維效率的降低。MeshTheCloud-nativeArchitectureWhitePaperbyAlibabaMesh（RPC、緩存、異步消息等）從業(yè)務(wù)進(jìn)程中分離，讓中間件與業(yè)務(wù)代碼進(jìn)一步解耦，從而使得中間件升級對業(yè)務(wù)進(jìn)程沒有影響，甚至遷移到另外一個(gè)平臺(tái)的中間件也對業(yè)務(wù)透明。分離后在業(yè)務(wù)進(jìn)程中只保留很“薄”的lintlent通常很少變化，只負(fù)責(zé)與MTheCloud-nativeArchitectureWhitePaperbyAlibabaTheCloud-nativeArchitectureWhiteSDKSDKSDKMesh（流量控制、安全策略、微隔離傳統(tǒng)架 Mesh化架esh化架構(gòu)后，大量分布式架構(gòu)模式（熔斷、限流、降級、重試、反壓、隔倉……）都由Msh（比如零信任架構(gòu)能力）/Serverless模式和大部分計(jì)算模式不同，Serverless將“部署”這個(gè)動(dòng)作從運(yùn)維中“收走”，使發(fā)者不用關(guān)心應(yīng)用在哪里運(yùn)行，更不用關(guān)心裝什么OS、怎么配置網(wǎng)絡(luò)、需要多少CPU……從架構(gòu)抽象上看，當(dāng)業(yè)務(wù)/Serverless還沒有達(dá)到任何類型的應(yīng)用都適用的地步，因此架構(gòu)決策者需要關(guān)心應(yīng)用類型是否適合于Serverless運(yùn)算。如果應(yīng)用是有狀態(tài)的，云在進(jìn)行調(diào)度時(shí)可能導(dǎo)致上下文丟失，畢竟Serverless的調(diào)度不會(huì)幫助應(yīng)用做狀態(tài)同步；如果應(yīng)用是長時(shí)間后臺(tái)運(yùn)行的密集型計(jì)算任務(wù)，會(huì)得不到ServerlessI/O（網(wǎng)絡(luò)或者存儲(chǔ)，以及服務(wù)間調(diào)用），也因?yàn)镮/OServerlessCAPC（一致性）這個(gè)維度，A（可用性）和P（分區(qū)容錯(cuò)性），因而獲得更好的彈性。在云環(huán)境中，推薦把各（如session但仍然有一些狀態(tài)如果保存到遠(yuǎn)端緩存，會(huì)造成交易性能的明顯下降，比如交易會(huì)話數(shù)據(jù)太大、需要不Eventg+（CheckPoint）啟后快速增量恢復(fù)服務(wù)，減少不可用對業(yè)務(wù)的影響時(shí)長。微服務(wù)模式提倡每個(gè)服務(wù)使用私有的數(shù)據(jù)源，而不是像單體這樣共享數(shù)據(jù)源，但往往大顆粒度的業(yè)務(wù)需要訪問多個(gè)微服務(wù)，必然帶來分布式事務(wù)問題，否則數(shù)據(jù)就會(huì)出現(xiàn)不一致。架構(gòu)師需要根據(jù)不同的場景選擇合適的分布式事務(wù)模式。XA基于消息的最終一致性（BAS）通常有很高的性能，但是通用性有限，且消息端只能成功而不能觸發(fā)消息生產(chǎn)端的事務(wù)回滾；TCC模式完全由應(yīng)用層來控制事務(wù)，事務(wù)隔離性可控，也可以做到比較高效；但是對業(yè)務(wù)的侵入性非常強(qiáng)，SAGATCCtry這個(gè)階段，而是每個(gè)正向事務(wù)都對應(yīng)一個(gè)補(bǔ)償事務(wù)，也是開源項(xiàng)目SEATA的AT模式非常高性能且無代碼發(fā)工作量，且可以自動(dòng)執(zhí)行回滾操作，同時(shí)也存在一些可觀測架構(gòu)包括Logging、Tracing、Metrics三個(gè)方面，其中Logging提供多個(gè)級別（verbose/debug/warning/error/fatal）的詳細(xì)信息跟蹤，由應(yīng)用發(fā)者主動(dòng)提供；Tracing提供一個(gè)請求從前端到后端的完整調(diào)用鏈路跟蹤，對于分布式場景尤其有用；MetricsTheCloud-nativeArchitectureWhitePaperbyAlibaba架構(gòu)決策者需要選擇合適的、支持可觀測的源框架（比如OpenTracing、OpenTelemetry），并規(guī)范上下文的可觀測數(shù)據(jù)規(guī)范（例如方法名、用戶信息、地理位置、請求參數(shù)等），規(guī)劃這些可觀測raingsanTheCloud-nativeArchitectureWhitePaperbyAlibaba由于建立可觀測性的主要目標(biāo)是對服務(wù)SLO（ServiceLevelObjective）進(jìn)行度量，從而優(yōu)化SLA，因此架構(gòu)設(shè)計(jì)上需要為各個(gè)組件定義清晰的SLO，包括并發(fā)度、耗時(shí)、可用時(shí)長、容量等。TheCloud-nativeArchitectureWhite事件驅(qū)動(dòng)架構(gòu)（EDA，EventDrivenArchitecture）schmeentEDAQoS保障機(jī)制，也能夠?qū)κ录幚硎∵M(jìn)行響應(yīng)。事件驅(qū)動(dòng)架構(gòu)不僅用于（微）服務(wù)解耦，還可應(yīng)用于下面的場景中：就不會(huì)對上游帶來影響；API接口；結(jié)合EDA中的EventSourcingEDA數(shù)據(jù)變化通知：在服務(wù)架構(gòu)下，往往一個(gè)服務(wù)中的數(shù)據(jù)發(fā)生變化，另外的服務(wù)會(huì)感興趣，比如用戶訂單EDA事件流處理：應(yīng)用于大量事件流（而非離散事件）Kafka基于事件觸發(fā)的響應(yīng)：在IoT時(shí)代大量傳感器產(chǎn)生的數(shù)據(jù)，不會(huì)像人機(jī)交互一樣需要等待處理結(jié)果的返回，EDA來構(gòu)建數(shù)據(jù)處理應(yīng)用。4 龐大單體應(yīng)用的最大問題在于缺乏依賴隔離，包括代碼耦合帶來的責(zé)任不清、模塊間接口缺乏治理而帶來變更影響擴(kuò)散、不同模塊間的發(fā)進(jìn)度和發(fā)布時(shí)間要求難以協(xié)調(diào)、一個(gè)子模塊不穩(wěn)定導(dǎo)致整個(gè)應(yīng)用都變慢、擴(kuò)容時(shí)只能整體擴(kuò)容而不能對達(dá)到瓶頸的模塊單獨(dú)擴(kuò)容……因此當(dāng)業(yè)務(wù)模塊可能存在多人發(fā)的時(shí)候，就需要考慮通過服務(wù)化進(jìn)行一定的拆分，梳理聚合根，通過業(yè)務(wù)關(guān)系確定主要的服務(wù)模塊以及這些模塊的邊界、清晰定義模塊之間的接口，并讓組織關(guān)系和架構(gòu)關(guān)系匹配。隊(duì)間協(xié)同代價(jià)高的嚴(yán)重問題。為了支撐不斷增長的流量，該應(yīng)用需要不斷增加機(jī)器，很快后端數(shù)據(jù)庫連2008思路就是微服務(wù)架構(gòu)，第一個(gè)服務(wù)從用戶中心始建設(shè)，后續(xù)交易、類目、店鋪、商品、評價(jià)中心等服務(wù)陸續(xù)從單體中獨(dú)立出來，服務(wù)之間通過遠(yuǎn)程調(diào)用通信，每個(gè)中心由獨(dú)立團(tuán)隊(duì)專門維護(hù)，從而解決了研發(fā)協(xié)同問題，以及按規(guī)模持續(xù)水平擴(kuò)展的問題。小規(guī)模軟件的服務(wù)拆分：軟件規(guī)模不大，團(tuán)隊(duì)人數(shù)也少，但是為了微服務(wù)而微服務(wù)，強(qiáng)行把耦合度高、代碼量少的模塊進(jìn)行服務(wù)化拆分，一次性的發(fā)布需要拆分為多個(gè)模塊分發(fā)布和維護(hù)；數(shù)據(jù)依賴：服務(wù)雖然拆分為多個(gè)，但是這些服務(wù)的數(shù)據(jù)是緊密耦合的，于是讓這些服務(wù)共享數(shù)據(jù)庫，導(dǎo)致數(shù)據(jù)的變化往往被扇出到多個(gè)服務(wù)中，造成服務(wù)間數(shù)據(jù)依賴；間變大了上千倍，導(dǎo)致整個(gè)服務(wù)鏈路性能急劇下降。TheCloud-nativeArchitectureWhitePaperbyAlibaba軟件架構(gòu)中非常重要的一個(gè)維度就是處理軟件復(fù)雜度問題，一旦問題規(guī)模提升了很多，那就必須重新考慮與之適應(yīng)的新方案。在很多軟件組織中，發(fā)、測試和運(yùn)維的工作單位都是以進(jìn)程為單位，比如把整個(gè)用戶管理作為一個(gè)單獨(dú)的模塊進(jìn)行打包、發(fā)布和運(yùn)行；而進(jìn)行了微服務(wù)拆分后，這個(gè)用戶管理模塊可能被分為用戶信息管理、基本信息管理、積分管理、訂單管理等多個(gè)模塊，由于仍然是每個(gè)模塊分別打包、發(fā)布和運(yùn)TheCloud-nativeArchitectureWhitePaperbyAlibaba試用例的增加，更多的軟件模塊排隊(duì)等待測試和發(fā)布，如果缺乏自動(dòng)化會(huì)造成軟件發(fā)布時(shí)間變長，在多環(huán)境發(fā)布或異地發(fā)布時(shí)更是需要專家來處理環(huán)境差異帶來的影響。同時(shí)更多的進(jìn)程運(yùn)行于一個(gè)環(huán)境中，造成了故障處理時(shí)間變長，以及使得日常運(yùn)維操作都需要專家才能完成。所有這些問題導(dǎo)致軟件交付時(shí)間變長、風(fēng)險(xiǎn)提升以及運(yùn)維成本的增加。31 OperatingOperating Bin/Bin/OperatingVirtualOperatingVirtualOperatingBin/Bin/Bin/OperatingTraditional Virtualized Container8LinuxCgroups資源管理機(jī)制、Linuxe視圖隔離方案，讓應(yīng)用得以運(yùn)行在獨(dú)立沙箱環(huán)境中，避免相互間沖突與影響；但直到Dcker容器引擎的源，才很大程度上降低了容器技術(shù)的使用復(fù)雜性，加速了容器技術(shù)普及。ocer作系統(tǒng)內(nèi)核、輕量、沒有資源損耗、秒級啟動(dòng)，極大提升了系統(tǒng)的應(yīng)用部署密度和彈性。更重要的是，ockrDoker算環(huán)境間一致、可靠地運(yùn)行。借助容器技術(shù)呈現(xiàn)了一個(gè)優(yōu)雅的抽象場景：讓發(fā)所需要的靈活性、放容器鏡像迅速成為了應(yīng)用分發(fā)的工業(yè)標(biāo)準(zhǔn)。隨后源的Kubernetes，憑借優(yōu)秀的放性、可擴(kuò)展性以及活躍發(fā)者社區(qū)，在容器編排之戰(zhàn)中脫穎而出，成為分布式資源調(diào)度和自動(dòng)化運(yùn)維的事實(shí)標(biāo)準(zhǔn)。Kubernetes屏蔽了IaaS層基礎(chǔ)架構(gòu)的差異并憑借優(yōu)良的可移植性，幫助應(yīng)用一致地運(yùn)行在包括數(shù)據(jù)中心、云、邊緣計(jì)算在內(nèi)的不同環(huán)境。企業(yè)可以通過Kubernetes，結(jié)合自身業(yè)務(wù)特進(jìn)了容器生態(tài)的分工和協(xié)同?；贙ubernetes，生態(tài)社區(qū)始構(gòu)建上層的業(yè)務(wù)抽象，比如服務(wù)網(wǎng)格Istio、機(jī)器學(xué)KubeflowKnativeIT3~10IT50的計(jì)算成本。以在線教育行業(yè)為例，面對疫情之下指數(shù)級增長的流量，教育信息化應(yīng)用工具提供商希沃Seewo利用阿里云容器服務(wù)ACK和彈性容器實(shí)例ECI大大滿足了快速擴(kuò)容的迫切需求，為數(shù)容器已經(jīng)成為應(yīng)用分發(fā)和交付的標(biāo)準(zhǔn)技術(shù)，將應(yīng)用與底層運(yùn)行環(huán)境進(jìn)行解耦；Kubernetes成為資源調(diào)度和編排的標(biāo)準(zhǔn)，屏蔽了底層架構(gòu)差異性，幫助應(yīng)用平滑運(yùn)行在不同基礎(chǔ)設(shè)施上。CNCF云原生計(jì)算基金會(huì)推出了Kubernetes一致性認(rèn)證，進(jìn)一步保障了不同K8s實(shí)現(xiàn)的兼容性，這也讓企業(yè)愿意采用容器技術(shù)來構(gòu)建云時(shí)TheCloud-nativeTheCloud-nativeArchitectureWhitePaperbyAlibaba資源調(diào)度：根據(jù)應(yīng)用請求的資源量CPU、Memory，或者GPU等設(shè)備資源，在集群中選擇合適的節(jié)點(diǎn)來運(yùn)的編排，讓存儲(chǔ)卷與容器應(yīng)用的生命周期相關(guān)聯(lián)；TheCloud-nativeArchitectureWhite自動(dòng)修復(fù)：KubernetesOS出現(xiàn)故障，節(jié)點(diǎn)健康檢查會(huì)自動(dòng)進(jìn)行應(yīng)用遷移；K8s服務(wù)發(fā)現(xiàn)與負(fù)載均衡：通過Service資源出現(xiàn)各種應(yīng)用服務(wù)，結(jié)合DNS和多種負(fù)載均衡機(jī)制，支持容器化彈性伸縮：K8sCPUKubernetes的控制平面包含四個(gè)主要的組件：APIServer、Controller、Scheduler以及etcd。如下圖所示：NodeNodeContainerCtrlPlane-SystemNodeEndContainerSystemNetwordEdgeKubernetes聲明式API：發(fā)者可以關(guān)注于應(yīng)用自身，而非系統(tǒng)執(zhí)行細(xì)節(jié)。比如（無狀態(tài)應(yīng)用）、KubernetesAPI“l(fā)evel-triggered”實(shí)現(xiàn)比“edge-triggered”方式可以提可擴(kuò)展性架構(gòu)：所有K8s組件都是基于一致的、放的API實(shí)現(xiàn)和交互；三方發(fā)者也可通過CRD（CustomResourceDefinition）/OperatorK8s可移植性：K8sLoadbalanceService（負(fù)載均衡服務(wù)）、CNI（容器網(wǎng)絡(luò)接口）、CSI（容2 過去發(fā)一個(gè)后端應(yīng)用最為直接的方式就是通過單一后端應(yīng)用提供并集成所有的服務(wù)，即單體模式。隨著業(yè)務(wù)發(fā)展與需求不斷增加，單體應(yīng)用功能愈發(fā)復(fù)雜，參與發(fā)的工程師規(guī)?？赡苡勺畛鯉讉€(gè)人發(fā)展到十幾人，應(yīng)用迭代效率由于集中式研發(fā)、測試、發(fā)布、溝通模式而顯著下滑。為了解決由單體應(yīng)用模型衍生的過度集中微服務(wù)模式將后端單體應(yīng)用拆分為松耦合的多個(gè)子應(yīng)用，每個(gè)子應(yīng)用負(fù)責(zé)一組子功能。這些子應(yīng)用稱為“微服務(wù)”，多個(gè)“微服務(wù)”共同形成了一個(gè)物理獨(dú)立但邏輯完整的分布式微服務(wù)體系。這些微服務(wù)相對獨(dú)立，通過解耦研發(fā)、測試與部署流程，提高整體迭代效率。此外，微服務(wù)模式通過分布式架構(gòu)將應(yīng)用水平擴(kuò)展和冗余部署，從根本上解決了單體應(yīng)用在拓展性和穩(wěn)定性上存在的先天架構(gòu)缺陷。但也要注意到微服務(wù)模型也面臨著分布式系統(tǒng)的典型挑戰(zhàn)：如何高效調(diào)用遠(yuǎn)程方法、如何實(shí)現(xiàn)可靠的系統(tǒng)容量預(yù)估、如何建立負(fù)載均衡體系、如何面向松耦合系統(tǒng)進(jìn)行集成測試、如何面向大規(guī)模復(fù)雜關(guān)聯(lián)應(yīng)用的部署與運(yùn)維……在云原生時(shí)代，云原生微服務(wù)體系將充分利用云資源的高可用和安全體系，讓應(yīng)用獲得更有保障的彈性、可用性與安全性。應(yīng)用構(gòu)建在云所提供的基礎(chǔ)設(shè)施與基礎(chǔ)服務(wù)之上，充分利用云服務(wù)所帶來的便捷性、穩(wěn)定性，降低應(yīng)用架構(gòu)的復(fù)雜度。云原生的微服務(wù)體系也將幫助應(yīng)用架構(gòu)全面升級，讓應(yīng)用天然具有更好的可觀測性、可控制性、可容錯(cuò)性等特性。相較于單體應(yīng)用，微服務(wù)架構(gòu)的架構(gòu)轉(zhuǎn)變，在提升發(fā)、部署等環(huán)節(jié)靈活性的同時(shí)，也提升了在運(yùn)維、監(jiān)TheTheCloud-nativeArchitectureWhitePaperbyAlibabaPythonJavaTheCloud-nativeArchitectureWhite進(jìn)一步，微服務(wù)也應(yīng)具備正交分解特性，在職責(zé)劃分上專注于特定業(yè)務(wù)并將之做好，即SOLID原則中單一職責(zé)原則（SRPSingleResponsibilityPrinciple）。如果當(dāng)一個(gè)微服務(wù)修改或者發(fā)布時(shí)，不應(yīng)該影響到同一系統(tǒng)里另AAB如何在不重新發(fā)布的前提下，如何能夠自動(dòng)感知到服務(wù)A的變化？這里需要引入第三方服務(wù)注冊中心來滿足服務(wù)的可發(fā)現(xiàn)性；特別是對于大規(guī)模微服微服務(wù)的可交互性是指服務(wù)A采用什么樣的方式可以調(diào)用服務(wù)B。由于服務(wù)自治的約束，服務(wù)之間的調(diào)用需要采用與語言無關(guān)的遠(yuǎn)程調(diào)用協(xié)議，比如REST協(xié)議很好的滿足了“與語言無關(guān)”和“標(biāo)準(zhǔn)化”兩個(gè)重要因素，但在高性能場景下，基于IDL的二進(jìn)制協(xié)議可能是更好的選擇。另外，目前業(yè)界大部分微服務(wù)實(shí)踐往往沒有達(dá)到HATEOAS啟發(fā)式的REST調(diào)用，服務(wù)與服務(wù)之間需要通過事先約定接口來完成調(diào)用。為了進(jìn)一步實(shí)現(xiàn)服務(wù)與服升系統(tǒng)吞吐能力、充分利用好機(jī)器資源，可以通協(xié)程、Rx在微服務(wù)領(lǐng)域，提倡數(shù)據(jù)存儲(chǔ)隔,aeSegregation）原則，即數(shù)據(jù)是微服務(wù)的私有資產(chǎn)，AI耦合的原則。同時(shí)，出于性能考慮，通常采取讀寫分離（CQRS）手段。從微服務(wù)系統(tǒng)設(shè)計(jì)一始，就需要考慮以下因素高效運(yùn)維整個(gè)系統(tǒng)，從技術(shù)上要準(zhǔn)備全自動(dòng)化的CI/CD流水線滿足對發(fā)效率的訴求，并在這個(gè)基礎(chǔ)上支持面對復(fù)雜系統(tǒng)，全鏈路、實(shí)時(shí)和多維度的可觀測能力成為標(biāo)配。為了及時(shí)、有效地防范各類運(yùn)維風(fēng)險(xiǎn)，需要拆分的持續(xù)，故障發(fā)現(xiàn)時(shí)效性和根因精確性始終是發(fā)運(yùn)維人員的核心訴求。TheTheCloud-nativeArchitectureWhitePaperbyAlibaba2011ServiceServiceServiceContainerContainerDiscoveryDiscovery ServiceDiscoveryServiceDiscoveryandfaultServiceDiscoveryandfaultContainerContainerContainerTheCloud-nativeArchitectureWhiteDiscoveryDiscoveryServiceServiceDiscoveryandfaultDiscoveryandfaultServiceContainerContainerDiscovery6-DK-Sidecar-Clodatieicroservces，邊車（Sdecar）進(jìn)程始接管微服務(wù)應(yīng)用之間的流量，承載第二代中服務(wù)框架的功能，包括服務(wù)發(fā)現(xiàn)、調(diào)用容錯(cuò)，到DiscoveryServiceServiceDiscoveryandfaultDiscoveryandfaultServiceFunctionasa近兩年始，隨著AWSLambda的出現(xiàn)，部分應(yīng)用始嘗試?yán)肧erverless來架構(gòu)微服務(wù)，這種方式被稱之務(wù)管理、安全等等。同時(shí)，在發(fā)側(cè)始提倡面向localhost編程的理念，提供標(biāo)準(zhǔn)API屏蔽掉底層資源、服務(wù)、ApacheDubbo作為源自阿里巴巴的一款源高性能RPC框架，特性包括基于透明接口的RPC、智能負(fù)載均微服務(wù)框架并構(gòu)建了強(qiáng)大的生態(tài)體系。為了鞏固Dubbo生態(tài)的整體競爭力，2018年阿里巴巴陸續(xù)源了Spring-Chaosblade(故障注入)，以便讓用戶享受阿里巴巴十年沉淀的微服務(wù)體系，獲得簡單易用、高性能、高可用等核心能力。Dubbo在v3中發(fā)展ServiceMesh，目前Dubbo協(xié)議已經(jīng)被Envoy支持，數(shù)據(jù)層選址、負(fù)載均衡和服務(wù)Istio/Pilot-discoverySringClod作為發(fā)者的主要微服務(wù)選擇之一，為發(fā)者提供了分布式系統(tǒng)需要的配置管理、服務(wù)發(fā)現(xiàn)、斷Toen、全局鎖、決策競選、分布式會(huì)話與集群狀態(tài)管理等能力和發(fā)工具。EclipseMicroProfile作為Java微服務(wù)發(fā)的基礎(chǔ)編程模型，它致力于定義企業(yè)Java微服務(wù)規(guī)范，MicroProfile提供指標(biāo)、API文檔、運(yùn)行狀況檢查、容錯(cuò)與分布式跟蹤等能力，使用它創(chuàng)建的云原生微服務(wù)可以自ServiceMesh架構(gòu)。Tars是騰訊將其內(nèi)部使用的微服務(wù)框架TAF（TotalApplicationFramework）多年的實(shí)踐成果總結(jié)而成的源項(xiàng)目，在騰訊內(nèi)部有上百個(gè)產(chǎn)品使用，服務(wù)內(nèi)部數(shù)千名C++、Java、Golang、Node.Js與PHP發(fā)者。TarsSOFAStack（ScalableOpenFinancialArchitectureStack）是由螞蟻金服源的一套用于快速構(gòu)建金融級分布式架構(gòu)的中間件，也是在金融場景里錘煉出來的最佳實(shí)踐。MOSN是SOFAStack的組件，它一款采用Go語言發(fā)的ServiceMesh數(shù)據(jù)平面代理，功能和定位類似Envoy，旨在提供分布式、模塊化、可觀測、智能化的代理能力。MOSNEnvoyIstioAPIIstioTheCloud-nativeArchitectureWhitePaperbyAlibabaTheCloud-nativeArchitectureWhitePaperbyAlibabaTheCloud-nativeArchitectureWhite3 隨著以Kubernetes為代表的云原生技術(shù)成為云計(jì)算的容器界面，Kubernetes成為云計(jì)算的新一代操作系統(tǒng)。面向特定領(lǐng)域的后端云服務(wù)（BaaS則是這個(gè)操作系統(tǒng)上的服務(wù)APIAI等領(lǐng)域的大量產(chǎn)品與技術(shù)都始提供全托管的云形態(tài)服務(wù)，如今越來越多用戶已習(xí)慣使用云服務(wù)，而不是自己搭建存儲(chǔ)系統(tǒng)、部署數(shù)據(jù)庫軟件。當(dāng)這些BaaS云服務(wù)日趨完善時(shí)，Serverless因?yàn)槠帘瘟朔?wù)器的各種運(yùn)維復(fù)雜度，讓發(fā)人員可以將更多精力用于業(yè)務(wù)邏輯設(shè)計(jì)與實(shí)現(xiàn)，而逐漸成為云原生主流技術(shù)之一。Serverless計(jì)算包含以下特征：的發(fā)、運(yùn)維、安全、高可用等工作；BaaSAPI函數(shù)計(jì)算（FunctionasaService）Serverless中最具代表性的產(chǎn)品形態(tài)。通過把應(yīng)用邏輯拆分多個(gè)函數(shù)，每個(gè)函數(shù)都通過事件驅(qū)動(dòng)的方式觸發(fā)執(zhí)行，例如當(dāng)對象存儲(chǔ)（OSS）中產(chǎn)生的上傳/刪除對象等事件，能夠自動(dòng)、可靠地觸發(fā)FaaS函數(shù)處理且每個(gè)環(huán)節(jié)都是彈性和高可用的，客戶能夠快速實(shí)現(xiàn)大規(guī)模數(shù)據(jù)的實(shí)時(shí)并行處理。同樣的，通過消息中間件和函數(shù)計(jì)算的集成，客戶可以快速實(shí)現(xiàn)大規(guī)模消息的實(shí)時(shí)處理。目前函數(shù)計(jì)算這種Serverless函數(shù)編程以事件驅(qū)動(dòng)方式執(zhí)行，這在應(yīng)用架構(gòu)、發(fā)習(xí)慣方面，以及研發(fā)交付流程上都會(huì)有比較大的改變；函數(shù)編程的生態(tài)仍不夠成熟，應(yīng)用發(fā)者和企業(yè)內(nèi)部的研發(fā)流程需要重新適配；針對這些情況，在Serverless計(jì)算中又誕生出更多其他形式的服務(wù)形態(tài)，典型的就是和容器技術(shù)進(jìn)行融合創(chuàng)新，通過良好的可移植性，容器化的應(yīng)用能夠無差別地運(yùn)行在發(fā)機(jī)、自建機(jī)房以及公有云環(huán)境中；基于容器工具鏈能夠加快解決Serverless的交付。云廠商如阿里云提供了彈性容器實(shí)例（ECI）以及更上Serverless應(yīng)用引擎（SAE），Google提供了CloudRun服務(wù)，這都幫助用戶專注于容器化應(yīng)用構(gòu)建，而無需關(guān)心基礎(chǔ)設(shè)施的管理成本。此外Google也源了基于Kubernetes的Serverless應(yīng)用框架相對函數(shù)計(jì)算的編程模式，這類Serverless應(yīng)用服務(wù)支持容器鏡像作為載體，無需修改即可部署在Serverless環(huán)境中，可以享受到Serverless帶來的全托管免運(yùn)維、自動(dòng)彈性伸縮、按量計(jì)費(fèi)等優(yōu)勢。下面是傳統(tǒng)的彈性計(jì)算服務(wù)、基于容器的Serverless應(yīng)用服務(wù)和函數(shù)計(jì)算的對比：ServerlessSAEGoogleKnative近兩年來Serverless近年來呈加速發(fā)展趨勢，用戶使用Serverless架構(gòu)在可靠性、成本和研發(fā)運(yùn)維效小程序/Web/Mobile/API后端服務(wù)TheCloud-nativeArchitectureWhitePaperbyAlibabaWeb/MoibleAPI資源利用率通常小于30%，尤其是小程序等長尾應(yīng)用，資源利用率更是低于10%TheCloud-nativeArchitectureWhitePaperbyAlibabaTheCloud-nativeArchitectureWhite行任務(wù)信息的持久化和計(jì)算資源分配，使用Kubernetes等容器編排系統(tǒng)實(shí)現(xiàn)資源的伸縮和容錯(cuò)，自行搭建或集成ServerlessServerless通過將對象存儲(chǔ)和Serverless中心的大規(guī)模數(shù)據(jù)處理。用戶既可以通過增量處理對象存儲(chǔ)上的新增數(shù)據(jù)，也可以創(chuàng)建大量函數(shù)實(shí)例來并行處理存量數(shù)據(jù)。典型Serverless計(jì)算服務(wù)通過事件驅(qū)動(dòng)的方式，可以廣泛地與云端各種類型服務(wù)集成，用戶無需管理服務(wù)器通過和事件總線的集成，無論是一方BaaS云服務(wù)，還是三方的SaaS服務(wù)，或者是用戶自建的系統(tǒng)，所有事件都可以快速便捷地被函數(shù)計(jì)算處理。例如通過和API網(wǎng)關(guān)集成，外部請求可以轉(zhuǎn)化為事件，從而觸發(fā)后端函數(shù)APIIaaS資源利用率：在不損失性能的前提下，將計(jì)算密集型、I/O群整體資源利用率。資源調(diào)度服務(wù)是Serverless系統(tǒng)的關(guān)鍵鏈路。為了支撐每秒近百萬次的資源調(diào)度請求，系統(tǒng)需要對資源調(diào)度服TheTheCloud-nativeArchitectureWhitePaperbyAlibabaServerless計(jì)算平臺(tái)的定位是通用計(jì)算服務(wù)，要能執(zhí)行任意用戶代碼，因此安全是不可逾越的底線。系統(tǒng)應(yīng)從TheCloud-nativeArchitectureWhite4 開放應(yīng)用模型隨著Kubernetes技術(shù)體系逐漸成熟，整個(gè)云原生生態(tài)正在積極思考與探索如何達(dá)成云原生技術(shù)理念---“以應(yīng)用為中心”的終極愿景。2019年末，阿里云聯(lián)合微軟共同發(fā)布了OpenApplicationModel(OAM)源項(xiàng)目，其主要目標(biāo)是解決從Kubernetes項(xiàng)目到“以應(yīng)用為中心”的平臺(tái)之間最關(guān)鍵環(huán)節(jié)——標(biāo)準(zhǔn)化應(yīng)用容器技術(shù)以“徹底改變了軟件打包與分發(fā)方式”迅速得到大量企業(yè)的廣泛使用。不過軟件打包與分發(fā)方式的革新，并沒有能夠讓軟件本身的定義與描述發(fā)生本質(zhì)變化；基于Kubernetes的應(yīng)用管理體驗(yàn)，還沒有讓業(yè)務(wù)研發(fā)與運(yùn)維的工作變得足夠簡單。最典型的例子，Kubernetes至今都沒有“應(yīng)用”這個(gè)概念，它提供的是更細(xì)粒度的“工作負(fù)載”原語，比如Deployment或者DaemonSet。在實(shí)際環(huán)境中，一個(gè)應(yīng)用往往由一系列獨(dú)立組件組成，比如一個(gè)“PHP應(yīng)用容器”和一個(gè)“數(shù)據(jù)庫實(shí)例”組成電商網(wǎng)站；一個(gè)“參數(shù)服務(wù)節(jié)點(diǎn)”和一個(gè)“工作節(jié)點(diǎn)”組成機(jī)器學(xué)習(xí)訓(xùn)練任務(wù)；一個(gè)由“Deployment+StatefulSet+HPA+Service+Ingress”組成微服務(wù)應(yīng)用。OAM的第一個(gè)設(shè)計(jì)目標(biāo)就是補(bǔ)充“應(yīng)用”這一概念，建立對應(yīng)用和它所需的運(yùn)維能力定義與描述的標(biāo)準(zhǔn)OAMKubernetes在具體設(shè)計(jì)上，OAM的描述模型是基于KubernetesAPI的資源模型（KubernetesResourceModel）來構(gòu)建的，它強(qiáng)調(diào)一個(gè)現(xiàn)代應(yīng)用是多個(gè)資源的集合，而非一個(gè)簡單工作負(fù)載。例如在PHP電商網(wǎng)站的OAM語境中，一個(gè)PHP容器和它所依賴的數(shù)據(jù)庫以及它所需要使用的各種云服務(wù)，都是一個(gè)“電商網(wǎng)站”應(yīng)用的組成部分。同時(shí)，OAM把這個(gè)應(yīng)用所需的“運(yùn)維策略”也認(rèn)為是應(yīng)用的一部分，比如這個(gè)PHP容器所需的HPA（水平自動(dòng)擴(kuò)展策略）：ComponentComponentsecurity Componentsecurity TheTheCloud-nativeArchitectureWhitePaperbyAlibabaOAM項(xiàng)目的第二個(gè)設(shè)計(jì)目標(biāo)就是提供更高層級的應(yīng)用層抽象和以應(yīng)關(guān)注點(diǎn)分離的定義模型。Kubernetes作為一個(gè)面向基礎(chǔ)設(shè)施工程師的系統(tǒng)級項(xiàng)目，主要負(fù)責(zé)提供松耦合的基礎(chǔ)設(shè)施語義，這就使得用戶編寫KubernetesYAML文件時(shí)，往往會(huì)感覺這些文件里的關(guān)注點(diǎn)非常底層。實(shí)際上，對于業(yè)務(wù)研發(fā)人員和運(yùn)維人員而言，他們并不OAM組件依賴：OAM定義和規(guī)范了組成應(yīng)用的組件（Component）。例如，一個(gè)前端WebServer應(yīng)用運(yùn)維特征：OAM定義和規(guī)范了應(yīng)用所需的運(yùn)維特征（Trait）Ingress應(yīng)用配置：OAM定義和規(guī)范了應(yīng)用實(shí)例化所需的配置機(jī)制，從而能夠?qū)⑸鲜鲞@些描述轉(zhuǎn)化為具體應(yīng)用實(shí)例。例如，一個(gè)由PHP容器和Redis實(shí)例組成的應(yīng)用，在OAM的框架和規(guī)范下，就可以用如下的示意圖來表達(dá)Applicationscaling:route:securitygroup:scaling:securitygroup:Whatto Howto而在上述模塊化的應(yīng)用定義基礎(chǔ)上，OAM模型還強(qiáng)調(diào)整個(gè)模型的關(guān)注點(diǎn)分離特性。即業(yè)務(wù)研發(fā)人員負(fù)責(zé)定義與維護(hù)組件(Component)來描述服務(wù)單元，而運(yùn)維人員定義運(yùn)維特征(TraitOAM可交付物–ApplicationConfiguration。這種設(shè)計(jì)使OAM在能夠無限接入Kubernetes各種能力同時(shí)，為業(yè)務(wù)研發(fā)TheCloud-nativeArchitectureWhiteKubernetes依賴庫項(xiàng)目），KubernetesOAM功能一：無縫對接現(xiàn)有K8sAPI資源OAMKubernetes核心依賴庫支持將任何現(xiàn)有CRD被聲明為WorkloadTrait，而無需做任何改動(dòng)。這也意味著任何KubernetesAPI資源也可以被聲明為Workload或者Trait。通過這種設(shè)計(jì)，現(xiàn)有KubernetesOAM化變得非常容易。舉例：通過OAM定義和部署OpenFaaSComponent

apiVersion:core.oam.dev/vlalpha2kind:Componentname:web-functiondescription:OpenFaaSapiVersion:/v1kind:Function工工負(fù)載name:nodeinfohandler:nodemain.jsimage:function/nodeinfohttp_proxy::3128no_proxy:http://gateway/OAMKubernetesOAMKubernetes而這些工作負(fù)載和運(yùn)維能力之間的交互需要標(biāo)準(zhǔn)化、統(tǒng)一化，Wrklad與Trait標(biāo)準(zhǔn)化交互機(jī)制應(yīng)運(yùn)而生。比如DeploymentHPA（自動(dòng)水平擴(kuò)展控制器）的協(xié)作關(guān)系中，DeploymentOAMWorkload，HPATraitOAMApplicationConfigurationWorkloadTraitKubernetes在OAMKubernetes核心依賴庫中，過DuckTyping（鴨子類型）機(jī)制，在Trait對象上自動(dòng)記錄與之綁定Workload（Workload）和運(yùn)維能力（Trait）之間的雙向記錄關(guān)系：給定任何一工作負(fù)載（Workload）給定任何一個(gè)運(yùn)維能力（Trait），系統(tǒng)可以直接獲取到它所要作用于的所有工作負(fù)載（Workload）。這種雙向記錄關(guān)系對于在一個(gè)大規(guī)模的生產(chǎn)環(huán)境中保證運(yùn)維能力的可管理性、可發(fā)現(xiàn)性和應(yīng)用穩(wěn)定性是至關(guān)重要的。除此之外，OAMKubernetesComponent版本管理：對于任何一次Component變更，OAM平臺(tái)都將記錄下來其變更歷史，從而允許運(yùn)維通過Trait來進(jìn)行回滾、藍(lán)綠發(fā)布等運(yùn)維操作。Component間依賴關(guān)系與參數(shù)傳遞：該功能將解決部署亟需的組件間依賴問題，包括Component間的依賴和傳輸傳遞，以及TraitComponentComponent運(yùn)維策略：該功能將允許研發(fā)在Component中聲明對運(yùn)維能力的訴求，指導(dǎo)運(yùn)維人員或者系統(tǒng)給這個(gè)Component綁定和配置合理的運(yùn)維能力。相比于傳統(tǒng)PaSOpertor為基礎(chǔ)的云原生生態(tài)”銜接的現(xiàn)狀，基于AM和KberntesKberntes，保證應(yīng)用平臺(tái)能夠無縫接入整個(gè)云原生生態(tài)。同時(shí)，OMA/BApplicationKubernetes（+OAM核心依賴庫KubernetesTheCloud-nativeArchitectureTheCloud-nativeArchitectureWhitePaperbyAlibaba此外，OAM還定義了一組核心工作負(fù)載/運(yùn)維特征/應(yīng)用范疇，作為應(yīng)用程序交付平臺(tái)的基石。當(dāng)模塊化的Workload和Trait越來越多，就會(huì)形成組件市場。而OAM就像是這個(gè)組件市場的管理者，通過處理組件之間的關(guān)系，把許多組件集成為一個(gè)產(chǎn)品交付給用戶。OAM加持下的Kubernetes應(yīng)用拼圖，可以像樂高積木一樣靈活組TheCloud-nativeArchitectureWhiteOMCrosplneOAMOMKbernteserverlss臺(tái)甚至邊緣環(huán)境上運(yùn)行而無需對應(yīng)用描述做任何修改。OAM5 ServiceMeshServiceMesh是分布式應(yīng)用在微服務(wù)軟件架構(gòu)之上發(fā)展起來的新技術(shù)，旨在將那些微服務(wù)間的連接、安全、流性從業(yè)務(wù)進(jìn)程剝離到另外進(jìn)程中，ServiceMeshServiceMesh的DataDataMeshDiscoveryConfigurationControlServiceServiceIstio在這張架構(gòu)圖中，ServiceAServiceBProxy（EnvoySidecar）ServiceAServiceBControlPlanePilotMixer雖然相比較沒有服務(wù)網(wǎng)格的場景多了4個(gè)IPC通訊的成本，但整體調(diào)用的延遲隨著軟硬件能力的提升而并不會(huì)帶來顯著的影響，特別是對于百毫秒級別的業(yè)務(wù)調(diào)用而言可以控制在2%以內(nèi)。從另一方面，服務(wù)化的應(yīng)用并沒有做任何改造，就獲得了強(qiáng)大的流量控制能力、服務(wù)治理能力、可觀測能力、49IPC服務(wù)網(wǎng)格的技術(shù)發(fā)展上數(shù)據(jù)平面與控制平面間的協(xié)議標(biāo)準(zhǔn)化是必然趨勢。大體上，Servceesh繞“事實(shí)標(biāo)準(zhǔn)”去展——共建各云廠商共同采納的源軟件。從接口規(guī)范的角度：sto采納了nvy所實(shí)現(xiàn)的xDSMicrosofteMesh（SMI，致力于讓數(shù)據(jù)平面和控制平面的標(biāo)準(zhǔn)化做更高層次的抽象，以期為Isto、LinerderviceMesh務(wù)觀測、流量控制等方面實(shí)現(xiàn)最大程度的源能力復(fù)用。UDPA（UniversalaeAPI）是基于xDS協(xié)議xDS此外數(shù)據(jù)平面插件的擴(kuò)展性和安全性也得到了社區(qū)的廣泛重視。從數(shù)據(jù)平面角度，Envoy得到了包括Google、IBM、Cisco、Microsoft、阿里云等大廠的參與共建以及主流云廠商的采納而成為了事實(shí)標(biāo)準(zhǔn)。在Envoy的軟件設(shè)計(jì)為插件機(jī)制提供了良好擴(kuò)展性的基礎(chǔ)之上，目前正在探索將Wasm技術(shù)運(yùn)用于對各種插件進(jìn)行隔離，避免因?yàn)槟骋徊寮能浖毕荻鴮?dǎo)致整個(gè)數(shù)據(jù)平面不可用。Wasm技術(shù)的優(yōu)勢除了提供沙箱功能外，還能很好地支持多語言，最大程度地讓掌握不同編程語言的發(fā)者可以使用自己所熟悉的技能去擴(kuò)展Envoy的能力。在安全方面，ServiceMeshPODIdentitymTLSRPC上實(shí)施RBACACLIdentity（動(dòng)態(tài)選取一組節(jié)點(diǎn)組成安全域）。Gartner，IstioServiceMesh的事實(shí)標(biāo)準(zhǔn)，而ServiceMesh本身也將成為容器服務(wù)技術(shù)的標(biāo)配技術(shù)組件。即便如此，ServiceMesh(EarlyadoptionIstio，GoogleAWS分別推出了各自的云服務(wù)TrafficDirectorAppMesh。這兩個(gè)Service都推出了ServiceMesh產(chǎn)品，同樣采用Envoy技術(shù)作為數(shù)據(jù)面并在此基礎(chǔ)上提供了應(yīng)用發(fā)布、流量管控、APMTheTheCloud-nativeArchitectureWhitePaperbyAlibaba身的核心能力）。Istio（包括安全性、監(jiān)控、路由、連TheCloud-nativeArchitectureWhite能仍受業(yè)界詬病。源社區(qū)正試圖通過架構(gòu)層面演進(jìn)改善這一問題。由于Istio是建構(gòu)于Kubernetes技術(shù)之上，所KubernetesIstioIstioLinkerd、Consul這樣相對小眾的ServiceMesh解決方案。Linkerd在數(shù)據(jù)平面采用了Rust編程語言實(shí)現(xiàn)了linkerd-proxy，控制平面與Istio一樣采用Go語言編寫。最新的性能測試數(shù)據(jù)顯示，LinkerdIstioConsulConsulServer，在數(shù)據(jù)面上可以EnvoyIstio，LinkerdConsulIstioConduit作為Kubernetes的超輕量級ServiceMesh，其目標(biāo)是成為最快、最輕、最簡單且最安全的ServiceMesh。它使用Rust構(gòu)建了快速、安全的數(shù)據(jù)平面，用Go發(fā)了簡單強(qiáng)大的控制平面，總體設(shè)計(jì)圍繞著Linkerd相仿，數(shù)據(jù)平面是在應(yīng)用代碼之外運(yùn)行的輕量級代理，控制平面是一個(gè)高可用的控制器，然而與Linkerd不同的是，ConduitKubernetes6 DevOps就是為了提高軟件研發(fā)效率，快速應(yīng)對變化，持續(xù)交付價(jià)值的的一系列理念和實(shí)踐，其基本思想就是的技術(shù)和方法，用一種理念來整合資源。DevOps理念從提出到現(xiàn)在，已經(jīng)深刻影響了軟件發(fā)過程。DevOps提ITDevOps要實(shí)施DevOps，需要遵循一些基本原則，這些原則被簡寫為CAMS，文化自動(dòng)化（Automation）度量（Measurement）共享（Sharing）談到DevOpsDvps定性和安全性是第一。而發(fā)人員則想著如何盡快讓新功能上線，實(shí)現(xiàn)創(chuàng)新和突破，為客戶提供更大價(jià)值。不同的業(yè)務(wù)視，必然導(dǎo)致誤會(huì)和摩擦，導(dǎo)致雙方都覺得對方在阻撓自己完成工作。要實(shí)施Dvps，就首先要讓發(fā)和evps決的問題。只有解決了認(rèn)知問題，才能打破不同團(tuán)隊(duì)之間的鴻溝，實(shí)現(xiàn)流程自動(dòng)化，把大家的工作融合成一體。DvOs實(shí)施DevOps首先就要分析已有的軟件發(fā)流程盡量利用各種工具和平臺(tái)實(shí)現(xiàn)發(fā)和發(fā)布過程的自動(dòng)化。經(jīng)過多年發(fā)展，業(yè)界已經(jīng)有一套比較成熟的工具鏈可以參考和使用，不過具體落地還需因地制宜。TheCloud-nativeArchitectureWhitePaperTheCloud-nativeArchitectureWhitePaperbyAlibabavisibility：讓每個(gè)人可以了解團(tuán)隊(duì)其它人的工作。這樣可以知道是否某一項(xiàng)工作會(huì)影響另一部分。TheCloud-nativeArchitectureWhite透明性transparencytransferofknowledge點(diǎn)，從而導(dǎo)致一個(gè)人的休假或離職，就導(dǎo)致工作不能完成。另一個(gè)是提高團(tuán)隊(duì)的集體能力，團(tuán)隊(duì)的集體能力要高于個(gè)人的能力。要實(shí)現(xiàn)知識(shí)共享有很多方法。在敏捷發(fā)中，通過日站會(huì)來共享進(jìn)度。在發(fā)中，通過代碼、文檔和注釋來共享知識(shí)。hatpsDvOs個(gè)良好的文化氛圍并通過工具支持讓所有的共享更加方便高效。文化、自動(dòng)化、度量和共享四個(gè)方面相輔相成，獨(dú)立而又相互聯(lián)系，所以要落實(shí)DevOps時(shí)，要統(tǒng)一考慮。通CAMS也認(rèn)識(shí)到，CI/CDDevOps中很小的一部分。DevOps不僅僅是一組工具，更重要是代表了DevOps要有合乎理性的期待。DevOps提供了一套工具，工具能夠起多大的作用，其最重要的影響有兩個(gè)，一是使用工具的人，另外就是對于需要解決的問題本身復(fù)雜性的掌握。雖然DevOps已經(jīng)被廣泛接受和認(rèn)可，DevOpsDevOps進(jìn)化分為三個(gè)級別，80%被調(diào)查團(tuán)隊(duì)處于中等評級，而處于高級階段和低級階段的都在10%左右。報(bào)告分析，這是因?yàn)橥ㄟ^實(shí)現(xiàn)自動(dòng)施。這也符合組織文化變革中的J型曲線。在經(jīng)過了初期的效率增長之后，自動(dòng)化的深化進(jìn)入了瓶頸期。更進(jìn)一步DevOps落地和深化還有很長路要走。轉(zhuǎn)型的J

DevOpsDevOpsIaCIaC前面說過，DeOps所面對的矛盾就是發(fā)和運(yùn)維團(tuán)隊(duì)之間的矛盾。因?yàn)閮蓚€(gè)團(tuán)隊(duì)的關(guān)注點(diǎn)完全不同，或者說是沖突的。在這種背景下，IaCTheCloud-nativeArchitectureTheCloud-nativeArchitectureWhitePaperbyAlibabaTheCloud-nativeArchitectureWhite聲明式最明顯的優(yōu)點(diǎn)是變更審核簡單明了。配置中心會(huì)保存歷史上的所有版本的配置文件。通過對比新的配置和上一個(gè)版本，可以非常明確看到配置的具體變更。一般來說，每次變更的范圍不是很大，所以審核比較方便。通過審核可以攔截很多人為失誤。通過把所有的變更形式都統(tǒng)一為對配置文件的變更，無論是機(jī)器的變更、網(wǎng)絡(luò)的變更還是軟件版本和應(yīng)用配置的變更等。在人工審核之外，還可以通過程序來檢測用戶配置是否合乎要求，從而捕捉用戶忽略掉的一些系統(tǒng)性的限制，防患于未然。復(fù)雜性抽象：系統(tǒng)復(fù)雜性越來越高，系統(tǒng)間相互依賴和交互越來越廣泛，以及由于操作者無法掌握所有可能的假設(shè)條件、依賴關(guān)系等而帶來的運(yùn)維復(fù)雜性。解決這個(gè)問題的唯一思路，就是要把更多邏輯和知識(shí)沉淀到運(yùn)維平臺(tái)中，從而有效降低用戶使用難度和操作風(fēng)險(xiǎn)。GitOpsIaCGitGitOpsGitOpsGitDevOps所提倡的透明化原則。同時(shí)，GitOpsGitOpsGitOpsKubernetesConfig GitOpsGitGitOpsGitOps云原生時(shí)代的IT首先是容器技術(shù)和Kubernetes服務(wù)編排技術(shù)的結(jié)合，解決了應(yīng)用部署自動(dòng)化、標(biāo)準(zhǔn)化、配置化問題。CNCF打破了云上平臺(tái)的壁壘使建設(shè)跨平臺(tái)的應(yīng)用成為可能成為事實(shí)上的云上應(yīng)用發(fā)平臺(tái)的標(biāo)準(zhǔn)極大簡化了多云部署一個(gè)完整發(fā)流程涉及到很多步驟，而環(huán)節(jié)越多，一次循環(huán)花費(fèi)的時(shí)間越長，效率就越低。微服務(wù)通過把巨石應(yīng)用拆解為若干單功能的服務(wù)，減少了服務(wù)間的耦合性，讓發(fā)和部署更加便捷，可以有效降低發(fā)周期，提高部署靈活性。erviceeshrveress讓運(yùn)維對發(fā)透明，對于應(yīng)用所需資源進(jìn)行自動(dòng)伸縮。aaS是Srveress的一種實(shí)現(xiàn)，則更加簡化了發(fā)運(yùn)維的過程，從發(fā)到最后測試上線都可以在一個(gè)集成發(fā)環(huán)境中完。無論哪一種場景，后臺(tái)的運(yùn)維平臺(tái)的工作都是不可以缺少的，只是通過技術(shù)讓擴(kuò)容、容錯(cuò)等技術(shù)對發(fā)人員透明，讓效率更高。7 動(dòng)技術(shù)、Serverless等技術(shù)的廣泛應(yīng)用，其中網(wǎng)格化（ServiceMesh）、微服務(wù)和Serverless前面都講過了，這身架構(gòu)和采用的技術(shù)標(biāo)準(zhǔn)有關(guān)，比如一個(gè)PHP發(fā)的REST應(yīng)用也會(huì)自動(dòng)具備流量灰度發(fā)布能力、可觀測能力，IKberetesuerneesKubernetes服務(wù)注冊發(fā)現(xiàn)和配置中心的功能主要致力于解決微服務(wù)在分布式場景下的服務(wù)發(fā)現(xiàn)和分布式配置管理兩個(gè)核心問題。隨著云原生技術(shù)的發(fā)展，服務(wù)發(fā)現(xiàn)領(lǐng)域出現(xiàn)了兩個(gè)趨勢，一個(gè)是服務(wù)發(fā)現(xiàn)標(biāo)準(zhǔn)化（Istio），一個(gè)是服務(wù)下沉(CoreDNS)；配置管理領(lǐng)域也有兩個(gè)趨勢，一個(gè)是標(biāo)準(zhǔn)化（ConfigMap），一個(gè)是安全(Secret)。TheCloud-nativeArchitectureWhitePaperbyAlibaba提到事件驅(qū)動(dòng)就必須先講消息服務(wù)，消息服務(wù)是云計(jì)算aaS領(lǐng)域的基礎(chǔ)設(shè)施之一，主要用于解決分布式應(yīng)aaS化的消息使用模式，用戶無需預(yù)先購買服務(wù)器和自行搭建消息隊(duì)列，也無需預(yù)先評估消息使用容量，只需要在云平臺(tái)通即用，按消息使用量收費(fèi)。例如阿里云MaS（essagngasaServce）提供的是一站式消息平臺(tái)TheCloud-nativeArchitectureWhitePaperbyAlibaba事件驅(qū)動(dòng)架構(gòu)：由于IoTTheCloud-nativeArchitectureWhite件的抽象、異步化，來提供業(yè)務(wù)解耦、加快業(yè)務(wù)迭代。在過去事件驅(qū)動(dòng)架構(gòu)往往是通過消息中間件來實(shí)現(xiàn)，事件用消息來傳遞。進(jìn)入云計(jì)算時(shí)代，云廠商提供更加貼近業(yè)務(wù)的封裝，比如Azre一些運(yùn)維操作內(nèi)置事件，用戶可以自行編寫事件處理程序?qū)崿F(xiàn)運(yùn)維自動(dòng)化；ASSSTpcebokSererlss，所以現(xiàn)在很多云廠商都采用自身的ervrlessuntineFunction、AWSaEventBridge，作為事件驅(qū)動(dòng)和無服務(wù)器架構(gòu)的核心承載產(chǎn)品。41 ACNA（AlibabaCloudNativeArchitecting）IT計(jì)方法——ACNA（AlibabaCloudNativeArchitecting）。ACNA是一個(gè)「4+1」的架構(gòu)設(shè)計(jì)流程，「4」代表架構(gòu)設(shè)計(jì)的關(guān)鍵視角，包括企業(yè)戰(zhàn)略視角、業(yè)務(wù)發(fā)展視角、組織能力視角和云原生技術(shù)架構(gòu)視角；「14

能 化程 測

韌 自動(dòng)能 水ACNATheCloud-nativeArchitectureWhiteACNA除了是一個(gè)架構(gòu)設(shè)計(jì)方法，也包含了對云原生架構(gòu)的評估體系、成熟度衡量體系、行業(yè)應(yīng)用2 ITIT戰(zhàn)略只是服務(wù)好業(yè)務(wù)戰(zhàn)略進(jìn)行必要的技術(shù)支撐呢，還是IT戰(zhàn)略本身也是業(yè)務(wù)戰(zhàn)略的一部分。通常高科技公司本身會(huì)對云計(jì)算有更高的需求，比如通過大量使用云廠商提供的AI技術(shù)為用戶提供智能化的用戶體驗(yàn)，也會(huì)使用IoT和音視頻技IT略應(yīng)該在企業(yè)戰(zhàn)略中扮演技術(shù)賦能業(yè)務(wù)創(chuàng)新的重要角色，CTO（ChiefTechnologyOfficer）、（ChiefInformationOfficer）、CDO（ChiefDataOfficer）、CISO（ChiefInformationSecurityOfficer）3 業(yè)務(wù)快速上線、成本以及科技賦能業(yè)務(wù)創(chuàng)新。業(yè)務(wù)連續(xù)性訴求主要包括了數(shù)字化業(yè)務(wù)必須能夠持續(xù)為用ug自然災(zāi)害等意外事故。此外，當(dāng)業(yè)務(wù)規(guī)?？焖僭鲩L時(shí)，不能因?yàn)檐浻布Y源來不及購買或者部署而導(dǎo)致不能拓展新用戶。市場瞬息萬變，數(shù)字化業(yè)務(wù)由于比傳統(tǒng)實(shí)體業(yè)務(wù)更靈活可變而被要求更快的推向市場能力，包括新業(yè)務(wù)快速構(gòu)建的能力、現(xiàn)有業(yè)務(wù)快速更新的能力。這些能力訴求被云原生架構(gòu)深刻理解并在產(chǎn)品、工具、流程等層面得到不同程度的處理，需要注意的是這個(gè)訴求同時(shí)對組織結(jié)構(gòu)帶來了新的要求，也可能要求應(yīng)用進(jìn)行徹底的重構(gòu)（比如微服務(wù)化）。XX不用事先購買大批軟硬件資源，而是用多少付多少；同時(shí)大量采用云原生架構(gòu)也會(huì)降低企業(yè)發(fā)和運(yùn)維30%傳統(tǒng)模式下如果要使用高科技技術(shù)賦能業(yè)務(wù)，有一個(gè)冗長的選型、PC、試點(diǎn)和推廣的過程，而大量使用云廠商和三方的云服務(wù)，由于這些云服務(wù)具備更快的連接和試錯(cuò)成本，且在不同技術(shù)的集成上具備統(tǒng)一平臺(tái)和統(tǒng)一技術(shù)依賴的優(yōu)勢，從而可以讓業(yè)務(wù)更快速的應(yīng)用新技術(shù)進(jìn)行創(chuàng)新。4 云原生架構(gòu)涉及到的架構(gòu)升級對企業(yè)中的發(fā)、測試、運(yùn)維等人員都帶來了巨大的影響，技術(shù)架構(gòu)的不斷評估、檢查架構(gòu)設(shè)計(jì)與執(zhí)行之間的偏差。此外前面提到云原生服務(wù)中重要的架構(gòu)原則就是服務(wù)化（包括微服務(wù)、小服務(wù)等，這個(gè)領(lǐng)域典型的一個(gè)原則就是“康威定律”，要求企業(yè)中讓技術(shù)架構(gòu)與企業(yè)溝通架構(gòu)保持一致，否則會(huì)出現(xiàn)畸形的服務(wù)化架構(gòu)實(shí)現(xiàn)。5 用微服務(wù)或者小服務(wù)構(gòu)建業(yè)務(wù)，分離大塊業(yè)務(wù)中具備不同業(yè)務(wù)迭代周期的模塊，并讓業(yè)務(wù)以標(biāo)準(zhǔn)化API等方式SLA能力；TheCloud-nativeArchitectureWhitePaperTheCloud-nativeArchitectureWhitePaperbyAlibaba來影響，這就需要系統(tǒng)有全面的可觀測性，從傳統(tǒng)的日志方式、監(jiān)控、APMQoS度量；TheCloud-nativeArchitectureWhite關(guān)注整個(gè)發(fā)、測試和運(yùn)維三個(gè)過程的敏捷，推薦使用容器技術(shù)自動(dòng)化軟件構(gòu)建過程、使用OAM標(biāo)準(zhǔn)化軟件交付過程、使用IaC（InfrastructureasCode）/GitOps等自動(dòng)化CI/CD流水線和運(yùn)維過程；關(guān)注業(yè)務(wù)的數(shù)字化安全，在利用云服務(wù)加固業(yè)務(wù)運(yùn)行環(huán)境的同時(shí)，采用安全軟件生命周期發(fā)，使應(yīng)用符合ISO27001、PCIDSS6 7 由于云原生架構(gòu)包含了6個(gè)關(guān)鍵架構(gòu)維度（簡寫為SESORA，Service+Elasticity+Serverless+ObservabilityResilienceAutomation），因此我們先定義關(guān)鍵維度的成熟度級別：ACNA-（0（1（2ACNA-（3&&&360SLA（HAHA、冷備容災(zāi)AI由于云原生架構(gòu)包含了6個(gè)關(guān)鍵架構(gòu)維度（簡寫為SESORA，Service+Elasticity+Serverless+ObservabilityResilienceAutomation），因此我們先定義關(guān)鍵維度的成熟度級別：101016ACNA-116ACNA-2SESORASESORA6TheTheCloud-nativeArchitectureWhitePaperbyAlibaba51 阿里巴巴云原生產(chǎn)品家族包括容器產(chǎn)品家族、微服務(wù)產(chǎn)品家族、Serverless產(chǎn)品家族、ServiceMesh微服務(wù)網(wǎng)關(guān)

EventCenter（EventBridge） 微服務(wù)引擎 微服務(wù)引擎 分布式配置（FC、

分布式事務(wù)ServiceMesh基礎(chǔ)設(shè)（EDAS、ACM、ARMS、

IT

MQ（MQ系列 數(shù)據(jù)庫 大數(shù)據(jù) 其他2 Kubernetes版（ACK）和ServerlessKubernetes（ASK）PaaSServerlessKubernetesApacheSpringApache之上，計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、安全等，并為企業(yè)客戶提供標(biāo)準(zhǔn)化接口、優(yōu)化的能力和簡化的用戶體驗(yàn)。通過的CNCFKubernetesACK端到端可觀測性、多云混合云等。鏡像服務(wù)（ACR）作為企業(yè)云原生應(yīng)用資產(chǎn)管理的核心，企業(yè)可以借之高效管理DockerHelmChartCI/CDDevSecOps3 EDAS（企業(yè)分布式應(yīng)用服務(wù)）是一個(gè)面向微服務(wù)應(yīng)用的應(yīng)用全生命周期PaS持HSF、DugCloud技術(shù)體系，提供ECS集群和K8s集群的應(yīng)用發(fā)、部署、監(jiān)控、運(yùn)維等全棧式解決方案。TheCloud-nativeArchitectureWhitePaperbyAlibabaMSE（微服務(wù)引擎）是一個(gè)面向業(yè)界主流源微服務(wù)框架TheCloud-nativeArchitectureWhitePaperbyAlibabaACM（應(yīng)用配置管理），是一款應(yīng)用配置中心產(chǎn)品，實(shí)現(xiàn)在微服務(wù)、DeOps、大數(shù)據(jù)等場景下的分布式配置服務(wù)，保證配置的安全合規(guī)。CSBMicroGateway（微服務(wù)網(wǎng)關(guān)服務(wù)）針對微服務(wù)架構(gòu)下API放的特點(diǎn)，提供能與微服務(wù)環(huán)境的治理策略無縫銜接的網(wǎng)關(guān)服務(wù)，實(shí)現(xiàn)高效的微服務(wù)API放。TheCloud-nativeArchitectureWhiteGTS（全局事務(wù)服務(wù)）用于實(shí)現(xiàn)分布式環(huán)境下特別是微服務(wù)架構(gòu)下的高性能事務(wù)一致性，可以與多種數(shù)據(jù)源、微服務(wù)框架配合使用，實(shí)現(xiàn)分布式數(shù)據(jù)庫事務(wù)、多庫事務(wù)、消息事務(wù)、服務(wù)鏈路級事務(wù)及各種組合。ARMS（)Prometeus監(jiān)控三大子產(chǎn)品，涵蓋了瀏覽器、小程序、AP、分布式應(yīng)用和容器環(huán)境等性能管理，實(shí)現(xiàn)全棧式性能監(jiān)控和端到端全鏈路追蹤診斷。鏈路追gAnalysis為分布式應(yīng)用的發(fā)者提供了完整的調(diào)用鏈路還原調(diào)用請求量統(tǒng)計(jì)、鏈路拓?fù)?、?yīng)用依賴分析等工具，能夠幫助發(fā)者快速分析和診斷分布式應(yīng)用架構(gòu)下的性能瓶頸，提高微服務(wù)時(shí)代下的發(fā)診斷效率。egService）是一款云化測試工具，提供性能測試、API等多種能力，緊密結(jié)合監(jiān)控、流控等產(chǎn)品提供一站式高可用能力，高效檢驗(yàn)和管理業(yè)務(wù)性能。4 Serverless產(chǎn)品家族FC（函數(shù)計(jì)算）ServerlessSAE（Serverless應(yīng)用引擎）實(shí)現(xiàn)了Serverless架構(gòu)+微服務(wù)架構(gòu)的完美融合，真正按需使用、按量計(jì)費(fèi)，節(jié)省閑置計(jì)算資源，同時(shí)免去IaaS運(yùn)維，有效提升發(fā)運(yùn)維效率；SAE支持SpringCloud、DubboHSFServerless工作流是一個(gè)用來協(xié)調(diào)多個(gè)分布式任務(wù)執(zhí)行的全托管Serverless云服務(wù)，致力于簡化5 托管服務(wù)網(wǎng)格（ASM）提供全托管的微服務(wù)應(yīng)用流量管理平臺(tái)，兼容stioKbrnees能力。AAS（應(yīng)用高可用服務(wù)）是專注于提高應(yīng)用及業(yè)務(wù)高可用的工具平臺(tái)，目前主要提供應(yīng)用架構(gòu)探測感知，故障注入式高可用能力評測和流控降級高可用防護(hù)三大核心能力，通過各自的工具模塊可以快速低成本的在營銷活動(dòng)場景、業(yè)務(wù)核心場景全面提升業(yè)務(wù)穩(wěn)定性和韌性。6 RocketMQApacheRocketMQ構(gòu)建的低延遲、高并發(fā)、高可用、高可Kafaea的產(chǎn)品之一，阿里云提供全托管服務(wù)，用戶無需部署運(yùn)維，更專業(yè)、更可靠、更安全。消息隊(duì)列AMQP版由阿里云基于MQP標(biāo)準(zhǔn)協(xié)議自研，完全兼容RabiMQ源生態(tài)以及多語言客戶端，打造分布式、高吞吐、低延遲、高可擴(kuò)展的云消息服務(wù)。MQTTMIIoT金融支付、智能餐飲、即時(shí)聊天、移動(dòng)Apps、智能設(shè)備、車聯(lián)網(wǎng)等多種應(yīng)用場景；通過對MQTT、WebSocket等協(xié)議的全面支持，連接端和云之間的雙向通信，實(shí)現(xiàn)C2C、C2B、B2C等業(yè)務(wù)場景之EventBridgeSaaSCloudEvents1.0協(xié)議在這些應(yīng)用之間路TheCloud-nativeArchitectureWhiteTheCloud-nativeArchitectureWhitePaperbyAlibabaPolarDB是阿里巴巴自主研發(fā)的下一代關(guān)系型分布式云原生數(shù)據(jù)庫，目前兼容三種數(shù)據(jù)庫引擎：MySQL、PostgreSQL、高度兼容Oracle語法；計(jì)算能力最高可擴(kuò)展至1000TheCloud-nativeArchitectureWhite可達(dá)10T。PlarB經(jīng)過阿里巴巴雙十一活動(dòng)的最佳實(shí)踐，讓用戶既享受到源的靈活性與價(jià)格，又享受到商業(yè)數(shù)據(jù)庫的高性能和安全性。PolarDB-X（原DRDS升級版）是由阿里巴巴自主研發(fā)的云原生分布式數(shù)據(jù)庫，融合分布式SQLDRDSX-DB，專注解決海量數(shù)據(jù)存儲(chǔ)、超高并發(fā)吞吐、大表瓶頸以及復(fù)雜計(jì)算118 AnalyticDBMySQL（ABySL）是一種支持MSQLQL:2003海量數(shù)據(jù)進(jìn)行即時(shí)的多維分析透視和業(yè)務(wù)探索，快速構(gòu)建企業(yè)云上數(shù)據(jù)倉庫。產(chǎn)品規(guī)格按需可選，基礎(chǔ)I10TB云原生數(shù)據(jù)倉庫AnalyticDBPostgreSQLSQL2003，PostgreSQL/Greenplum,Oracle維度在線分析探索，也支持高性能離線數(shù)據(jù)處理；是面向互聯(lián)網(wǎng)，金融，證券，保險(xiǎn)，銀行，數(shù)字政務(wù)，新零售等行業(yè)有競爭力的數(shù)據(jù)倉庫方案。6隨著云計(jì)算的普及與云原生的廣泛應(yīng)用，越來越多的從業(yè)者、決策者清晰地認(rèn)識(shí)到「云原生化將成為企業(yè)技術(shù)創(chuàng)新的關(guān)鍵要素，也是完成企業(yè)數(shù)字化轉(zhuǎn)型的最短路徑」。因此，具有前瞻思維的互聯(lián)網(wǎng)企業(yè)從應(yīng)用誕生之初就扎根于云端，謹(jǐn)慎穩(wěn)重的新零售、政府、金融、醫(yī)療等領(lǐng)域的企業(yè)與機(jī)構(gòu)也逐漸將業(yè)務(wù)應(yīng)用遷移上云，深度使用云原生技術(shù)與云原生架構(gòu)。面對架構(gòu)設(shè)計(jì)、發(fā)方式到部署運(yùn)維等不同業(yè)務(wù)分布式、自助、按需等產(chǎn)品優(yōu)勢。借助以下幾個(gè)典型實(shí)踐案例，我們來看看企業(yè)如何使用云原生架構(gòu)解決交付周期長、資源利用率低等實(shí)際業(yè)務(wù)問題。1 TB100+個(gè)計(jì)算節(jié)點(diǎn)來實(shí)時(shí)處理業(yè)務(wù)。IDCIDC著業(yè)務(wù)體量指數(shù)級增長，業(yè)務(wù)形式愈發(fā)多元化。原有系統(tǒng)暴露出不少問題，傳統(tǒng)IOE架構(gòu)、各系統(tǒng)架構(gòu)的不規(guī)范、核心業(yè)務(wù)搬遷上阿里云。2019年始將業(yè)務(wù)逐步從IDCTheCloud-nativeArchitectureWhite申通核心業(yè)務(wù)系統(tǒng)原架構(gòu)基于Vmwre+OraleKubernetes的云原生架構(gòu)體系。其中，引入云原生數(shù)據(jù)庫并完成應(yīng)用基于容器的微服務(wù)改造是整個(gè)應(yīng)用服務(wù)架構(gòu)重OLTPOLAP型數(shù)據(jù)庫，將在線數(shù)據(jù)與離線分析邏輯拆分到兩種數(shù)據(jù)庫中，改變此前完全依賴OracleOracle伴隨著容器化技術(shù)的引進(jìn)，通過應(yīng)用容器化有效解決了環(huán)境不一致的問題，確保應(yīng)用在發(fā)、測試、生產(chǎn)環(huán)由于過往很多業(yè)務(wù)是基于Oracle的存儲(chǔ)過程及觸發(fā)器完成的，系統(tǒng)間的服務(wù)依賴也需要Oracle數(shù)據(jù)庫OGG同步完成。這樣帶來的問題就是系統(tǒng)維護(hù)難度高且穩(wěn)定性差。通過引入Kubernetes的服務(wù)發(fā)現(xiàn)，組建微ACK云數(shù)據(jù)庫」的云原生解決方案，從Linux-外部：sto-內(nèi)部SLB-外部Linux-外部：sto-內(nèi)部SLB-外部SLB-內(nèi)部外部內(nèi)部生產(chǎn)-2Nginx生產(chǎn)-3Ingress云VMWare基礎(chǔ)設(shè)施，全部計(jì)算資源取自阿里云的神龍裸金屬服務(wù)器。相較于一般云服務(wù)器（EC），Kuernees神龍服務(wù)器能夠獲得更優(yōu)性能及更合理的資源利用率。且云上資源按需取量，對于擁有大促活動(dòng)等短期大流量業(yè)務(wù)場景的申通而言極為重要。相較于線下自建機(jī)房、常備機(jī)器，云上資源隨取隨用。在大促活動(dòng)結(jié)束后，云上資源使用完畢后即可釋放，管理與采購成本更低，相應(yīng)效率。流量接入，阿里云提供兩套流量接入，一套是面向公網(wǎng)請求，另外一套是服務(wù)內(nèi)部調(diào)用。域名解析采用云DNS及PrivateZone。借助Kubernetes的Ingress能力實(shí)現(xiàn)統(tǒng)一的域名轉(zhuǎn)發(fā)，以節(jié)省公網(wǎng)SLB的數(shù)量，提高運(yùn)維管基于Kubernetes打造的云原生PaaSDevOps閉環(huán)，統(tǒng)一測試，集成，預(yù)發(fā)、生產(chǎn)環(huán)境；集成了日志、鏈路診斷、MetricsApiServer每個(gè)應(yīng)用都在Kubernetes上面創(chuàng)建單獨(dú)的一個(gè)Namespace，應(yīng)用跟應(yīng)用之間實(shí)現(xiàn)資源隔離。通過定義各個(gè)應(yīng)amlTheCloud-nativeArchitectureWhitePaperbyAlibabaTheCloud-nativeArchitectureWhitePaperbyAlibaba按量付費(fèi)。另外云產(chǎn)品都免運(yùn)維自行托管在云端，有效節(jié)省人工運(yùn)維成本，讓企業(yè)更專注于核心業(yè)務(wù)。TheCloud-nativeArchitectureWhite59SLA次，部分