元のアドレス：https：//microservices.io/patterns/microservices.html

シーンの説明

次の要件を持つ大規模なサーバー側エンタープライズアプリケーションを開発しているとします。

WEBブラウザー、WAPブラウザー、ネイティブモバイルアプリなど、さまざまなクライアントをサポートする必要があります。
呼び出し用のパブリックAPIを公開する
HTTP要求またはメッセージを処理し、対応するビジネスロジックを実行します。
データベースにアクセスし、応答データをキャッシュまたは永続化します
他のシステムと通信し、必要な情報を交換します
HTTP応答を返し、JSON、XMLなどの特定のシリアル化メソッドを指定します。
ビジネスロジックと機能に応じて、さまざまなロジックモジュールを設計および分割します

このようなアプリケーションをどのように設計および展開しますか？

考慮事項

これはチームによって開発されたプロジェクトであり、独立したチームが責任を負います
チームメンバーは変わります、新しいメンバーはすぐに始めなければなりません
アプリケーションは理解しやすく、変更しやすいものでなければなりません
アプリケーションの継続的インテグレーションとデプロイを実現することを期待してください
スケーラビリティと可用性の要件を満たすには、アプリケーションを複数のインスタンスにデプロイできる必要があります。
比較的新しいテクノロジー（フレームワーク、プログラミング言語など）を使用したい

解決

疎結合マイクロサービスのセットとしてアプリケーションを構築するコラボレーションアーキテクチャを定義します。各マイクロサービスは、次の条件を満たすものです。

高度に保守可能でテスト可能：迅速かつ頻繁な開発と展開をサポートします。
他のマイクロサービスとの疎結合：チームは、他のマイクロサービスの変更の影響を受けたり、他のマイクロサービスに影響を与えたりすることなく、ほとんどの場合、独自のマイクロサービスで独立して作業できます。
独立した展開：チームが他のチームと調整することなくサービスを展開できるようにします。
通信コストの削減：小さなチームに分割して独自のマイクロサービスに集中できるため、大規模なチームの内部通信コストを削減できます。

サービスは、同期プロトコル（HTTP / RESTなど）または非同期プロトコル（AMQPなど）を使用して通信します。サービスは、互いに独立して開発および展開できます。各サービスには、他のサービスから分離するための独自のデータベースがあります。サービス間のデータ整合性はSAGAモードを使用します

例えば

eコマースアプリケーションを設計しているとします。機能には、顧客からの注文の受信（StoreFrontUI）、在庫残高の確認と維持（Inventory Service）、ユーザーが利用可能な残高の確認と維持（Accounting Service）、注文の正常化と出荷（Shipping）が含まれます。サービス））。このアプリケーションは、次の図に示すように、マイクロサービスアーキテクチャアプリケーションとして設計されています。

分析

メリット

大規模で複雑なアプリケーションの継続的デリバリーとデプロイをサポートします
- 保守性の向上：各サービスは比較的小さいため、理解と変更が容易です。
- テストが容易：サービスが小さくなり、テスト速度が速くなります。
- 展開性の向上：サービスは独立して展開できます。
- 分業とモジュールビジネスの境界がより明確になり、特定のマイクロサービスを1つ以上のチームが提供および維持できます。各チームは、他のすべてのチームとは独立して、サービスを開発、テスト、展開、および拡張できます。
各マイクロサービスは比較的小さいです：
- 開発者にとって理解しやすい
- IDEの負荷が低く、速く、開発効率が向上します
- アプリケーションの起動が速くなり、デバッグ効率が向上し、展開が高速化されます。
障害の切り分け。たとえば、マイクロサービスでメモリリークが発生した場合、そのマイクロサービスのみが影響を受けます。他のサービスは引き続きリクエストを処理できます。
テクノロジースタックを更新する方が簡単です。新しいマイクロサービスモジュールが開発されると、新しいテクノロジースタックを実験的な開発と使用に使用できます。安定した後、他のマイクロサービスに徐々に拡張できます。

害

開発者は、分散システムによってもたらされる追加の複雑さに直面する必要があります。
- 開発者は、RPC通信に精通し、障害処理ロジックを作成する必要があります。
- 複数のサービスにまたがってリクエストを実装することはより困難です。
- テストサービス間の相互作用はより困難です。単体テストはすべてのシナリオを網羅できるわけではなく、統合テストは展開がより面倒です。
- 複数のサービスにわたって要求を達成するには、チーム間の注意深い調整が必要です。
- IDEは主にモノリシックアプリケーションの構築を対象としており、分散アプリケーションの開発を明示的にサポートしていません。
展開の複雑さ。本番環境では、さまざまなサービスで構成されるシステムの展開と管理も運用が複雑になります。現在のコンテナ化およびコンテナオーケストレーションソリューションは、この問題を解決することです。
メモリなどのリソースの消費を増やします。各マイクロサービスがJVMを占有すると仮定すると、JVM自体が占有するリソース（GCが占有するCPUとメモリ、メタスペース、コードキャッシュなど）は、モノリシックと比較して元のリソースよりも多くなります。アプリケーション。。マイクロサービスがコンテナ、さらには仮想マシン、マシンを占有する場合、このリソースの浪費はさらに大きくなります。

考慮すべき問題

マイクロサービスアーキテクチャをいつ使用するのですか？

マイクロサービスアーキテクチャを使用する際の課題の1つは、いつ使用するかを決定することです。アプリケーションの最初のバージョンを開発するとき、通常、この方法で解決する必要のある問題は発生しません。さらに、より洗練された分散アーキテクチャ設計を使用すると、開発速度が遅くなります。新興企業にとって、これは大きな問題になる可能性があり、彼らが直面する最大の課題は、多くの場合、ビジネスを迅速に開発し、アプリケーションを迅速に反復する方法です。ただし、製品の反復が進むにつれて、このモノリシックアプリケーションはますます大きくなり、チームのサイズはますます大きくなります。マイクロサービスアーキテクチャへの機能分解を使用する必要がある場合、複雑な依存関係によってアプリケーションが作成される可能性があります。一連のサービスに分解することは困難です。

アプリケーションをサービスに分解する方法は？

もう1つの課題は、システムをマイクロサービスに分割する方法を決定することです。これは主に芸術ですが、参照できる戦略はたくさんあります。

ビジネスごとのビジネス機能に対応するマイクロサービスを分解して定義します。
アート主導の設計サブドメイン分解によると
ユーザーの行動とユースケースごとに分解し、特定の操作を担当するマイクロサービスを定義します。たとえば、Shipping Serviceは、完全な注文の配送を担当します。
特定のタイプのエンティティ/リソースの操作を担当するマイクロサービスを定義します。たとえば、アカウントサービスはユーザーアカウントの管理を担当します。

理想的には、各サービスの責任はごくわずかである必要があります。ボブ・マーティンは、単一責任の原則を使用する必要があると話しました。クラスに関する限り、その変更の理由は1つだけです。また、単一責任の原則をサービス設計に適用することも理にかなっています。

サービス設計に役立つもう1つの例えは、Unixユーティリティの設計です。Unixには、grep、cat、findなどの多数のユーティリティが用意されています。各ユーティリティは1つのことだけを実行し、他のユーティリティと組み合わせてシェルスクリプトを使用することにより、複雑なタスクを実行します。

データの整合性を維持する方法は？

疎結合を保証するために、各サービスには独自のデータベースがあります。多くのアプリケーションでは、2フェーズコミット（2PC）または分散トランザクションは適切な選択ではないため、サービス間のデータの整合性を維持することは困難です。アプリケーションはSAGAモードを使用する必要があり、サービスはデータが変更されたときにイベントを公開し、他のサービスはイベントを使用してデータを更新します。データの確実な更新とイベントの公開には、イベントソーシングやトランザクションログテーリングなど、いくつかの方法があります。

クエリを実装する方法は？

もう1つの課題は、複数のサービスが所有するデータを取得する必要があるクエリを実装することです。

[翻訳]マイクロサービスデザインパターン-2。マイクロサービスアプリケーションパターン