開源云原生大潮下的訊息和流系統演進

云原生的誕生是為了解決傳統應用在架構、故障處理、系統迭代等方面的問題，而開源則為企業打造云原生的架構貢獻了中堅力量，本文作者在全身心投入開源以及每日參與云原生的程序中，對開源行業和云原生流系統解決方案有了不一樣的思考與實踐，

作者 | 李鵬輝 責編 | 唐小引
出品 | 新程式員

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

本文出自《新程式員·云原生和全面數字化實踐》

云原生成為基礎戰略

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

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

搭配開源底色的云原生

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

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

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

為云而生的訊息流資料系統

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

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

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

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

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

實作天然云原生的關鍵要素

上文提到，云原生時代帶給開發者的是能夠快速擴縮容、降低資源浪費，加速業務推進落地，有了類似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中的對等存盤節點，可以保證多個備份被并發訪問，也保證了即使存盤中只有一份資料可用，也可以對外提供服務，

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

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

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

讀寫區別

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

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

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

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

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

IO隔離

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

如果利用云平臺的資源，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），允許組成跨機房集群來進行資料的雙向同步，很多國外用戶在不同的云廠商部署跨云集群，當有一個集群出現問題時，可以快速切換到另外的集群，異步復制只會產生細微的資料同步缺口，但可以獲得更高的服務質量，同時訂閱的狀態也可以在集群間同步，

進入無服務器架構時代

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，

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現有方案中可能存在的元資料與運行狀態不一致的問題，

結語

在本文中，我分享了自己在云原生環境下，對于開源行業的思考和云原生流平臺解決方案的技術實踐，作為一名全身心投入的開源人，我很高興看到近幾年有越來越多的人認可開源理念并成為開源開發者與貢獻者，開源行業正在蓬勃發展，我希望能和無數的開發者一樣，在開源道路上一往無前，助力更多企業加速云原生和數字化行程，

本文出自《新程式員·云原生和全面數字化實踐》，在《新程式員003》中，我們聚焦“云原生時代的開發者”與“全面數字化轉型”兩大主題，阿里、位元組跳動、網易、快手、亞馬遜等互聯網大廠的云原生技術的賦能者，從技術定義、技術應用、實踐案例分享等方面，以直擊內核的硬核輸出全面決議云原生，幫助開發者在云原生時代快速找到適合自身發展的技術范式，

同時，我們也將對微軟、英特爾、華為、施耐德、西門子等首批開啟數字化轉型的企業展開報道，通過十多位技術專家分享的鮮活案例，一窺金融、新零售、工業物聯網等領域的數字化轉型成果，幫助更多關注數字化轉型的開發者從先驅者的經驗中獲得啟迪，
閱讀更多相關技術文章及行業資訊，歡迎訂閱《新程式員003》紙質書+電子書，