この記事では、エンタープライズ レベルの最新のアプリケーション構築にインスピレーションを与えることを期待して、エンタープライズ レベルのマイクロサービス ガバナンスと開発の主要な概念と選択ガイドラインを体系的に理解する方法について説明します。
アプリケーションのモダナイゼーションのトレンドの下では、マイクロサービスは避けられない選択です
デジタル経済の継続的な発展に伴い、企業は新しい時代のより多様で機敏な IT 要件に直面しています。
· ユーザーの行動の変化:ビジネス アプリケーションへのユーザー アクセスは予測不能であり、突然アクセスが増加し、一時的なホット イベントやプロモーション期間などの制御不能なビジネス ピーク期間が発生します。
· ビジネス モデルの変化:すべてのビジネス アクセスは、Web、モバイル アプリ、WeChat アプレットなどを含むインターネット チャネルを通じて行われます。
· 業務システム開発の変化:半年や 1 年前にアプリケーションを計画するのではなく、需要が常に変化し、2 週間ごとのイテレーションが標準になっています。ビジネス アプリケーションには、短いリード タイムと高品質の要件があります。
· 運用および保守モデルの変更: 24 時間年中無休のオンデューティ、オンライン アップグレード、および迅速な対応が必要である. 異なるチーム、特にアウトソーシング チームは異なるテクノロジ スタックを使用しており、一様に管理および制御することはできない.
したがって、企業がマイクロサービス アーキテクチャを採用する必要があるかどうかを評価する際には、多くの場合、次の 5 つの重要な条件を調べます。データ量とビジネスの複雑さ、チームの規模、ビジネス トラフィックの変化への対応、十分なフォールト トレランスが必要かどうか、機能の繰り返しとエラーのコストです。
ますます激化するデジタル競争の下で、企業は市場の変化をより迅速に受け入れ、新しいユーザーのニーズにいつでも対応し、競合他社よりも早く製品を市場に投入する必要があります。
マイクロサービスは、企業がアジャイルイノベーション能力を加速するための重要な出発点として、企業がアプリケーションの独立した更新と展開を迅速に実装し、市場の変化に迅速に対応するのに役立ちます.企業がアプリケーションのモダナイゼーションを加速するための必然的な選択になりました.
マイクロサービス アーキテクチャの選択方法
· ダボ
Dubbo は比較的初期のマイクロサービス アーキテクチャであり、アプリケーションが高性能 RPC を介してサービスの出力および入力機能を実現できるようにし、Spring フレームワークとシームレスに統合します。
RPC の長い接続 + NIO のほうがパフォーマンスが高いという利点がありますが、プロトコルの制限により、生態系の発展と互換性が制限されます。
・春の雲
Spring Cloud は、Spring Boot に基づいてマイクロサービスを実装するための一連のフレームワークで、マイクロサービスの開発に必要な構成管理、サービス ディスカバリ、サーキット ブレーカー、インテリジェント ルーティング、マイクロエージェント、制御バスなどのコンポーネントを提供します。Spring Cloud には多くのサブフレームワークが含まれています. その中で, Spring Cloud Netflix はフレームワークの 1 つです. Netflix によって開発され、後に Spring Cloud ファミリーに組み込まれました. 提供する主なモジュールには、サービス検出、サーキットブレーカーが含まれます監視、インテリジェント ルーティング、クライアント ロード バランシングなど。
Spring Cloud には、より成熟した Spring コミュニティ エコロジーとより成熟したエンタープライズ アプリケーション ケースがありますが、クロス言語プラットフォームの問題や、マイクロサービス ガバナンスがコードに侵入するなど、特定の欠陥もあります。
・それに
Istio は、現在の Service Mesh 形式で比較的人気のある実装ソリューションであり、K8s と深く統合して、サービス ガバナンスをより迅速かつ便利に実現できます。Istio は、サービス コードを変更することなく、ロード バランシング、サービス間の認証、モニタリングなどを提供するサービスのネットワークを作成する簡単な方法を提供します。環境全体に専用のサイドカー プロキシ サービスをデプロイして、マイクロサービス間のすべてのネットワーク通信をインターセプトすることにより、構成と管理全体が Istio コントロール パネルから行われます。
新世代のマイクロサービス アーキテクチャとして, そのマイクロサービス ガバナンスと開発はより完全に分離され、より広い範囲のシナリオに適応します. 多くの企業はSpring CloudからService Meshに徐々に移行しています.独自に開発するには一定の学習コストが必要であり、従来の IT 運用と保守/開発の壁を破り、専門の技術ベンダーの導入を検討することで、この問題を完全に解決できます。
上の図は、Istio の基本的な動作原理を示しています。
1. ユーザーが新しい構成を Kubernetes に送信すると、図のステップ 1 に示すように、Galley によって kubernetes に登録された webhook が最初にトリガーされ、webhook は構成が適切かどうかをチェックします。
2. 構成が検証に合格しない場合、kubernetes はユーザーが送信した構成を拒否し、対応するエラー メッセージを表示します。図に示すように、ステップ 2。
3. 構成が検証に合格すると、ギャレーは kubernetes の通知メカニズムを介して構成変更情報を取得します。
4. ステップ 4 に示すように、Galley は変更された構成/サービス情報を MCP 形式に変換し、MCP プロトコルを介してパイロットにプッシュします。
5. 最後のステップで、パイロットは変更された構成を xDS プロトコルを介してデータ プレーンにプッシュします。
以上が現在の一般的なマイクロサービスのアーキテクチャですが、実際に変革する際に企業はどうすればよいのでしょうか。私たちは提案します:
· さまざまなタイプのアプリケーションが、マイクロサービス機能を通じて最新のアプリケーションに進化できます。
従来のアプリケーションに安定した変換パスを提供する必要がある
大規模な適応を必要としない Spring Cloud アプリケーション用のクラウドネイティブ変換パスを提供する必要がある。
マイクロサービス アーキテクチャの設計方法
まず、マイクロサービスの定義から、マイクロサービスとは、相互に連携する独立した小さなサービス単位であり、同期的および非同期的に呼び出したり、独立して分割したり、独立してデプロイしたり、独立してアップグレードしたりできるバックエンド ミドルウェア、ストレージ リソース、データベースなどです。 . も独立していますが、ベスト プラクティスは、各マイクロサービスが独自のデータベースを持ち、マイクロサービス アプリケーションの分離を真に実現することです。
次に、マイクロサービスの必要な基本理論であり、企業がマイクロサービスで従う必要がある主要な原則であるコンウェイの法則を見てみましょう。
組織形態はシステム設計に相当します。システムを設計する組織は、組織内および組織間の通信構造と同等の設計を作成します。
第 1 の法則: コミュニケーションが設計を指示します (組織のコミュニケーションはシステム設計によって表現されます)。
人と人とのコミュニケーションは非常に複雑で、一人のコミュニケーションエネルギーは限られているため、問題が複雑すぎて多くの人で解決する必要がある場合は、組織を分割してコミュニケーション効率管理を実現する必要があります。チーム内で頻繁に、きめの細かいコミュニケーションをとります。チームの外部に対しては、インターフェイスとコントラクトを定義し、粗粒度のコミュニケーションのみを行います。これにより、通信コストを削減でき、高凝集低結合の原則にも準拠できます。
第 2 法則: 何かを正しく行うための十分な時間はありませんが、それをやり直すための十分な時間は常にあります (時間がいくらあっても、1 つのことを完全に行うことはできませんが、1 つのことを完了する時間は常にあります)。 .
複雑なシステムは、フォールト トレラントで柔軟な方法で継続的に最適化する必要があります。大規模で包括的な設計やアーキテクチャを期待しないでください。優れたアーキテクチャと設計はゆっくりと反復されます。したがって、企業は変化を受け入れ、現状を解決し、最初に小さな目標を達成する必要があります。
第 3 法則: システムの線形グラフからその設計組織の線形グラフへの準同型性があります (線形システムと線形組織構造の間には潜在的な異質性と準同型性があります)。
どんなシステムが欲しいか、どんなチームを作るか、その逆もまた然り。
第 4 法則: 大規模なシステムの構造は、開発中に崩壊する傾向があり、小規模なシステムよりも質的に崩壊する傾向があります (大規模なシステム組織は、常に小規模なシステムよりも崩壊する傾向があります)。
大規模な組織は、通信コスト/管理上の問題により、常に小さなチーム (2 つのピザ チーム) に分割されます。
具体的には、マイクロサービス アーキテクチャを変換する際に、企業は次の標準に従うことができます。
· 分散サービスで構成されるシステム。
• テクノロジーではなくビジネスで組織を分割します。
· プロジェクトではなく、生きた製品を作る。
· 分散化。
自動化された 運用と保守 (DevOps)。
· フォールト トレランス。
• 急速な進化。
同時に、自社の組織体制や経営状況に応じて、的を絞った企画・設計を行います。
エンタープライズ レベルのマイクロサービス トランスフォーメーションの要件がある場合は、お問い合わせください。アプリケーションのモダナイゼーションのベスト プラクティスを一緒に探ります。
前: エンタープライズ アプリケーションのモダナイゼーションのための実用的なチュートリアル | アプリケーションを迅速、正確、容赦なくコンテナーに変換する方法
次へ: エンタープライズ アプリケーションのモダナイゼーションに関する実践的なコース | IT アーキテクトのための必読の DevOps アクション ガイド