超链接实验室，是融云策划推出的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 源获取。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
