コンテキスト

サーバー側のエンタープライズアプリケーションを開発しています。デスクトップブラウザ、モバイルブラウザなど、さまざまなクライアントをサポートする必要があります。ネイティブモバイルアプリケーション。アプリケーションは、サードパーティが使用するAPIを公開する場合もあります。また、Webサービスまたはメッセージブローカーを介して他のアプリケーションと統合する場合もあります。アプリケーションは、ビジネスロジックを実行することにより、要求（HTTP要求およびメッセージ）を処理します。データベースへのアクセス。他のシステムとのメッセージ交換。そして、HTML / JSON / XML応答を返します。アプリケーションのさまざまな機能領域に対応する論理コンポーネントがあります。

問題

アプリケーションのデプロイメントアーキテクチャは何ですか？

力

• アプリケーションに取り組んでいる開発者のチームがあります
• 新しいチームメンバーはすぐに生産的になる必要があります
• アプリケーションは理解しやすいものでなければなりませんおよび変更
• アプリケーションの継続的な展開を実践したい
• スケーラビリティと可用性の要件を満たすには、アプリケーションの複数のインスタンスを複数のマシンで実行する必要があります
• 新しいテクノロジー（フレームワーク、プログラミング言語など）を利用したい

ソリューション

アプリケーションを疎結合のセットとして構造化するアーキテクチャを定義します。コラボレーションサービス。このアプローチは、スケールキューブのY軸に対応します。各サービスは次のとおりです。

• 高度なメンテナンスとテストが可能-raを有効にします迅速で頻繁な開発と展開
• 他のサービスとの疎結合-チームは、他のサービスへの変更の影響を受けたり、他のサービスに影響を与えたりすることなく、サービスの大部分の時間を独立して作業できます。
• 独立して展開可能-チームが他のチームと調整することなくサービスを展開できるようにします
• 小さなチームで開発できます-大規模なコミュニケーション責任者を避けて高い生産性を実現するために不可欠ですチーム

サービスは、HTTP / RESTなどの同期プロトコルまたはAMQPなどの非同期プロトコルのいずれかを使用して通信します。サービスは、互いに独立して開発および展開できます。各サービスには、他のサービスから切り離されます。サービス間のデータの一貫性は、佐賀パターンを使用して維持されます

サービスの性質の詳細については、この記事をお読みください。

例

架空のeコマースアプリケーションon

顧客からの注文を受け取り、在庫と利用可能なクレジットを確認して出荷するeコマースアプリケーションを構築していると想像してみましょう。このアプリケーションは、ユーザーインターフェイスを実装するStoreFrontUIを含むいくつかのコンポーネントで構成されています。 、クレジットの確認、在庫の維持、注文の発送のためのいくつかのバックエンドサービスとともに。アプリケーションは一連のサービスで構成されています。

コードを見せてください

Chris Richardsonによって開発されたサンプルアプリケーションをご覧ください。Githubのこれらの例は、マイクロサービスアーキテクチャのさまざまな側面を示しています。

結果のコンテキスト

メリット

このソリューションには多くのメリットがあります。

• 大規模で複雑なアプリケーションの継続的デリバリーと展開を可能にします。
  • 保守性の向上-各サービスは比較的小さいため、理解と変更が容易です
  • テスト性の向上-サービスはより小さく、テストが高速です
  • 展開性の向上-サービス独立して展開できます
  • これにより、複数の自律的なチームを中心に開発作業を整理できます。各（いわゆる2つのピザ）チームは、1つ以上のサービスを所有し、責任を負います。各チームは、他のすべてのチームとは独立して、サービスを開発、テスト、デプロイ、拡張できます。
• 各マイクロサービスは比較的小規模です。
  • より簡単に開発者が理解する
  • IDEの方が高速で、開発者の生産性が向上します
  • アプリケーションの起動が速くなるため、開発者の生産性が向上し、デプロイが高速化されます
• 障害分離の改善。たとえば、1つのサービスでメモリリークが発生した場合、そのサービスのみが影響を受けます。他のサービスは引き続きリクエストを処理します。これに対して、モノリシックアーキテクチャの1つの誤動作コンポーネントは、システム全体をダウンさせる可能性があります。
• テクノロジースタックへの長期的な取り組みを排除します。新しいサービスを開発するときは、新しいテクノロジースタックを選択できます。同様に、既存のサービスに大きな変更を加えるときは、新しいテクノロジースタックを使用してサービスを書き換えることができます。

欠点

このソリューションには、いくつかの欠点があります。

• 開発者は、分散システムを作成する際のさらなる複雑さに対処する必要があります。
  • 開発者はサービス間通信メカニズムを実装し、部分的な障害に対処する必要があります
  • 複数のサービスにまたがるリクエストの実装はより困難です
  • サービス間の相互作用のテストはより困難です難しい
  • 複数のサービスにまたがるリクエストを実装するには、チーム間の注意深い調整が必要です
  • 開発者ツール/ IDEはモノリシックアプリケーションの構築を目的としており、分散アプリケーションの開発を明示的にサポートしていません。
• 導入の複雑さ。本番環境では、さまざまなサービスで構成されるシステムの展開と管理の運用上の複雑さもあります。
• メモリ消費量の増加。マイクロサービスアーキテクチャは、N個のモノリシックアプリケーションインスタンスをNxMサービスインスタンスに置き換えます。各サービスが独自のJVM（または同等のもの）で実行される場合（通常はインスタンスを分離するために必要）、JVMランタイムのM倍のオーバーヘッドが発生します。さらに、Netflixの場合のように、各サービスが独自のVM（EC2インスタンスなど）で実行されている場合、オーバーヘッドはさらに高くなります。

問題

対処しなければならない多くの問題。

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

このアプローチを使用する際の1つの課題は、いつ使用するのが理にかなっているのかを判断することです。アプリケーションの場合、このアプローチで解決できる問題がないことがよくあります。さらに、複雑な分散アーキテクチャを使用すると、開発が遅くなります。これは、ビジネスモデルをどのように迅速に進化させ、 Y軸分割を使用すると、迅速な反復がはるかに困難になる可能性がありますが、後で、スケーリングの方法が課題であり、機能分解を使用する必要がある場合、絡み合った依存関係により、モノリシックアプリケーションをに分解することが困難になる可能性があります一連のサービス。

アプリケーションを分解する方法

もう1つの課題は、システムをマイクロサービスに分割する方法を決定することです。これは非常に芸術的ですが、役立つ戦略がいくつかあります。

• ビジネス機能ごとに分解し、ビジネス機能に対応するサービスを定義します。
• ドメイン駆動設計サブドメインごとに分解します。
• 動詞またはユースケースごとに分解し、特定のアクションを担当するサービスを定義します。 。例えば完全な注文の発送を担当するShipping Service。
• 特定のエンティティ/リソースに対するすべての操作を担当するサービスを定義することにより、名詞またはリソースで分解します。タイプ。例えばユーザーアカウントの管理を担当するAccount Service。

理想的には、各サービスの責任はごくわずかです。（叔父）ボブマーティン単一責任原則（SRP）を使用したクラスの設計について説明します。SRPは、クラスの責任を変更の理由として定義し、クラスには変更の理由が1つだけあるべきであると述べています。SRPをサービス設計に適用することは理にかなっています。

サービスデザインに役立つもう1つの類似点は、Unixユーティリティのデザインです。Unixは、grep、cat、findなどの多数のユーティリティを提供します。各ユーティリティは1つのことを実行しますが、多くの場合、非常に優れています。シェルスクリプトを使用して他のユーティリティと組み合わせて複雑なタスクを実行することを目的としています。

データの一貫性を維持する方法

緩い結合を確保するために、各サービスには独自の機能があります。データベース.2フェーズコミット/分散トランザクションはそうではないため、サービス間のデータ整合性を維持することは課題です多くのアプリケーションのオプション。アプリケーションは代わりにSagaパターンを使用する必要があります。サービスはデータが変更されたときにイベントを公開します。他のサービスはそのイベントを消費してデータを更新します。データを確実に更新してイベントを公開するには、イベントソーシングやトランザクションログのテーリング。

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

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

• API構成とコマンドクエリの責任分離（CQRS）パターン。

マイクロサービスパターンに関連するパターンは多数あります。モノリシックアーキテクチャは、マイクロサービスアーキテクチャの代替です。他のパターンは、マイクロサービスアーキテクチャを適用するときに発生する問題に対処します。

• 分解パターン
  • ビジネス機能ごとに分解
  • サブドメインごとに分解
• サービスごとのデータベースパターンは、それぞれの方法を説明しますサービスには、疎結合を保証するための独自のデータベースがあります。
• APIゲートウェイパターンは、クライアントがマイクロサービスアーキテクチャのサービスにアクセスする方法を定義します。
• クライアント側の検出パターンとサーバー側の検出パターンは、クライアントのリクエストをマイクロサービスアーキテクチャで利用可能なサービスインスタンス。
• メッセージングとリモートプロシージャの呼び出しパターンは、サービスが通信できる2つの異なる方法です。
• ホストごとの単一サービスとホストごとの複数のサービスパターンは2つの異なる展開戦略。
• 横断的な懸念パターン：マイクロサービスシャーシパターンと外部化された構成
• テストパターン：サービスコンポーネントテストとサービス統合契約テスト
• 回路ブレーカー
• アクセストークン
• 可観測性パターン：
  • ログ集計
  • アプリケーションメトリック
  • 監査ログ
  • 分散トレース
  • 例外追跡
  • ヘルスチェックAPI
  • ログのデプロイと変更
• UIパターン：
  • サーバー側のページフラグメント構成
  • クライアント側のUI構成

既知の用途

Netflix、Amazon、eBayなどのほとんどの大規模Webサイトは、モノリシックアーキテクチャからマイクロサービスアーキテクチャに進化しました。

Netflixは、非常に人気のあるビデオストリーミングサービスです。インターネットトラフィックの最大30％に対応し、大規模なサービス指向アーキテクチャを備えています。800を超えるさまざまな種類のデバイスからのビデオストリーミングAPIへの1日あたり10億を超える呼び出しを処理します。各APIは、平均6つまでファンを呼び出します。バックエンドサービスへの呼び出し。

Amazon.comは元々2層アーキテクチャでした。拡張するために、数百のバックエンドサービスで構成されるサービス指向アーキテクチャに移行しました。アプリケーションを含むいくつかのアプリケーションがこれらのサービスを呼び出します。 Amazon.com WebサイトとWebサービスAPIを実装します。Amazon.comWebサイトアプリケーションは、100〜150のサービスを呼び出してWebページの構築に使用されたデータ。

オークションサイトebay.comも、モノリシックアーキテクチャからサービス指向アーキテクチャに進化しました。アプリケーション層は複数の独立したアプリケーションで構成されています。各アプリケーションはビジネスロジックを実装しています。購入や販売などの特定の機能領域に対して。各アプリケーションはX軸分割を使用し、検索などの一部のアプリケーションはZ軸分割を使用します。Ebay.comはX、Y、およびZスタイルのスケーリングの組み合わせも適用します。データベース層。

マイクロサービスアーキテクチャを使用している企業の例は他にもたくさんあります。

クリスリチャードソンには、マイクロサービスベースのアプリケーションの例があります。

関連項目

マイクロサービスアーキテクチャの優れた紹介を提供するCodeFreeze2018基調講演をご覧ください。