雲原生熱度持續攀升，這一趨勢也延伸了到中介軟體領域。藉助雲原生技術，中介軟體正在解決了自身的彈性、韌性、運維、交付等問題。同時，開發者使用中介軟體方式也越來越雲原生化。
那麼，在雲原生時代，中介軟體應該如何完成自己的技術 “進化” 呢？5 月 30 日，網易數帆雲原生首席架構師馮常健做客《極客有約》，與我們一起探討了這一話題。以下內容根據直播內容整理，並做了不改變原意的刪減，完整內容[[可點選檢視回放視訊]](https://www.infoq.cn/video/Zq...)
6 月 22 日 19:00-20:30，數字化基礎軟體自主創新分享周・中介軟體技術論壇，3 位專家解讀雲原生中介軟體高穩定、高效能、高可用實踐，歡迎關注：多元共生 連線新機 - 2022 網易數帆數字化基礎軟體自主創新分享周
中介軟體為什麼要雲化
Q：馮老師 12 年加入網易，已經有十多年的研發經驗。您是什麼時候開始關注雲原生的？
A：我大概做了十多年的開發和架構設計工作，比較幸運的是，我正好完整地趕上了雲原生從萌芽、發展，再到目前逐漸成熟，在生產環境裡可以大規模創新落地的整個過程。在 2014 年的時候，Kubernetes1.0 版本還沒有出來，我們就基於 Docker、Kubernetes 開發容器雲平臺。目前，我在公司裡面也一直在做雲原生相關的微服務、容器化、服務網格、中介軟體以及 DevOps 等雲原生工程大規模落地實踐方面的事情。
Q：您覺得，雲原生從最開始到現在發生了哪些重大進展？
A：最直觀的感受還是雲原生對研發運維過程產生了很大的影響。5、6 年前，DevOps 還沒有太多比較具體的落地路徑，更多還是在強調 DevOps 開發運維一體化的理念。隨著雲原生各項技術的發展，大家慢慢發現 DevOps 理念倡導的敏捷、靈活和快速，都可以通過雲原生技術落地。可以說，雲原生技術真正重塑了企業開發和運維的整個過程。
Q：那中介軟體雲化的必要性體現在哪裡？
A：首先，雲的根本特徵就是具備資源彈性，可以應對突發性的流量波動，而彈性的背後就是資源的池化，即把所有的計算、網路、儲存等做成一個資源池，我們可以充分地排程，來提升資源利用率。
第二方面，我覺得自動化運維方面是繞不過去的。在傳統領域，如果不做雲化和平臺化，按照我們的工程經驗，通過指令碼或半自動化方式可以搞定三五十個叢集。但當數量達到網際網路業務常見的三五百個叢集規模後，傳統指令碼或半自動化方式是很難掌控這麼多例項穩定執行的。雲化的必要性在於，它可以很好地解決自動化運維的問題。
第三方面，標準化也是雲化必要性的一個體現。假如不考慮雲原生化，我們實際上會面臨特別多的版本，特別是中介軟體領域，同一個中介軟體的選型會有很多版本，另外還有很多不同的部署架構，自動化各方面能力也難以統一。
而云化就意味著相對標準化，有助於技術棧的統一。我們可以把整個技術棧聚焦到少數幾個選型上，還可以進一步做企業級的技術規範化，大家約定使用某個版本後會便於後續的維護和統一升級。
還有一點，雲化意味著中介軟體服務供給方式的變化。規模化組織裡，微服務架構除了應用外，還需要快取、訊息佇列等中介軟體。這樣的中介軟體要做微服務，首先要申請流程，如果運維團隊和業務團隊不是一個成本中心，還需要提前做容量規劃、採購計劃等等。這個過程涉及了多方大量的流程性互動。
雲化的中介軟體平臺提供了一個技術中臺，或者說是一個門戶，可以自主申請，經過一些必要的審批之後，各業務部門自己可以按需採用，大大縮短了流程，使整個資源管控效率更高。
Q：什麼樣的中介軟體可以稱之為雲原生的中介軟體？
A：我認為執行在 K8s 上面，用 K8s 原生的方式設計架構的中介軟體服務，就是雲原生的中介軟體。
Q：雲原生中介軟體和本地 PaaS 中介軟體之間是否有本質上的不同？
A：差異來源是雲原生中介軟體基於 K8s。中介軟體的很多基礎能力都下沉到了 K8s，大量常規的高頻運維操作都被抽象成 K8s 上面一個個資源的定義，運維人員經常碰到的擴縮容、遷移、重建、故障恢復等高頻動作都可以通過 kubectl 或其他對應的白屏化操作統一操作，極大降低了運維門檻和工作量，這是標準化帶來的一個好處。
另外，因為有 Kubernetes 這一層抽象，雲原生中介軟體天然可以做跨雲或者跨異構基礎設施的部署互動，所以使用者體驗可以在整個過程中保持完全一致。也就是說，在雲端計算時代，我們可以選擇不同的國內外主流雲廠商，把中介軟體服務完全跑在雲上，而且可以隨時遷移。這些理論上就是基於 Kubernetes 這一層的解耦。
中介軟體的雲化路徑
Q：雲原生中介軟體的技術棧主要涵蓋了哪些？又如何通過對企業發展起到降本增效的作用？
A：我們整個技術棧主要基於 K8s 以及 K8s 上面的框架，比如 Operator 等。
對於怎麼降本增效，其實就是效率和成本的問題。效率上，更多是在流程和自動化兩個方面提升。我們可以做很多自動化、故障根因分析、故障治癒，甚至可以做提前故障感知、穩定性巡檢等事情。
成本也是雲端計算一直以來的問題。雲端計算一直在提降本增效，但多年實踐下來發現，用了雲端計算以後成本反而處於不可控的狀況。我認為，企業還是要更精細化去管控、合理地使用資源。
Q：你們內部會對雲原生的中介軟體進行分類嗎？
A：會有，主要還是按狀態去分，即有狀態和無狀態。我們說負責負載均衡的，如 Nginx、API 閘道器，屬於無狀態的中介軟體，像訊息快取這種就是弱狀態的中介軟體。
Q：對於有狀態的中介軟體，比如 Kafka，它們的雲原生路徑是什麼的？其中的難點又是什麼？
A：雲原生中介軟體是構建在 K8s 下面的定義，中介軟體包括本身的執行時、像 Redis 這樣的引擎，以及配套的管控系統。我覺得它們雲化的主要路徑主要包括通用的技術框架和一些差異化的管控流程這兩個方面。
目前，K8s 上管理有狀態的主流方案就 Operator 框架及其託管平臺 OLM，負責管控中介軟體叢集的生命週期，這個過程中也會涉及到 K8s 上像 CPU 記憶體、磁碟網路這樣的資源管理排程。此外，中介軟體統一訪問路口的問題也非常重要。這需要結合企業裡複雜的網路架構，涉及叢集內外的訪問，需要考慮很多細節。
接下來，我們還要做相對高階一點的能力，比如自動化的彈性擴縮容、例項遷移、一些動態的配置下發等，來實現更高層次的高可用等特性，最後還會涉及到配套相關的可觀測性方面的內容。
生命週期管理、排程、訪問方式，以及可觀測性這些都是通用的，即 Kafka、Redis 等其他各種中介軟體都繞不開的這些設計。
此外，還有一些差異化的管控流程。“差異化” 意味著需要在通用的基礎框架上來實現不同的資源依賴管理。比如各種中介軟體，有些是磁碟密集型的，有些是記憶體密集型，有些是網路密集型，那麼不同中介軟體對不同的資源就有不同的要求，也就需要不同的技術方案。
另外，中介軟體高可用的方案也是五花八門的，即它們的叢集拓撲管理方式不一樣，比如 Kafka 依賴 ZK 的管理叢集，相對比較容易自動化，而 Redis 需要在整個叢集啟動之後再進行角色分配的，相對來說管控面就會重一些。
整體來說，還是通過一些通用的技術框架和差異化管理去實現各個品類中介軟體的雲化。
運維之難
Q：輕舟有專門的運維穩定性管控產品，為什麼會做專門運維產品？運維難點體現在哪些方面？
A：雲原生中介軟體的優勢在於重塑了技術供給方式，但如果穩定性問題不解決，就無法體現出這個優勢。中介軟體運維需要消耗很大的精力。影響穩定性的因素非常多，我舉幾個例子後大家可能會非常能理解。
比如典型的資源水位問題，我們很難去做容量規劃。資源水位的風險大概有兩類，一類是實時流量帶來的頻寬風險，像 CPU、磁碟 IOPS、網路卡頻寬等；還有一種是逐步增長和堆積的容量型風險，主要體現在磁碟空間和記憶體水位，影響容量相關的風險很多，比如應用的業務流量、中介軟體內在的支撐機制等。
中介軟體都是多副本的叢集，一個掛了後往往會有自身重建的過程，但重建過程會給剩餘的一些存活節點帶來負載壓力，這個時候它們很不可控，有時甚至會放大。現在一個節點掛了後要先恢復，這個節點恢復過程中會從存活的節點拉資料，這就會對資源水位造成影響，進而引發其他問題。其他比如像均衡性、熱點資源，硬體故障、配置引數異常等都會引起穩定性問題。
我們剛才說網易數帆專門的穩定性管控產品是我們運維團隊十多年經驗的沉澱，為使用者提供監控告警、穩定性容量、日常排障等方面的服務。另外，我們也試著建立一種穩定性的改進迴圈。思路就是發現問題、分析整改，然後再把沉澱的經驗加到規則引擎裡來，避免下次發生同樣的問題，如此迴圈下去，逐步將企業的運維經驗沉澱到平臺裡。中介軟體的穩定性管理需要非常資深的人和經驗，我們希望這個平臺可以把這部分經驗固化下來。
Q：看到朋友問，一人多崗的小公司如何做運維？
A：我覺得這樣的企業反而更有必要去做雲原生的轉型。因為現在各種各樣的中介軟體都有各自的應用場景和擅長解決問題的領域。所以運維人員每天都要學習業務側提交的對中介軟體的需求。
Redis、Kafka 都是很常見的中介軟體，還有一些比如圖資料庫或者時序資料庫，有時候也會被歸到中介軟體的領域裡來。對沒有多少運維人員的小公司或者是 “一人多搞” 這樣的公司來說，運維反而很容易失控，結果就是不再提供這些中介軟體，出現技術選型受限問題。
那麼，有這麼一套中介軟體平臺有什麼好處？我們前面講到的雲化必要性或者說雲原生中介軟體的根本特徵，其中一條就是足夠的標準化。所有運維人員的必要技能是理解 K8s、理解宣告式 API、理解 CRD 對資源定義，這樣無論是 Kafka 還是 Redis，運維人員的學習路徑、技術理解等方面都是一致的。比如，Kafka 和 Redis 的擴容操作都可以宣告為一個同樣的 CR，這樣哪怕有十個中介軟體，他們都可以用幾乎同樣的運維方式去應對。
這就是雲原生很大的一個優勢，它可以解耦，將很多技術細節沉澱到 Operator 裡。對運維人員來說，工作介面就是一個 K8s 的命令列，有助於解放他們的生產力。
中介軟體雲化的技術選型
Q：輕舟具體什麼時候開始做雲原生中介軟體的？
A：我們做雲化中介軟體比較早。整個網易網際網路業務從 2012 年就開始做私有云，當時是基於 OpenStack 提供雲主機、網路、硬碟，同時基於 OpenStack 的虛擬化環境提供基於虛擬機器的 PaaS 中介軟體。所以，我認為真正做雲化中介軟體是從 2012 年就開始了，我們大概用了一兩年的時間把網易 95% 的網際網路業務遷移到了雲平臺上，並使用我們的雲主機和一些雲化的中介軟體。
14、15 年左右，網易進入了雲原生階段。我們開始嘗試做無狀態應用的容器化，讓集團的一些無狀態業務跑在 K8s 上面，還做服務網格。到了 19 年左右，企業該容器化的基本都完成了容器化，大量的核心業務都在服務網格平臺上執行。
從 18 年下半年開始，我們開始真正意義上基於 Operator 做雲原生的中介軟體。經過三年多時間，逐步建立了一些深度的產品能力，我們從早期專注中介軟體生命週期管理，即建立、刪除、擴縮容等能力，慢慢發展到現在更多地去考慮做多機房、多叢集的高可用，以及國產化異構軟硬體平臺的適配等。
去年年初，我們逐步做剛才提到的穩定性巡檢產品化，另外也開始做 “兩地三中心” 以及多活能力的建設。現在我們已經經過了生命週期管理階段，慢慢做更加深度的能力。
Q：我們現在是全部的業務都上雲嗎？
A：我們網際網路業務基本上都是雲化，無狀態應用全部容器化，有狀態的目前在慢慢遷移。像訊息佇列、快取這樣的可能會快一些，資料庫類的相對來說會慢一些。
Q：前邊您提到了很多次 Operator 框架，為什麼當時會選擇這個框架？企業如何去做技術選型？
A：K8s 上的應用交付有兩種方式，一種是基於 Helm，另一種就是基於 Operator。
Helm 更多適合一些無狀態應用，它依賴 K8s 原生資源控制器去保證各項 K8s 資源的自愈、擴縮容能力，但管控能力比較弱，不能保證 K8s 原生資源之間的關聯性。比如我們在做中介軟體的時候，涉及到某個 Pod 下面的一些狀態變化互相之間是有依賴的，就是說某個 Pod 會依賴另外一個 Pod 的結果，我需要把這個資訊注入到對應的 Kubernetes 裡去，這其中有一些複雜的業務邏輯，這是 Helm 控制器搞不定的。
另外就是基於 Operator 使用者可自定義資源的管理方式。如果我們現在把 Kubernetes 理解成硬體上面的一個分散式作業系統，Operator 就是在這個作業系統上面開發雲原生應用的一套框架，它比較適合做中介軟體應用，或者說有狀態應用。
中介軟體有兩個核心特徵，一是狀態，這個狀態表現為儲存、網路 IP 等；還有就是中介軟體叢集之間各個副本都是有關係的，比如 Redis 兩個副本之間有主從關係，這樣就不能把他們兩個同等對待。Operator 是一種封裝了一些特定領域的運維知識經驗的抽象，可以自定義做很多事情，選擇用 Operator+CRD 的方式管理中介軟體是非常匹配的。
Q：隨著業務規模不斷擴大，雲原生的中介軟體如何保證自身的高效能和高穩定？
A：這個也是很多企業把有狀態應用容器化時的一個顧慮，效能和穩定性是中介軟體最看重的。可以說下我們在這方面的具體思路和解決辦法。
在效能方面，首先會涉及到負載均衡，可以把更多分散式處理能力利用起來，需要一些負載均衡元件、代理元件。還有就是考慮彈性的快速擴容，可以是一種水平擴充套件或提升整個叢集效能容量的方式。另外，如果對 IO 或磁碟要求特別高的話，可以考慮用更加高效能的本地盤方式。當然最重要的，可以對中介軟體在雲原生場景下面做一些引數級的調優。這些都是我們提升效能的一些方案。
穩定性方面也有很多方式。一種是利用穩定性巡檢平臺，可以更合理地使用整個平臺的資源，確保資源水位保持健康的狀態。另外，我們採用了一些像 Operator 這樣的自動化開發框架，使中介軟體可以有治癒能力，並配和一些可觀測性方式和混沌工程。如果我們把這些故障都能有效地解決，那大家對這個系統就會比較放心。
Q：整個雲原生框架是越來越複雜的，大家現在都越來越關注可觀測性。目前業內在可觀測性方面發展得如何？
A：可觀測性也是大家先有各自的標準，一些主流廠商主導，慢慢再在基層社群形成共識，進而產生新的業界標準。
現在，很多五花八門的應用在可觀測性方向的指標、鏈路、日誌都遵循社群標準。比如，鏈路方面有 OpenTelemetry 這樣的社群標準，目前整個社群向好。大量開源的雲原生軟體都會號稱至少遵循這樣的社群關係標準。這樣大家不用太考慮相容性和互操作性方面的問題。目前來說，已經發展到這個階段了。
Q：網易數帆在可觀測行上做了哪些探索？
A：我們自己也做了一個一體化監控的可觀測性產品。微服務的場景需要以應用為中心，我們需要把散落在各個元件裡應用的各種指標和資訊收集起來，在一個螢幕上有邏輯地顯示出來。
所以，我們通過一些語言資料系統，把監控系統和各子產品，比如說服務框架、服務網格、涉及流量入口的一些 API 閘道器，以及中介軟體的日誌、鏈路等資料全部會聚在這個立體化監控平臺上，然後將資料打通。
資料統一採集是第一步，下面還有很多想象空間，比如可以做進一步的根因分析。以前的根因分析可能僅在某個緯度，比如東西流量呼叫、南北流量呼叫，或者某個中介軟體。現在，根因定位過程能夠串聯起整個過程。比如訪問慢了可以直接定位到容器層或者更往下的網路記憶體等。
另外，我們在一些小的領域，比如日誌領域，也做了很多事情。我們以前也用了 Fluentd 等開源的日誌採集工具，但在一些大規模的網際網路場景下，效能還是不夠，像日誌丟了很難查出來這個日誌到底有沒有采集上來、丟沒丟。由於痛點一樣，所以我們跟中國工商銀行聯合共建，釋出了開源日誌採集軟體 Loggie。
落地實踐
Q：網易目前落地了哪些中介軟體的雲化？
A：在我們集團的網際網路業務中，Redis、Kafka、RocketMQ、ES、ZK 這些已經落地，MySQL 這塊也在推進落地。上面幾個相對比較成熟，新業務也大都會使用雲原生。
Q：之前看到介紹說，網易雲音樂在引入了輕舟中介軟體的 Redis 後，成本節約了 30% 以上。具體都做了哪些工作來達到這個效果？
A：首先我們在 2012 年後做了一個基於 KVM 虛擬化的 PaaS 中介軟體服務，到後面應用容器化後，相比虛擬化開銷天然就有 10% 以上的成本節省。
其次，我們研發了一個在 K8s 上的管控系統，主要負責離線上業務混部。比如在水位較低的時候，把音樂典型的轉碼等離線計算服務排程到 Redis 上。通過系統混部能夠把資源利用率提高到 60% 以上，而一般情況下可能是百分之一二十，甚至更少。當然還有其他的混部嘗試，比如將 Redis 和其他中介軟體混部等。
第三方面就是資源超售，這也是雲平臺基本都會做的事情，就是對 K8s 進行資源超售，比如合理設計 requests 與 limit 的超售比等，儘量把測試環境裡資料例項密度提上來。我們線上和線下的整個應用規模大概 1：1 左右，我們對線下做了更加極端些的操作。
Q：雲原生的中介軟體更適合在哪些場景下應用？
A：其實，雲原生中介軟體就是對傳統中介軟體的替代。比如快取類中介軟體就是資料快取、需要快速訪問的場景，訊息佇列類中介軟體就是用於解耦、削峰填穀場景，API 閘道器就是用在流量均衡的場景。在場景方面，沒有說雲原生特別適合、傳統中介軟體不適合的，只不過本地化 PaaS 或者傳統中介軟體，已經不適應現在微服務架構的一些要求了，這些就可能需要雲原生中介軟體去提供。
比如金融行業都需要做多活架構，服務框架具備這樣的功能了，但中介軟體資料庫無法支援，這就沒辦法繼續推進整個架構發展，逼著你一定要用雲原生化的中介軟體去支撐它的雲化架構。
Q：整個落地過程中會面對哪些困難或者挑戰？
A：從業界來看，要麼自研，要麼外部採購，或者兩個結合。網易主要還是自主開發為主。自研肯定基於開源的技術框架等，但沒有開源社群會真正為穩定性兜底，也很少有專業的支援，可能都是靠大家價值觀或技術熱情驅動，一般企業的個性化需求不見得能響應。總的來說，還是場景化程度比較低，企業級管控能力比較弱。這些都是基於開源做自主開發可能會碰到的，企業要點對點地解決這些高可用、穩定性和大規模應用等問題。
外採是一個很快捷的路徑，但這塊的困難主要是採購方沒有形成對中介軟體完整的掌控能力，畢竟是外面買來的，缺乏掌控的技術能力。這種時候，培訓是很重要的，需要確保能夠對這個產品日常使用。
歸根到底，還是需要人了。自研也好，或者外採也好，就都需要懂雲原生、懂 K8s 的技術人才，去構建整個生態。
Q：需要開發人員去理解業務嗎？
A：中介軟體的開發是需要的，理解業務後才能更好的設計，因為你的東西設計出來是給別人用的，甚至給業務人員使用的。
但是這裡可以從兩方面理解。一方面是要理解企業的 IT 流程，比如瞭解各種各樣技術平臺各自的定位、不同平臺之間的職能到底是什麼、邊界在哪裡、平臺間是怎麼協同的。
另一方面就是了解一些業務場景下的最佳實踐。為支撐大規模應用需要沉澱一些最佳實踐，這時就需要中介軟體開發人員理解業務的使用方式。比如 API 閘道器的業務流量模型是什麼樣的、流量趨勢是隨機的還是固定的，Kafka 或 Redis 對資料分片、效能、擴充套件性和高可用的要求，都會涉及到固有架構和它依賴資源的選型，我們只有瞭解了它的業務型別，才能做出合理的評估。比如在做異地多活或者單元化架構的時候，對於一些不重要的業務，就沒必要做複雜的架構，同城架構就可以。我覺得這些都需要理解業的，很難說有一種很通用的協議可以在所有場景使用。
Q：汪源老師曾在分享中表示，同樣一箇中介軟體，基於 K8s 研發程式碼量減少了 50% 到 80%。這是如何做到的？
A：我覺得這可能是我們最早基於 Operator 或者容器化去做中介軟體帶來的最直觀的一個收益。
當時，我們基於 KVM 虛擬機器的 PaaS 中介軟體也好幾個團隊，剛才列舉了大概六七個這樣的中介軟體是六七個團隊去做的，所有人都要去理解中介軟體的整個管控過程，尤其是高可用、容災方面的。整個管控過程是缺少這種抽象的、程式碼也很難複用，使得研發效率比較低，一箇中介軟體 PaaS 服務從開始的立項、開發、測試到上線，大概需要兩三個月，這還是比較快的，還不包括企業級的能力，如計費計量、許可權控制、資源池等。
我們用了 Operator 框架以後，程式碼量減少可能是最終結果，那我們過程中做了哪些事情？前面講過，Operator 可以分為通用部署和差異化部署，通用部分體現在設計規範上，包括設計原則、最佳實踐、CRD 響應設計。
那時候，我們大量轉型到用 Golang 作為開發語言，就是用的 Operator SDK 作為開發框架，遵循宣告式 API 設計規範。所以我們從設計規範、開發規範、部署規範、運維規範、測試規範等研發過程中的各種規範，以及線上穩定性管理、對中介軟體的高可用要求等方面，去制訂標準和約束，最終結果就是有 50% 以上程式碼量的減少。
做雲原生中介軟體不一定是為了減少程式碼量，但這確實是個副產品。我們當時做第一代 PaaS 中介軟體大概是五六萬行程式碼，容器化以後大概只有兩萬行左右。其他也類似，Kafka 原先大概是五萬行，後來是兩萬多行。
未來發展
Q：雲原生中介軟體未來還有哪些想象力？
A：現在大家對中介軟體的定義都有自己的理解，但我認為一些有狀態應用都是可以雲原生化的，包括現在看比較過時的一些中介軟體。
舉個例子，我們集團在使用一個早期的快取中介軟體 Memcached，可能在很多業務看來它是一個已經快要被淘汰的中介軟體，但是在我們的某個業務裡面它還被一些應用大量使用，因為它在一些特定場景中還有很多應用。我們基於 Operator 的 SDK 框架快速實現了對 Memcached 的 Operator，用雲原生化的 Memcached 替代。
我們真正開始基於 K8s 去做這些標準化的能力，包括前面說到的各種各樣規範，開發和實現替代是很快的。如果我們沒有這樣的框架沉澱和技術儲備，這些可能就是歷史負債，下又下不掉，甚至有些可能都沒法替換，還需要有人持續維護。我們把這些看起來快要過時的中介軟體雲原生化，同時花很小的成本就可以統一維護。
這只是舉個例子，我想說的是，很多有狀態的中介軟體都可以通過雲原生化的方式來提升運維效率。
當然對應的還有一個成本的優勢。現在公有云 IaaS 在資源層面的競爭已經非常激烈，有各種同質化的應用，毛利非常低。相反，PaaS 中介軟體是有比較大的利潤空間的，它會想盡辦法讓業務用它的 PaaS 服務。如果關注成本，人們會在公有云的 IaaS 上自建中介軟體平臺，這相對來說整個成本就會低很多。由於大家都是基於標準的 K8s 底座，所以這件事情就比較可行。
Q：未來，輕舟在中介軟體雲化方面有哪些規劃？
A：技術方面，我們跟進了雲原生，我們的多叢集、多活等都還在持續建設中。雖然我們有很多技術層面的積累，但還需要在產品層面進一步做場景化驗證。整個業界都一樣，都在持續進化。
另外，對於大家現在提的比較多的中介軟體的網格化，雖然目前還沒有特別實際的生產場景需求，但它描繪的願景確是非常美好：進一步提升開發效率和運維效率，我們也會持續關注。
此外，我們希望可以實現更多支撐微服務架構中介軟體的雲原生化。對於開源開放的技術棧，我們希望能夠實現對核心中介軟體的國產化替代，除了網易自己的網際網路場景外，希望能在金融、製造、能源等各個行業做技術輸出。
6 月 22 日 19:00-20:30，數字化基礎軟體自主創新分享周・中介軟體技術論壇，3 位專家解讀雲原生中介軟體高穩定、高效能、高可用實踐，歡迎關注：多元共生 連線新機-2022網易數帆數字化基礎軟體自主創新分享周
本文轉載自 InfoQ：雲原生時代，中介軟體應該如何“進化”？