融云国产化适配排坑指南

超链接实验室,是融云策划推出的 IT 系列直播课,携手行业专家,一起聊聊 IT 国产化、协同办公通信、通信中台、企业数字化的那些事儿。关注【融云 RongCloud】,了解协同办公平台更多干货。

融云支持国产化的初心,可追溯到 2017 年进入政企市场之日起。时至今日,融云已成为国产化支持最完善、彻底的企业之一。
融云国产化适配排坑指南_第1张图片
(融云国产化适配范围)

基于丰富的国产化经验,「超链接实验室」首期课程《国产化之路 —— 国产化适配的那些坑》于 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 型号

融云国产化适配排坑指南_第2张图片
(公众号后台回复【超链接实验室】获得讲师 PPT)

从国产芯片现状可以看出,国产化 CPU 以精简指令集阵营居多,并且,在实际交付中,我们所能够碰到的国产 CPU 也是以精简指令集类型居多。例如:ARM 架构的鲲鹏 / ⻜腾系列、MIPS 架构的⻰芯(龙芯后续会主推 LoongArch 架构)等。由于复杂指令集和精简指令集的设计初衷不同,导致精简指令集 CPU 在性能上与复杂指令集存在较大差异(相同规格复杂指令集的 CPU 性能高于精简指令集 CPU)。

融云建议:在实际的交付部署中,根据不同的性能指标进行部署资源估算。而关于性能测试覆盖范围,融云建议以下几种:

鲲鹏 920 / 920S、飞腾 2000 / 2000+、龙芯 3B3000 / 4000,搭配的操作系统:统信 V20 及麒麟 V10。x86 架构的海光 CPU ,性能上可以认为与其他同等规格的 x86 CPU 相近即可。

客户端国产化适配

多数的国产系统都分桌面版和服务版,对于客户端的国产化适配,我们只针对桌⾯版来看待和解决问题,桌⾯客户端在国产化适配中,容易遭遇如下问题:

◆ 不同操作系统打包规范不同导致桌⾯客户端各种⼩问题

主要问题如:卸载后图标未被清理、托盘显示 2 个图标、托盘不闪烁等。
融云国产化适配排坑指南_第3张图片
融云建议:先找到国产操作系统厂商咨询,索要打包规范,然后依据规范再进行打包(这里需要说明的是,各大厂商非常重视自身生态发展,所以对于咨询的态度是十分开放的,可以大胆咨询)。

◆ 不同操作系统 libc 版本不⼀致导致桌面客户端不能正常使用

融云协同办公产品客户端协议栈使用 C++ 作为开发语言,同时,插件也基于 C++ 开发,而在客户端国产化适配过程中,C++ 的协议栈、插件等因为不同操作系统 libc 版本不⼀致,也容易引发一系列问题。

经过多次尝试,衷心建议伙伴们:无论是 ARM 还是 MIPS 架构,都在麒麟系统上进行编译,因为同一架构下麒麟系统的 libc 版本比统信系统低,一般麒麟系统的 libc 版本为 2.2.3 ,统信的则为 2.2.8 。这样基本可以避免客户端 C++ 插件及组件的异常。

◆ 截屏模块采用静态编译

在国产化适配客户端功能测试中,客户端截屏功能⽆法正常使⽤是最早暴露的问题之⼀ ,与前一问题不同的是,这里只针对客户端的插件范畴,给出另外一种解决方案。起初,融云截屏相关组件采用的是动态编译的⽅式,由于该⽅式与操作系统的依赖性较强,经常出现在这个系统下可用、在另外系统下不可⽤的情况。经过探索,最终我们采用在静态编译 QT 的基础上编译截屏 node ⽂件的方式,成功解决了不同操作系统下客户端截屏功能无法正常使用的问题。
融云国产化适配排坑指南_第4张图片
(公众号后台回复【超链接实验室】获得讲师 PPT)


国产化部署交付

几乎所有的应用业务系统都会使用和依赖⼀些中间件或者工具,例如:消息队列中间件、缓存中间件、进程管理工具等。在部署交付之前,常常都会预先把所有的部署资源提前准备好,包括:服务自身的编译包、中间件等,因为现场临时编译显然不是明智之举,做不到快速部署,也无法保证整个过程的可控。
融云国产化适配排坑指南_第5张图片
(公众号后台回复【超链接实验室】获得讲师 PPT)

在部署资源准备方面,国产化适配容易遭遇以下几个问题:

◆ 不同操作系统 glibc 版本不⼀致导致中间件编译失败
在版本的选择上,不可过高也不可过低,如果版本过高,那么在遇到低版本时,⼀定会出问题;而版本过低,又会出现找不到依赖的情况。因此,为了统⼀编译,达到泛部署的目的,我们建议找到⼀个合适的版本进行中间件的编译,以适应多数场景。对此融云针对麒麟、统信做了⼤量的摸索和尝试,目前已达到预编译部署资源在多数场景下的正常使用。

◆ 不同操作系统 Path 环境变量不同
很多中间件在正常运行时都依赖于系统环境变量的设置,可以通过软链的方式去解决,这样可以避免对系统 Path 环境变量的修改,毕竟作为国产操作系统的使用者,在理解及评估能力方面远不及厂商自身,不直接修改操作系统的环境变量,我们就能够规避因为修改系统的环境变量而引发其他问题的风险。

◆ 不同操作系统 rpm 包存在差异
通常在自动化部署工具的实现上,大家都会用 Python,Python 自身依赖于 Python rpm 包,在不同操作系统下,rpm 包存在差异,就可能会出现问题,需要针对不同操作系统做对应的处理。这里建议⼤家:优先使⽤操作系统⼚商所提供的 rpm 包,其次是从 OS 的 yum 源获取。

你可能感兴趣的:(sqljava)