パターン：Microserviceアーキテクチャ

コンテキスト

あなたは、サーバー側のエンタープライズアプリケーションを開発しています。これは、デスクトップブラウザ、モバイルブラウザとネイティブモバイルアプリケーションを含む、さまざまなクライアントを、サポートしている必要があります。また、アプリケーションは、サードパーティの使用のためのAPIを開くことができます。また、他のアプリケーションとWebサービスやメッセージ・ブローカーを経由して統合することができます。ビジネス・ロジックの処理要求（HTTPリクエストとメッセージ）を実行するアプリケーションによって、データベースにアクセスし、他のシステムとメッセージを交換すると、HTML / JSON / XML応答を返します。アプリケーション・ロジック・コンポーネントに対応する異なる機能領域が存在します。

問題

アプリケーションのどのような展開アーキテクチャのですか？

フォーカス

アプリケーションの開発における開発者のグループがあります
新チームのメンバーはすぐに作業効率を向上させる必要があります
アプリケーションは、理解しやすいことと変更する必要があります
あなたは実用的なアプリケーションを展開していきたいです
あなたは、スケーラビリティと可用性の要件を満たすために、複数のコンピュータ上で複数のアプリケーションインスタンスを実行する必要があります
あなたは新技術（フレームワーク、プログラミング言語など）を利用したいです

ソリューション

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

保守性とテスト容易性の高いです -
緩く他のサービスとの結合の高速、頻繁開発と展開
チームは独立して、ほとんどの時間を仕事にできます、他のサービスが変更によって影響を受けることはありませんが、それは他のサービスに影響はありません独立して展開することができます
それは小さなチームを開発するために、他のチームと連携しなくてもサービスを展開するためにチームを可能にします
大規模なチームを担当して高い通信者を避けることにより、生産性を向上させることが不可欠です

HTTP / RESTプロトコル等時性または非同期AMQPプロトコルを使用する他のサービス。互いに独立して、サービスを開発し、展開することができます。各サービスは、独自のデータベースを持っている他のサービスから分離します。サービス間のデータの一貫性を維持するために、佐賀モードを使用します

サービスの性質については、こちらをご覧ください、この記事を読んで。

例

架空の電子商取引アプリケーション

あなたがeコマース・アプリケーションを構築している、アプリケーションが利用可能なクレジットの顧客、検証、インベントリから順番を受け取り、それらを出荷するとしましょう。アプリケーションは、クレジットをチェックするためだけでなく、StoreFrontUIユーザインタフェースの実現を含めたいくつかのコンポーネントで構成され、保守サービスのバックエンドの在庫と出荷注文の一部。アプリケーションは、サービスのセットが含まれています。

コード例

クリス・リチャードソンはマイクロサービスの例を開発した。GitHubの上のこれらの例は、マイクロサービスアーキテクチャの様々な態様を説明します。

インパクト

利点

このソリューションは、多くの利点があります。

大規模複雑なアプリケーションの連続配信と展開をサポートしています。
- メンテナンス性が向上 - 各サービスは比較的小さいので、理解しやすいと変更されています
- より良いテスト容易性 - テストサービスより小さく、より速く
- より良い展開性 - サービスは、独立して展開することができます
- これは、チームの周りに複数の自律開発作業を整理することができます。それぞれの（2枚のピザと呼ばれる）と、1つ以上のサービスを担当するチームを持っています。各チームは、他のすべてのチームから独立して開発、テスト、彼らのサービスを展開して展開することができます。
各マイクロサービスは比較的小さいです。
- 開発者が理解しやすいです
- IDEには、より高速な開発者の生産性を向上させることができます
- アプリケーションは、高い開発者の生産を行っており、より高速起動、および展開のスピードを加速します
改善された障害分離。サービスでメモリリークがある場合たとえば、それだけのサービスに影響を与えます。その他のサービスは要求を処理していきます。対照的に、成分のシングルチップアーキテクチャ不適切な振る舞いは、全体のシステムをクラッシュさせることができます。
技術スタックへの長期的なコミットメントを排除します。新サービスの開発では、新しい技術スタックを選択することができます。同様に、重要な変更が既存のサービスに、新しい技術スタックを使用することができたときに、それを書き換えます。

欠陥

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

開発者は、分散システムの追加の複雑さを作成するために対処する必要があります。
- 開発者は、クロスサービスの通信メカニズムを実装し、部分的な障害を処理しなければなりません
- リクエスト複数のサービス間で実装するより難しいです
- テストサービス間の相互作用をより困難
- 複数のサービス間で実施することはチーム間の慎重な調整を必要とする要求
- 単一のアプリケーションを構築するための開発ツール/ IDE、それは、分散アプリケーションの開発のための明示的なサポートを提供していません。
展開の複雑さ。本番では、システムの導入と管理からなるさまざまなサービスの数によって、操作の複雑さが残っています。
増加メモリ消費量。モノリシックなN×M個のサービスインスタンスを使用して、あるいはN、マイクロサービスアーキテクチャのアプリケーションインスタンス。各サービスは、通常、単離されたインスタンスが必要であるJVM自身の（または同等のサーバ）上で実行されている場合、それはM M倍が実行オーバーヘッドビューを生成することになります。各サービスは（例えばEC2インスタンス）に独自のVMで実行されている場合、また、ネットフリックスの場合のように、コストはさらに高くなります。

問題

あなたは多くの問題を解決する必要があります。

マイクロサービスアーキテクチャを使用する場合は？

このアプローチの使用は、それを使用する際に決めることが課題です。アプリケーションの最初のバージョンの開発では、通常、この方法で解決される問題は発生しません。また、適切に設計され、分散型アーキテクチャを使用することは、開発のスピードが遅くなります。スタートアップ企業にとっては、これが最大の課題はすぐに含まれているビジネスモデルやアプリケーションを開発する方法である通常は大きな問題である可能性があります。迅速なイテレーションさらに困難を引き起こす可能性がY軸分割を使用してください。課題は、拡張する方法であり、あなたが機能分割を使用する必要がある場合しかし、後に、もつれた依存関係は、一連のサービスにアプリケーション全体あなたのためにそれが困難になることがあります。

どのサービスへの応用？

もう一つの課題は、システムはマイクロサービスに分かれている方法を決定することです。これは芸術ですが、助けることができる多くの戦略があります。

ビジネス能力によって破壊し、サービスに対応するビジネス機能を定義します。
駆動設計ドメインはサブドメインによって分解します。
例えば、動詞やサービスを分解し、定義によっては、特定の操作を担当しています。このような完全なオーダーの送信を担当配信サービス、など。
名詞やリソースへのダウンサービスブレークを定義することにより、サービスは、エンティティ/リソースの特定のタイプのすべての操作を担当しています。たとえば、サービスアカウントのユーザーアカウントを管理する責任があります。

理想的には、各サービスは、責任のほんの一部である必要があります。（おじさん）ボブ・マーティンは、単一責任の原則（SRP）デザインのコースに来ます。SRPは、変更する理由として、クラスの責任を定義し、クラスのみ変更する理由でなければなりません宣言します。SRPにも理にかなっているサービスの設計に適用されます。

別のアナロジーは、サービス設計のUnixユーティリティを助けるように設計されています。Unixのは、grepの、猫と見つけるなどのユーティリティの数を提供します。各ユーティリティは通常、非常に良い、一つのことをやっている、とあなたは、複雑なタスクを実行するために、他のユーティリティと組み合わせてシェルスクリプトを使用することができます。

データの一貫性を維持するには？

疎結合を確保するために、各サービスは、独自のデータベースを有しています。分散トランザクションが送信オプション/第2フェーズ多くのアプリケーションではありませんので、サービス間でのデータの一貫性を維持することは、挑戦です。アプリケーションは、佐賀モードを使用する必要があります。サービス公開イベント時にそのデータが変更されます。その他のサービスは、そのデータを更新するには、このイベントを使用します。確実なイベントの調達およびトランザクション・ログ・テーリングを含むデータおよび出版イベントを更新するには、いくつかの方法があります。

クエリを実装する方法？

もう一つの課題は、クエリを持っている複数のサービスからデータを取得する必要性を実現することです。

APIとコマンド責任の組み合わせは、アイソレーション（CQRS）モードを照会します。

既知のユーザー

マイクロサービスアーキテクチャの開発から、シングルチップ・アーキテクチャを含むネットフリックス、アマゾンやイーベイを含むほとんどの大規模なサイト、、。
ネットフリックスは、非常に人気のあるビデオストリーミングサービスであるインターネットトラフィックの30％まで、大規模、サービス指向アーキテクチャーを担当しています。彼らは10億回のコールオーバー800台の異なるデバイスからの毎日のビデオストリームのAPIを扱います。各APIコールは、6回の平均値にバックエンドサービスと呼ばれます。
Amazon.com最初は2層構造。拡大するためには、彼らは、バックエンドサービス指向サービスの何百もの構成アーキテクチャに移行します。いくつかのアプリケーションは、アプリケーションAmazon.comのWebサイトやWebサービスAPIの実現を含め、これらのサービスを呼び出すがあります。Amazon.comのアプリケーションは、Webページを構築するために使用されるデータを取得するために100-150のサービスを呼び出します。
Ebay.comのオークションサイトは、サービス指向アーキテクチャモノリシックアーキテクチャから進化しました。アプリケーション層は、別のアプリケーション複数の成分から成ります。こうした売買などの各アプリケーションのビジネスロジックは、特定の機能領域、。各アプリケーションは、X軸は分割されている使用して、いくつかのアプリケーション（例えば、検索Z軸の分割を使用して）。Ebay.comまたX、Y及びZの組み合わせパターンは、データベース層にスケーリング。
マイクロサービスアーキテクチャ会社の使用は、他の多くの例があります。

例

クリス・リチャードソンが持っている例 microservicesベースのアプリケーションのを。

私を参照してくださいコードフリーズ2018基調 microserviceアーキテクチャの入門を提供し、。

モード：マイクロサービスアーキテクチャ