マイクロサービスアーキテクチャ設計を理解するための図

序文

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

 トラフィックエントリーNginx

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

ゲートウェイ

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

上図では Spring Cloud Gateway 配下に jwt と OAuth2 がありますが、実際にはこの 2 つはトークンベースの認証と認証です 一般的なインターネット プロジェクトでは、ログイン モジュールは OAuth2 を使用した承認ログインである WeChat または qq ログインをサポートしています。Oauth2 の詳細について詳しく知りたい場合は、以前のOauth2.0 クライアント サーバーの例などの一連の記事を参照してください。

ビジネスコンポーネント

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

サービスレジストリ

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

キャッシュと分散ロック

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

Redis の高可用性を確保するために、1 つのマスターと 2 つのスレーブの 3 つの Redis ノードの代わりにセンチネル デプロイメントを使用でき、フェイルオーバーを実現して単一点の問題を回避するために 3 つのセンチネル ノードが同時にデプロイされます。 Redis に保存されるデータの量は大きく、単一ノード Redis のパフォーマンスのボトルネックを解消するために、Redis クラスター モードを使用して分散ストレージを実装することもできます。Redis Sentinel の詳細については、「Redis Sentinel アーキテクチャ原則の詳細説明 (1)」など、これまでの連載記事を参照してください。

データ永続化レイヤー

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

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

構造化データストレージ

上記の mysql ストレージ データはすべて非構造化データ ストレージです。私たちのプロジェクトでは、JSON 文字列の保存など、構造化データを保存する必要がよくあります。このシナリオでは、mysql を介してデータを保存するのは明らかに不適切です。

ストレージにはElasticsearchまたはMangoDBを使用することが一般的ですが、ビジネスで検索機能が必要な場合はElasticsearchを使用することをお勧めします。Elasticsearch は DSL をサポートしており、比較的豊富なクエリおよび検索機能を備えており、GIS 空間検索機能も実現できます。

メッセージミドルウェア

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

ログ収集

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

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

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

タイミング関数はプロジェクトでよく使用されます。単一アプリケーションでは、sping に付属するスケジュールを使用するか、Quartz を使用できます。分散アプリケーションでは、Quartz などの分散タイマーを統合する必要があります (Quartz はデータベース テーブルと連携し、分散もサポートしています)タイミング タスク)、Elastic-Job、XXL-JOB など。

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

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

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

プロジェクトには多くの場合、写真、オーディオ、ビデオなどのファイルのアップロード機能があります。分散アーキテクチャでは、ノード サーバーにファイルを保存することは当然不可能であるため、現時点では分散ファイル ストレージを導入する必要があります。一般的なソリューションには、MinIo、Ali の OSS (有料)、Ali FastDFS などが含まれます。
MinIO は、Go 言語に基づいて開発された高性能の分散オブジェクト ストレージ システムです。クライアントは Java、Net、Python、Javacript、Golang 言語をサポートします。

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