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