全場景創新，這些厲害的 openEuler 技術創新，你值得擁有

在剛剛結束的 openEuler Summit 2022 上，華為伺服器 OS 首席架構師、openEuler 社區技術委員會委員熊偉為廣大開發者介紹了 openEuler 在過去 3 年的成就和成果。而其中最值得關注的是，openEuler 在雲、伺服器、邊緣計算、嵌入式等四大場景下的八個技術方向的創新。

用熊偉博士的話來說，「在過去的三年里，openEuler 深入行業和產業，用八個技術方向的縱深創新，引領全場景的產業領先」。接下來，作為一個一直關注開源操作系統的技術人，我分享一下我的理解。

可編程內核：系統調度的極限追求

首先介紹一下可編程內核。

我們知道，內核是一個操作系統的核心。對於我們所熟悉的 PC 和伺服器，由於對資源的消耗和性能的需求沒有那麼的敏感，無需毫釐必爭，所以往往不太需要在內核層面做刪減，正常使用即可。刪減內核功能的成本可能遠高於增加內存的成本。

但對於資源消耗和成本更加敏感的邊緣計算、嵌入式設備來說，每一絲的資源佔有，都是難以估量的成本。對於資源集群量級極大的雲計算場景而言，每 0.1% 的性能優化，對於整個集群而言，都是十分可觀的收益。一個可編程的內核相比於模塊化的內核，為生產環境下的優化提供了更多的可能性 —— 工程師可以根據業務的實際變化，隨時調整內核的實現和策略，從而優化系統的性能。

在這種情況下，對於內核進行組裝，支持可編程能力，就變得極其重要。openEuler 創新性地借鑒了社區當中 eBPF 的思想，並在此基礎之上，將內核的機制和框架進行了分離，將框架內置到內核，實現的功能和策略則可以在開發完成後，注入到內核中即可實現對內核二次編程的效果。

說起來簡單，但在具體落實層面，openEuler 做了不少的工作來達成這個目標：

openEuler 在系統內核層面，提供了編寫用戶態策略的基礎庫函數和可配置的調度策略模板，可以幫助用戶快速理解內核的編程方式。支持用戶快速編排和擴展，降低用戶對內核實現調整時的成本，降低上手的門檻。在具體的管理機制方面，則提供了對任務 / 進程 / 組 / 用戶等對象的自定義拓展標籤，從而承載了用戶態與內核態、內核態組件之間協同調度的語義，實現了整個內核的統一調度，確保力往一處使。此外，openEuler 還在內核層面提供了豐富的鉤子點位和輔助函數，從而支持對 CFS 調度類的選核、選任務、搶佔流程的自定義策略注入。

對於普通的開發人員來說，也可以基於 openEuler 提供的可編程框架，來實現針對不同的應用場景來開發自定義策略，動態載入到內核執行，提升內核的執行效率，為整個業務系統降本增效。

除了內核級別的資源調度，在 openEuler 操作系統中，還實現了兩種不同層面的混合部署：在線/離線業務混部和軟硬實時混部。從這個角度看，openEuler 志在實現更多更大場景的統一管理和運籌。我們先來看一下在線/離線業務混部：

在線/離線業務混部：資源利用率和系統性能的極限平衡追求

對於任何規模化的業務來說，必然會存在波峰和波谷。如何平衡不同業務之間分配的資源從而實現資源的最大化利用，是一個極為重要的課題。

在 openEuler 當中，你可以使用可編程的內核來完成內核級別的資源調度；而在更上一層，openEuler 提供了完整的在線/離線業務混部能力。openEuler 為開發者提供了三層不同的層次的資源調度能力。

在內核層，基於內核優先順序隔離調度技術，對於 CPU、內存、IO/NET 等資源維度實現干擾隔離，從根源上優化資源調度和隔離的能力。在用戶態，為用戶提供了基於 Rubik 的動態配置和拓撲編排能力，同時配合新一代 QoS 感知資源調度器 Skylark 所提供的資源調度能力，從而實現為不同的 QoS 要求的混部業務提供合適的資源調度。

Rubik 為開發者提供了基於應用畫像的應用調度機制，來實現自動的資源調度能力。通過自動注入技術，來實現業務的自動畫像和自動分析，得出不同業務負載對於資源的敏感度和壓力度。再基於畫像和標記，對各節點的資源進行調度（如 CPU、內存帶寬、緩存帶寬、磁碟帶寬、網路帶寬等）和數據收集，並基於歷史數據二次調度資源，均衡各不同業務對於資源的平均利用水平。

在應用調度之上，Rubik 還會基於業務指標進行一定程度上的節點資源超賣。通過對業務資源維度的採樣，預測可壓縮資源的使用情況，從而實現基於預測情況的超賣。在為在線業務準確預留所需資源，保障其 QoS 的同時，將未使用資源儘可能多地分配給離線業務，最大化離線業務的吞吐率，提升節點的資源利用率。

通過引入 Rubik 在離線混部解決方案，在保證業務 SLA 不下降的情況下，資源利用率從業界平均的 15% 提升到 35%。

除了在線/離線業務混部之外，openEuler 還支持軟硬體層面的實時混部：

軟硬實時混部：多層次確定性時延需求滿足

在 openEuler 當中，集成了一個新的硬實時內核 uniProton，幫助開發者磨平底層的硬體平台的差異，提供一套標準統一的操作系統平台。uniProton 支持任務管理、事件管理、隊列管理、硬中斷管理等管理方式，兼容 POSIX 標準介面的開發，降低了開發者的開發成本。

而對於開發者而言，更重要的是 uniProton 是鴻蒙系統和 openEuler 共同支持的內核。開發者可以開發一套應用，同時運行在 openEuler 計算設備和鴻蒙設備上，降低了開發者的開發成本。

對於需要硬實時方案的開發者來說，配合 uniProton 和 openEuler 的系統鏡像裁剪能力，可以實現 KB 級的系統鏡像，調度時延 < 3us；而可以接受軟實時方案的開發者則可以選擇基於內核自旋鎖和信號量優先順序繼承機制，配合周期性、Workqueue 延時、負載均衡等任務驅逐機制，實現 20us 中斷響應。

通過軟硬實時方案的混部能力，openEuler 實現了 CPU 、內存等全域資源的隔離分區，滿足了數控機床、傳統工業場景下對於多層次確定性時延的需求，幫助 openEuler 開發者可以進行傳統工業場景的開發。

openEuler 除了和鴻蒙系統共建 uniProton，還提供了一個更有價值的特性 —— 多晶元架構的支持。

異構互聯：泛架構算力存儲統一調度

openEuler 全版本支持 x86、ARM、申威、龍芯、RISC-V 等五大架構，並支持英特爾、AMD、兆芯等多款 CPU 晶元，支持多個硬體廠商發布的多款整機型號、板卡型號，對於開發者來說，可以輕鬆完成多個不同型號的設備之間的互聯和統一調度。

配合分散式軟匯流排，可以實現鴻蒙設備和 openEuler 系統設備之間的即插即用、高效傳輸。開發者可以無需關注設備的發現機制，藉助分散式軟匯流排提供的通信機制，快速完成設備的發現、組網、連接和傳輸能力。開發者可以通過使用分散式軟匯流排提供的 API 實現設備間的高速通信，無需關心通信細節，進而實現業務平台的高效部署與運行能力。

SysMaster： 安全可靠機制可靠的服務管理系統

除了上面介紹的各種內核、硬體方面的技術突破以外，openEuler 還在開發者最熟悉的初始化系統上做了一些探索和改進。

我們過去熟悉的初始化系統（比如 sysVinit、systemd、upstart），大多是使用 C 寫的，且往往因為設計複雜，功能大一統等有違 UNIX 傳統思維的做法而廣受詬病。openEuler 社區為社區提供了一個全新的、採用 Rust 編寫的初始化系統 —— SysMaster。

和 systemd 相比，由於 SysMaster 採用 Rust 語言編寫，原生地規避了內存泄漏問題，開發者無需擔心內存泄漏導致的 1 號進程掛掉。而從零構建的 SysMaster，也摒棄了之前的初始化系統中存在問題，為開發者提供了新一代的初始化系統。

相比於過去的初始化系統，SysMaster 提供了全新的架構設計，分為 SysMaster Core 和 SysMaster Extend 兩類。SysMaster Core 提供了極度輕量的調度方式，佔用更少的資源，以及更快的啟動速度。拆分的架構則可以支持拓展多種服務類型，實現 1+1+N 的架構，滿足初始化系統的多樣化訴求。而它的生態兼容工具，則可以讓開發者可以自由選擇 systemd 和 SysMaster，無需擔心被生態綁定。

總結

openEuler 的技術創新覆蓋的場景相當地豐富和深入，以至於我無法在一篇文章中逐一分析和披露所有細分場景和技術創新點。在撰寫這篇文章時，給我的最大感受是「他們居然實現了！」

對於一個產業的研發人員來說，毫無疑問，openEuler 的這些技術創新，將幫助產業和行業的開發者節省大量的時間，用更短的時間完成應用的建設，將精力投放在產業和業務當中，產生價值。

從過去的「要打造根社區」，到如今的「成為根社區，並從根出發，進入縱深領域創新」，openEuler 給我了太多的驚喜。假以時日，我相信，openEuler 還給我帶來更多的震撼。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive