超連結實驗室，是融雲策劃推出的 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 源獲取。