1、概述
隨著IT技術的不斷演進,公有云、專屬云、混合云、云原生等相關技術概念層出不窮,云計算已經有了廣泛應用,成為數字經濟、政企數字化轉型的新型基礎設施。 在云計算時代,由于功耗低、高性能以及指令集的優勢,越來越多的云廠商開始選擇基于ARM體系來構建云服務。從AWS發布的Graviton2,到Apple的M1芯片,到中國電子云十年磨一劍的“PK架構”,再到華為鯤鵬體系,ARM體系成為了未來的趨勢方向。 對于企業數字化轉型來說,應用上云是必經之路。從狹義來說,上云是將運行在物理機上的應用系統搬遷到云上。從廣義上看,上云會涉及到跨架構適配、虛擬化、容器化、云原生等一系列的技術升級和重構。 上云的不同階段,所依賴的技術并不同。從左至右,應用對云的依存度也越來越高。
下文對幾個階段涉及到的技術做簡單闡述。
階段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平臺編譯器編譯后,得到匯編代碼如下:
備注:以上mov、push等均為X86體系架構匯編指令。 在ARM平臺編譯后,得到匯編代碼如下:
備注:以上mov,STR,LDR均為ARM架構匯編指令。 匯編指令的簡單對比如下:
僅從常用指令集名稱來看,兩者比較相似,但實際大相徑庭。
舉例說明,在ARM指令中,MOV與ADD之間需要通過STR和LDR兩條指令完成數據從內存往寄存器的加載,其原因是ARM算術指令只能運行在寄存器,而X86則無此限制。
其他差異本文不再一一分析。
由此可以看出,X86和ARM架構的指令集差異很大,對于C++語言來說,編譯器幫我們搞定這些差異,但需要從源代碼重新編譯。
b) Step 2 匯編
匯編是將匯編代碼轉變成機器代碼的過程。以上匯編代碼在X86平臺下,得到的機器代碼如下:
備注:以上為局部截圖。 而在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機器上編譯,得到如下字節碼:
經比較,會發現兩者得到的字節碼基本一致。
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架構遷移只是一小步,對于應用來說,如何借助云計算實現更好的可部署性、可伸縮性、便捷運維以及高并發帶來的性能挑戰,值得不斷的探索。
審核編輯:湯梓紅
-
ARM
+關注
關注
134文章
9097瀏覽量
367560 -
cpu
+關注
關注
68文章
10863瀏覽量
211765 -
云計算
+關注
關注
39文章
7806瀏覽量
137402 -
X86
+關注
關注
5文章
294瀏覽量
43467
原文標題:從X86到ARM,跨越CPU架構鴻溝
文章出處:【微信號:架構師技術聯盟,微信公眾號:架構師技術聯盟】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論