分散型アーキテクチャとマイクロサービスアーキテクチャを3分で理解する

1. マイクロサービス入門

1. マイクロサービスの誕生

マイクロサービスは分割統治の考え方に基づいて進化しました。これまで、従来の大規模で包括的なシステムでは、インターネットの発展に伴う市場の技術需要を満たすことが困難になっていました。そのため、単一アーキテクチャから分散アーキテクチャへ、分散アーキテクチャから SOA アーキテクチャへと進化してきました。マイクロサービス アーキテクチャが誕生するまで、サービスは継続的に分割、分解され、粒度はどんどん細かくなっていきました。

マイクロサービス アーキテクチャは、単一のアプリケーションを一連の小さなサービスに分割し、それらが相互に調整および連携してユーザーに究極の価値を提供することを提唱するアーキテクチャ パターンです。

各サービスは独自の独立したプロセスで実行され、軽量の通信メカニズム (通常は HTTP ベースの RESTful API) を使用して相互に通信します。各サービスは特定のビジネスを中心に構築されており、本番環境、本番に近い環境などに個別に展開できます。また、統一された集中型のサービス管理メカニズムは可能な限り避ける必要があります。特定のサービスについては、ビジネスコンテキストに応じて適切な言語とツールを選択して構築する必要があります。

2. マイクロサービスアーキテクチャとSOAアーキテクチャの違い

マイクロサービスは真に分散され、非中央集権化されています。ルーティング、メッセージ解析などのすべての「思考」ロジックをサービス内に配置して、統合された ESB を削除し、サービス間の通信を容易にすることは、SOA よりも徹底した分割です。

マイクロサービス アーキテクチャによって強調される重要なポイントは、ビジネス システムが完全にコンポーネント化され、サービス指向である必要があるということです。元の単一のビジネス システムは、独立して開発、設計、実行、保守できる複数の小さなアプリケーションに分割されます。これらの小さなアプリケーションは、サービスを通じて相互に対話し、統合されます。

3. マイクロサービスアーキテクチャが引き起こす問題

ビジネス データ全体がさまざまなサブサービスに分散されるため、最も明白な 2 つの問題が発生します。

• ビジネス管理システムは、ページングクエリ、複数条件クエリなどのデータ整合性をクエリします。データが断片化された後、どのように統合するのでしょうか?
• データ分析とマイニング: これらの要件では、データ全体の分析が必要になる場合がありますが、分析は現在のビジネスに影響を与えてはなりません。

技術的な観点から見ると、これらの問題に対処するには一般的に 2 つの選択肢があります。 1 つ目はデータをオンラインで処理すること、2 つ目はデータをオフラインで処理することです。

• オンライン データ処理のソリューション: マイクロサービスによって提供されるインターフェースを通じてデータを取得し、そのデータを統合します。ただし、この方法には明らかな欠点があります。つまり、呼び出し側はデータを処理するために大量のコードを記述する必要があるということです。第二に、各マイクロサービスからデータを取得すると、マイクロサービスの通常のビジネス処理パフォーマンスに影響します。
• オフライン データ処理ソリューション: ビジネス データをほぼリアルタイムで別のデータベースに同期し、同期プロセス中にデータの統合と処理を実行して、ビジネス パーティのデータ ニーズを満たします。データが同期された後、外部データ出力を担当する別のサービス インターフェイスが提供されます。このソリューションには 2 つの特徴があります。① データ同期ソリューションが鍵となります。技術的な選択肢は数多くあります。企業のビジネスに適した技術ソリューションを選択する方法。 ②オフラインデータ処理はマイクロサービスの通常の業務処理に影響を与えません。

2番目の方法をお勧めします。 Spring Boot と MongoDB を使用すると、この問題は簡単に解決できます。技術的な手段により、N 個のマイクロサービスに分割されたデータを MongoDB クラスターに同期し、同期プロセス中にデータクリーニングを実行して、企業のさまざまなビジネスニーズを満たすことができます。

マイクロサービス アーキテクチャには、サービス障害の伝播、サービスの分割、分散トランザクションなど、大きな課題があります。

2. CAP理論

一貫性: データの強い一貫性を指します。データが正常に書き込まれると、後で読み取られるデータは新しく書き込まれたデータになります。データの書き込みに失敗した場合、後で読み取られるデータは書き込みに失敗したデータではありません。可用性: サービスの可用性を指します。パーティション耐性: パーティション耐性を指します。

分散システムでは、P は基本要件ですが、モノリシック サービスは CA システムであり、マイクロサービス システムは通常、可用性とパーティション耐性の両方を満たす AP システムです。

これは難しい問題を提起します。分散システムでデータの一貫性をどのように確保するか?これは誰もがよく議論する分散トランザクションです。

3. 分散トランザクション

マイクロサービス アーキテクチャでは、分散トランザクションのソリューションは2 フェーズ コミットまたは3 フェーズコミットです。どちらを使用した場合でも、トランザクションの失敗が発生し、データの不整合が発生する可能性があり、重要な瞬間にデータを手動で復元する必要があります。

• フェーズ 1: 分散トランザクションを開始し、トランザクション コーディネーター TC に渡して処理します。 TC は、トランザクション操作を処理するための準備操作を、トランザクションに参加しているすべてのノードに送信します。参加しているすべてのノードが準備操作を実行し、元に戻す情報とやり直し情報をログに書き込み、準備操作が成功したかどうかをトランザクション マネージャーに返します。
• フェーズ 2: トランザクション マネージャーは、すべてのノードの準備操作の成功を収集します。すべてが成功した場合、すべてのノードにコミット操作を実行するように通知します。失敗した場合は、ロールバック操作を実行します。

2 フェーズ コミットでは、トランザクションを 2 つの部分に分割することで、分散トランザクションの成功確率を大幅に高めることができます。最初のステージのすべてのステップが成功しても、2 番目のステージのノードが失敗した場合は、依然として不正確なデータが生成されます。これには通常、手動処理が必要になるため、最初のステップでログが記録されます。さらに、分散トランザクションに多数のノードが関与している場合、特定のノードでネットワーク異常が発生するとトランザクション全体がブロックされ、データベースのパフォーマンスが大幅に低下します。したがって、一般的には、分散トランザクションをできるだけ使用しないようにしてください。

4. サービス部門

水平分割: 注文、マーケティング、リスク管理、ポイント リソースなどのさまざまなビジネス ドメインに従って分割します。独立したビジネス ドメイン マイクロサービス クラスターを形成します。

垂直分割: ビジネス機能内の異なるモジュールまたはコンポーネントを分割します。たとえば、共通コンポーネントを独立したアトミック サービスに分割し、最下層に沈めて、比較的独立したアトミック サービス層を形成します。このようにして、ビジネスの垂直分割と水平分割を実現できます。

マイクロサービスの階層化をうまく行う必要があります。つまり、コアアプリケーションとパブリックアプリケーションを選別して抽出し、独立したサービスとしてコア機能レイヤーとパブリック機能レイヤーに沈め、フロントエンドアプリケーションが変化する市場の需要に迅速に対応できるように、徐々に安定したサービスセンターを形成する必要があります。

つまり、マイクロサービスの設計は段階的である必要があり、サービス内の凝集度が高く、サービス間の結合度が低いことが一般的な原則です。

マイクロサービスの機能:

• 業務ごとにサービスを分割し、サービスごとのコード量が少なく、業務が単一でメンテナンスが容易
• 各マイクロサービスには、データベース、キャッシュなどの独自の独立したインフラストラクチャ コンポーネントがあり、独立したプロセスで実行されます。
• マイクロサービス間の通信は、HTTP プロトコルまたはメッセージ コンポーネントを介して行われ、フォールト トレラントです。
• マイクロサービスには、一連のサービス ガバナンス ソリューションがあります。サービスは結合されておらず、いつでも追加および削除できます。
• 単一のマイクロサービスをクラスターにデプロイし、バランスをとることができる。
• マイクロサービスシステム全体には、ユーザー認証、権限認証、リソース保護など、完全なセキュリティメカニズムが必要です。
• マイクロサービスシステム全体にリンク追跡機能がある
• 完全なリアルタイムログシステムがあります

1. データベースの課題

サービスが分割された後、私たちが遭遇した最大の問題は、バックグラウンドで管理される共同クエリでした。各マイクロサービスには独自の独立したデータベースがあるため、バックグラウンドはどのように処理すればよいでしょうか?

一般的には以下の方法があります。

1. マイクロサービスの分割を厳密に遵守します。マイクロサービスは互いに独立しており、各マイクロサービス データベースも独立しています。バックグラウンドでデータを表示する必要がある場合は、各マイクロサービスのインターフェースを呼び出して対応するデータを取得し、データ処理後に表示します。これは標準的な使用法であり、最も面倒な使用法でもあります。
2. ビジネスとの関連度が高いテーブルを 1 つのライブラリにまとめ、ビジネスとの関連度が低いテーブルはマイクロサービス モデルに厳密に従って分割します。これは、マイクロサービスが使用できるだけでなく、データベースの分散によるバックエンドシステムの統計機能の実装の困難さも回避できる妥協案です。
3. データベースは、ビジネスの高い同時実行性を満たすために、マイクロサービスの要件に従って厳密にセグメント化されています。各マイクロサービス データベースのデータは、リアルタイムまたは準リアルタイムで NoSQL データベースに同期されます。バックエンドビジネスシステムの使用に合わせて、同期プロセス中にデータクリーニングが実行されます。 MongoDB、HBase などが推奨されます。

私は異なる企業でこれら 3 つのソリューションをすべて使用しました。最初のソリューションは、比較的シンプルなビジネスを展開する小規模企業に適しています。 2 番目のソリューションは、元のシステムに基づいて徐々にマイクロサービス アーキテクチャに進化する企業に適しています。 3 番目のソリューションは、大規模で同時実行性の高いインターネット企業に適しています。

5. ヒューズ

分散システムの雪崩効果を解決するために、分散システムはヒューズメカニズムを導入します。

一定時間内にサービスに対するユーザー要求の処理失敗回数が設定されたしきい値を下回ると、ヒューズは閉じた状態になり、サービスは正常になります。

一定時間内にサービスがユーザー要求の処理に失敗した回数が設定されたしきい値を超えると、サービスが失敗し、ヒューズが開いていることを意味します。つまり、すべてのリクエストはすぐに失敗し、ビジネス ロジックは実行されません。

ヒューズがオープン状態の場合、一定時間後にセミオープン状態になり、一定数のリクエストが実行されます。残りのリクエストはすぐに失敗します。リクエストの実行が失敗した場合、ヒューズは開いたままになります。成功するとヒューズが閉じられます。

ヒューズはシステムの「雪崩」効果を防ぐだけでなく、次の機能も備えています。

• リソースを分離する
• サービス劣化機能
• 自己治癒能力

6. サービスゲートウェイ

マイクロサービス システムでは、API インターフェース リソースは通常、サービス ゲートウェイ (API ゲートウェイとも呼ばれます) によって均一に公開され、内部サービスは API リソースを外部に直接公開しません。利点は、内部サービスを隠し、システムのセキュリティを保護することです。

ゲートウェイ層は通常、クラスターの形で存在します。 Nginx は通常、負荷分散のためにサービス ゲートウェイ層の前に追加されます。

ゲートウェイの意味:

• ゲートウェイはすべてのサービスAPIインターフェースリソースを集約し、外部に公開します。
• ゲートウェイは、API インターフェイスを操作するための不正な要求を防ぎ、内部サービスを保護するために、いくつかのユーザー ID 認証と権限認証を実行できます。
• ゲートウェイは監視機能、リアルタイムログ出力、記録要求を実現できる。
• ゲートウェイを使用すると、トラフィックを監視し、トラフィックが多い場合にサービスをダウングレードできます。
• APIインターフェースはテストを容易にするために内部サービスから分離されています

もちろん、これらの機能を実現するにはゲートウェイの可用性を高める必要があります。そうでないと、ゲートウェイがアーキテクチャの成功におけるボトルネックになる可能性があります。最も一般的に使用されるゲートウェイ コンポーネントは、Zuul と Nginx です。

7. サービス構成の統合管理

マイクロサービス アーキテクチャでは、SpringCloud Config コンポーネント、Alibaba の Diamond、Baidu の Disconf、Ctrip の Apollo など、構成ファイルを統一的に管理するコンポーネントが必要です。

8. サービスリンクの追跡

マイクロサービス アーキテクチャでは、リクエストに関係するサービスと参加順序を追跡するために、分散リンク トラッキングを実装する必要があります。各リクエスト リンクは明確に表示されるため、問題を迅速に特定できます。

一般的なリンク追跡コンポーネントには、Google の Dapper、Twitter の Zipkin、Alibaba の Eagleeye などがあります。

9. マイクロサービスフレームワーク

市場で一般的に使用されているマイクロサービスフレームワークは、Spring Cloud、Dubbo、Kubernetesです。

• 機能モジュールの観点から見ると、Dubbo にはゲートウェイ、リンク トラッキングなどの多くの機能モジュールが欠けています。
• 学習コストを考慮すると、Dubbo バージョンは安定していて、安定性と完成度が高く、すぐに学習して使用でき、学習しやすい傾向があります。 Spring Cloud は Spring Boot をベースとしているため、まず Spring Boot を習得する必要があります。例外としては、Spring Cloud のドキュメントはほとんどが英語であるため、学習者は一定レベルの英語の読解力を持っている必要があります。
• 開発スタイルの観点から、Dubbo は XML 構成を好みます。 Spring Cloud は Spring Boot をベースとしており、アノテーションと JavaBean 構成に基づくアジャイル開発を採用しています。
• 開発速度の点では、Spring Cloudの方が開発と展開の速度が速い。
• 通信方法の観点から見ると、Spring Cloud は HTTP Restful スタイルに基づいており、サービスは完全に無関係で分離されています。 Dubbo はリモート呼び出しに基づいており、インターフェース、プラットフォーム、言語に強く依存しています。クロスプラットフォーム実装が必要な場合は、追加のミドルウェアが必要です。

したがって、Dubbo はサービス ガバナンスに重点を置いています。 Spring Cloud は、マイクロサービス アーキテクチャ エコシステムに重点を置いています。

10. SpringCloudの共通コンポーネント

• Eureka: サービス登録および検出コンポーネント
• Hystrix: サーキットブレーカー
• リボン: 負荷分散コンポーネント
• Zuul: ルーティングゲートウェイ

上記の 4 つのコンポーネントは Netflix から提供されており、総称して Spring Cloud Netflix と呼ばれます。

• Spring Cloud Config: 構成ファイルの統合管理
• Spring Cloud Security: Spring Security コンポーネントのカプセル化。ユーザー認証と権限認証を提供し、通常は Spring Security OAuth2 グループと一緒に使用され、認可サービスを構築し、トークンまたは JWT を検証してマイクロサービス システム全体でセキュリティ認証を実行します。
• Spring Cloud Sleuth: Dapper、Zipkin、Kibana コンポーネントをカプセル化する分散リンク トレース コンポーネント
• Spring Cloud Stream: Spring Cloudフレームワークのデータストリーム操作パッケージは、RabbitMq、ActiveMq、Kafka、Redisなどのメッセージコンポーネントをカプセル化できます。Spring Cloud Streamは、メッセージの送受信に使用できます。

Spring Cloud で構築されたシンプルなマイクロサービス システムは、通常、サービス登録センター Eureka、ゲートウェイ Zuul、構成センター Config、および承認サービス Auth で構成されます。

Spring Cloud Netflix の機能:

• サービス検出: Eurekaインスタンスを登録でき、クライアントはSpring管理Beanを使用してインスタンスを検出できます。
• サービスディスカバリ: 宣言型Java構成を使用して組み込みEurekaサーバーを作成できます。
• サーキットブレーカー: Hystrixクライアントは、シンプルなアノテーション駆動型メソッドデコレータを使用して構築できます。
• サーキットブレーカー: 宣言型 Java 構成を備えた組み込み Hystrix ダッシュボード
• 宣言型 REST クライアント: Feign は、JAX-RS または Spring MVC アノテーションで装飾されたインターフェースの動的な実装を作成します。
• クライアント側ロードバランサー: リボン
• 外部構成: Spring 環境から Archaius へのブリッジ (Spring Boot 規約を使用して Netflix コンポーネントのネイティブ構成を可能にする)
• ルーターとフィルター: Zuul フィルターの自動再登録、およびリバース プロキシ作成のためのシンプルな設定上の規約