? ? ? ?隨著業務與環境的變化，云原生的趨勢越來越明顯。現在正是企業從云計算向云原生轉型的時代，云原生理念經過幾年落地實踐的打磨已經得到了企業的廣泛認可，云上應用管理更是成為企業數字化轉型的必選項。可以說，現在的開發者，或正在使用基于云原生技術架構衍生的產品和工具，或正是這些產品和工具的開發者。

? ? ? ?1 云原生成為基礎戰略

? ? ? ?那么，什么是云原生？每個人都有不同的解釋。我認為，首先，云原生就是為了在云上運行而開發的應用，是對于企業持續快速、可靠、規模化地交付業務的解決方案。云原生的幾個關鍵詞，如容器化、持續交付、DevOps、微服務等無一不是在詮釋其作為解決方案的特性與能力，而Kubernetes更以其開創性的聲明式API和調節器模式，奠定了云原生的基礎。

其次，云原生是一種戰略。云原生的誕生是為了解決傳統應用在架構、故障處理、系統迭代等方面存在的問題。從傳統應用到云，與其說是一次技術升級，不如說將其視為戰略轉型。企業上云面臨應用開發、系統架構、企業組織架構，甚至商業產品的全面整合，是否加入云原生大潮一次是將從方方面面影響企業長期發展的戰略性決策。

? ? ? ?2 搭配開源底色的云原生

? ? ? ?近幾年誕生的與架構相關的開源項目大部分采用云原生架構設計，開源為企業打造云原生的架構貢獻了中堅力量。

? ? ? ?開源技術與生態值得信任，云可以給用戶帶來好的伸縮性，降低資源浪費。云原生和開源的關系也可以從以CNCF為主的開源基金會持續推進云原生的發展中略窺一二。許多開源項目本身就是為云原生架構而生的，這是用戶上云會優先考慮的基礎軟件特點。

? ? ? ?以Apache軟件基金會為例，它是一個中立的開源軟件孵化和治理平臺。Apache軟件基金會在長期的開源治理中，總結出的Apache之道（Apache Way）被大家奉為圭臬，其中“社區大于代碼”廣為流傳，即沒有社區的項目是難以長久的。一個社區和代碼保持高活躍度的開源項目，經過全世界開發者在多種場景的打磨，可以不斷完善、頻繁地升級迭代，并誕生豐富的生態以滿足不同的用戶需求。云原生大潮與當前開源大環境兩種因素疊加，就會使那些伴隨技術環境不斷升級的優秀技術推陳出新、脫穎而出，不適應時代的技術會漸漸落后，甚至被淘汰。正如我之前所說，云原生是戰略性決策，企業的戰略性決策必定會首選最先進、最可靠的技術。

? ? ? ?3 為云而生的消息流數據系統

? ? ? ?前文講述了云原生環境下開源的重要性，那么一個云原生的開源項目需要如何去設計、規劃和演進？云原生時代的企業數字化轉型應如何選擇消息和流系統？在本文中，我將以自己全身心投入的開源云原生消息和流數據系統Apache Pulsar的設計和規劃為例進行剖析。希望能夠為大家提供參考思路，并為尋求消息和流數據系統解決方案帶來啟發。

? ? ? ?回顧歷史：消息與流的雙軌制

? ? ? ?消息隊列通常用于構建核心業務應用程序服務，流則通常用于構建包括數據管道等在內的實時數據服務。消息隊列擁有比流更長的歷史，也就是開發者們所熟悉的消息中間件，它側重在通信行業，常見的系統有RabbitMQ和ActiveMQ。相對來說，流系統是一個新概念，多用于移動和處理大量數據的場景，如日志數據、點擊事件等運營數據就是以流的形式展示的，常見的流系統有Apache Kafka和AWS Kinesis。

? ? ? ?由于之前的技術原因，人們把消息和流分為兩種模型分別對待。企業需要搭建多種不同的系統來支持這兩種業務場景（見圖1），由此造成基礎架構存在大量“雙軌制”現象，導致數據隔離、數據孤島，數據無法形成順暢流轉，治理難度大大提升，架構復雜度和運維成本也都居高不下。

圖1 企業搭建不同的系統支持業務場景導致的“雙軌制”

? ? ? ?基于此，我們亟須一個集成消息隊列和流語義的統一實時數據基礎設施，Apache Pulsar由此而生。消息在Apache Pulsar主題上存儲一次，但可以通過不同訂閱模型，以不同的方式進行消費（見圖2），這樣就解決了傳統消息和流“雙軌制”造成的大量問題。

圖2 Apache Pulsar集成消息隊列與流語義

? ? ? ?實現天然云原生的關鍵要素

? ? ? ?上文提到，云原生時代帶給開發者的是能夠快速擴縮容、降低資源浪費，加速業務推進落地。有了類似Apache Pulsar這種天然云原生的消息和流數據基礎設施，開發者可以更好地聚焦在應用程序和微服務開發，而不是把時間浪費在維護復雜的基礎系統上。

? ? ? ?為什么說Apache Puslar是“天然云原生”？這與在當初設計原型的底層架構有關。存儲計算分離、分層分片的云原生架構，極大地減輕了用戶在消息系統中遇到的擴展和運維困難，能在云平臺以更低成本給用戶提供優質服務，能夠很好地滿足云原生時代消息系統和流數據系統的需求。

? ? ? ?生物學有一個結論，叫“結構與功能相適應”。從單細胞原生生物到哺乳動物，其生命結構越來越復雜，具備的功能也越來越高級。基礎系統同理，“架構與功能相適用”體現在Apache Pulsar上有這樣幾點：

? ? ? ?存儲計算分離架構可保障高可擴展性，可以充分發揮云的彈性優勢。

? ? ? ?跨地域復制，可以滿足跨云數據多備的需求。

? ? ? ?分層存儲，可充分利用如AWS S3等的云原生存儲，有效降低數據存儲成本。

? ? ? ?輕量化函數計算框架Pulsar Functions，類似于AWS Lambda平臺，將FaaS引入Pulsar。而Function Mesh是一種Kubernetes Operator，助力用戶在Kubernetes中原生使用Pulsar Functions和連接器，充分發揮Kubernetes資源分配、彈性伸縮、靈活調度等特性。

? ? ? ?基礎架構：存儲計算分離、分層分片

? ? ? ?上文說到，Pulsar在誕生之初就采用了云原生的設計，即存儲計算分離的架構，存儲層基于Apache軟件基金會開源項目BookKeeper。BookKeeper是一個高一致性、分布式只追加（Append-only）的日志抽象，與消息系統和流數據場景類似，新的消息不斷追加，剛好應用于消息和流數據領域。

? ? ? ?Pulsar架構中數據服務和數據存儲是單獨的兩層（見圖3），數據服務層由無狀態的Broker節點組成，數據存儲層則由Bookie節點組成，服務層和存儲層的每個節點對等。Broker僅負責消息的服務支持，不存儲數據，這為服務層和存儲層提供了獨立的擴縮容能力和高可用能力，大幅減少了服務不可用時間。BookKeeper中的對等存儲節點，可以保證多個備份被并發訪問，也保證了即使存儲中只有一份數據可用，也可以對外提供服務。

圖3 Pulsar架構

? ? ? ?在這種分層架構中，服務層和存儲層都能夠獨立擴展，提供靈活的彈性擴容，特別是在彈性環境（如云和容器）中能自動擴縮容，動態適應流量峰值。同時，顯著降低集群擴展和升級的復雜性，提高系統的可用性和可管理性。此外，這種設計對容器也非常友好。

? ? ? ?Pulsar將主題分區按照更小的分片粒度來存儲（見圖4）。這些分片被均勻打散，將會分布在存儲層的Bookie節點上。這種以分片為中心的數據存儲方式，將主題分區作為一個邏輯概念，分為多個較小的分片，并均勻分布和存儲在存儲層中。這樣的設計可以帶來更好的性能、更靈活的擴展性和更高的可用性。

圖4 分片存儲模型

? ? ? ?從圖5可見，相比大多數消息隊列或流系統（包括Apache Kafka）均采用單體架構，其消息處理和消息持久化（如果提供了的話）都在集群內的同一個節點上。此類架構設計適合在小型環境部署，當大規模使用時，傳統消息隊列或流系統就會面臨性能、可伸縮性和靈活性方面的問題。隨著網絡帶寬的提升、存儲延遲的顯著降低，存儲計算分離的架構優勢變得更加明顯。

圖5 傳統單體架構vs存儲計算分層架構

? ? ? ?讀寫區別

? ? ? ?接著上述內容，我們來看一下消息的寫入、讀取等方面的區別體現在哪里。

? ? ? ?首先看寫入。圖6左側是單體架構的應用，數據寫入leader，leader將數據復制到其他follower，這是典型的存儲計算不分離的架構設計。在圖6右側則是存儲計算分離的應用，數據寫入Broker，Broker并行地往多個存儲節點上寫。假如要求3個副本，在選擇強一致性、低延遲時兩個副本返回才算成功。如果Broker有leader的角色，就會受限于leader所在機器的資源情況，因為leader返回，我們才能確認消息成功寫入。

圖6 單體架構與分層架構寫入對比

? ? ? ?在右側對等的分層架構中，三個中任意兩個節點在寫入后返回即為成功寫入。我們在AWS上進行性能測試時發現，兩種結構在刷盤時的延遲也會有幾毫秒的差距：在單機系統中落在leader上的topic會有延遲，而在分層架構中受到延遲影響較小。

? ? ? ?在實時數據處理中，實時讀取占據了90%的場景（見圖7）。在分層架構中，實時讀取可以直接通過Broker的topic尾部緩存進行，不需要接觸存儲節點，能夠在很大程度上提升數據讀取的效率和實時性。

圖7 單體架構與分層架構讀取實時數據對比

? ? ? ?架構也導致了讀取歷史數據時的區別。從圖8可見，在單體架構中，回放消息時直接找到leader，從磁盤上讀取消息。在存儲計算分離的架構上，需要將數據加載到Broker再返回客戶端，以此保證數據讀取的順序性。當讀取數據對順序性沒有嚴格要求時，Apache Pulsar支持同時并行從多個存儲節點讀取數據段，即使是讀取一個topic的數據也可以利用多臺存儲節點的資源提升讀取的吞吐量，Pulsar SQL也是利用這種方式來讀取的。

圖8 單體架構與分層架構讀取歷史數據對比

? ? ? ?IO隔離

? ? ? ?BookKeeper內部做了很好的數據寫入和讀取的IO隔離。BookKeeper可以指定兩類存儲設備，圖9左側是Journal盤存放writeheadlog，右側才是真正存儲數據的地方。即使在讀取歷史數據時，也會盡可能地保證寫入的延遲不會受到影響。

圖9 BookKeeper的IO隔離

? ? ? ?如果利用云平臺的資源，Pulsar的IO隔離可以讓用戶選擇不同的資源類型。由于Journal盤并不需要存放大量的數據，很多云用戶會根據自己的需求配置來達到低成本、高服務質量的目的，如Journal盤使用低存儲空間、高吞吐低延遲的資源，數據盤選擇對應吞吐可以存放大量數據的設備。

? ? ? ?擴縮容

? ? ? ?存儲計算分離允許Broker和BookKeeper分別進行擴縮容，下面為大家介紹擴縮容topic的過程。假設n個topic分布在不同的Broker上，新的Broker加入能夠在1s內進行topic ownership的轉移，可視為無狀態的topic組的轉移。這樣，部分topic可以快速地轉移至新的Broker。

? ? ? ?對于存儲節點來說，多個數據分片散布在不同的BookKeeper節點上，擴容時即新加入一個BookKeeper，并且這種行為不會導致歷史數據的復制。每一個topic在經歷一段時間的數據寫入后，會進行分片切換，即切換到下一個數據分片。在切換時會重新選擇Bookies放置數據，由此達到逐漸平衡。如果有BookKeeper節點掛掉，BookKeeper會自動補齊副本數，在此過程中，topic不會受到影響。

? ? ? ?跨云數據多備

? ? ? ?Pulsar支持跨云數據多備（見圖10），允許組成跨機房集群來進行數據的雙向同步。很多國外用戶在不同的云廠商部署跨云集群，當有一個集群出現問題時，可以快速切換到另外的集群。異步復制只會產生細微的數據同步缺口，但可以獲得更高的服務質量，同時訂閱的狀態也可以在集群間同步。

圖10 跨云數據多備

? ? ? ?4 進入無服務器架構時代

? ? ? ?Pulsar Functions與Function Mesh讓Pulsar跨入了無服務器架構時代。Pulsar Functions是一個輕量級的計算框架，主要是為了提供一個部署和運維都能非常簡單的平臺。Pulsar Functions主打輕量、簡單，可用于處理簡單的ETL作業（提取、轉化、加載）、實時聚合、事件路由等，基本可以覆蓋90%以上的流處理場景。Pulsar Functions借鑒了無服務器架構（Serverless）和函數即服務（FaaS）理念，可以讓數據得到“就近”處理，讓價值得到即時挖掘（見圖11）。

圖11 單條Pulsar Function消息流轉

? ? ? ?Pulsar Functions只是單個應用函數，為了讓多個函數關聯在一起，組合完成數據處理目標，誕生了Function Mesh（已開源）。Function Mesh同樣采用無服務器架構，它也是一種Kubernetes Operator，有了它，開發者就可以在Kubernetes上原生使用Pulsar Functions和各種Pulsar連接器，充分發揮Kubernetes資源分配、彈性伸縮、靈活調度等特性。例如，Function Mesh依賴Kubernetes的調度能力，確保Functions的故障恢復能力，并且可以在任意時間適當調度Functions。

? ? ? ?Function Mesh主要由Kubernetes Operator和Function Runner兩個組件組成。Kubernetes Operator監測Function Mesh CRD、創建Kubernetes資源（即StatefulSet），從而在Kubernetes運行Function、連接器和Mesh。Function Runner負責調用Function和連接器邏輯，處理從輸入流中接收的事件，并將處理結果發送到輸出流。目前，Function Runner基于Pulsar Functions Runner實現。

? ? ? ?當用戶創建Function Mesh CRD時（見圖12），Function Mesh控制器從Kubernetes API服務器接收已提交的CRD，然后處理CRD并生成相應的Kubernetes資源。例如，Function Mesh控制器在處理Function CRD時，會創建StatefulSet，它的每個Pod都會啟動一個Runner來調用對應的Function。

圖12 Function Mesh處理CRD過程

? ? ? ?Function Mesh API基于現有Kubernetes API實現，因此Function Mesh資源與其他Kubernetes原生資源兼容，集群管理員可以使用現有Kubernetes工具管理Function Mesh資源。Function Mesh采用Kubernetes Custom Resource Definition（CRD），集群管理員可以通過CRD自定義資源，開發事件流應用程序。

? ? ? ?用戶可以使用kubectl CLI工具將CRD直接提交到Kubernetes集群，而無須使用pulsar-admin CLI工具向Pulsar集群發送Function請求。Function Mesh控制器監測CRD并創建Kubernetes資源，運行自定義的Function、Source、Sink或Mesh。這種方法的優勢在于Kubernetes直接存儲并管理Function元數據和運行狀態，從而避免在Pulsar現有方案中可能存在的元數據與運行狀態不一致的問題。