摘要：如今，Serverless化已經成為訊息流平臺發展的新趨勢，而如何更好地基於Serverless化的訊息流平臺進行應用設計和開發，則成為了一個值得思考的問題。
本文分享自華為雲社群《9000字乾貨：從訊息流平臺Serverless之路，看Serverless標準演進》，作者：華為雲PaaS服務小智。
這是一個最美好的時代。
隨著以數字化升級為代表的第四次工業革命浪潮的席捲，企業正在不斷地深化運用這一技術，構建一個又一個全連線，全感知，全場景，全智慧的數字世界，進而最佳化再造物理世界的業務，對傳統業務模式，經營模式，管理模式以及商業模式進行創新和重塑，帶來新一輪可觀的業務增長。
而這背後，雲服務已經成為企業數字化升級的必然選擇。
Gartner預測，2025年將有近三分之二的應用軟體支出轉向雲技術，到2026年全球雲端計算市場將突破萬億美元。
去年10月，隨著馬斯克旗下的X工程技術團隊的重磅發帖，下雲，瞬間成為了一個熱議話題。拋開背後的政治、商業合作、經濟下行等因素不談，從工程技術以及資產運營角度來看，早些年，一部分藉助低固定成本的公有云率先成長起來的企業，出於進一步安全可靠、低邊際成本、靈活定製等新一輪發展需求，開始將自己的業務有選擇的下雲。當然，下雲依然有不小代價，還要考慮自建IDC機房的運營成本（不僅僅是建設成本）。
事實上，現代雲平臺和自建IDC，對於資源的利用率都沒有達到盡善盡美的程度，資源浪費的情況始終存在，這主要受限於傳統的軟體技術架構，並沒有很好地適應雲化場景。雲廠商也在不斷積極探索與創新，透過技術變革不斷最佳化結構，提供更靈活的付費模式。
另一方面，一些雲廠商透過FinOps服務（一種透過工程、財務、產品等方面的跨職能團隊的協作，實現更快的產品交付、獲得更多的財務控制和可預測性的實踐活動）幫助企業合理使用雲。由此可見，從“上好雲”到“用好雲”，是所有企業新一輪數字化飛躍的關鍵機遇所在。
為了幫助企業更有效地用好雲，雲廠商們不約而同地轉向Serverless這一新的架構設計理念。不但能夠充分利用資源規模化效應，提供更好的彈性，也能讓企業享受到真正的按需使用，按用付費。
Serverless模型使開發者無需關注具體的部署資源，透過事件驅動的方式使用雲資源，執行業務。
Serverless化正在朝著雲端計算通用標準正規化演進。Gartner 則認為這是“十大未來將影響基礎設施和運維的技術趨勢之一”。雲平臺所面對的使用者群體非常龐大，結合Serverless化架構，能夠將資源利用、成本最佳化提升到新的高度。雲廠商深厚的工程技術團隊和運維經驗，也能更好地支撐企業不斷的技術演進升級。
作為Serverless架構通用事件驅動底座的訊息流平臺，在這一時期迎來了新的爆發增長。在諸如金融、遊戲、電商、交通、教育等關鍵行業，訊息流引擎扮演了削峰填谷、依賴解耦、實時通訊與計算等重要作用。作為線上業務核心鏈路的基礎元件，其往往同時具有訊息（資料）和流的屬性。
在訊息場景，如訂單業務等，對可靠性、一致性等有較高的要求；而在流的場景，如風控、實時交通等，又對延時、吞吐有更高的要求。傳統的訊息流平臺，往往基於單體架構或傳統分散式架構設計，難以充分發揮雲上巨大的資源優勢，在擴縮容速度、成本等方面，都面臨著巨大的挑戰。
在深度用雲的雲原生時代，Serverless架構模式能夠更大限度地發揮雲平臺的優勢。目前，不少廠家也在不斷進行Serverless化的嘗試。但由於對部署架構、儲存方式依然有著強烈包袱，存在著不必要的資源開銷，並沒有一種非常完善、成熟的解決方案。華為雲訊息流在不斷的架構演進中，也在嘗試解決這些問題，實現一種適用於訊息流的Serverless化技術方案。
01 華為雲訊息流發展歷程
華為雲訊息流平臺在為客戶持續提供價值、使能業務的過程中，不斷思考、探索如何更好地發揮資源價值，提供更靈活、更低成本、更高可靠的訊息流能力。我們在技術發展過程中，也經歷過幾次大的架構演進：
最初的架構是一個共享叢集的模式，所有業務都跑在一個公共的叢集上，不同的業務按不同Topic進行隔離。
這種模式的優點是構建複雜度較低，資源提前部署，使用者不感知底層節點，只關注業務Topic，起步成本較低。
然而，隨著使用者和業務的快速增長，雲上叢集的壓力也越來越大，尤其在一些大流量、大資料量的場景下，這種共享叢集的模式開始顯得力不從心。同時，由於資源共享帶來的爆炸半徑大、資源搶佔、擾鄰的問題，也使得其在面對多使用者、高負載場景時，存在一定的侷限性。
因此，為了更好地適應雲上大業務量的場景，我們演進出了獨立叢集的架構，即每個租戶的叢集都是獨佔的，使用獨立的計算和儲存資源部署，網路上也是獨立的VPC。可靠性上，支援計算節點在AZ級和物理機級的反親和部署，保證單物理機故障、單AZ故障時，叢集依然可用，並且單叢集故障或異常，不會影響其他叢集，也不會有叢集間的資源爭搶和擾鄰問題。
在這種架構模式下，使用者需要提前評估業務量，建立特定規模的叢集。然而，業務總是在變化的，每個業務在不同時間階段也可能有不同的效能容量訴求，建立新的叢集往往意味著業務的拆分，需要進行業務改造，在生產環境中往往是成本很高，或者是難以接受的。
因此，也對單叢集的擴充套件能力提出了要求，這種擴充套件主要體現在儲存、計算和頻寬上。
訊息流平臺本質上也是一種儲存服務平臺，要滿足不斷變化的儲存訴求，就需要支援儲存空間的動態擴充套件。
基於LVM技術，在需要擴容儲存空間時，建立指定大小的雲盤，掛載到對應的計算節點，並加入對應的邏輯卷組，擴充到邏輯卷中，達到儲存空間的動態擴容，上層業務邏輯不用感知底層的多塊雲盤。對於計算和頻寬資源，我們則是透過擴大節點規格和增加節點數來達到擴容的目的。
這種單租架構也是業界比較常採用的一種方式，然而這種架構模式沒有實現完全的Serverless化，也存在著一些不足，主要體現在儲存、計算和頻寬資源的彈性和成本上。
目前主流實現下，在叢集擴容時，新節點由於沒有分片的分佈，無法承接流量，均衡負載，需要進行分片的遷移，而遷移會因為資料複製而帶來遷移時間長、佔用資源的問題，雖然可以透過限制遷移的頻寬和設定在低峰時間進行遷移，一定程度上減小遷移帶來的業務衝擊，但對於高負載下緊急擴容場景，遷移時間長和業務衝擊的問題依然難以避免。對於儲存資源，業務需要按最大儲存空間訴求來預留儲存容量，導致儲存空間的利用率不高，會有一定的儲存資源浪費。
面對這些問題，我們在不斷思考、探索的過程中，也逐漸演進出了新的資料流處理平臺架構。
02 新一代訊息架構
當前主流架構下，由於計算和資料繫結，計算層擴容時，壓力無法分擔到新的節點，需要將資料分片遷移到新節點。
而分片遷移的過程需要同步歷史資料，該過程會導致額外的頻寬佔用，導致原有節點負載加重，影響業務。
需要遷移資料是因為計算和資料是繫結的，每個節點只能訪問本節點的資料。那麼，我們如果可以將資料訪問解綁，就可以不遷移資料，消除資料遷移帶來的諸多問題。
計算和儲存分離，能夠使得業務擴充套件更靈活，計算的擴充套件不需要遷移資料，但伴隨而來，是更復雜的部署架構和基礎設施資源，對於雲上多租、大業務量等場景，更適合存算分離模式，而在小型化部署等輕量化場景，更適合存算一體的模式。
因此，一個更普適的架構，應該是儲存計算可分可合，邏輯上獨立，物理部署上同時相容兩種模式。我們基於這種思想，也進行了一系列的實踐。將儲存與上層佇列模型進行了解耦，徹底消除了儲存介質、儲存位置及儲存方式與佇列模型的耦合關係，透過面向應用的邏輯資料對映訪問儲存。
邏輯儲存架構
訊息流資料往往是一種過程性資料，資料追加寫入，讀取也主要集中在剛寫入的資料。基於這種特點，我們首先實現了一種邏輯儲存方式，在遷移分片時，只做邏輯上的遷移，物理資料在不同節點儲存，透過後設資料實現邏輯儲存和物理儲存的對映。
前面提到，訊息是一種流式的資料，通常情況下，生產的訊息都會被及時消費，也就是隻需要訪問本地的資料，並不會產生時延的增加，並且隨著新資料的不斷產生和歷史資料的清理，分片的資料分佈會逐漸趨近於目標節點，達到就近訪問的效果。
透過這種邏輯儲存方式，避免了在分割槽遷移時進行資料同步帶來的資源開銷，從實測的結果看，能做到秒級的遷移，並且不會增加原有節點的負載，讓擴縮容和遷移過程更平順。
這種方式一定程度上解決了分割槽遷移過程中的資料同步問題，但在物理部署上依然是儲存計算繫結的，對於儲存成本高、利用率低等問題，依然沒有得到很好的解決。
在業界，我們看到一些訊息流服務也在做相關的嘗試，但是對部署架構、儲存方式有著強烈耦合，帶來了較大的運維成本。
我們看到，造成這些問題的關鍵在於儲存介質、部署和計算依然存在一定的耦合，因此需要做更徹底的分離。
分級儲存架構
我們知道，在儲存體系中，儲存介質、訪問時延、成本是互相平衡的，如下圖所示，越接近CPU的儲存介質，時延越低，相應的，容量也越小，單位容量的成本也越高。
因此，不同型別的儲存介質適合儲存不同型別的資料，訪問頻繁、時延低的資料適合放在高效能、低容量的儲存，訪問不頻繁、資料量大、需要長時間儲存的資料，適合放在低效能、大容量的儲存中。
在儲存領域，業界已有對冷熱資料分離的相關實踐。對冷熱資料的劃分，主要根據其訪問的頻率，高頻訪問的為熱資料，低頻的為冷資料，其次是根據最近訪問原則，長久未訪問的資料也會被判定為冷資料。
AWS根據資料訪問的頻率，將頻繁訪問的線上類資料劃分為熱資料，非頻繁訪問的離線類資料劃分為冷資料，在Redshift架構中，則是將冷熱資料進行了分離儲存，本地快取的熱資料使用SSD儲存，而冷資料則透過S3進行儲存，以提高儲存效率，最佳化成本。
我們看訊息流資料的特點：生產是追加式的，消費場景絕大多數都是及時消費，在金融、訊息回溯等場景，可能需要訪問歷史的資料，這部分歷史資料的特點是資料量大，但訪問相對不頻繁。因此，從讀寫和儲存的生命週期，將資料分為熱、溫、冷三種：
•熱資料：實時讀寫的快取資料，這部分資料既是最近訪問的，又是近期會頻繁訪問的，這種訪問趨勢在流場景是可以預測的，這類資料通常資料量不會很大，但對訪問時延、吞吐要求較高；
•溫資料：在訊息積壓場景，資料會在寫入後一段時間才內讀取，訪問頻率和實時性相對熱資料更低，但其訪問依然是可預見的，且對訪問效能也有較高的要求，適合高效能、小容量的儲存；
•冷資料：已經消費過的歷史資料，只在訊息回溯等場景再次訪問，訪問頻率低，適合儲存在大容量、低成本的物件儲存中。
我們根據訊息流資料的分佈特點，採用分級儲存的架構，將冷熱資料分別儲存在大容量的遠端儲存和低時延的本地儲存，達到存算分離、成本最佳化的效果。
華為雲訊息流平臺在分級儲存架構上的實踐，採用塊儲存作為本地儲存，物件儲存作為遠端儲存。物件儲存的特點是儲存容量大，相比本地塊儲存具有成本上的優勢，並且支援按需使用。
在Serverless化大背景下，物件儲存正在逐漸成為一種標準儲存解決方案。而在讀寫效能上，塊儲存具有更好的時延表現。
因此，我們使用了本地塊儲存和遠端物件儲存相結合的方式，本地塊儲存保證了資料實時寫入的低時延，物件儲存則儲存不常訪問但資料量龐大的冷資料，達到效能和成本的平衡。
同時，大多業務場景中，流量都是波動的，本地塊儲存可以作為遠端儲存的緩衝，起到為磁碟IO“削峰填谷”的效果，消除物件儲存瞬時效能的不足帶來的影響。
IO讀寫路徑
根據前面對訊息流資料冷熱特徵的分析，我們在訊息生產時，先寫入pagecache，再同步或非同步地刷到本地資料段，非同步地將資料段上傳到物件儲存中，並更新後設資料。
對於冷資料往物件儲存中解除安裝的過程，我們的設計是，從時間和空間兩個維度出發，儲存時間達到閾值，或超出儲存容量閾值的資料，這部分資料已經不是訪問的熱點了，對訪問的時延要求也沒有那麼高，可以由遠端儲存來承載，會被非同步解除安裝到物件儲存中。
消費訊息時，根據需要拉取的資料位點，判斷目標資料是否在本地儲存，如果本地儲存命中，則直接從本地儲存獲取資料，這種情況通常發生在及時消費的場景，往往在pagecache中就能命中，也就不需要產生真正的磁碟IO。當目標資料不在本地時，會嘗試從遠端儲存進行拉取。
一種直觀的想法是從遠端把資料檔案下載到本地磁碟，再從本地磁碟進行讀取。
然而這種方式下，會因為IO串擾而導致嚴重的效能問題。我們知道，流式儲存在實時消費場景吞吐很高，其中一個重要原因，就是消費的資料，在pagecache中能命中，也就是我們所說的熱資料，直接從pagecache獲取資料，無需緩慢的IO操作，如果出現大量的冷資料訪問，資料已經從pagecache中被逐出，需要從磁碟中讀取，就會導致磁碟IO，時延上升，並且pagecache中的熱資料被冷資料逐出，導致及時消費的流量也需要從磁碟中讀取，pagecache“失效”，也就是快取汙染問題。
如果我們把資料檔案從遠端下載到本地儲存，再從本地儲存進行讀取，那麼快取汙染問題依然存在，更加拖慢了訪問的延遲，同時，因為多了從遠端下載資料到本地的過程，增加了IO頻寬的開銷，每份資料要進行兩次磁碟IO，導致額外的資源開銷和時延開銷，也增加了本地塊儲存的空間使用，在發生大量隨機讀時，會導致大量下載資料檔案，使原本輕量的本地塊儲存變得不堪重負。
前面提到，訊息流資料是流式的、過程性的資料，在訪問冷資料時也具有這種特點，一段資料通常不會在較長一段時間內被反覆訪問，也就是通常不會有相對固定的熱點資料，或者說熱點資料是在持續變化的。
基於這種特點，我們實現了基於記憶體的遠端資料訪問機制，透過應用層記憶體池技術，對記憶體空間進行管理，將快取的資料分為多個slice，和真實的資料段進行對映，資料訪問不需要額外的磁碟IO，頻寬佔用更小、時延更低。而且實現了冷熱資料的IO隔離，解決了pagecache汙染的問題，吞吐能力提升20%以上。同時能夠避免因大量隨機讀而導致大量下載資料檔案，最佳化本地塊儲存空間，降低儲存成本。
快取預讀最佳化
由於訊息的訪問通常是順序的，因此對於即將訪問的資料位置，通常是可預測的，可以透過提前預讀下一塊資料，提升資料從遠端載入的整體效能，減小讀取卡頓。
在快取管理模組中，存在一個預載入水位，當某個slice的訪問位點達到預載入水位時，快取管理模組開始載入下一個或多個slice，該過程是非同步執行的，並不會阻塞當前的讀取操作。這樣，當訪問到下一個slice時，資料已經提前完成了載入，避免了因從遠端載入而產生的卡頓。
儲存Serverless化
目前業界主流的訊息流平臺，使用者需要提前購買指定大小的磁碟容量，並持續關注磁碟容量使用率的監控，在容量不足時提前進行容量擴容，否則可能因為磁碟寫滿而影響業務。
在實際的生產環境中，業務量並不是一直穩定不變的，很多業務都存在業務高峰和低谷，如雙11的流量突增等，相應的，對磁碟容量的需求也可能有較大的波動，在這種模式下，業務通常需要按業務量峰值來評估磁碟使用量，並預留資源，這就直接導致了在非業務高峰時期的資源的浪費。
據估算，目前業界訊息流平臺的儲存使用率平均在20%-30%左右。
在分級儲存架構下，由於大量的資料都被解除安裝到了遠端物件儲存，對於業務層而言，是一個統一的儲存池，而且支援儲存空間的按需使用和超長時間儲存，無需預留儲存空間，無需進行磁碟的擴容和縮容，消除儲存空間使用率不高帶來的成本浪費，提升資源利用率，結合線上統計資料，可以提升3-5倍的儲存使用率。
同時，華為雲物件儲存服務透過儲存介質的慢盤/壞道檢測、AZ內裝置和資料冗餘、AZ之間資料容災、跨區域複製等技術方案，提供針對介質、伺服器、機櫃、資料中心和區域的多級可靠性保障。其資料永續性高達99.9999999999%（12個9），可用性高達99.995%，遠高於傳統架構。
基於這種資料的高可靠和高可用，業務層在解除安裝資料時，只需保留主副本，減少了多副本對儲存空間的額外開銷。以三副本為例，在相同業務量下，可以減少約2/3的儲存空間，結合儲存按需使用帶來的儲存使用率提升，綜合儲存效率提升10-15倍。
彈性擴縮容
在這種分級儲存架構下，由於Broker本地只有有限的一小部分溫資料，使得Broker變得更“輕量”，在進行叢集擴縮容時，只需遷移Broker本地的一小部分的資料，大大降低了遷移過程中資料同步帶來的負載影響，並且大幅縮短遷移時間。
這裡我們會發現，在遷移過程中，同步的這部分資料，最終也會被解除安裝到遠端儲存，那麼如果我們直接解除安裝到遠端，就可以省去這部分的資料同步，透過遠端儲存來達到資料的“同步”。
這裡我們用到了前面提到的邏輯儲存的思想，將分級儲存和邏輯儲存結合，在分割槽遷移時，新的Broker只同步增量的資料，當需要發生主備切換時，原主會進行資料檔案的切割，並將分段的資料檔案解除安裝到遠端儲存，當解除安裝完成後，進行主備切換，切換過程在秒級完成，無需同步歷史資料，10GB資料的節點，可在1min內完成解除安裝和主備切換。在高負載場景下也能實現高效、平滑的擴容。
故障轉移
對於故障的場景，基於引擎自身的主備能力，能做到秒級的感知、切換，配合客戶端的重試機制，能做到業務不中斷的故障自愈。對於部分節點故障導致的負載加重問題，由於計算節點沒有歷史資料，可以透過快速擴容節點和分割槽遷移，實現負載的均衡。
售賣模式
傳統的訊息流平臺售賣方式，是基於例項叢集的規格，使用者需要知道每種規格對應的效能，需要評估節點規格、節點數量等，而使用者關注更多的是能力，業務需要多少吞吐、多少TPS。我們在新的架構中，提供按效能指標售賣的模式，如TPS等，讓使用者根據效能指標選擇所需的規格，迴歸業務本身，而無需關注底層資源，這也是Serverless化理念所倡導的。
計費主要分為計算部分、儲存部分和增值服務部分。計算部分的計費模式為基礎頻寬/TPS + 彈性流量。當流量/TPS超出基礎規格範圍時，我們將允許一定比例的超限使用，即彈性流量，超出部分獨立計費，避免流量突增場景對業務的影響，使用者也無需為臨時性的流量突增而擴大叢集規格，減少資源的浪費。
透過這種模式，幫助使用者更合理地使用服務資源，最佳化成本；儲存部分支援按需使用，即根據實際使用的儲存空間進行計費，不再需要進行儲存的擴縮容；增值服務部分主要包含基本的訊息收發之外的一些增量能力，如可觀測日誌功能、超出規格範圍的topic數、資料同步等。
智慧可觀測
在這種分層儲存的架構下，我們需要考慮每一層的穩定性，並提供相應的可觀測和恢復能力。例如，我們會實時監控物件儲存層的訪問狀態，當物件儲存層出現訪問異常時，能夠快速感知，並自動調整塊儲存資源，避免IO受阻。
另外，傳統的運維方式對運維人員的經驗有較強的依賴，當線上業務執行產生異常時，往往需要運維人員後臺排查，效率較低。目前，業界已有一些自動診斷的實踐，這些診斷主要是對一些觀測結果和異常項的彙總，如CPU使用率過高等，對於一些相對複雜的異常場景，如頻繁rebalance導致消費延遲等，無法直接得出產生異常的原因和指導性的建議。
針對這些問題，我們基於長期以來積累的運維經驗和可觀測手段，實現了一鍵智慧診斷的能力，在基礎觀測指標的基礎上，做更深入的自動化業務分析，給使用者呈現導致異常的原因和最佳化建議。
03 雲上Serverless訊息流實踐標準探索
如今，Serverless化已經成為訊息流平臺發展的新趨勢，而如何更好地基於Serverless化的訊息流平臺進行應用設計和開發，則成為了一個值得思考的問題。
在雲平臺具備高可靠、高可用等能力基礎之上，本文結合華為雲訊息流平臺在Serverless化演進中的實踐，總結提煉出了Serverless訊息流的三大目標和五大特徵，並和信通院共同努力推動標準落地，幫助使用者更好地理解Serverless化訊息流平臺架構原則並能更高效地進行應用開發，發揮Serverless化帶來的巨大優勢，如下表所示。
目標一：業務聚焦（Business Focus）
Serverless化的訊息流平臺，應為使用者遮蔽底層基礎設施，讓使用者聚焦於業務本身，具備以下特徵：
基礎設施無感知（Infra-less）：使用者在使用其提供的服務時，無需直接感知叢集底層的資源型別，也無需感知叢集的構成，如叢集節點數等，使用者只需關注其本身的業務訴求，如所需使用的頻寬、對時延的要求等，大大降低了其使用的複雜度。同時，在運維過程中，使用者也無需感知底層資源的負載，如叢集節點的CPU、記憶體使用率等，更聚焦於業務本身。
目標二：成本最佳化（Cost Optimization）
Serverless化的訊息流平臺，會透過更具彈性的架構和技術手段，在提供同等服務能力的情況下，提升資源利用率，最佳化成本，具備以下特徵：
按需使用（On-Demand）：通常，業務負載會隨著時間而波動，有的業務會有明顯的波峰和波谷，如果按峰值負載預留叢集規格，則會導致資源的浪費。
在Serverless化模式下，訊息流平臺支援按使用者實際使用的資源服務進行收費，主要包括計算服務費用、儲存服務費用和附加能力費用：計算服務透過業務吞吐衡量，體現在流量和TPS；儲存服務透過儲存容量衡量，體現在統計時間點的實際儲存容量；附加能力費用包括一些高階特性，如訊息軌跡、智慧分析等。在負載低峰時，相應的費用也會降低，幫助使用者最佳化成本。華為雲訊息流平臺在Serverless模式設計中，也依據使用者對資源的實際使用來計費。
自動彈性伸縮（Auto Scaling）：隨著業務負載的波動，底層資源也需要相應地進行擴縮容，以最合適的資源規模滿足業務負載訴求。Serverless化的訊息流平臺，在面對負載變化時，能夠根據負載情況，自動進行彈性伸縮，及時調整底層資源，並進行業務流量的負載均衡，整個過程對使用者無感。
目標三：運維簡化（Maintenance Simplification）
Serverless化的訊息流平臺在為使用者提供訊息流能力的同時，也將大大降低其運維複雜性，讓運維變得更簡單、快捷，具備以下特徵：
可觀測（Observability）：Serverless化的訊息流平臺為使用者遮蔽了底層資源，不再提供直接的資源指標，如CPU、記憶體等，而是為使用者提供更為豐富的業務級可觀測能力，如細粒度監控、訊息軌跡、關鍵事件通知等，幫助使用者快速、實時地掌握業務的負載情況，發現業務效能瓶頸和潛在風險，及時調整業務。
智慧診斷（Intelligent Diagnosis）：在業務遇到異常時，能夠結合各類觀測指標，自動對異常現象進行分析診斷，給出可能的原因和修復的建議，降低使用者運維的複雜度和運維投入，並提升異常發現和恢復的速度，同時，能夠對當前的業務使用情況進行分析，並給出最佳化建議。
04 未來展望
軟硬結合垂直最佳化
華為雲自主創新共享儲存池，透過軟硬體結合最佳化，使用智慧硬體裝置和最佳化儲存演算法，提升儲存利用率，透過最佳化資料存取方式，提升資料讀寫的效能，並保障故障時資料持久度不降級。
華為雲訊息流平臺將基於共享儲存池，構建高效能、高可靠的統一儲存層，應用層無需感知多級儲存概念，專注於業務邏輯，減少資料在多級儲存之間轉移帶來的頻寬開銷，進一步最佳化成本。
同時，結合華為雲底層硬體加速能力，將部分計算邏輯解除安裝到硬體中執行，降低CPU/IO開銷，避免因大量CPU計算導致資源爭搶、執行緒阻塞等問題，有效降低時延，實現十倍效能提升。
儲存計算輕量化
將狀態從計算層完全抽離，消除副本概念，透過統一的接入層，在所有計算節點上負載均衡，擴縮容無需遷移分片。同時基於華為雲Serverless底座，將計算節點輕量化，實現計算節點秒級擴縮。同時，支援儲存計算“可分可合”的靈活架構，支援小型化場景部署。
智慧化
在業務波動等場景，根據業務實時負載，自動感知，自動彈性擴縮，做到計算能力的按需使用。藉助快速發展的AI能力，自動分析歷史業務變化趨勢，自動調整資源分配，做到精細化的資源控制。
在保障業務穩定的同時，也能進一步最佳化成本。同時，透過AI自動分析叢集異常和不恰當的使用方式，實現自動運維、無人運維，能夠“自動駕駛”的訊息流平臺。
點選關注，第一時間瞭解華為雲新鮮技術~