Rainbond v5.14.2 バージョン (新荘バージョンとも呼ばれます)。このバージョン以降、オープンソース ユーザーは、Rainbond を使用して、Xinchuang の要件を満たすハードウェア コンピューティング リソースを管理することもできます。このバージョンでは、製品チームは、これまでエンタープライズ版製品にしか存在しなかった新荘関連の機能を分割し、オープンソース製品ルートに統合しました。この記事では、新荘環境でアプリケーションをクラウドに移行する方法に焦点を当て、Rainbond 新荘バージョンの機能を組み合わせて、実現可能な実装計画を示します。
アプリケーションを新荘環境に移行する必要性
イノベーション産業、つまり情報技術アプリケーションのイノベーション産業は、我が国のデジタル変革の重要な部分であり、主要なインフラストラクチャーの重要なサポートです。その核心は、ローカライズされた情報技術ソフトウェアとハードウェアの基礎となるアーキテクチャシステムと、業界アプリケーションを通じてフルサイクルエコシステムを構築し、コア技術の主要なリンクにおけるボトルネックの問題を解決し、中国の発展のための強固なデジタル基盤を築くことです。
一般のソフトウェア サプライヤーにとって、党、政府、軍事企業にソフトウェアを販売する場合、現地の新荘の要件を満たすことが、徐々に回避できない厳格な基準になってきました。納品されたソフトウェアについても、その後の建設計画において、新荘市の変革期にある党、政府、軍事企業は、局所的な新荘環境への移行という厳格な要件を打ち出すことになる。需要の背後には常にビジネスチャンスが隠れており、ローカライズされた新荘を背景にアプリケーション移行能力を習得し、ソフトウェア製品を新荘アプリケーションに変換することは、新荘のすべての ToB/ToG アプリケーション サプライヤーが習得しなければならない能力です。レインボンド新荘版はそんなシーンで大活躍します。
新荘ハードウェアエコロジー
Xinchuang アプリケーションは、ローカライズされたハードウェアとオペレーティング システム上で実行する必要があります。ローカライズされたハードウェア エコロジーで最も重要なのは CPU チップであり、CPU チップのアーキテクチャは、新荘アプリケーションがローカライズされたハードウェア上で実行できるかどうかに直接影響します。現在、主流のローカライズ CPU メーカーには、Phytium、Huawei、Loongson、Haiguang、Zhaoxin などがあり、その命令セットは集中しており、X86高度Armに自律性がありますLoongArch(MIPS 命令セットの後継)。命令セットの違いは、新荘アプリケーションを適応させるために再コンパイルする必要があるかどうかに直接影響します。
国産 CPU チップのエコロジーにはいくつかの特徴があることを理解するのは難しくありません。
LoongArch自律性は最も強いものの、その生態は厳しく制限されており、短期間でうまく市場に出すことはできません。- Haiguang と Zhaoxin は、
X86最も繁栄した生態環境を備えた命令セットの認可を保持していますが、自律性の度合いは最も弱いです。X86成熟しすぎて安定しており、先人の建物がすでに建てられているため、これをベースにイノベーションを起こすのは困難です。 - Huawei と Phytium は
Arm命令セットの認可を持ち、ある程度の自律性があり、Armエコロジーが急成長しており、X86エコロジーと競合することができます。
市場からのフィードバックは非常に合理的で、現在国内のCPUチップ市場では、Phytiumが党・政府分野のPC市場シェアをリードしており、HaiguangとKunpengが通信事業者のサーバーで主なシェアを占めている。新荘のアプリケーションサプライヤーの視点に戻ると、Arm カードをいかにうまく活用するかが、新荘のローカライズされた路線に食い込むための重要なポイントとなります。Rainbond Xinchuang バージョンは、ワンクラウド マルチコア機能により、Arm を含むマルチ アーキテクチャ クラスターの管理を容易にします。
「複数のコアを備えた 1 つのクラウド」で Arm および x86 クラスターを管理
名前が示すように、1 つのクラウド内に複数のコアを持つ異種クラスターとは、同じクラスター内のコンピューティング ノードが異なる CPU チップ アーキテクチャを持っているという事実を指します。
一般に、CPU チップのアーキテクチャはX86Intel が導入した命令セットに基づいており、新星である AMD も完全互換のX86命令amd64セットを導入しており、両者は同等と見なすことができます。新荘国内のシーンでは、多くの国内 CPU アーキテクチャがArm命令セットに基づいて開発されており、一般的な Kunpeng 920 および Feiteng チップはすべてこのアーキテクチャ タイプに属します。ローカライズされた新荘 IT エコシステムに統合できるようにするために、Rainbond はArm自己革新バージョンから始まるアーキテクチャと完全に互換性があります。
新荘のローカライズは決して 1 回限りのイベントではありません。従来のアーキテクチャで開発された多数のX86アプリケーションは、ローカライズされたチップ上で完全に実行できるようになるまでに、長期間の調整やリファクタリングが必要です。1 つのクラウド マルチコアは実行に重点を置いています。複数のアーキテクチャ アプリケーションを同時に実行できる機能は、ローカリゼーション置換の過渡段階で重要な役割を果たします。
Rainbond Xinchuang バージョンは、同じクラスター内で異なる CPU アーキテクチャを備えたコンピューティング ノードを均一に管理およびスケジュールできます。また、マルチクラスター管理機能を利用して複数の単一アーキテクチャ クラスターを管理することもできます。非常に高い柔軟性により、意思決定者は異種コンピューティング リソースの展開戦略を決定できます。
Arm アーキテクチャに加えて、Rainbond 新荘バージョンは、主流のローカライズされたソフトウェアおよびハードウェアとも互換性があり、新荘シナリオを完全にサポートし、国内の主要な CPU メーカーおよびオペレーティング システム メーカーによって認定されています。新荘アプリケーションの開発、運用と保守、配信のプロセス全体を統合的に管理することで、新荘のローカライズされたシナリオにおけるアプリケーション管理コストが大幅に削減されます。
新荘市のアプリケーション移行の問題
新荘市のアプリケーション サプライヤーにとって、一連の新荘市アプリケーションをゼロから開発することは難しくありません。我が国の新荘エコロジーはますます充実しており、オペレーティングシステム、開発ツール、データベースのいずれにおいても空白の領域はなく、新しい新荘アプリケーションの開発を包括的にサポートしています。本当の難しさは、従来のサーバー上ですでに実行されているレガシー ビジネス システムをローカライズされた新荘環境に移行する方法にあります。従来型からアーキテクチャX86への移行はArm、基本的に、ビジネス システム内のすべてのサービス コンポーネントの再コンパイル、さらにはリファクタリングを意味します。ビジネスの継続性を確保するという前提の下で、従来のアプリケーションから新荘アプリケーションへの移行を完了することは避けられない課題です。
まず、開発言語と操作モードに従ってサービスを分類しましょう。
通訳された言語
Python、PHP、および Shell に代表されるインタープリタ言語は、スクリプト言語とも呼ばれ、CPU アーキテクチャから完全に独立しています。新荘環境で使用できる言語インタープリターを提供するだけでよく、コードを 1 行も変更せずにこのサービスを実行できます。
バイトコード用コンパイルファイル
このタイプは、Java 言語によってコンパイルされた Jar および War パッケージによって表されます。Jar および War パッケージは、非常に一般的なソフトウェア成果物です。CPUアーキテクチャに関係のないバイトコードを詰め込んでおり、最終的な動作はクロスプラットフォームのJVM仮想マシンが担当するため、新荘環境でそのまま利用できるJDKとJREツールを提供するだけで済みます。このサービスを実行することを前提としたコード行。
コンパイル言語
バイトコードのコンパイル済みファイルもコンパイル済み言語で生成されるため、ここでの説明は厳密ではありません。ここでは特に C、C++、Golang に代表されるコンパイル言語を指しますが、これらはコンパイル時の CPU アーキテクチャと強く関係しており、コンパイルされたバイナリ製品は指定された CPU アーキテクチャでのみ動作します。この機能は、移行プロセスを新荘環境で実行する前に再コンパイルする必要があることも意味します。
レガシー ビジネス システムをローカライズされた新荘環境に移行するのは簡単な作業ではなく、当事者 A とサプライヤー間の緊密な協力が必要です。ただし、レガシー業務システムの特性上、サプライヤーが提供できるサポートは異なります。サポートのレベルが異なると、移行の効果に直接影響します。
手伝う
当事者 A がレガシー ビジネス システムの移行を決定したとき、サプライヤーが約束したサポート期間がまだ終了していないことが起こります。サプライヤーがビジネス システムの移行に対して包括的なサポートを提供できる場合、問題ははるかに簡単になります。コンパイル済み言語であっても、ソース コードを提供して再コンパイルできる限り、新荘への移行は完了しますが、時間と労力がかかります。
サポートなし
甲社があるレガシー業務システムを移行することになった際、サプライヤーが約束していたサポート期間が過ぎてしまい、サプライヤーにも連絡が取れなくなってしまい、事態はさらに困難になってしまいます。当事者 A はレガシー ビジネス システムを深く理解しておらず、分析用のソフトウェア成果物を見つけて、新荘環境に基づいてコンパイルと運用環境を構築することしかできません。しかし、一部の古くからある業務システムの場合、その年のソースコードを見つけるのは困難であり、このサービスがコンパイル言語でコンパイルされたバイナリファイルであった場合、基本的には新荘社の移行は行き詰まっていることを意味する。現時点では、甲はシステムを再構築するために別のサプライヤーに再入札することを検討する必要がありました。新しい代替システムの導入は一夜にして実現するものではありません。この期間中、このサービスがローカライズされた新荘の全体的な導入プロセスを妨げるものではありません。
Rainbond「新荘」バージョンの中核機能は、新荘環境における従来のアプリケーションのクラウド移行をサポートすることです。ユーザーが使用するさまざまな言語タイプに細心の注意を払い、新荘語の移行を自動化します。すべてのコンポーネントが正常にデプロイされると、組み込みの ServiceMesh マイクロサービス アーキテクチャを通じてクロスアーキテクチャ マイクロサービス オーケストレーションを実現でき、サービス コンポーネントを接続して完全なビジネス システムを形成できます。
従来のアプリケーションをクラウドに移行する
Rainbond 新荘バージョンは、アーキテクチャの違いを自動的にシールドし、アプリケーションをローカライズされた新荘環境に最低コストで移行します。ソース コードのみを提供する必要があり、指定されたアーキテクチャ環境でコンパイルして実行できます。オープン ソース アプリケーション ストアは、さまざまなアーキテクチャのアプリケーション テンプレートと、数百ものオープン ソース ソフトウェアのワンクリック展開を提供します。新荘のアプリケーションプロバイダーは、技術的コストと時間的コストを最小限に抑えながら、さまざまな種類のサービスを再コンパイルして新荘の環境に展開できます。
異種マイクロサービス オーケストレーション機能
Rainbond Xinchuang バージョンは、ワンクラウド マルチコア管理機能を備えており、同じクラスター内の異なる CPU アーキテクチャを備えたコンピューティング ノードを均一にスケジュールして管理できます。アプリケーション内のサービス コンポーネントは、必要に応じて指定されたアーキテクチャにデプロイすることもできます。しかし、異なるアーキテクチャのマイクロサービス コンポーネントを配置して相互に通信できる場合にのみ、それらは有機的な全体となり、完全なビジネス システムを形成できます。同時に、伝統的なものからローカライゼーションX86への移行期における新荘アプリケーションの特別な要件も満たしますArm。
Service Mesh または Kubernetes Service の機能により、Rainbond はクロスアーキテクチャ マイクロサービス間のオーケストレーションと通信を自然にサポートします。使用方法は、Rainbond のドラッグ アンド ドロップ ビルディング ブロック スタイルのマイクロサービス オーケストレーション方法と変わりません。
