融雲國產化適配排坑指南

融雲RongCloud發表於2022-05-04

超連結實驗室,是融雲策劃推出的 IT 系列直播課,攜手行業專家,一起聊聊 IT 國產化、協同辦公通訊、通訊中臺、企業數字化的那些事兒。關注【融雲 RongCloud】,瞭解協同辦公平臺更多幹貨。

融雲支援國產化的初心,可追溯到 2017 年進入政企市場之日起。時至今日,融雲已成為國產化支援最完善、徹底的企業之一。

(融雲國產化適配範圍)

基於豐富的國產化經驗,「超連結實驗室」首期課程《國產化之路 —— 國產化適配的那些坑》於 3 月 30 日正式開播。融雲服務端研發架構師陳祥從服務端國產化適配、客戶端國產化適配、以及國產化部署交付等三個部分為主要切入點,詳細講述了融雲在國產化適配過程中曾遭遇的難題,並提出了一系列經過融雲多次驗證的解決方案,希望正走在“國產化之路”上的夥伴們可以以此為鑑,少走彎路。


服務端國產化適配

◆ 關係型資料庫表名 / 欄位名建議全⼤寫且避免以單個單詞命名

⽀持 SQL 的資料庫⼀般由儲存服務(Service)、儲存引擎(Engine)組成,分析器進⾏ SQL 語句的詞法和語法分析,執⾏器負責與儲存引擎互動,國產關聯式資料庫分析器層⾯均遵循 SQL 規範,但在儲存引擎上各不相同。主流國產關聯式資料庫人大⾦倉、達夢、神舟通用、南大通用雖然都⽀持 SQL ,但並不意味 MySQL 上執⾏沒有問題的 SQL 語句在國產資料庫上執行同樣沒有問題。

融雲建議:關係型資料庫表名 / 欄位名建議全⼤寫,並且避免以單個單詞命名(在極端情況下可以將其列為開發規範明令禁止)。

全⼤寫可以避免因為資料庫大小寫敏感設定所導致的找不到庫 / 表 / 欄位的情況的發生;不以單個單詞命名錶 / 欄位,則基本可以避免關鍵字衝突問題。

◆ 使用 jdk-8u192 作為 Java 執行環境

為了保障高效能,融雲協同辦公產品的所有接入介面服務均使用 Netty(Netty 提供非同步的、事件驅動的網路應用程式框架和工具,用以快速開發高效能、高可靠性的網路伺服器和客戶端程式)。問題是,Netty 依賴的第三方包較多,因此出現不支援 ARM / MIPS 的可能性較大,容易遭遇 HTTPS 處理失敗等問題。

經過多方嘗試,建議:使用 jdk-8u192 作為 Java 執行環境,並在對應架構下重新編譯。

需要補充說明的是,2019 年 1 月起 Oracle 對 JDK8 進⾏收費,8u192 是 2018 年的最後⼀個版本更新,可以繼續免費使用下去。但是從 2019 年 1 月開始,如果還想獲取 JDK 的更新,則需要付費訂閱。

◆效能測試應覆蓋主要國產 CPU 型號


(公眾號後臺回覆【超連結實驗室】獲得講師 PPT)

從國產晶片現狀可以看出,國產化 CPU 以精簡指令集陣營居多,並且,在實際交付中,我們所能夠碰到的國產 CPU 也是以精簡指令集型別居多。例如:ARM 架構的鯤鵬 / ⻜騰系列、MIPS 架構的⻰芯(龍芯後續會主推 LoongArch 架構)等。由於複雜指令集和精簡指令集的設計初衷不同,導致精簡指令集 CPU 在效能上與複雜指令集存在較大差異(相同規格複雜指令集的 CPU 效能高於精簡指令集 CPU)。

融雲建議:在實際的交付部署中,根據不同的效能指標進行部署資源估算。而關於效能測試覆蓋範圍,融雲建議以下幾種:

鯤鵬 920 / 920S、飛騰 2000 / 2000+、龍芯 3B3000 / 4000,搭配的作業系統:統信 V20 及麒麟 V10。x86 架構的海光 CPU ,效能上可以認為與其他同等規格的 x86 CPU 相近即可。

客戶端國產化適配

多數的國產系統都分桌面版和服務版,對於客戶端的國產化適配,我們只針對桌⾯版來看待和解決問題,桌⾯客戶端在國產化適配中,容易遭遇如下問題:

◆ 不同作業系統打包規範不同導致桌⾯客戶端各種⼩問題

主要問題如:解除安裝後圖示未被清理、托盤顯示 2 個圖示、托盤不閃爍等。

融雲建議:先找到國產作業系統廠商諮詢,索要打包規範,然後依據規範再進行打包(這裡需要說明的是,各大廠商非常重視自身生態發展,所以對於諮詢的態度是十分開放的,可以大膽諮詢)。

◆ 不同作業系統 libc 版本不⼀致導致桌面客戶端不能正常使用

融雲協同辦公產品客戶端協議棧使用 C++ 作為開發語言,同時,外掛也基於 C++ 開發,而在客戶端國產化適配過程中,C++ 的協議棧、外掛等因為不同作業系統 libc 版本不⼀致,也容易引發一系列問題。

經過多次嘗試,衷心建議夥伴們:無論是 ARM 還是 MIPS 架構,都在麒麟系統上進行編譯,因為同一架構下麒麟系統的 libc 版本比統信系統低,一般麒麟系統的 libc 版本為 2.2.3 ,統信的則為 2.2.8 。這樣基本可以避免客戶端 C++ 外掛及元件的異常。

◆ 截圖模組採用靜態編譯

在國產化適配客戶端功能測試中,客戶端截圖功能⽆法正常使⽤是最早暴露的問題之⼀ ,與前一問題不同的是,這裡只針對客戶端的外掛範疇,給出另外一種解決方案。起初,融雲截圖相關元件採用的是動態編譯的⽅式,由於該⽅式與作業系統的依賴性較強,經常出現在這個系統下可用、在另外系統下不可⽤的情況。經過探索,最終我們採用在靜態編譯 QT 的基礎上編譯截圖 node ⽂件的方式,成功解決了不同作業系統下客戶端截圖功能無法正常使用的問題。

(公眾號後臺回覆【超連結實驗室】獲得講師 PPT)


國產化部署交付

幾乎所有的應用業務系統都會使用和依賴⼀些中介軟體或者工具,例如:訊息佇列中介軟體、快取中介軟體、程式管理工具等。在部署交付之前,常常都會預先把所有的部署資源提前準備好,包括:服務自身的編譯包、中介軟體等,因為現場臨時編譯顯然不是明智之舉,做不到快速部署,也無法保證整個過程的可控。
圖片
(公眾號後臺回覆【超連結實驗室】獲得講師 PPT)

在部署資源準備方面,國產化適配容易遭遇以下幾個問題:

◆ 不同作業系統 glibc 版本不⼀致導致中介軟體編譯失敗
在版本的選擇上,不可過高也不可過低,如果版本過高,那麼在遇到低版本時,⼀定會出問題;而版本過低,又會出現找不到依賴的情況。因此,為了統⼀編譯,達到泛部署的目的,我們建議找到⼀個合適的版本進行中介軟體的編譯,以適應多數場景。對此融雲針對麒麟、統信做了⼤量的摸索和嘗試,目前已達到預編譯部署資源在多數場景下的正常使用。

◆ 不同作業系統 Path 環境變數不同
很多中介軟體在正常執行時都依賴於系統環境變數的設定,可以通過軟鏈的方式去解決,這樣可以避免對系統 Path 環境變數的修改,畢竟作為國產作業系統的使用者,在理解及評估能力方面遠不及廠商自身,不直接修改作業系統的環境變數,我們就能夠規避因為修改系統的環境變數而引發其他問題的風險。

◆ 不同作業系統 rpm 包存在差異
通常在自動化部署工具的實現上,大家都會用 Python,Python 自身依賴於 Python rpm 包,在不同作業系統下,rpm 包存在差異,就可能會出現問題,需要針對不同作業系統做對應的處理。這裡建議⼤家:優先使⽤作業系統⼚商所提供的 rpm 包,其次是從 OS 的 yum 源獲取。

相關文章