ビジネスは閉じられていません: ソフトウェア システムのアップグレードの問題点を解決する新しい方法

デジタル時代においては、製品の性能や機能に対するユーザーの要求が継続的に向上しており、アプリケーション サービスのアップグレードは企業が競争力を維持するための鍵の 1 つとなっています。しかし、従来のアプリケーション サービスのアップグレードは、多くの場合、ユーザーに不必要な中断や不便をもたらします。この「傷を負う」アップグレード方法では、もはやユーザーの増大するニーズを満たすことができません。認識されないアップグレードをどのように実現するかが、多くの企業にとって課題となっています。早急に解決されますように。

エンタープライズデータセンターとビジネスコラボレーションプロジェクトを例に挙げると、プロジェクトの過程で、メリルリンチのマイクロサービスアプリケーションが使用される、メリルリンチのゲートウェイを入口とし、マルチベンダーのビジネスシステムを備えたコンバージド展開アーキテクチャが形成されました。他ベンダーのシステム事業をサポートする基本サービスとしてご利用いただけます。
ここに画像の説明を挿入
システム内のサービスをアップグレードする必要がある場合は、常に次のような問題に直面することになります。

▶ ビジネスの通常の運用への影響: サービスのアップグレード時にサービスを一時停止する必要があるため、ユーザーのビジネス機能が中断されます。複雑なパッチ アップグレード シナリオでは、ダウンタイムが 1 日続く場合もあります。サービスの新しいバージョンに問題がある場合、バージョンのロールバックプロセス中にサービスを一時停止する必要があり、その時間が長くなり、ビジネスの発展に重大な影響を及ぼします。

▶ リリースリスクの増加:サービスがアップグレードされた後、ユーザーは新しいバージョンのサービスにアクセスすることになりますが、新機能に未知の問題が発生する可能性があるため、リリースリスクが増加し、システム全体の安定性と信頼性に影響を与える可能性があります。

では、サービスがアップグレードされたときにユーザー エクスペリエンスが影響を受けないようにするにはどうすればよいでしょうか?

パート 1 の解決策

従来のアップグレード プロセスにおけるビジネスの問題点を解決するために、メリルリンチのデータ テクノロジ専門家チームは、ゲートウェイ サービスと Nacos ベースのアプリケーション サービスのアップグレードを意識せずに実行できる一連のソリューションを提供しました。
ここに画像の説明を挿入

  • 2 つの Nginx サービス ノードをデプロイし、フロント ロード F5 プロキシを通じて Nginx サービスの高可用性を確保します。2 セットの基本サービス ノード (ゲートウェイ サービス、システム管理、プロセス エンジン、タイミング スケジューリングなど) を展開します。サーバー A とサーバー B の基本サービスはまったく同じです。
  • データベース、Nacos、キャッシュなどのミドルウェアはすべてクラスター内にデプロイされ、基本的なサービス ノードは同じミドルウェア セットに接続されます。
  • ダウンストリーム アプリケーション サービスは、特定のサービス、他のダウンストリーム メーカーの製品、および顧客が開発した第 2 世代サービスを実装するための基本サービスに基づいています。これらのサービスには、少なくとも 2 つのノードをデプロイする必要があります。これらのノードは、アプリケーションの異なるバージョンであってもかまいません。

この展開スキームに従って展開されたシステムは高可用性を満たし、基本サービスとアプリケーション サービスの認識されないアップグレードをサポートします。

1. 基本サービスのアップグレード

基本サービスのアップグレードは、プリロードバランサのトラフィックスイッチングに基づいて実装され、ゲートウェイサービスは、ユーザーリクエストが最初にローカルアプリケーションに配信されることを制限します。つまり、リクエストはサーバー上のシステム管理やタイミングスケジューリングなどの基本サービスに優先的に転送されます。 A はサーバー A 上のゲートウェイ サービスを経由します。

アップグレードする前に、サーバー A とサーバー B のアプリケーションが、サービスのバージョンやサービス構成を含めて一貫していることを確認する必要があります。サーバー B を例として、非対応ソリューションのアップグレード プロセスを示します。アップグレード プロセスは次のとおりです。
ここに画像の説明を挿入
2. アプリケーション サービスのアップグレード

メリルリンチの技術専門家チームは、バージョン管理テクノロジーを通じて、下流のビジネス システム アプリケーション サービスの非知覚的なアップグレードを実現しました。サービスをデプロイする前に、各サービスにバージョン番号をタグ付けします。ユーザーは、異なるバージョンのサービスにアクセスするための条件を設定し、ゲートウェイサービスはリクエスト情報とユーザーの設定に従って、指定されたバージョンのビジネスアプリケーションサービスへのアクセスを実装します。

クライアントに基づく IP アクセスを例として、ビジネス システム製品サービスのアップグレード プロセスを示します。
ここに画像の説明を挿入

PART 2 プログラム値

1) 配信効率の向上: アップグレード サービスは、アップグレードのためのダウンタイムなしで日中に実行でき、ユーザーのビジネスが中断されないため、アップグレード時間を少なくとも 50% 節約できます。

2) アップグレードのリスクを軽減します: リスクはアクセス制御テクノロジーによって効果的に軽減できます。新しいバージョンに問題やエラーが発生した場合、影響を受けるのは一部のユーザーのみであり、ユーザー グループ全体には影響しません。問題が発生した場合、チームは問題をすぐにロールバックまたは修正できるため、潜在的な悪影響が軽減されます。

3) システムの可用性の向上: このソリューションを導入したシステムでは、運用中にサービス ノードがダウンした場合、他の利用可能なノードにすぐに切り替えることができ、通常のビジネスを確保し、一部のユーザーが新しいバージョンのサービスにアクセスするように制御できます。機能テスト、パフォーマンス テスト、負荷テストを実施すると、新しいバージョンが運用環境で安定して実行できるようになり、潜在的な問題やエラーが軽減されることが保証されます。

小さなTの概要

「アプリケーション サービス非認識アップグレード ソリューション」は、大規模な分散アプリケーション サービスの継続的なアップグレード、エンタープライズ レベルのアプリケーションのシームレスなアップグレード、オンライン サービスの中断のない更新などのシナリオに適用できます。中断ゼロに対するユーザーの期待に応え、ユーザー エクスペリエンスを向上させるだけでなく、システムの信頼性を確保し、アップグレード プロセス中のビジネスへの影響を軽減し、企業の発展を促進します。

おすすめ

転載: blog.csdn.net/qq_42963448/article/details/131938381