您現在的位置是:首頁 > 垂釣

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

  • 由 CESTC 發表于 垂釣
  • 2022-09-25
簡介3.1 藍信對中國電子雲的適配過程藍信原生是構建在X86體系架構下的,針對中國電子雲底層採用PKS架構,需要做整個系統的適配,主要工作體現以下幾點:1. 針對體系架構改變的適配程式碼級重新編譯以適配ARM架構,由於目前流行的開發語言早已對A

x86是怎麼跑arm的機器的

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

1

概述

隨著IT技術的不斷演進,公有云、專屬雲、混合雲、雲原生等相關技術概念層出不窮,雲計算已經有了廣泛應用,成為數字經濟、政企數字化轉型的新型基礎設施。

在雲計算時代,由於

功耗低、高效能以及指令集的優勢,越來越多的雲廠商開始選擇基於ARM體系來構建雲服務。從AWS釋出的Graviton 2,到Apple的M1晶片,到中國電子雲十年磨一劍的“PK架構”,再到華為鯤鵬體系,ARM體系成為了未來的趨勢方向。

對於企業數字化轉型來說,應用上雲是必經之路。

從狹義來說,上雲是將執行在物理機上的應用系統搬遷到雲上。從廣義上看,上雲會涉及到

跨架構適配、虛擬化、容器化、雲原生

等一系列的技術升級和重構。

上雲的不同階段,所依賴的技術並不同。

從左至右,應用對雲的依存度也越來越高。

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

下文對幾個階段涉及到的技術做簡單闡述。

階段1:跨架構適配

傳統應用大部分是基於X86架構來開發和執行。面對ARM架構越來越流行的今天,越來越多的雲計算廠商開始圍繞ARM架構構建雲應用生態。並據此引發了大量的適配測試需求。X86和ARM體系架構的差異對於應用有哪些影響?X86應用向ARM體系遷移會碰到哪些技術難題?對於不同程式語言實現的應用來說,遷移的難度是否有區別?

本文將針對以上問題開展分析。

階段2:虛擬化

計算虛擬化能力是雲計算提供的核心能力。截至到今天,很多行業使用者的上雲還是停留在這個階段。虛擬化的最大用途是使得應用與物理機器解耦,

將資源池化,按需分配資源,並因此獲得彈性伸縮和遷移能力。

這個階段的上雲,往往會涉及到P2V和V2V這兩種主要場景。前者是從物理機向虛擬機器遷移(

Physical to Virtual Migration)

,後者是虛擬化的跨雲遷移(

Virtual Machine to Virtual Machine

)。

階段3:容器化

容器化是將應用程式及其所需的庫、框架和配置檔案打包在一起的過程,以便可以在各種計算環境中高效執行它。得益於Docker等技術的流行,應用容器化更進一步促進了應用的配置、依賴以及映象的標準化,使得應用交付、運維等領域有極大的提升。這個階段的上雲,對於軟體開發過程有一定的要求,需遵循相應的容器化規範。

階段4:雲原生

雲原生時代的到來,是容器化後的必然階段。透過Kubernetes、Devops、微服務等技術的不斷髮展,尤其是對有狀態應用支撐能力的不斷增強,雲原生已然成為新一代應用開發的事實標準。

技術的發展有天才工程師的靈光一現,其背後同樣也需要遵循客觀自然規律。下文從階段1入手,嘗試從底層技術進行解構,或許能幫助我們更清晰的看到本質。

2

跨越CPU架構

縱觀計算機技術的發展史,

軟體系統

是一個不斷抽象,不斷疊加的過程。作業系統的出現,解決的是單機硬體多樣性的難題,為上層應用軟體提供一致的底層執行環境。雲計算的出現,解決的是分散式架構引入的多樣性問題,為應用提供跨機器、跨地域的一致執行環境。

我們先從CPU指令集的差異對比開始。

2.1 CPU指令集對比

在計算機體系結構的發展過程中,誕生了CISC(複雜指令集)和RISC(精簡指令集)這兩大流派,它們採用了不同的設計理念和方法,CISC採用單條複雜指令完成特定複雜功能,提高了儲存器訪問效率;

RISC則採用多條精簡短指令完成特定複雜功能,提高了處理器執行速度。基於這兩類指令集,產生了兩種主流的CPU架構:X86架構,採用的是CISC複雜指令集,而ARM架構則採用了RISC精簡指令集。

CISC指令集指令系統龐大,指令數目、指令格式和定址方式複雜,指令字長不固定,各種指令執行週期和訪問頻率相差很大,採用微指令碼控制單元的設計。

RISC指令集選取使用頻率最高的精簡指令,避免複雜指令,將指令數目、指令格式和定址方式種類減少,指令長度固定,大多數的指令都可以在一個機器週期裡完成。以控制邏輯為主,不用或者少用微指令碼控制。

2.2 對應用遷移的影響

應用本質上是一種程式,程式在執行態是由一系列程序組成,而程序可以說是計算機科學最重要和最成功的概念之一。

程序的執行依賴作業系統對CPU、記憶體的排程和管理,作業系統保持跟蹤程序執行所需的所有狀態資訊。比如暫存器、PC計數器、邏輯單元ALU等。

綜合來說,X86 和ARM屬於不同的架構。

X86屬於複雜指令集,而ARM屬於精簡指令集, X86 上的程式根本不可能毫無阻礙地就可以在ARM上使用,必須經過適配遷移。

從另外的角度來看,應用選擇不同的程式語言,會有不同的跨架構能力。

下面分析下主流的C++和Java應用在不同架構下的差異表現。

2.3.1 C/C++語言

眾所周知,C/C++程式是計算機系統級別最為成功的語言之一。

業界存在大量的知名開源軟體基於C/C++構建,比如Windows/Linux作業系統自身,以及使用廣泛的分散式儲存系統Ceph。

在C/C++世界裡,從原始碼演變成執行中的程序,需要經歷

編譯、彙編、連結、執行

等一系列過程。

a)

Step 1 編譯

編譯

是將原始碼經過處理,轉變成組合語言的過程。這一過程的關鍵工具是編譯器。有了編譯器的存在,現代程式語言(如C++)的原始碼一般能做到架構無關,透過不同平臺編譯器(如GCC)的處理,可以得到不同體系結構下的彙編程式碼。

舉例如下原始碼:

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

在X86平臺編譯器編譯後,得到彙編程式碼如下:

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

備註:以上mov、push等均為X86體系架構彙編指令。

在ARM平臺編譯後,得到彙編程式碼如下:

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

備註:以上mov,STR,LDR均為ARM架構彙編指令。

彙編指令的簡單對比如下:

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

僅從常用指令集名稱來看,兩者比較相似,但實際大相徑庭。

舉例說明,在ARM指令中,MOV與ADD之間需要透過STR和LDR兩條指令完成資料從記憶體往暫存器的載入,其原因是ARM算術指令只能執行在暫存器,而X86則無此限制。

其他差異本文不再一一分析。

由此可以看出,X86和ARM架構的指令集差異很大,對於C++語言來說,編譯器幫我們搞定這些差異,但需要從原始碼重新編譯。

b)

Step 2 彙編

彙編

是將彙編程式碼轉變成機器程式碼的過程。

以上彙編程式碼在X86平臺下,得到的機器程式碼如下:

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

備註:以上為區域性截圖。

而在ARM平臺下,得到的機器程式碼會完全不同。

c)

Step 3 連結

連結在C++語言特有的處理機制,將OS裡的連結庫與程式進行連結的過程。這一過程的輸出物即為可執行程式。最終的執行,對於C++和Java來說,通常都有Main函式作為程式的執行入口(某些框架會對其進行封裝,如Java Spring框架)。

綜合以上,對於C/C++開發的應用程式來說,向ARM架構遷移需要完成重新完成編譯、彙編、連結的全過程,應用跨架構遷移的難度較大。

2.3.2 Java語言

Java語言在Web應用開發佔據絕對的主導地位。Java是基於虛擬機器的語言,也是所謂提供跨平臺執行能力的語言。Java應用從原始碼到執行,需經歷編譯、執行兩個環節。

a)

Step 1 編譯

使用javac命令進行編譯,通常得到java位元組碼檔案,以。Class字尾命名的檔案。

以下面的程式碼為例。

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

X86環境編譯得到的位元組碼如下:

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

備註:以上為區域性截圖。

ARM機器上編譯,得到如下位元組碼:

上雲實踐|從X86到ARM,跨越CPU架構鴻溝

經比較,會發現兩者得到的位元組碼基本一致。

b)

Step 2 執行

Java體系為X86和ARM分別提供了不同的JVM。在執行時,JVM透過類載入器執行以上位元組碼檔案。

備註:實際執行時,JVM會將位元組碼轉換成機器碼來執行,這個過程暫且忽略不表。

綜合來看,對於Java應用來說,X86和ARM架構的差異完全由JVM層遮蔽,應用跨架構遷移的難度很小。

上文主要從CPU架構差異、程式語言差異的角度來分析對應用的影響。

下面結合中國電子雲的實際上雲案例來做進一步的闡述。

3

藍信上雲實踐

藍信是中國電子雲上執行的重量級應用之一,作為中國電子雲“一雲一端”的戰略組成部分,提供安全可靠的企業訊息通訊、影片會議和協同辦公能力,在政企市場有著廣泛的應用場景。

3.1 藍信對中國電子雲的適配過程

藍信原生是構建在X86體系架構下的,針對中國電子雲底層採用PKS架構,需要做整個系統的適配,主要工作體現以下幾點:

1. 針對體系架構改變的適配

程式碼級重新編譯以適配ARM架構,由於目前流行的開發語言早已對ARM體系進行過適配(例如,golang,java,c/c++, python等)這部分工作難度不大。

2. 資料庫的適配

資料庫部分,藍信需要從MySQL遷移到達夢資料庫,由於達夢資料庫對MySQL語句的良好支援,只有部分語法存在相容性問題,僅需在資料層進行適配,業務層並不需要改動,整體適配可在一個月內完成,其中主要成本集中在適配後的全量功能測試上。

3. 基礎設施及中介軟體的適配

藍信依賴的基礎設施及中介軟體也需要適配,例如etcd,k8s,redis,kafka,mongoDB等,這部分工作由於大部分基礎元件已經有了ARM版本,直接使用即可,極個別的元件,需要進行原始碼級的編譯。

4

總結和思考

在當前數字產業大發展的背景下,對ARM架構的關注必然會不斷升溫,各行業會出現大量應用從X86向AMR架構遷移,也催生了大量的應用跨架構適配測試需求。

透過前文的分析,我們可以得出如下結論:

1、X86架構和ARM架構的確存在較大差異。兩者在指令集、暫存器等方面均有很大的不同,但對於應用系統的移植來說,並非是不可逾越的鴻溝;

2、應用開發採用的不同程式語言,會導致跨架構移植難度絕然不同。C/C++等系統級語言所編寫的應用程式,其移植需要經過重新編譯、連結、執行等全過程,難度相對較大;而以Java為代表的虛擬機器語言則具備良好的跨平臺移植性;而對於Python、JavaScript等指令碼型語言來說,移植難度會更小。從這個角度來看,在雲計算環境下開發應用程式,建議優先選擇跨架構友好的程式語言。

3、在大型應用系統遷移實踐中,需要深入分析系統架構,有針對性的設計遷移方案。

完成跨CPU架構遷移只是一小步,對於應用來說,如何藉助雲計算實現更好的可部署性、可伸縮性、便捷運維以及高併發帶來的效能挑戰,值得不斷的探索。

Top