作者簡介：知乎大V OwlLite，中科院自動化所 模式識別與智能系統(tǒng)學(xué)博士，現(xiàn)任圖像算法工程師。

1.架構(gòu)變遷

說到CPU架構(gòu)，我們可能必然會提到CISC(復(fù)雜指令集，比如桌面端采用的X86系列)和RISC(精簡指令集，比如移動端廣泛采用的ARM系列)。理論上，RISC 相比于 CISC(Intel 和 AMD) 處理器，指令譯碼和流水線的實現(xiàn)精簡化，可以在芯片上使用更少的三極管，換取更多的寄存器和流水線性能 ( 多線程 / 并發(fā)能力，高吞吐 ) 。過去，由于應(yīng)用主要是跑在對功耗不敏感的X86架構(gòu)CPU上，人們對該架構(gòu)下的應(yīng)用進行了大量的優(yōu)化，ARM平臺的性能優(yōu)勢并沒有充分的發(fā)揮出來。最近數(shù)年，轉(zhuǎn)機出現(xiàn)了，ARM平臺在移動端(比如手機)和物聯(lián)網(wǎng)終端(比如家用智能設(shè)備)的大規(guī)模使用，使得對該平臺算法和軟件的性能優(yōu)化變得越來越充分(近年來，開源社區(qū)對ARM平臺的支持已經(jīng)足夠用戶將X86應(yīng)用在合理的投入下遷移到ARM平臺，LLVM等基礎(chǔ)工具大部分可以找到支持ARM平臺的版本)。結(jié)合既有的并發(fā)能力優(yōu)勢，使得ARM 平臺的服務(wù)器在一些應(yīng)用場景下顯得頗有吸引力。另外，對于移動應(yīng)用，在云端采用ARM平臺服務(wù)器，還可以做到端云同構(gòu)，節(jié)省開發(fā)調(diào)試成本。

在這樣的背景下，業(yè)界大廠紛紛推出ARM平臺服務(wù)器CPU. ARM平臺服務(wù)器CPU在云端服務(wù)器啃下一塊市場也是必然。2019年，華為推出了第二代ARM平臺數(shù)據(jù)中心處理器鯤鵬920芯片(預(yù)期今年推出其升級版鯤鵬930)，采用7nm制程，最高支持64個內(nèi)核，工作頻率高達2.6 GHz，支持8通道DDR4，以及一對100G RoCE端口。并且推出就自產(chǎn)自銷上華為云。從配置來看，其設(shè)計特別強調(diào)高吞吐能力，目前性能仍處于ARM平臺服務(wù)器CPU的第一梯隊。

2.為什么需要做服務(wù)遷移

越來越多的服務(wù)轉(zhuǎn)向ARM云平臺是一個趨勢。ARM架構(gòu)芯片核的面積僅為X86核的1/7，這也意味著在單位面積下，ARM可以集成更多的核心——實際數(shù)據(jù)是四倍以上。這意味著ARM架構(gòu)CPU 的眾核架構(gòu)橫向擴展的方式會更符合分布式業(yè)務(wù)的需求。如果是新的應(yīng)用，可以直接選擇鯤鵬云平臺進行開發(fā)，充分利益ARM云平臺的優(yōu)勢。但是當(dāng)前，絕大部分云平臺應(yīng)用都跑在于X86架構(gòu)CPU上，需要將服務(wù)進行某種形式的“重構(gòu)”才能運行在ARM云平臺上。其主要原因在于，用戶在往ARM平臺遷移時需要處理指令集上的差異，才能使得原來運行在x86架構(gòu)下的程序能夠平穩(wěn)運行于ARM平臺，完成遷移。

<指令集差異>

這些指令集的差異，使得像C/C++, Go 等編譯型語言寫的應(yīng)用程序，需要采用ARM64(aarch64)編譯器重新編譯后才能運行。這是因為編譯型語言先要被“翻譯”成匯編，然后轉(zhuǎn)換成二進制指令。而ARM平臺的鯤鵬處理器和X86架構(gòu)的處理器，其匯編和二進制指令不一樣，導(dǎo)致一方的可執(zhí)行程序不能直接移植到另一個平臺運行。像Java, Python 等本身支持跨平臺的解釋型語言，如果原應(yīng)用不依賴C/C++語言編譯的公共組件(大部分情況下)，則可以直接運行在ARM平臺上。對于剩下的極少部分的匯編語言，則需使用ARM指令集改寫一遍。比如在X86架構(gòu)下，128位按位做and運算：

PAND xmm1 , xmm2/m128

對于ARM架構(gòu)處理器，可以替換為NEON指令：

AND Vd., Vn., Vm.

<三類語言的服務(wù)遷移路徑>

以上這些遷移路徑說明，傳統(tǒng)X86架構(gòu)服務(wù)的遷移雖然會帶來潛在的優(yōu)勢，但遷移也是有成本的，需要投入時間對軟件/服務(wù)進行對應(yīng)的更改和測試。

3.鯤鵬社區(qū)助力服務(wù)遷移

ARM平臺的性能優(yōu)勢和特點是幫助其從巨大的云計算市場中吃下一塊的基礎(chǔ)。至于能以多快的速度吃下多大的市場，其決定性因素的可能并不是這些架構(gòu)和制程決定技術(shù)優(yōu)勢，而是用戶的選擇，具體地，也就是用戶的遷移成本相對于可能帶來的優(yōu)勢的比較——如果只需要修改少量的代碼就可以將服務(wù)轉(zhuǎn)換到支持更高并發(fā)的ARM云平臺上，這對于那些對吞吐量尤其敏感的后端服務(wù)來說，何樂而不為呢。

為了降低用戶的遷移成本，華為花費了相當(dāng)?shù)牧α拷ㄔO(shè)了華為云學(xué)院和鯤鵬社區(qū)，指導(dǎo)和幫助用戶進行應(yīng)用遷移方面的工作。并且推出了鯤鵬開發(fā)套件(包括掃描評估工具Dependency Advisor, 遷移工具Porting Advisor, 和性能優(yōu)化工具Tuning Kit https://support.huaweicloud.com/ug-pa-kunpengdevps/kunpengpt_06_0004.html)幫助用戶評估工程的可移植性，檢查用戶軟件 C/C++ 源碼，識別需要修改的部分并提供修改建議和性能調(diào)優(yōu)。而且這些內(nèi)容中的絕大部分對用戶來說是免費獲取的。在注冊華為云之后，用戶可以在華為云端實驗室(https://lab.huaweicloud.com/)免費使用華為云資源(ECS等)進行應(yīng)用往ARM云平臺遷移的實驗。

以相對更耗時更復(fù)雜的C/C++應(yīng)用遷移為例，可選擇云端實驗室中的“通過鯤鵬工具鏈將X86 C/C++代碼遷移到鯤鵬平臺”實驗進行體驗。用戶在該實驗中首先預(yù)置實驗環(huán)境，免費獲取實驗所需的鯤鵬ECS、EIP, VPC, 安全組等資源(可以通過開發(fā)者免費試用區(qū)https://activity.huaweicloud.com/free_test/index.html?#individual 獲取更多更長時間的資源試用)。

然后可以依照提示，在網(wǎng)頁端中通過公網(wǎng)EIP登錄分配的ECS之后，修改教程中提供的C/C++應(yīng)用包的編譯腳本和相關(guān)代碼段，重新編譯即可完成安裝、驗證和測試。

<實驗體驗環(huán)境>

4.服務(wù)遷移實戰(zhàn)

在上文的體驗例子中，可以完整的經(jīng)歷如下典型的C/C++工程遷移過程的關(guān)鍵部分：

包括修改編譯腳本;修改宏定義，增加aarch64 架構(gòu)的宏定義;修改編譯宏分支，確保 aarch64 架構(gòu)下使能 SIMD 的 NEON 特性;修改aarch64 架構(gòu)下的內(nèi)聯(lián)匯編指令;重新編譯源碼并安裝測試。

對于C/C++工程遷移的鯤鵬ARM平臺移植，可能會碰到如下的典型問題：

1.編譯時gcc參數(shù)設(shè)置需要調(diào)整，這方面的問題可以參考gcc官方文檔(https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html)

2.編譯時找不到函數(shù)、缺少庫文件等?？梢酝ㄟ^安裝鯤鵬ARM平臺兼容的依賴庫來解決。目前來看，隨著ARM平臺的發(fā)展，這種情況下的問題解決不了的可能性越來越小。如果你的C/C++工程本身是在Linux平臺編寫/編譯的，那這種情況還會相比于從windows平臺遷移少很多

3.開源項目庫不支持 ARM 架構(gòu)，這種情況較就更少了，一般發(fā)生在較舊的項目代碼。面對這種情況可能不得不尋找替代組建或者修改自己的代碼以消除依賴。

4. 編譯時提示代碼錯誤，比如在上面的體驗例子中如果不修改相關(guān)類型的宏定義就會出現(xiàn)，解決方法于上面體驗例子中類似。

5. 需要重寫內(nèi)聯(lián)匯編語句，如上文所述，這是由于ARM與X86架構(gòu)指令集不同導(dǎo)致的。可能需要使用ARM指令修改每一條相關(guān)代碼才能解決。

至于云端常見但由于Java的跨平臺性，遷移更為容易的Java Web應(yīng)用，可以通過云學(xué)院提供的“基于華為云鯤鵬彈性云服務(wù)器部署Web應(yīng)用”教程體驗，其過程中不涉及對代碼的修改，這類應(yīng)用的遷移相比于C/C++類應(yīng)用要容易得多。

對于將軟件遷移到ARM平臺來說，大部分情況下只要建立軟件開發(fā)編譯環(huán)境-編譯軟件-出現(xiàn)錯誤-修復(fù)bug的流程就可以解決問題，這跟很多人碰到過的將Windows平臺軟件遷移到Linux平臺運行差不多。對于更復(fù)雜的應(yīng)用軟件，比如數(shù)據(jù)庫、翻譯程序，可能需要修改匯編語言。當(dāng)然現(xiàn)在很多數(shù)據(jù)庫采用的是開源軟件的或者本身支持多平臺的軟件，這類問題也變得越來越容易解決。

當(dāng)然，實際的業(yè)務(wù)遷移到鯤鵬ARM云平臺，涉及的程序語言和軟件依賴會相當(dāng)復(fù)雜。比如某大叔據(jù)搜索系統(tǒng)的業(yè)務(wù)軟件棧：

這里的mysql, redis, Apache和Hadoop都可以通過鯤鵬代碼遷移工具找到鯤鵬ARM平臺兼容的版本，其遷移自然不是問題。對于其他暫不兼容的，比如kudu, Impala和Ceph，其官方發(fā)布已經(jīng)提供了完整的或者大部分功能的aarch64平臺支持(https://issues.apache.org/jira/browse/KUDU-3007, https://issues.apache.org/jira/browse/IMPALA-9376), 如果升級到支持aarch64的新版后調(diào)試通過，那移植到aarch64平臺也不會有問題。對于剩下的不兼容的，則需要找替代或者修改代碼了。

從上面的實例可以看出，如果你的業(yè)務(wù)軟件棧大量采用開源軟件并且保持了版本的更新(大家都意識到aarch64平臺變得越來越流行，需求越來越多，順勢推出了該平臺的版本)，那么遷移的成本就會比較低。相反，如果采用了較老的軟件或者不支持aarch64的商業(yè)軟件，那就需要花費比較多的精力，甚至不得不采取繞過依賴的方案。這也就意味著，僅從實際業(yè)務(wù)軟件棧的情況來看，就有部分業(yè)務(wù)并不適合遷移，企業(yè)需要根據(jù)自己的實際情況量力而行。因此，企業(yè)業(yè)務(wù)遷往ARM云平臺雖然是一個趨勢，但X86云平臺在未來相當(dāng)長一段時間并不會消失，而是會繼續(xù)占有相當(dāng)?shù)氖袌觯cARM云平臺并駕齊驅(qū)。

鯤鵬開發(fā)者系列課程傳送門在此，良心知識不付費，參與回帖互動還有獎品拿，吐槽建議都闊以：http://suo.im/5X8M85