Rainbond v5.14.2 version, also known as Xinchuang version. Starting from this version, open source users can also use Rainbond to manage hardware computing resources that meet Xinchuang's requirements. In this version, the product team split out Xinchuang related functions that only existed in the enterprise version products before, and integrated them into the open source product route. This article focuses on how to migrate applications to the cloud in the Xinchuang environment , and combines the capabilities of the Rainbond Xinchuang version to give a feasible implementation plan.
The necessity of migrating applications to Xinchuang environment
The innovation industry, namely the information technology application innovation industry, is an important part of my country's digital transformation and an important support for key infrastructure. Its core is to build the underlying architecture system of localized information technology software and hardware and a full-cycle ecological system through industry applications, solve the problem of bottlenecks in key links of core technologies, and lay a solid digital foundation for China's development.
For general software suppliers, when selling software to party, government and military enterprises, compliance with the requirements of localized Xinchuang has gradually become a rigid standard that cannot be bypassed. Even for the software that has been delivered, in the later construction plan, the party, government, and military enterprises in the transformation period of Xinchuang will put forward the rigid requirement of migrating to the localized Xinchuang environment. There are always business opportunities hidden behind the demand. Mastering the application migration ability under the background of localized Xinchuang and transforming software products into Xinchuang applications is the ability that all ToB/ToG Xinchuang application suppliers must master. Rainbond Xinchuang version can play a great role in such a scene.
Xinchuang hardware ecology
Xinchuang applications must run on localized hardware and operating systems. The most important thing in the localized hardware ecology is the CPU chip. The architecture of the CPU chip directly affects whether Xinchuang applications can run on the localized hardware. At present, the mainstream localized CPU manufacturers include Phytium, Huawei, Loongson, Haiguang, Zhaoxin, etc., and their instruction sets are concentrated in X86and Armhighly autonomous LoongArch(the successor of the MIPS instruction set). The difference in instruction sets directly affects whether Xinchuang applications need to be recompiled for adaptation.
It is not difficult to see that the ecology of domestically produced CPU chips has several characteristics:
LoongArchThe degree of autonomy is the strongest, but its ecology is severely restricted, and it cannot be well promoted to the market in a short period of time.- Haiguang and Zhaoxin hold
X86the instruction set authorization with the most flourishing ecology, but the degree of autonomy is the weakest.X86It is too mature and stable, and the buildings of the predecessors have already been built, so it is difficult to make innovations on this basis. - Huawei and Phytium have
Arminstruction set authorization, a moderate degree of autonomy, andArmthe ecology is booming, and they canX86compete with the ecology.
The feedback from the market is very rational. In the current domestic CPU chip market, Phytium leads the PC market share in the party and government field, and Haiguang and Kunpeng occupy the main share of operators' servers. Returning to the perspective of Xinchuang application suppliers, how to play the Arm card well will be the key point to break into the localized Xinchuang track . The Rainbond Xinchuang version facilitates the management of multi-architecture clusters including Arm through the one-cloud multi-core capability.
"One cloud with multiple cores" manages Arm & x86 clusters
As the name implies, a heterogeneous cluster with multiple cores in one cloud refers to the fact that the computing nodes in the same cluster have different CPU chip architectures.
In general, the architecture of CPU chips is based on X86the instruction set introduced by Intel, and AMD, a rising star, has also introduced a fully compatible X86instruction amd64set, and the two can be regarded as equivalent. In the domestic Xinchuang scene, many domestic CPU architectures are Armdeveloped based on instruction sets, and the common Kunpeng 920 and Feiteng chips all belong to this architecture type. In order to be able to integrate into the localized Xinchuang IT ecosystem, Rainbond is fully compatible with Armthe architecture starting from the self-innovation version.
Localization of Xinchuang is by no means a one-time event. A large number of X86applications developed under the traditional architecture require a long period of adjustment or even refactoring before they can be fully run on localized chips. One cloud multi-core focuses on running multiple architecture applications at the same time ability, will play a major role in the transitional stage of localization substitution.
The Rainbond Xinchuang version can uniformly manage and schedule computing nodes with different CPU architectures in the same cluster, and can also manage multiple single-architecture clusters with the help of multi-cluster management capabilities. Ultra-high flexibility allows decision makers to decide the deployment strategy of heterogeneous computing resources.
In addition to the Arm architecture, the Rainbond Xinchuang version is also compatible with mainstream localized software and hardware, fully supports Xinchuang scenarios, and has been certified by major domestic CPU manufacturers and operating system manufacturers. Integrated management of the entire process of development, operation and maintenance, and delivery of Xinchuang applications greatly reduces application management costs in localized Xinchuang scenarios.
Xinchuang application migration difficulties
For Xinchuang application suppliers, it is not difficult to develop a set of Xinchuang applications from scratch. my country's Xinchuang ecology has become more and more complete. No matter it is the operating system, development tools or database, there is no blank area. They provide comprehensive support for the development of new Xinchuang applications. The real difficulty lies in how to migrate the legacy business system already running on the traditional server to the localized Xinchuang environment . Leaping from traditional X86to Armarchitecture basically means the recompilation and even refactoring of all service components in the business system. Under the premise of ensuring business continuity, it is an unavoidable task for us to complete the transformation of traditional applications to Xinchuang applications.
First, let's classify services according to their development language and operation mode:
interpreted language
Interpreted languages represented by Python, PHP, and Shell, also known as scripting languages, are completely independent of the CPU architecture. We only need to provide a language interpreter that can be used in the Xinchuang environment, and we can run this service without changing a single line of code.
Compilation file for bytecode
This type is represented by the Jar and War packages compiled by the Java language. Jar and War packages are very common software deliverables. Since it packs bytecodes that have nothing to do with the CPU architecture, and the final operation is in charge of the cross-platform JVM virtual machine, so we only need to provide JDK and JRE tools that can be used in the Xinchuang environment without changing a line of code Under the premise of running this service.
compiled language
The description here is not strict, because bytecode compiled files are also produced in compiled languages. Here, we specifically refer to compiled languages represented by C, C++, and Golang. They are strongly related to the CPU architecture during compilation, and the compiled binary products can only run under the specified CPU architecture. This feature also means that the migration process must be recompiled before it can run in the Xinchuang environment.
Migration of legacy business systems to the localized Xinchuang environment is no easy task, requiring close cooperation between Party A and suppliers. However, due to the characteristics of legacy business systems, the support that suppliers can provide is different. Different levels of support directly affect the effect of migration.
provide support
When Party A decides to migrate a certain legacy business system, it happens that the support period promised by the supplier has not yet expired, and the problem will be much simpler when the supplier can provide comprehensive support for the migration of the business system. Even for compiled languages, as long as the source code can be provided for recompilation, Xinchuang migration can be completed, but it is time-consuming and labor-intensive.
no support
When Party A decides to migrate a certain legacy business system, it happens that the support period promised by the supplier has expired, and even the supplier cannot be contacted, and things are much more difficult. Party A does not have a deep understanding of the legacy business system, and can only find the software deliverables for analysis, and build a compiling and running environment based on the Xinchuang environment. However, for some long-standing business systems, it is difficult to find the source code of that year. If this service happens to be a binary file compiled by a compiled language, it basically means that Xinchuang's migration has come to a dead end. At this time, Party A had to consider re-bidding another supplier to reconstruct the system. The implementation of the new replacement system will not happen overnight. During this period, this service should not hinder the overall implementation process of localized Xinchuang.
The core function of Rainbond "Xinchuang" version is to support the cloud migration of traditional applications in the Xinchuang environment . It pays close attention to the different language types used by users and automates the migration of Xinchuang. Once all components are successfully deployed, cross-architecture microservice orchestration can be realized through the built-in ServiceMesh microservice architecture, and service components can be connected to form a complete business system.
Migrating traditional applications to the cloud
The Rainbond Xinchuang version automatically shields the architecture difference, and migrates the application to the localized Xinchuang environment at the lowest cost. Only the source code needs to be provided, and it can be compiled and run in the specified architecture environment. The open source application store provides application templates with different architectures, and one-click deployment of hundreds of open source software. Xinchuang application providers can recompile different types of services and deploy them to Xinchuang's environment with minimal technical and time costs.
Heterogeneous microservice orchestration capability
With its one-cloud multi-core management capability, Rainbond Xinchuang version can uniformly schedule and manage computing nodes with different CPU architectures in the same cluster. The service components in the application can also be deployed to the specified architecture as required. But only when microservice components of different architectures can be arranged and communicate with each other, can they become an organic whole and form a complete business system. At the same time, it also meets the special requirements of Xinchuang application in the transition period from traditional X86to Armlocalization.
With the help of Service Mesh or Kubernetes Service capabilities, Rainbond naturally supports the orchestration and communication between cross-architecture microservices. The method of use is no different from Rainbond's drag-and-drop building block-style microservice orchestration method.
