【マイクロサービス】マイクロサービスアーキテクチャの設計がわかる図

1 はじめに

現在、マイクロサービス アーキテクチャは多くの企業で導入されていますが、次の図はマイクロサービス アーキテクチャの設計で一般的に使用されるコンポーネントを簡単にまとめたものです。マイクロサービスが使用されてから数年が経っているとは言えません。その結果、マイクロサービス アーキテクチャに対する全体的な理解が得られていません。レンガの動かし方だけを知っているプログラマーは、優れたプログラマーではありません。

ここに画像の説明を挿入

2. 交通入口Nginx

上の図からわかるように、アーキテクチャ全体のトラフィック入口としての Nginx は、リクエストのルーティングと転送負荷分散動的および静的分離などの機能を担う外部ゲートウェイとして理解できます。Nginx はコア エントリ ポイントとしてマルチノード展開を採用し、同時にkeepalivedプラットフォーム全体の高可用性を確保することで高可用性を実現する必要があります。

3. ゲートウェイ

Gateway は、Nginx の背後にあるもう 1 つのコア コンポーネントです。リクエストの認証ルーティング転送プロトコル変換トラフィック監視などの一連の機能を担います。上図のゲートウェイはSpring Cloud Gatewayを利用してビジネスゲートウェイの機能を実現しています。ゲートウェイの選択では、他のオプションもあります。 Zuul1、Zuul2、Kong など、これらのソリューションにはそれぞれ利点と制限があるため、それぞれの特性に応じてどれを選択するかを選択できます。

上図では Spring Cloud Gateway 配下に JWT と OAuth2 が存在しますが、実際にはこの 2 つはトークンベースの認証と認証であり、一般的なインターネット プロジェクトでは、ログイン モジュールは OAuth2 を使用した認可ログインである WeChat または QQ ログインをサポートしています。

4. ビジネスコンポーネント

上記のアーキテクチャ図からわかるように、ゲートウェイ以降はビジネス コンポーネントであり、電子商取引プラットフォームで一般的なアカウントサービス注文サービス請求書サービスレジサービスなどの分割後のマイクロサービスとして理解できます。サービス コンポーネントは Feign を通じて呼び出されhttp、Feign はリボンを統合してクライアント側の負荷分散を実現します。特定のサービス ドメイン分割とサービス境界コンテキストの設定は追加の知識であり、サービス分割を適切に実行したい場合は、DDD ドメイン駆動設計について詳しく学ぶことができます。

5. サービス登録センター

DubboをベースとしたSOAであっても、Spring Cloud Splittingをベースとしたマイクロサービスアーキテクチャであってもサービスレジストリが必要となり、サービスコンポーネントを全てレジストリに登録することで動的なサービス呼び出しを実現します。登録センター機能を実装できる一般的なものは、Zookeeper、Eureka、Nacos です。Dubbo では Zookeeper が広く使われていますが、現在同社のサービスマイクロサービスアーキテクチャは Eureka をベースにしており、Eureka は現在メンテナンスされていないようです。一般に、Nacos を直接統合するには、新しいプラットフォームを推奨します。Nacos は、登録センターとしてだけでなく、分散構成センターとしても使用でき、Sping Cloud Config よりも優れています。

6. キャッシュと分散ロック

図の左下隅に Redis コンポーネントが表示されます。Redis をキャッシュとして使用し、クエリが遅く使用率が高いホット データをキャッシュすることで、インターフェイスの応答時間を迅速に改善できます。同時に、マイクロサービスにおける Redis の主な使用シナリオの 1 つは分散ロックであり、従来の同期ロックや表示ロックでは明らかに分散同時実行の問題を解決できません。

Redis の高可用性を確保するために、3 つの Redis ノード ( 1 つのマスターと 2 つのスレーブ) の代わりにセンチネル デプロイメントを使用でき、フェイルオーバーを実現して単一点の問題を回避するために 3 つのセンチネル ノードが同時にデプロイされます。 Redis に保存されるデータの量は大きく、単一ノード Redis のパフォーマンスのボトルネックを解消するために、Redis クラスター モードを使用して分散ストレージを実装することもできます。

7. データ永続層

単一サービス、マイクロサービスを問わず、データ永続化層は必要であり、DBとしてはインターネットプロジェクトでよく使われるMySQLを選択し、サービスの読み書き効率と高可用性を確保するため、マスターサーバーを使用しています。スレーブ分離モードにより、読み取りと書き込みを同時に分離し、MySQL の読み取りと書き込みのパフォーマンスを確保します。

ビジネス量の増加に伴い、単一テーブルのデータ量がパフォーマンスのボトルネックに達すると、サブデータベースとサブテーブルを使用してデータベーステーブルを水平方向と垂直方向に分割する必要があります。合理的な分割方法とテクノロジの選択方法は次のとおりです。プロジェクトの既存のテーブル構造設計と密接に関係している 後の拡張性を考慮する必要がある 短期間での解体はできない 分割サーバーがデプロイされている もちろん、一般企業のデータ規模ではそこまでの規模には達しません。

8. 構造化されたデータストレージ

MySQL はリレーショナル データの保存に優れています。JSON 文字列の保存など、プロジェクトに構造化データを保存する必要があるシナリオがあります。そのようなシナリオの保存に MySQL を使用するのは明らかに不適切です。ストレージにはElasticsearchかMongoDBを使用するのが一般的ですが、業務上検索機能が必要な場合にはElasticsearchを推奨します。Elasticsearch は DSL をサポートしており、比較的豊富なクエリおよび検索機能を備えており、GIS 空間検索機能も実現できます。

9. メッセージミドルウェア

前述したように、マイクロサービス アーキテクチャでは、サービス間の同期呼び出しは Feign によって実現され、サービス間の非同期デカップリングは MQ によって実現する必要があります。複数のスレッドを介して非同期呼び出しを実装できますが、そのような非同期呼び出しは永続性をサポートしておらず、メッセージ損失が発生する可能性があるため、通常は RabbitMQ または RocketMQ が統合されます。

10. ログ収集

マイクロサービス アーキテクチャでは、たとえばコンポーネントを通じて、注文サービスがマルチノード分散方式でデプロイされ、各ノードのログがノード上にローカルに保存されます。各ノードにログインして、対応するログ情報を見つけますか? このような閲覧記録は絶対に許せません。したがって、ELK はログ収集と視覚的な表示クエリのために導入されるのが一般的です。

  • Logstashはログ収集に使用されます。通常、Logstash の前に Filebeat が追加されます。Filebeat がログを収集し、Logstash がデータ変換を行います。
  • Elasticsearch はデータを保存し、Kibana で簡単に取得できるようにインデックス データを生成します。
  • Kibana はデータ表示機能とクエリ検索機能を備えており、キーワード検索により目的のログ情報を素早く検索できます。

11. タスクスケジューリングセンター

プロジェクトではタイミング機能がよく使われますが、単体アプリケーションの場合はSpring付属のScheduleやQuartzを利用することができますが、分散アプリケーションの場合はQuartzなどの分散タイマーを組み込む必要があります(Quartzは連携します)。データベース テーブル (分散タイミング タスク)、Elastic-Job、XXL-JOB などもサポートします。

  • Elastic-Job は、Dangdang.com が Quartz をベースに開発した柔軟な分散タスク スケジューリング システムであり、豊富で強力な機能を備えており、Zookeeper を使用して分散調整、高可用性、タスクの断片化を実現します。Elastic-Job は、Dangdang.com によってオープンソース化されている分散スケジューリング ソリューションです。2 つの独立したサブプロジェクトと で構成されていますElastic-Job-Lite。ElasticElastic-Job-Cloud-Job を使用すると、分散タスク スケジューリングを迅速に実現できます。

  • XXL-JOB分散タスク スケジューリング プラットフォーム(XXL は作者 Xu Xueli の名前のピンイン表記のイニシャルです) であり、その中心的な設計目標は、迅速な開発、容易な学習、軽量、容易な拡張です。派遣動作は「派遣センター」というパブリックプラットフォームに抽象化されており、プラットフォーム自体はビジネスロジックを引き受けず、「派遣センター」が派遣依頼の開始を担当します。タスクは分散した JobHandler に抽象化され、「Executor」によって管理されます。Executor は、スケジュール要求を受信し、対応する JobHandler でビジネス ロジックを実行します。したがって、「スケジューリング」と「タスク」の 2 つの部分を相互に分離して、システム全体の安定性とスケーラビリティを向上させることができます。

12. 分散オブジェクトストレージ

プロジェクトには多くの場合、写真、オーディオ、ビデオなどのファイルのアップロード機能があります。分散アーキテクチャでは、ノード サーバーにファイルを保存することは当然不可能であるため、現時点では分散ファイル ストレージを導入する必要があります。一般的なソリューションには、MinIO、Ali の OSS (有料)、Ali FastDFS などが含まれます。

  • MinIO は、Go 言語に基づいて開発された高性能の分散オブジェクト ストレージ システムです。クライアントは Java、Net、Python、Javacript、Golang 言語をサポートします。

  • FastDFSは、オープンソースの軽量分散ファイル システムであり、ファイルを管理します。その機能には、ファイル ストレージ、ファイル同期、ファイル アクセス (ファイル アップロード、ファイル ダウンロード) などが含まれており、大容量ストレージとストレージの問題を解決します。これは、フォト アルバム Web サイトやビデオ Web サイトなど、キャリアとしてファイルを使用するオンライン サービスに特に適しています。

おすすめ

転載: blog.csdn.net/be_racle/article/details/132639028