2023阿里云原生架構白皮書

TheCloud-nativeArchitectureWhitePaperbyAlibaba3

ServerlessServiceMesh產(chǎn)品家族 3主要云原生技 6云原生架構實踐案 放應用模型 ServiceMesh

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

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

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

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

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

能 化程 測

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

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

分布式事務ServiceMesh基礎設（EDAS、ACM、ARMS、

IT

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