Rongyun Localization Adaptation Guide for Pit Arrangement

Hyperlink Lab is a series of live IT courses planned and launched by Rongyun. Together with industry experts, we talk about IT localization, collaborative office communication, communication middle-office, and enterprise digitization. Follow [RongCloud] to learn more about the collaborative office platform.

The original intention of Rongyun to support localization can be traced back to the day it entered the government and enterprise market in 2017. Today, Rongyun has become one of the enterprises with the most complete and thorough localization support.

(Rongyun localization adaptation range)

Based on rich experience in localization, the first course of "Hyperlink Lab", "The Road to Localization - Those Pits for Localization" was officially launched on March 30. Chen Xiang, the R&D architect of Rongyun's server, took the three parts as the main entry point: server localization adaptation, client localization adaptation, and localization deployment and delivery, and described in detail the process of localization adaptation of Rongyun. The problems encountered in the past, and a series of solutions that have been verified by Rongyun for many times, hope that partners who are walking on the "road of localization" can learn from this and avoid detours.

---

Server-side localization adaptation

◆ Relational database table/field names are recommended to be all capitalized and avoid naming with a single word

A database that supports SQL is generally composed of a storage service (Service) and a storage engine (Engine). The analyzer performs lexical and grammatical analysis of SQL statements, the executor is responsible for interacting with the storage engine, and the domestic relational database analyzers are all at the level of the analyzer. Follows the SQL specification, but varies on storage engines. Although the mainstream domestic relational databases NPC Jincang, Dameng, Shenzhou GM, and Nanda GM all support SQL, it does not mean that SQL statements that are executed on MySQL without problems can also be executed on domestic databases without problems.

Rongyun Suggestion: It is recommended that the table/field name of a relational database be all uppercase, and avoid naming it with a single word (in extreme cases, it can be listed as a development specification that prohibits it).

All uppercase can avoid the situation that the library/table/field cannot be found due to the case-sensitive setting of the database; if the table/field is not named with a single word, the keyword conflict problem can be basically avoided.

◆ Use jdk-8u192 as Java runtime environment

In order to ensure high performance, all access interface services of Rongyun collaborative office products use Netty (Netty provides an asynchronous, event-driven network application framework and tools to rapidly develop high-performance, high-reliability network servers and clients terminal program). The problem is that Netty relies on many third-party packages, so it is more likely to not support ARM/MIPS, and it is easy to encounter problems such as HTTPS processing failure.

After many attempts, it is recommended to use jdk-8u192 as the Java runtime environment and recompile under the corresponding architecture.

It should be added that Oracle charges for JDK8 from January 2019, and 8u192 is the last version update in 2018, which can continue to be used for free. But starting in January 2019, if you also want to get JDK updates, you will need a paid subscription.

◆The performance test should cover the main domestic CPU models

(The official account will reply to [Hyperlink Lab] to get the lecturer's PPT)

From the status quo of domestic chips, it can be seen that most of the domestic CPUs are in the simplified instruction set camp, and in actual delivery, the domestic CPUs we can encounter are mostly of the reduced instruction set type. For example: Kunpeng/Hongteng series of ARM architecture, Hongxin of MIPS architecture (Loongson will focus on the LoongArch architecture in the future), etc. Due to the different design intentions of the complex instruction set and the reduced instruction set, the performance of the reduced instruction set CPU is quite different from that of the complex instruction set (the performance of the CPU with the same specification of the complex instruction set is higher than that of the reduced instruction set CPU).

Rongyun's suggestion: In actual delivery and deployment, estimate deployment resources based on different performance indicators. Regarding performance test coverage, Rongyun recommends the following:

Kunpeng 920 / 920S, Feiteng 2000 / 2000+, Loongson 3B3000 / 4000, with operating systems: Tongxin V20 and Kirin V10. The performance of the Haiguang CPU of the x86 architecture can be considered to be similar to other x86 CPUs of the same specification.

Client localization adaptation

Most domestic systems are divided into desktop version and service version. For the localization adaptation of the client, we only look at and solve problems for the desktop version. In the localization adaptation of the desktop client, it is easy to encounter the following problems:

◆ Different packaging specifications for different operating systems lead to various minor problems on desktop clients

The main problems are: icons are not cleaned up after uninstallation, 2 icons are displayed on the tray, and the tray does not flicker.

Rongyun's suggestion: first find domestic operating system manufacturers for consultation, ask for packaging specifications, and then package according to the specifications (it should be noted here that major manufacturers attach great importance to their own ecological development, so their attitude towards consultation is very open, and you can be bold consult).

◆ Inconsistent libc versions of different operating systems cause the desktop client to not work properly

The client protocol stack of Rongyun collaborative office products uses C++ as the development language. At the same time, the plug-ins are also developed based on C++. In the process of localization and adaptation of the client, the C++ protocol stack and plug-ins are inconsistent due to the different libc versions of different operating systems. , but also easily lead to a series of problems.

After many attempts, I sincerely recommend that partners: Whether it is ARM or MIPS architecture, compile on the Kylin system, because the libc version of the Kylin system under the same architecture is lower than that of the Tongxin system, and the libc version of the general Kylin system is 2.2.3 , and 2.2.8 of Tongxin. In this way, exceptions of client-side C++ plug-ins and components can be basically avoided.

◆ The screenshot module is compiled statically

In the localization adaptation client function test, the failure of the client screen capture function to be used is one of the earliest exposed problems. Different from the previous problem, here is only the plug-in category of the client, and another solution is given. Program. At first, Rongyun screenshot-related components adopted the dynamic compilation method. Due to the strong dependence of this method on the operating system, it often occurs that it is available under this system but not available under other systems. After exploration, we finally adopted the method of compiling the screenshot node file on the basis of statically compiling QT, and successfully solved the problem that the client screenshot function cannot be used normally under different operating systems.

(The official account will reply to [Hyperlink Lab] to get the lecturer's PPT)

---

Localized deployment and delivery

Almost all application business systems use and rely on some middleware or tools, such as message queue middleware, cache middleware, process management tools, etc. Before deployment and delivery, all deployment resources are often prepared in advance, including: the compilation package of the service itself, middleware, etc., because on-site temporary compilation is obviously not a wise move, it cannot achieve rapid deployment, and it cannot guarantee the entire process. controllable.

(The official account will reply to [Hyperlink Lab] to get the lecturer's PPT)

In terms of deployment resource preparation, localization adaptation is prone to encounter the following problems:

◆ Inconsistent glibc versions of different operating systems lead to middleware compilation failure <br>In the choice of version, neither too high nor too low, if the version is too high, there will be problems when encountering a low version; If the version is too low, there will be a situation where no dependencies can be found. Therefore, in order to compile uniformly and achieve the purpose of pan-deployment, we recommend finding a suitable version to compile the middleware to suit most scenarios. In this regard, Rongyun has made a lot of explorations and attempts on Kylin and Tongxin, and has reached the normal use of precompiled deployment resources in most scenarios.

◆ Different operating systems have different Path environment variables <br> Many middlewares depend on the setting of system environment variables during normal operation, which can be solved by means of soft links, which can avoid the modification of system Path environment variables. The users of the operating system are far inferior to the manufacturers themselves in terms of understanding and evaluation capabilities. Without directly modifying the environment variables of the operating system, we can avoid the risk of other problems caused by modifying the environment variables of the system.

◆ There are differences in the rpm packages of different operating systems <br>Usually, in the implementation of automated deployment tools, everyone uses Python. Python itself depends on the Python rpm package. Under different operating systems, there are differences in the rpm package, which may cause problems. Corresponding processing needs to be done for different operating systems. It is suggested here that you should use the rpm package provided by the operating system manufacturer first, and then obtain it from the yum source of the OS.