阿里云原生技術(shù)架構(gòu)白皮書（附下載）
關(guān)于云原生的定義，版本眾多，云原生架構(gòu)的理解也不盡相同，阿里根據(jù)自身的云原生技術(shù)、產(chǎn)品和上云實踐，給出自己的理解。
從技術(shù)的角度，云原生架構(gòu)是基于云原生技術(shù)的一組架構(gòu)原則和設(shè)計模式的集合，旨在將云應(yīng)用中的非業(yè)務(wù)代碼部分進行最大化的剝離，從而讓云設(shè)施接管應(yīng)用中原有的大量非功能特性（如彈性、韌性、安全、可觀測性、灰度等），使業(yè)務(wù)不再有非功能性業(yè)務(wù)中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。
業(yè)務(wù)代碼、三方軟件、處理非功能特性的代碼中只有業(yè)務(wù)代碼是核心，是對業(yè)務(wù)真正帶來價值的，另外兩個部分都只算附屬物，但隨著軟件規(guī)模的增大、業(yè)務(wù)模塊規(guī)模變大、部署環(huán)境增多、分布式復(fù)雜性增強，使得今天的軟件構(gòu)建變得越來越復(fù)雜，對開發(fā)人員的技能要求也越來越高。
云原生架構(gòu)相比較傳統(tǒng)架構(gòu)進了一大步，從業(yè)務(wù)代碼中剝離了大量非功能性特性（不會是所有，比如易用性還不能剝離）到 IaaS 和 PaaS 中，從而減少業(yè)務(wù)代碼開發(fā)人員的技術(shù)關(guān)注范圍，通過云廠商的專業(yè)性提升應(yīng)用的非功能性能力。此外，具備云原生架構(gòu)的應(yīng)用可以最大程度利用云服務(wù)和提升軟件交付能力，進一步加快軟件開發(fā)。
云原生架構(gòu)有非常多的架構(gòu)模式，這里選取一些對應(yīng)用收益更大的主要架構(gòu)模式進行討論。
服務(wù)化架構(gòu)是云時代構(gòu)建云原生應(yīng)用的標(biāo)準(zhǔn)架構(gòu)模式，要求以應(yīng)用模塊為顆粒度劃分一個軟件，以接口契約（例如 IDL）定義彼此業(yè)務(wù)關(guān)系，以標(biāo)準(zhǔn)協(xié)議（HTTP、gRPC 等）確保彼此的互聯(lián)互通，結(jié)合 DDD（領(lǐng)域模型驅(qū)動）、TDD（測試驅(qū)動開發(fā)）、容器化部署提升每個接口的代碼質(zhì)量和迭代速度。服務(wù)化架構(gòu)的典型模式是微服務(wù)和小服務(wù)（Mini Service）模式，其中小服務(wù)可以看做是一組關(guān)系非常密切的服務(wù)的組合，這組服務(wù)會共享數(shù)據(jù)，小服務(wù)模式通常適用于非常大型的軟件系統(tǒng)，避免接口的顆粒度太細(xì)而導(dǎo)致過多的調(diào)用損耗和治理復(fù)雜度。
通過服務(wù)化架構(gòu)，把代碼模塊關(guān)系和部署關(guān)系進行分離，每個接口可以部署不同數(shù)量的實例，單獨擴縮容，從而使得整體的部署更經(jīng)濟。
Mesh化架構(gòu)是把中間件框架（比如 RPC、緩存、異步消息等）從業(yè)務(wù)進程中分離，讓中間件SDK與業(yè)務(wù)代碼進一步解耦，從而使得中間件升級對業(yè)務(wù)進程沒有影響，甚至遷移到另外一個平臺的中間件也對業(yè)務(wù)透明。分離后在業(yè)務(wù)進程中只保留很“薄”的Client部分，Client 通常很少變化，只負(fù)責(zé)與 Mesh 進程通訊，原來需要在SDK中處理的流量控制、安全等邏輯由 Mesh 進程完成。
實施 Mesh 化架構(gòu)后，大量分布式架構(gòu)模式（熔斷、限流、降級、重試、反壓、隔倉等）都由Mesh進程完成，即使在業(yè)務(wù)代碼的制品中并沒有使用這些三方軟件包；同時獲得更好的安全性（比如零信任架構(gòu)能力）、按流量進行動態(tài)環(huán)境隔離、基于流量做冒煙/回歸測試等。
Serverless 將“部署”這個動作從運維中“收走”，使開發(fā)者不用關(guān)心應(yīng)用在哪里運行，更不用關(guān)心裝什么 OS、怎么配置網(wǎng)絡(luò)、需要多少 CPU …… 從架構(gòu)抽象上看，當(dāng)業(yè)務(wù)流量到來/業(yè)務(wù)事件發(fā)生時，云會啟動或調(diào)度一個已啟動的業(yè)務(wù)進程進行處理，處理完成后云自動會關(guān)閉/調(diào)度業(yè)務(wù)進程，等待下一次觸發(fā)，也就是把應(yīng)用的整個運行時都委托給云。
今天Serverless還沒有達(dá)到任何類型的應(yīng)用都適用的地步，因此架構(gòu)決策者需要關(guān)心應(yīng)用類型是否適合于 Serverless 運算。如果應(yīng)用是有狀態(tài)的，云在進行調(diào)度時可能導(dǎo)致上下文丟失，畢竟Serverless的調(diào)度不會幫助應(yīng)用做狀態(tài)同步；如果應(yīng)用是長時間后臺運行的密集型計算任務(wù)，會得不到太多Serverless的優(yōu)勢；如果應(yīng)用涉及到頻繁的外部I/O（網(wǎng)絡(luò)或者存儲，以及服務(wù)間調(diào)用），也因為繁重的I/O負(fù)擔(dān)、時延大而不適合。Serverless非常適合于事件驅(qū)動的數(shù)據(jù)計算任務(wù)、計算時間短的請求/響應(yīng)應(yīng)用、沒有復(fù)雜相互調(diào)用的長周期任務(wù)。
分布式環(huán)境中的CAP困難主要是針對有狀態(tài)應(yīng)用，因為無狀態(tài)應(yīng)用不存在C（一致性）這個維度，因此可以獲得很好的A（可用性）和P（分區(qū)容錯性），因而獲得更好的彈性。在云環(huán)境中，推薦把各類暫態(tài)數(shù)據(jù)（如session）、結(jié)構(gòu)化和非結(jié)構(gòu)化持久數(shù)據(jù)都采用云服務(wù)來保存，從而實現(xiàn)存儲計算分離。但仍然有一些狀態(tài)如果保存到遠(yuǎn)端緩存，會造成交易性能的明顯下降，比如交易會話數(shù)據(jù)太大、需要不斷根據(jù)上下文重新獲取等，則可以考慮通過采用 Event Log + 快照（或 Check Point）的方式，實現(xiàn)重啟后快速增量恢復(fù)服務(wù)，減少不可用對業(yè)務(wù)的影響時長。
1）傳統(tǒng)采用XA模式，雖然具備很強的一致性，但是性能差；
2）基于消息的最終一致性（BASE）通常有很高的性能，但是通用性有限，且消息端只能成功而不能觸發(fā)消息生產(chǎn)端的事務(wù)回滾；
3）TCC模式完全由應(yīng)用層來控制事務(wù)，事務(wù)隔離性可控，也可以做到比較高效；但是對業(yè)務(wù)的侵入性非常強，設(shè)計開發(fā)維護等成本很高；
4）SAGA 模式與TCC模式的優(yōu)缺點類似但沒有 try 這個階段，而是每個正向事務(wù)都對應(yīng)一個補償事務(wù)，也是開發(fā)維護成本高；
5）開源項目 SEATA 的 AT 模式非常高性能且無代碼開發(fā)工作量，且可以自動執(zhí)行回滾操作，同時也存在一些使用場景限制。
可觀測架構(gòu)包括Logging、Tracing、Metrics三個方面，其中Logging提供多個級別的詳細(xì)信息跟蹤，由應(yīng)用開發(fā)者主動提供；Tracing 提供一個請求從前端到后端的完整調(diào)用鏈路跟蹤，對于分布式場景尤其有用；Metrics則提供對系統(tǒng)量化的多維度度量。
架構(gòu)決策者需要選擇合適的、支持可觀測的開源框架（比如OpenTracing、OpenTelemetry），并規(guī)范上下文的可觀測數(shù)據(jù)規(guī)范（例如方法名、用戶信息、地理位置、請求參數(shù)等），規(guī)劃這些可觀測數(shù)據(jù)在哪些服務(wù)和技術(shù)組件中傳播，利用日志和tracing信息中的span id/trace id，確保進行分布式鏈路分析時有足夠的信息進行快速關(guān)聯(lián)分析。
由于建立可觀測性的主要目標(biāo)是對服務(wù) SLO（Service Level Objective）進行度量，從而優(yōu)化 SLA，因此架構(gòu)設(shè)計上需要為各個組件定義清晰的SLO，包括并發(fā)度、耗時、可用時長、容量等。
事件驅(qū)動架構(gòu)（EDA，Event Driven Architecture）本質(zhì)上是一種應(yīng)用/ 組件間的集成架構(gòu)模式，典型的事件驅(qū)動架構(gòu)如下圖。
事件和傳統(tǒng)的消息不同，事件具有schema，所以可以校驗event 的有效性，同時EDA 具備QoS保障機制，也能夠?qū)κ录幚硎∵M行響應(yīng)。事件驅(qū)動架構(gòu)不僅用于（微）服務(wù)解耦，還可應(yīng)用于下面的場景中。
增強服務(wù)韌性：由于服務(wù)間是異步集成的，也就是下游的任何處理失敗甚至宕機都不會被上游感知，自然也就不會對上游帶來影響；
CQRS（Command Query Responsibility Segregation）：把對服務(wù)狀態(tài)有影響的命令用事件來發(fā)起，而對服務(wù)狀態(tài)沒有影響的查詢才使用同步調(diào)用的API 接口；結(jié)合 EDA 中的 Event Sourcing 可以用于維護數(shù)據(jù)變更的一致性，當(dāng)需要重新構(gòu)建服務(wù)狀態(tài)時，把EDA 中的事件重新“播放”一遍即可；
數(shù)據(jù)變化通知：在服務(wù)架構(gòu)下，往往一個服務(wù)中的數(shù)據(jù)發(fā)生變化，另外的服務(wù)會感興趣，比如用戶訂單完成后，積分服務(wù)、信用服務(wù)等都需要得到事件通知并更新用戶積分和信用等級；
構(gòu)建開放式接口：在 EDA 下，事件的提供者并不用關(guān)心有哪些訂閱者，不像服務(wù)調(diào)用的場景 —— 數(shù)據(jù)的產(chǎn)生者需要知道數(shù)據(jù)的消費者在哪里并調(diào)用它，因此保持了接口的開放性；
事件流處理：應(yīng)用于大量事件流（而非離散事件）的數(shù)據(jù)分析場景，典型應(yīng)用是基于 Kafka 的日志處理；
基于事件觸發(fā)的響應(yīng)：在 IoT 時代大量傳感器產(chǎn)生的數(shù)據(jù)，不會像人機交互一樣需要等待處理結(jié)果的返回，天然適合用EDA來構(gòu)建數(shù)據(jù)處理應(yīng)用。
>>參考來源：云原生技術(shù)架構(gòu)白皮書
>>白皮書下載：
鏈接:?
https://pan.baidu.com/s/1veSg3tpt3uJMWbN4M7B7yA?
提取碼: yk87
轉(zhuǎn)載申明：轉(zhuǎn)載本號文章請注明作者和來源，本號發(fā)布文章若存在版權(quán)等問題，請留言聯(lián)系處理，謝謝。
推薦閱讀
更多架構(gòu)相關(guān)技術(shù)知識總結(jié)請參考“架構(gòu)師技術(shù)全聯(lián)盟書店”相關(guān)電子書(35本技術(shù)資料打包匯總詳情可通過“閱讀原文”獲取)。
全店內(nèi)容持續(xù)更新，現(xiàn)下單“架構(gòu)師技術(shù)全店打包匯總(全)”，后續(xù)可享全店內(nèi)容更新“免費”贈閱，價格僅收188元(原總價290元)。
溫馨提示：
掃描二維碼關(guān)注公眾號，點擊閱讀原文鏈接獲取“架構(gòu)師技術(shù)全店資料打包匯總(全)”電子書資料詳情。
