超链接实验室，是融云策划推出的 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 源获取。