超鏈接實驗室，是融云策劃推出的 IT 系列直播課，攜手行業專家，一起聊聊 IT 國產化、協同辦公通信、通信中臺、企業數字化的那些事兒。融云政企公眾號[融云RongCloud]回復“超鏈接實驗室”，獲取入群報名鏈接。

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

(融云國產化適配范圍)

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

國產數據庫下命名沖突怎么辦?

中間件編譯失敗怎么辦?

客戶端截屏功能⽆法正常使⽤怎么辦?

……

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 源獲取。

以上，超鏈接實驗室第一期的分享，已經讓大家感受到了十足干貨、滿分誠意。

第二期課程《60 分鐘搭建一個企業自有“微信”》也將于 4 月 13 日(周三)16:00 如期到來，只聊干貨、不說廢話，歡迎各 SI、ISV、政企行業 IT 人員報名參與，線上暢聊!報名指路：融云公眾號[融云RongCloud]后臺回復“超鏈接實驗室”