マイクロサービス アーキテクチャの進化
モノリシック モードのアプリケーションには通常、異なるサブモジュールが含まれるアプリ サーバーがあり、それぞれが同じアプリケーション パッケージに記述されており、特に初期のコードが混在している場合、モジュール間の境界が特に明確に設計されていない場合があります。一緒に、それはお互いを呼び合うことを意味します。
この比較的重いモノリシック アーキテクチャでも、冗長展開と負荷分散を通じてアプリケーションの高可用性が保証されます。
モノリシック アーキテクチャは、複雑なビジネス ニーズにはもう適していません。ビジネス アーキテクチャにいくつかの調整を加え、サブシステムに 1 つずつ置き換えます。これらのサブシステムには、独立した展開ファイルと独立したライフ サイクルがあります。各サブシステムの高可用性の要件も異なり、サブシステムとサブシステムはネットワーク呼び出しを通じてビジネス全体を完了します。
単一インスタンスと単一プロセスのモデルなど、元のモノリシック システムは、数百のサブサービスになり、統合された展開ビューを形成します。
このとき、人間の身体に直接行って制御すると、コストが非常に高く、エラーの確率が非常に高くなります。このように、アプリケーション構成とサービス検出機能を完了するには、自動化された方法に依存する必要があります。
モノリシックシステムからマイクロサービスシステムへの進化
オンライン ストアがあり、販売部門には、物を販売するためのポータルを提供する販売モジュールがあるとします。オンラインストアで販売する商品は保管する必要があり、在庫を管理するための倉庫管理システムがあります。課金や割引の需要もあります。単一アプリケーションの場合は、単一アプリケーションの機能に提供されます。
同じ手順ですので、アドレスを教えていただければ、すべてのサービスにアクセスできます。
マイクロサービスアーキテクチャの進化
モノリシック アプリケーションをマイクロサービス アーキテクチャに分割するには、アプリケーション プロセスのさまざまな機能がさまざまなサブシステムに分割され、各サブシステムが独自の責任を負います。
販売部門はフロントエンド ビジネスをサポートするため、その可用性要件は高くなり、サポートする同時リクエストも多くなります。ここで、より多くのインスタンスをデプロイし、より多くの同時負荷サポートを提供し、より高い可用性を提供できます。
ネットワークは、サービスとサービス間の呼び出しを含め、システムごとにオープンする必要があります。この複雑な結合を解決するために、API ゲートウェイを使用できます。クラスター内には非常に多くのサービスが存在する可能性があり、これらのサービスは同じドメイン名を通じて公開される可能性があるため、さまざまな顧客リクエストを受け入れ、ゲートウェイを通じてさまざまなサービスに転送する API ゲートウェイが必要になります。
サービス間の呼び出しにはサービス検出メカニズムが必要であり、次にサービス レジストリが必要です。各サービスが起動した後、サービス自体を登録する必要があり、別の更新では私が生きていることが示されます。彼は自分自身の健康状態を登録する必要があり、他の人がサービス呼び出しを行うと、このサービスの背後でどの実サーバーが実行されているかを知ることができます。
ここにはサービス登録センターがあり、サービスセンターが登録するアドレス情報は、ポイントツーポイントで登録する場合、各ノードの健全性状態をリアルタイムに更新する必要がある。もう 1 つは、集中型負荷分散または分散型負荷分散を通じて、統合エントランスの仮想 IP がバインドされる方法です。
典型的なマイクロサービス ビジネス シナリオ
倉庫と会計の間には固定の呼び出し関係がある可能性があります。現在のシステム アーキテクチャは障害を想定して設計されています。システムを設計するときは、どのコンポーネントも信頼できないものであると想定する必要があります。会計では 2 つの障害が考えられます。おそらく、1 つは障害です。エラー コードが返される場合と、応答しない場合があり、応答がない場合、多くのアプリケーションはビジネス コードで 50x を返します。アニメーションが一時停止されている場合、ウェアハウスは会計に問題があることを認識せず、リクエストを会計に転送して応答を待ちます。アプリケーションが適切に作成されておらず、十分に堅牢でない場合は、無期限に待機します。しかし、会計は正常であると認識します。会計はエラー メッセージを返さないため、営業は引き続きリクエストを転送します。
そうなると、倉庫が大量の販売リクエストを受け取ることになります。戻り値を取得するためにこれらのリクエストを会計に転送する効果的な方法がなくなり、倉庫上のリクエストのバックログがますます増え、倉庫がまた故障もございます。
ウェアハウスの出現後も同様の問題が発生し、各コンポーネントに影響を及ぼし、それぞれのローカルな障害がグローバルに拡大する可能性があります。
多くの場合、ウェアハウスには融合機能が必要ですが、その 1 つはエラー コードを返すため、このエラー コードを正しく処理できなければなりません。
また、エラーコードを返さない場合は、少なくとも同時リクエストの数を把握し、上記の同時リクエストを制限する必要があり、同時リクエストが多い場合は融合やサービスの縮退を行う必要があり、営業担当者に、多数のリクエストが送信されたが応答がなかったことを伝えます。その場合、これ以上のリクエストを処理する方法はありません。
これはマイクロサービス アーキテクチャ システムであるため、各サービスはサービス レジストリに登録する責任があり、各サービスの下向き呼び出しには負荷分散機能が必要です。
HTTP サービスが提供される場合、検証は実行されません。この場合、このサービスは多くの悪意のあるリクエストまたは悪意のないリクエストの影響を受けるため、リクエストの有効性や頻度などを制御できなくなります。
サービスが削除機能を提供しており、検証と認証が行われていない場合、この保護は問題外です。
企業全体に、認証と認証のための一連の中央サービスが存在します。すべてのアプリケーションは、このサービスに接続されます。サービス間の呼び出しは、信頼できるアクセス許可に基づいている必要があります。あなたが誰であるかを知りたいのですが、このアクセス許可を持っている必要があります。私に電話することができます。通常、ここには認証サーバーがあります。
各サービスは認証サーバーと通信して、資格情報を承認する機能を取得します。
より完全なサービス アーキテクチャ
クライアントがリクエストを開始し、サーバーがこれらのリクエストに応答し、サーバーにはビジネス ロジックとプラットフォーム機能があります。
その後、完全なマイクロサービス フレームワークがビジネス機能とプラットフォーム機能を全体として統合します。
システム境界
プラットフォーム機能とビジネス機能をどのように整理するか。
ビジネスロジックとは何ですか? 販売倉庫会計割引があります。これらは実際にはビジネス関連のロジック コードです。
これらはビジネスです。
残りは、ビジネスとは関係のない、認証、サーキット ブレーク、ロード バランシング、プロトコルに関するものです。これらはプラットフォーム側の追加機能です。企業と企業の間の通話、どのような合意に基づいて、どのようなアピールを行うか、これらはすべてプラットフォーム側で統一されています。
この種のアーキテクチャは通常 2 つのタイプに分けられます。1 つは Java プログラマーによく知られている Spring Cloud で、このプロジェクトには Netflix 社のオープン ソース ソフトウェアである netfix が統合されています。これらのオープン ソース ソフトウェアには、サービス レジストリなどの eurka や、クライアントの負荷分散用のリボンが含まれます。
これらはビジネス コードに多くのオープン ソース ライブラリを埋め込んでおり、ビジネス コードをプラットフォーム側の機能に使用する場合は、ビジネス コードとプラットフォームの機能を深く統合する必要があります。次に、変更を加えたい場合は、デプロイされたパッケージを実際に移動する必要があります。たとえば、サービス検出機能や負荷分散機能のバージョンをアップグレードしたい場合は、war パッケージ全体をアップグレードする必要があります。
このようにして、ビジネス側とプラットフォームは密接な関係になります。
ビジネスをビジネスに属させ、プラットフォームをプラットフォームに属するようにする、より洗練された、より合理的な方法はあるのでしょうか。ビジネスが直面している基本プラットフォーム側の要件を簡素化できますか。
認証、サービス検出を行います。これらの融合機能はプラットフォーム側に与えられるため、ビジネス側は実際にビジネスのことだけを気にするようになります。このモードはサービスグリッドが推奨する機能であり、istioが追求した結果です。
