融雲國產化適配排坑指南

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

（融雲國產化適配範圍）

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

國產資料庫下命名衝突怎麼辦？

中介軟體編譯失敗怎麼辦？

客戶端截圖功能法正常使怎麼辦？

······

完整版影片請移步【融雲 RongCloud】回覆“超連結實驗室”觀看~助您尋找答案~

沒時間看影片？

沒關係，小編為您整理了本期乾貨集錦

後臺回覆【超連結實驗室】可領取 PPT。

01

服務端國產化適配

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

持 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 相近即可。

02

客戶端國產化適配

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

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

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

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

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

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

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

◆ 截圖模組採用靜態編譯

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

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

03

國產化部署交付

幾乎所有的應用業務系統都會使用和依賴些中介軟體或者工具，例如：訊息佇列中介軟體、快取中介軟體、程序管理工具等。在部署交付之前，常常都會預先把所有的部署資源提前準備好，包括：服務自身的編譯包、中介軟體等，因為現場臨時編譯顯然不是明智之舉，做不到快速部署，也無法保證整個過程的可控。

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

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

◆ 不同作業系統 glibc 版本不致導致中介軟體編譯失敗

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

◆ 不同作業系統 Path 環境變數不同

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

◆ 不同作業系統 rpm 包存在差異

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