狄更斯說：“這是最好的時代，也是最壞的時代。”這句話用來形容 2020 年再貼切不過。
國產 5G、雲計算、大數據、人工智能、區塊鏈技術迅速騰飛，與此同時，它們也將作為新的基礎設施支撐中國數字經濟發展新的動能。新基建時代到來的時刻，我國計算生態卻並不十分樂觀，傳統的計算基礎設施所需的成本投入卻居高不下，芯片產品的競爭力也還不能完全適配市場需求，國際巨頭常年盤踞讓隨其伴生的軟硬體生態同樣難以撼動，中國科技的繁榮景象之下其實暗藏殺機。
在尖端技術趕超而底層支撐不足的情況下，要打破現有生態路徑和生態體系，為國產技術持續高速發展護航，我們就要重塑屬於自己的強算力生態，要打造能夠支持國產化的作業系統、虛擬化軟體，要能能造出中國樁，製出中國芯，建設出完善的新型算力基礎設施。
這件事情，華為一直在做。多年來華為致力突破傳統的老的計算框架和計算平台，打造一個全新的全棧計算框架，在對計算生態而言最為關鍵的軟體上，華為也在不斷通過作業系統開源、數據庫開源、數據虛擬化引擎的開源，來支撐軟體夥伴打造商業化的解決方案。
硬體開放、軟體開源、使能夥伴是華為構建鯤鵬生態始終堅持的信條。從開放鯤鵬處理器到開源 openEuler 作業系統，華為堅持從“芯”到“魂”全面出擊。在 DevRun 開發者沙龍——鯤鵬開發者嘉年華上，華為現場為開發者分享了“鯤鵬遷移”和“openEuler”的相關技術原理、實踐經驗和對應方法論，蓄力新生態下算力提升。
鯤鵬軟體遷移
為什麽要進行軟體遷移
計算機是由軟體和硬體組成的，要執行軟體層的應用程序，就需要底層 CPU 支持由匯編器形成二進製的機器碼（由指令和數據組成）去運行。因此就需要底層計算平台能夠支持該 CPU 的指令，對於不同的處理器而言，它們能夠支撐的指令也大不相同，這也是在 x86 和鯤鵬編譯的區別之處。
通過上圖左側中的代碼示例，我們可以看到，在 x86 和鯤鵬上編譯之後的指令有三點差異，首先是匯編不同，x86 上使用了兩條 mov 指令，鯤鵬上則是通過兩條 ldr 指令、一條 add 指令以及一條 str 指令完成了整個過程；其次是指令長度不同，x86 上 mov 指令是 24 位的，ldr 指令是 16 位的，在鯤鵬上則都是 32 位；第三則是寄存器不同，x86 和鯤鵬處理器使用的向量寄存器不同，其向量指令級也存在差異。
正是因為在 x86 上面和鯤鵬上面使用的指令存在的這些差異，使得在 x86 上面運行的程序、二進製、動態庫這時候需要在鯤鵬上面重新編譯去運行，也就是需要軟體遷移的原因。
軟體遷移五步驟
通過大量項目和經驗總結，要實現軟體遷移需要以下五個步驟：
1. 遷移準備 -- 收集軟體棧信息，準備遷移環境
在這個階段，主要收集硬體和軟體信息。硬體方面的信息主要是收集芯片和伺服器的型號，從而方便提供配置性能差不多的鯤鵬伺服器；其次是收集軟體棧信息，主要分為作業系統、虛擬機、中間件、編譯器、上層依賴的開源軟體、商業軟體、業務軟體等信息。
2. 遷移分析 -- 分析軟體棧，指定遷移策略
遷移分析要做的，就是對收集到的信息和軟體棧做初步分析，判斷是否真正需要遷移，評估遷移的工作量。
對開源軟體來說，直接下載在 ARM 上已經被編譯好的包，或者自行下載原碼進行編譯就可以了。自研軟體的遷移則需要注意語言類型的差異，編譯型語言需要重新編譯之後才能運行在新環境上，不過對於解釋型的語言來說只要更換所依賴的虛擬機就可以。對於商用軟體，可以通過聯繫廠商獲取它對應 ARM 架構下的軟體版本，如果沒有的話就需要尋找有類似功能的軟體做替換。此外像運行環境、虛擬機、編譯器和作業系統這些也是要進行替換，可以直接去華為雲鯤鵬論壇內有軟體倉庫下載由鯤鵬官方所做的經過驗證的版本。
3. 編譯遷移 -- 軟體編譯打包，驗證基本功能
在這一階段，涉及到代碼遷移和套裝軟體遷移兩種場景。對代碼的遷移，不同語言要做不同的修改，像 C/C++ 這種編譯性語言需要重新進行編譯，因為涉及到指令級，跟指令級相關性比較大，所以在編譯腳本、代碼都需要做出修改，但是對純解釋性語言開發的應用來說，它們的程序代碼是不需要修改的。
對於套裝軟體遷移來說，首先需要掃描該套裝軟體是否存在依賴庫或者依賴的可執行程序，這些庫和可執行程序如果是用 C 語言寫的是需要重新編譯的，編譯之後重新把套裝軟體打包即可。
4. 性能調優 -- 利用五步法優化軟體性能
在遷移完成之後需要對性能進行調優，有【建立基準 - 壓力測試 - 確定瓶頸 - 實施優化 - 確認效果】五個步驟。
建立調優基準，該基準根據當前的硬體配置、組網、測試模型來做綜合評估，以建立合理的條有目標；其次在調優目標建立後，通過壓測工具對軟體或系統進行加壓，在加壓過程中暴露性能瓶頸，確定瓶頸之後對瓶頸進行優化；第四，注意在優化過程中要及時記錄，因為優化並不一定是正向的，出現負向優化時需要及時回退；最後在優化措施實施完成後，需要重新啟動壓力測試工具以確認優化效果。
5. 測試與認證 -- 保證商用上線，共建鯤鵬生態
在性能調優環節結束後，需要做一些壓力測試、長穩測試，使軟體能夠達到商用的目標，最後實現規模上線。此外也可以拿軟體和系統到鯤鵬上做鯤鵬展翅認證，其可以擴展應用的軟體使用空間並能夠加入鯤鵬生態。
代碼遷移
C/C++ 代碼遷移
C、C++、GO 都是非常典型的編譯型語言，編譯型語言所開發的程序從 x86 平台移植到鯤鵬平台時一般都需要重新編譯才能運行。編譯構建腳本類文件在遷移過程中，一般會涉及到編譯選項的移植，源碼類文件會涉及到編譯宏，另外可能還會有編譯器自帶的 Builtin 函數的移植、SSE intrinsic 函數移植等。
在 C/C++ 代碼編譯構建過程有六大步驟，首先是獲取源碼，可以通過 GitHub 等開源社區來獲取；其次需要選擇所需的編譯環境，就是安裝編譯器 gcc 等；之後根據源碼的編譯腳本生成 Makefile 文件，再用 Makefile 編譯生成可持續文件。如果這部分代碼之中有依賴 x86 平台的 SO 庫，那麽這部分的依賴庫是需要重新編譯替換的。在編譯完成之後進行安裝部署，之後進入到實際的系統之中進行測試。
Java/Python 代碼遷移
對於 Java、Python 這樣解釋性語言寫的程序，它們涉及到的遷移與編譯型語言大有不同。
從上圖中可以看到 Java 的技術架構和源碼運行過程。對 Java 而言，在實現遷移的過程中，涉及修改的部分首先就是 JDK，因為 JDK 有一些 C 的代碼，而且在 JDK 層屏蔽了很多跟指令級相關的內容，所以需要對 JDK 層進行替換；第二個修改點就是 SO 庫，SO 庫可能是由解釋性語言編譯的，它們跟指令集的關係十分密切，需要重新編譯才能運行；除此之外，還需注意在程序運行中的錯誤，這類問題或許並非遷移造成，但因為關乎運行性能也需多加注意。
Python 的運行過程和 Java 類似，在編譯修改上也是類似的，也是需要從編譯環境和 SO 庫兩大方面入手修改。環境上推薦使用 A32，Python3 你也可以通過樣本安裝，也可以通過源碼安裝；SO 庫有多種類型，但對於各種方式的 SO 庫，最後都是對應為一個 SO，定義為 SO 庫，需要的步驟也都是一致的，即裝配環境、重新編譯、重新替換。
Maven 倉軟體構建
對熟悉 Java 的開發者而言 Maven 已經不陌生了，我們需要用 Maven 去管理 Java 項目。Java 程序依賴著它的 jar 包，而把 jar 包重新下載編譯是十分耗時的，Maven 的作用就是把所有的開源軟體編輯成一個 jar 包放在 Maven 倉庫上面，需要時直接在 Maven 上調用，，這也叫作.jar 的依賴管理。
jar 依賴的分類有分本地倉庫、遠程倉庫和中央倉庫。在構建 jar 包的過程中，首先需要查詢本地倉庫，本地倉庫如果找不到就去遠程倉找，第三步需要編譯實現，並且驗證該版本在鯤鵬上是否可用，如果不可用，則需要重新編譯這個包，然後替換到本地的倉庫，再重新構建，編譯出可使用的版本。
但這個過程還是很繁瑣的，使用鯤鵬 Maven 倉則能大大簡化這一過程。鯤鵬 Maven 倉實質就是一個遠程倉，裡有各種各樣適用於鯤鵬平台的 jar 包，開發效率得到顯著提升。也就是說，基於上面的構建過程，在本地倉沒有找到合適的 jar 包時，就到鯤鵬的遠程倉找，下載出來就是在鯤鵬平台可以使用的 jar 包，無需重複校驗、編譯，就可以得到一個鯤鵬上可以用的版本包。
套裝軟體遷移
rpm 就是把應用程序進行打包，在應用程序裡面不可避免存在一些二進製或者 SO 庫，它們和 C、指令集都密切相關，因此套裝軟體部分也做一些程序編譯和替換，實現重新打包可以分為四個步驟。
首先下載 x86 套裝軟體，利用 Dependency Advisor 工具進行掃描。然後再鯤鵬上重新編譯 x86 依賴文件，為了減少勞動，在這一步驟，首先優先從鯤鵬 Maven 倉上查找文件，如果鯤鵬 Maven 倉中未找到，則在鯤鵬上重新編譯依賴文件。第三步時在鯤鵬上小紅心生成 rpm 包，首先得到 rpm 包對應的 spec 文件，然後解壓 x86 rpm, 再把包替換成 x86 依賴文件，最後打包生成新的 rpm 包。最後一個步驟是驗證，需要重新掃描，確認是否還有 x86 依賴文件，如果存在，則繼續編譯打包，直到沒有 x86 依賴文件存在。
openEuler
在計算多樣性的時代，鯤鵬有機組合為業界提供了最強算力的伺服器處理器和 AI 處理器，以滿足全棧全場景的不同需求，但從計算產業生態的層面來講，穩定和強大的作業系統是一切的前提。去年年底，華為作業系統 openEuler 正式開源，我們的計算世界因此真正地變得既有相似，更有不同起來。
A-Tune
一個系統想要達到性能最優，從底層的芯片到深層的應用涉及到各個方面都需要做調節，特別是像 openEuler 這樣基於宏內核的作業系統，在軟體設計的時候更要考慮各方面的場景，保證在大部分的場景下都是通用且有益的。而隨著數字化技術的不斷升級，新應用、新計算、新架構的出現，調優對象、業務場景數量隨之暴增，業務複雜度也直線上升，傳統系統調優越來越難以滿足當前需求。A-Tune 的出現，就是為了降低調優門檻，提升調優效率。
A-Tune 的目標
A-Tune 自優化的終極目標，是要通過自身充分發揮鯤鵬的硬體和 openEuler 基礎軟體性能，釋放鯤鵬芯片的算力，降低優化成本。在實現上，A-Tune 就是要通過感知上層的業務場景，自動完成調優配置。針對不同的場景，A-Tune 需要找到不同的需求，根據相應需求實現自動調優。
A-Tune 的技術實現
A-Tune 自動調優具備兩大關鍵能力。第一是在運行時自調優，這一能力使用了系統畫像技術，基於離線訓練好的業務模型，對數據進行采集，再通過聚類、分類相結合的方法，精準識別上層業務，匹配最佳資源模型；第二是面向專業工程師的離線自調優，這需要工程師給一個參數集，並且給業務評價指標，通過反饋式的不斷地迭代，再傳遞到貝葉斯優化算法，最終反饋給工程師最優的參數。
在運行時自調優過程中，用戶下發命令後，A-Tune 的服務端將采集數據進行負載識別，對上層業務或應用的類型進行識別感知，並在為其匹配合適的資源模型，然後將配置進行下發。這一過程非常迅速，在一分鐘之內就可以完成，大大減輕了人工調優的負擔。
對於離線自調優，當客戶端發送請求信息到服務端之後，服務端將構建一個由形象性能的參陣列成的參數集，再把這一參數集傳給貝葉斯優化算法，貝葉斯優化算法會返回新的參數，通過不斷地循環迭代，得到最優的參數，隨後服務端就會把最優的參數返回給用戶。
iSulad
從 2019 年開始，容器迎來了浪潮，大多數的企業開始全面擁抱容器化，容器的規模、密度更加擴大，它的問題和麻煩也隨之出現，重新打造一個容器引擎成為一種必然的選擇。面對新的挑戰，鯤鵬也造出來一個新輪子 --iSulad。
為什麽要造新輪子？
市面上容器用得很好，為什麽我們要重新造一個輪子？這要從三方面說起。首先，隨著微服務架構的出現，要求容器啟動速度越來越快；第二，節點變得越來越擁擠，當前業務量在激增，而資源結構卻沒有變化，節點變得越來越擁擠；第三，IoT、邊緣計算的興起也給容器帶來了新挑戰，運營商和電信領域給邊緣計算制定了的新規範，而邊緣計算一般情況會選擇容器作為部署，新的挑戰隨之而來。輕量化的容器引擎 iSulad 就此應運而生，在複雜的挑戰之下，為多種場景提供最靈活最穩定最安全的底層支撐。
iSulad 輕量級容器實現原理
容器化的實現可以總結成六大原理。第一，它由 C/C++ 語言編寫，可以獲得更輕的資源消耗。第二，它提供 CRI 接口，為兼容性的實現提供了保障。第三，它支持 OCI 鏡像，支持平滑替換 Docker，開發者無需擔心用了這個引擎之後重新準備鏡像的問題。第四，它支持包括安全容器在內的各種各樣的容器形態。第五，它提供更便捷使用的命令行，能夠兼容了大部分的 Docker 命令。第六，它提供插件化架構，可根據用戶需要開發定製化插件。
iSulad 的特點
輕、快、易、靈是 iSulad 的特點。
“輕”是因為 iSulad 是用 C/C++ 編寫的，而且能夠改變鏡像的組織格式，可在輕量化運行時減少調用鏈路。這種輕量化運行效果十分顯著，和 Docker 比較，100 個容器穩態的時候 iSulad 下降了 68% 左右。
iSulad 的“快”，體現在容器啟動、鏡像構建和鏡像下載三方面，用函數調用替代 Docker 容器傳統的調用鏈路縮短了調用時間，隔離鏡像的元數據實現了高速並發，支持鏡像按需下載提高了鏡像拉取速度。
至於“易”，是指實現遷移非常便捷容易。iSulad 將提供一個遷移轉化工具，在從 Docker 遷移的過程中，不需要再對本地所有的存儲結構做完整的配置就可實現遷移。
最後是“靈”，iSulad 有注重資源佔用的 light 模式和注重性能的 performance 模式兩種模式供以選擇，支持開發者針對不同場景進行靈活配置。
寫在最後
技術進步需要優良的產業生態為其護航，在摩爾定律陷入失效紛爭的今天，傳統計算生態的土地想要以既往姿態為 AI、雲計算、大數據等領域蓄力，無疑需要一塊滋養算力的沃土。從處理器到作業系統，鯤鵬持續發力，而隨著新基建時代到來，鯤鵬打造的算力生態，必將成為未來計算共同體的最強基座。
香港九龍灣馬來街興發大廈15樓D室