マイクロサービスアーキテクチャを選択するにはどうすればよいでしょうか?

アプリケーションの近代化のトレンドの中で、マイクロサービスは避けられない選択肢です

デジタル経済の継続的な発展に伴い、企業は新しい時代においてより多様化かつ機敏な IT 需要に直面しています。

ユーザー行動の変化: ビジネスアプリケーションへのユーザーアクセスは予測不可能であり、突然のアクセスの増加や、一時的なホットイベントやプロモーションなどの制御できないビジネスピークが発生します。
ビジネスモデルの変化: すべてのビジネスアクセスは、Web、モバイルアプリ、WeChat アプレットなどのインターネットチャネルを介して行われます。
業務システム開発の変化：従来のように半年や1年単位でのアプリケーション計画はなくなりました。要件はいつでも変更される可能性があり、2 週間ごとの反復が標準になっています。ビジネスアプリケーションの配信サイクルは短く、品質要件は高くなります。
運用および保守モデルの変更: 24 時間 365 日のオンコール、オンラインアップグレード、迅速な対応の要件。異なるチーム、特にアウトソーシングされたチームは異なるテクノロジースタックを使用するため、均一に管理することはできません。

したがって、企業がマイクロサービスアーキテクチャを採用する必要があるかどうかを評価する際には、データ量とビジネスの複雑さ、チームの規模、ビジネストラフィックの変化への対応、十分なフォールトトレランスと災害復旧の必要性、機能の重複とエラーコストという 5 つの重要な条件が検討されることが多いです。

デジタル競争が激化する中、企業は市場の変化をより迅速に受け入れ、新しいユーザーのニーズにいつでも対応し、競合他社よりも早く製品を市場に投入する必要があります。

マイクロサービスは、企業のアジャイルイノベーション能力の向上を加速する重要なツールとして、企業がアプリケーションを迅速に独自に更新および展開し、市場の変化に迅速に対応するのに役立ちます。これらは、企業がアプリケーションの近代化を加速するために徐々に不可欠な選択肢になりつつあります。

マイクロサービスアーキテクチャを選択するにはどうすればよいでしょうか?

ダボ

Dubbo は、アプリケーションが高性能 RPC を通じてサービス出力および入力機能を実装し、Spring フレームワークとシームレスに統合できるようにする、比較的初期のマイクロサービスアーキテクチャです。

利点は、RPC の長い接続 + NIO であり、パフォーマンスが高くなります。しかし、この議定書の制限により、生態系の発展と互換性が制限されることになります。

春の雲

Spring Cloud は、Spring Boot に基づいてマイクロサービスを実装するための完全なフレームワークであり、マイクロサービス開発に必要な構成管理、サービス検出、サーキットブレーカー、インテリジェントルーティング、マイクロエージェント、制御バスなどのコンポーネントを提供します。 Spring Cloud には多くのサブフレームワークが含まれており、そのうちの 1 つが Spring Cloud Netflix です。これは Netflix によって開発され、後に Spring Cloud ファミリーに統合されました。提供される主なモジュールには、サービス検出、サーキットブレーカーと監視、インテリジェントルーティング、クライアント負荷分散などがあります。

Spring Cloud には、より成熟した Spring コミュニティエコシステムと、より成熟したエンタープライズアプリケーションケースがあります。しかし、言語間プラットフォームの問題や、コードに大きく影響するマイクロサービスガバナンスなど、特定の欠点もあります。

イスティオ

Istio は、現在のサービスメッシュ形式で人気のある実装ソリューションです。 K8s と深く統合することで、サービスガバナンスをより迅速かつ便利に実現できます。 Istio を使用すると、サービスコードを変更することなく、負荷分散、サービス間認証、監視などを提供するサービスネットワークを簡単に作成できます。環境全体に専用のサイドカープロキシサービスを展開することで、マイクロサービス間のすべてのネットワーク通信が傍受され、構成と管理全体が Istio コントロールパネルを通じて実行されます。

新世代のマイクロサービスアーキテクチャとして、マイクロサービスのガバナンスと開発はより徹底的に分離されており、より幅広いシナリオに適応できます。多くの企業が Spring Cloud から Service Mesh に徐々に移行しています。しかし、この技術が比較的新しいため、企業は独自の技術を開発し、従来のIT運用と保守/開発の障壁を打ち破り、専門の技術ベンダーの導入を検討してこの問題を完璧に解決するために、一定の学習コストを必要とします。

上の図は、Istio の基本的な動作原理を示しています。

ユーザーが Kubernetes に新しい構成を送信すると、まず Galley によって Kubernetes に登録された webhook がトリガーされます。図のステップ 1 に示すように、Webhook は構成が正当かどうかを確認します。

構成が検証に合格しなかった場合、Kubernetes はユーザーが送信した構成を拒否し、対応するエラーメッセージを表示します。手順 2 に示すように。

構成が検証に合格すると、Galley は Kubernetes 通知メカニズムを通じて構成変更情報を取得します。

Galley は、変更された構成/サービス情報を MCP 形式に変換し、手順 4 に示すように、MCP プロトコルを通じてパイロットにプッシュします。

最後のステップでは、パイロットは xDS プロトコルを介して変更された構成をデータプレーンにプッシュします。

上記は現在一般的なマイクロサービスアーキテクチャですが、実際の変革時に企業は何をすべきでしょうか?おすすめ:

さまざまな種類のアプリケーションは、マイクロサービス機能を通じて最新のアプリケーションに進化できます。
従来のアプリケーションには安全な変換パスを提供する必要がある
SpringCloud アプリケーションには、クラウドネイティブで大規模な適応を必要としない変換パスを提供する必要があります。

マイクロサービスアーキテクチャを設計するにはどうすればいいですか?

まず、マイクロサービスの定義から言えば、マイクロサービスは連携して動作する独立した小さなサービス単位です。これらは同期的および非同期的に呼び出すことができ、独立して分割、展開、アップグレードできます。バックエンドミドルウェア、ストレージリソース、データベースなども独立しています。ベストプラクティスは、各マイクロサービスに独自のデータベースを持たせ、マイクロサービスアプリケーションの分離を真に実現することです。

次に、マイクロサービスの重要な基本理論であり、企業がマイクロサービスを実装する際に従う必要がある主要な原則であるコンウェイの法則を見てみましょう。

組織形態はシステム設計に相当します。システムを設計する組織は、組織内および組織間のコミュニケーション構造と同等の設計を作成します。

第一法則:コミュニケーションが設計を決定します (組織のコミュニケーション方法は、システム設計を通じて表現されます)。

人と人との間のコミュニケーションは非常に複雑であり、人のコミュニケーションエネルギーには限界があるため、問題が複雑すぎて解決に多くの人手が必要となる場合は、組織を分割してコミュニケーションの効率管理を実現する必要があります。チーム内で頻繁かつ詳細なコミュニケーションを実施します。チーム外の人に対しては、インターフェースと契約を定義し、粗粒度の通信のみを実行します。これにより、通信コストを削減できるだけでなく、高い凝集性と低い結合性の原則にも準拠できます。

第二法則:何かを正しく行うには時間が足りないが、やり直すには十分な時間がある。

複雑なシステムは、フォールトトレランスと回復力を通じて継続的に最適化する必要があります。大規模で包括的な設計やアーキテクチャを期待しないでください。優れたアーキテクチャとデザインは、段階的な反復を通じて開発されます。したがって、企業は変化を受け入れ、現在の問題を解決し、小さな目標を一つずつ達成する必要があります。

第三法則:システムの線形グラフからその設計組織の線形グラフへの準同型性が存在する。

システムに望む種類のチームを構築し、その逆も同様です。

第 4 法則:大規模システムの構造は、小規模システムよりも質的に開発中に崩壊する傾向があります。

大規模な組織は、コミュニケーションコストや管理上の問題により、常に小規模なチーム (ピザ 2 枚チーム) に分割されます。

具体的には、企業はマイクロサービスアーキテクチャを変革する際に次の標準に従うことができます。