共计 2748 个字符，预计需要花费 7 分钟才能阅读完成。
超链接实验室，是融云策动推出的 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 源获取。
