HyperlinkLab是融云策划推出的一系列IT直播课程。与行业专家一起，畅谈IT本土化、协同办公通信、通信中台、企业数字化。那些事。关注【融云】，了解更多协同办公平台。融云支持本地化的初衷可以追溯到2017年进军政企市场的那一天，时至今日，融云已经成为本地化支持最完善、最彻底的企业之一。（融云本地化适配范围）基于丰富的本地化经验，《超链实验室》第一期课程《国产化之路 —— 国产化适配的那些坑》于3月30日正式上线，融云服务器研发架构师陈翔详细讲述了融云本地化适配的过程由服务器本地化适配、客户端本地化适配和本地化部署交付三部分组成。遇到的困难，以及经过融云多次验证的一系列解决方案，希望走在“国产化之路”上的伙伴们能够借鉴，少走弯路。服务器本地化适配◆关系型数据库表名/字段名建议全部大写，避免单个单词。支持SQL的数据库一般由存储服务（Service）和存储引擎（Engine）组成。SQL语句的词法语法分析，执行器负责与存储引擎交互，国内的关系型数据库分析器都遵循SQL规范，只是存储引擎不同。虽然国内主流的关系型数据库如仁达金仓、大梦、神舟GM、台大GM都支持SQL，但并不代表在MySQL上执行无问题的SQL语句在国产数据库上也能执行无问题。融云建议：关系型数据库表名/字段名建议全部使用大写字母，避免使用单个单词命名（极端情况下可以列为开发规范明文禁止）。全部大写可以避免由于数据库的大小写设置导致找不到库/表/字段的情况；如果表/字段不是一个单词命名，关键字冲突的问题基本可以避免。◆使用jdk-8u192作为Java运行环境。为保证高性能，融云协同办公产品的所有访问接口服务均采用Netty（Netty提供异步、事件驱动的网络应用框架和工具，用于快速开发高性能、高可靠的Web服务器和客户端程序）。问题是Netty依赖了很多第三方包，所以不支持ARM/MIPS的可能性比较大，容易出现HTTPS处理失败等问题。经过多方尝试，推荐使用jdk-8u192作为Java运行环境，在相应架构下重新编译。需要补充的是，Oracle从2019年1月开始对JDK8收费，而8u192是2018年的最后一个版本更新，可以继续免费使用。但从2019年1月开始，如果你还想获得JDK更新，则需要付费订阅。◆性能测试要覆盖国产主要CPU型号（公众号后台回复【超链接实验室】获取讲师PPT）从国产芯片现状可以看出，国产CPU绝大部分来自精简指令集阵营，并且，在实际交付中，我们能接触到的国产CPU绝大部分都是RISC类型的。例如：基于ARM架构的鲲鹏/龙腾系列，基于MIPS架构的龙芯（龙芯未来将专注于LoongArch架构）等。由于复杂指令集和精简指令集的设计意图不同，性能精简指令集CPU的性能与复杂指令集有很大区别（相同规格的复杂指令集CPU性能要高于精简指令集CPU）。融云建议：在实际交付部署中，根据不同的性能指标预估部署资源。性能测试的覆盖范围，容云推荐以下机型：鲲鹏920/920S、飞腾2000/2000+、龙芯3B3000/4000，搭载操作系统：同芯V20、麒麟V10。x86架构的海光CPU的性能可以认为和其他同规格的x86CPU差不多。客户端本地化适配国内大部分系统分为桌面版和服务版。对于客户端的本地化适配，我们只针对桌面版查看和解决问题。在桌面客户端的本地化适配中，很容易遇到以下问题：◆不同操作系统的封装规格不同，导致桌面客户端出现各种小问题。主要问题是：卸载后图标没有清理，托盘显示2个图标，托盘不闪烁。融云的建议：先找国内操作系统厂商咨询，询问打包规范，然后按照规范打包（这里要说明一下，各大厂商都很重视自己的生态建设，所以对咨询的态度很开放，可以大胆参考）。◆不同操作系统libc版本不一致导致桌面客户端无法使用以C++为开发语言的融云协同办公产品客户端协议栈。同时，该插件也是基于C++开发的。C++协议栈、插件等容易因不同操作系统的libc版本不一致而引发一系列问题。经过多次尝试，真心建议小伙伴们：不管是ARM还是MIPS架构，都在麒麟系统上编译，因为同架构下麒麟系统的libc版本比同心系统低。一般Kylin系统的libc版本是2.2.3，同心是2.2.8。这样基本可以避免客户端C++插件和组件异常。◆截屏模块静态编译。在本地化适配客户端功能测试中，客户端截屏功能无法正常使用是最早暴露的问题之一。与上一个问题不同的是，这里只针对客户端的插件类。给出另一种解决方案。起初，融云截屏的相关组件采用了动态编译的方式。由于该方法对操作系统依赖性强，经常出现本系统下可用，其他系统下不可用的情况。经过摸索，我们最终在静态编译QT的基础上采用了编译截图节点文件的方法，成功解决了客户端截图功能在不同操作系统下无法正常使用的问题。(公众号后台回复【超链接实验室】获取讲师PPT）本地化部署交付几乎所有的应用业务系统都会使用和依赖一些中间件或工具，例如：消息队列中间件、缓存中间件、进程管理工具等。部署前和交付，往往所有的部署资源都是提前准备好的，包括：服务本身的编译包、中间件等，因为现场临时编译显然不是明智之举，无法实现快速部署，而且整个过程不能保证可控。（公众号后台回复【超链接实验室】获取讲师PPT）在部署资源准备方面，本地化适配容易出现以下问题：◆不同操作系统glibc版本不一致导致中间件编译失败。在选择上，不宜过高或过低。版本太高，遇到低版本肯定会出问题；如果版本太低，将找不到依赖项。因此，为了统一编译和通用部署，我们建议寻找适合大多数场景的中间件编译版本。在这方面，融云针对Kylin和同心做了很多探索和尝试，已经达到了大部分场景下预编译部署资源的正常使用。◆不同的操作系统有不同的Path环境变量。很多中间件在正常运行时依赖于系统环境变量的设置，可以通过软链接的方式解决，可以避免系统Path环境变量的修改。毕竟作为国产操作系统，用户在理解和评价能力上远不如厂商。无需直接修改操作系统的环境变量，就可以避免因修改系统的环境变量而带来其他问题的风险。◆不同操作系统的rpm包存在差异。通常，在自动化部署工具的实现中，大家都会用到Python。Python本身依赖于Pythonrpm包。操作系统进行相应的处理。这里给大家一个建议：先使用操作系统厂商提供的rpm包，再从操作系统的yum源中获取。
