👩‍👩‍👧‍👧 🌓 👩🏾‍🏫 マイクロサービスアーキテクチャ 🧒🏽 😴 😰

残念ながら、マイクロサービスの使用経験はありませんが、約1年前、このトピックに非常に積極的に興味を持ち、見つけられるすべての情報源を調べました。私は会議でいくつかのスピーチを見、マーティン・ファウラー、フレッド・ジョージ、エイドリアン・コッククロフト、クリス・リチャードソンなどの権威ある経験豊富な専門家によるいくつかの記事を読んで、マイクロサービスについて可能な限り学びました。この記事は私の研究の結果です。

内容

マイクロサービスアーキテクチャは、アプリケーションを作成するためのアプローチであり、単一のモノリシック構造を拒否することを意味します。つまり、インプロセスインタラクションを使用してサーバー上のアプリケーションのすべての制限されたコンテキストを実行する代わりに、いくつかの小さなアプリケーションを使用します。各アプリケーションはいくつかの制限されたコンテキストに対応します。さらに、これらのアプリケーションは異なるサーバー上で実行され、たとえばHTTPを介してネットワーク上で相互に対話します。

つまり、特定のアプリケーションコンテキストをマイクロサービスにカプセル化し、それぞれを1つにして、異なるサーバーでマイクロサービスをねじります。

SOAとマイクロサービス

Martin Fowlerによると、SOAという用語はあらゆる人に乱用されており、今日では多くのことを意味しています。マーティンの観点から見ると、マイクロサービスはSOAの一形態です。

マイクロサービスはいつ使用する必要がありますか？

実務家になりたい理論的アーキテクトとして、私は次のことを考慮します。マイクロサービスを使用するかどうかを決定する際には、神話や「次回試してみたい」、またはテクノロジーの最前線にいるという欲求に導かれるべきではありません。レイチェル・マイヤーズの結論によれば、これは実践的な観点からのみアプローチされるべきです。レイチェルは、アーキテクチャが次のことをすべきであると述べています

製品の柔軟性と障害に対する耐性を高める。
コードの理解、デバッグ、変更を促進します。
チームワークを支援します。

私はレイチェルに同意しますが、モノリシックなアーキテクチャスキームがこれらの基準を満たすと信じています。

Martin Fowlerは、モノリシックおよびマイクロサービスアーキテクチャのいくつかの利点を特定します。これにより、選択するアプローチを決定できます。

メリット
モノリシックアーキテクチャ	マイクロサービス
シンプルさモノリシックアーキテクチャは、実装、管理、および展開がはるかに簡単です。マイクロサービスは異なるサーバーにデプロイされ、APIを使用するため、慎重な管理が必要です。	部分展開マイクロサービスを使用すると、必要に応じてアプリケーションを部分的に更新できます。単一のアーキテクチャでは、アプリケーション全体を再デプロイする必要があり、はるかに多くのリスクが伴います。
一貫性モノリシックアーキテクチャを使用すると、コードの一貫性の維持、エラーの処理などが簡単になります。しかし、マイクロサービスは、さまざまな標準に準拠したさまざまなチームによって完全に制御できます。	在庫状況マイクロサービスには可用性があります。マイクロサービスの1つがクラッシュしても、アプリケーション全体がクラッシュすることはありません。
モジュール間リファクタリング単一のアーキテクチャにより、複数のモジュールが相互にやり取りする必要がある場合や、あるモジュールから別のモジュールにクラスを移動する場合に、作業が簡単になります。マイクロサービスの場合、モジュールの境界を非常に明確に定義する必要があります！	モジュール性の維持 SOLIDルールにもかかわらず、モジュール性とカプセル化を維持することは困難な場合があります。ただし、マイクロサービスはモジュール間で共有状態が存在しないことを保証できます。
	マルチプラットフォーム/異質性マイクロサービスを使用すると、タスクに応じてさまざまなテクノロジーと言語を使用できます。

個人的には、エリック・エヴァンスの実用的なアプローチが好きです。ハードウェアリソースに関するマイクロサービスには、統合アーキテクチャにはない利点があり、ソフトウェアの観点から多くの問題を簡単に解決できます。

マイクロサービス
ハードウェアの利点	ソフトウェアの利点
独立したスケーラビリティモジュールを個別のサーバーノードに配置する場合、他のモジュールとは独立してモジュールをスケーリングできます。	モジュール性の維持統合アーキテクチャとマイクロサービスアーキテクチャの両方で、モジュール性とカプセル化が可能です。ただし、これは非常に難しいタスクである可能性があり、SOLIDルールにもかかわらず、解決するには数十年かかります。しかし、サーバーが明示的に物理的に分離されているため、マイクロサービスはアプリケーションをモジュールに論理的に分離できます。物理的な分離は、限られたコンテキストの制限を破ることを防ぎます。
独立した技術スタックさまざまなサーバーノードと独立した対話言語にモジュールが分散されているため、まったく異なるプログラミング言語、対話ツール、監視、データストレージを使用できます。これにより、最適で最も便利なソリューションを選択したり、新しいテクノロジーを試すことができます。	サブシステムの独立した進化マイクロサービスの古いバージョンを必要な時間だけ動作させることができるため、マイクロサービスは古いバージョンのサポートに負担をかけることなく、下位互換性を開発および破壊できます。

マイクロサービスを使用する主な理由は、単一のアーキテクチャでは達成できないハードウェアの利点だと思います。したがって、上記の点があなたにとって重要である場合、マイクロサービスは競合していません。ハードウェアの利点が重要ではない場合、マイクロサービスアーキテクチャの複雑さがその利点を上回る場合があります。また、単一のアーキテクチャの助けを借りて、マイクロサービスに典型的な部分的な展開と部分的な可用性を達成することは不可能であるようにも思えます。これらは主な利点ではありません（とにかくこれらは利点です）。

私たちの好みや希望に関係なく、マイクロサービスアーキテクチャを使用してすぐに新しいプロジェクトを開始しないでください。最初に、マイクロサービスのエコシステムを作成するという非常に複雑な問題を克服するためにリソースを費やすことなく、タスクとその方法を理解することに集中する必要があります（ Rebecca Parsons 、 Simon Brown ）。

背景

継続的な展開

仕事の継続的な加速化の機会と焦点

マイクロサービスを使用する理由の1つは、ビジネス要件の変化に対応し、競合他社を上回るために、何かを迅速に変更できるようにすることです。または、エリック・エヴァンスの言葉を借りると、企業の混乱を認識する必要があります。

ソフトウェア開発の現実は、最初は問題を完全に理解していないということです。仕事をするにつれて理解が深まり、常にリファクタリングする必要があります。したがって、特にコンテキストの制約が尊重されない場合、コードはより複雑になるため、リファクタリングは必要ですが、同時に危険でもあります。マイクロサービスは、限られたコンテキストの制限に従うことを余儀なくされており、これにより、接続された別々のモジュールでコードの健全性、明確性、分離、カプセル化を維持できます。モジュール/マイクロサービスが混乱した場合、この混乱はその中にとどまり、それを超えて広がることはありません。

開発のすべての段階でより速く行動する必要があります！これはどのアーキテクチャにも当てはまりますが、この点ではマイクロサービスの方が便利です。マーティン・ファウラーは、次のことができる必要があると言います。

迅速なコミッション：開発、テスト、受け入れ、運用のために新しいマシンを迅速に展開します。
アプリケーションの迅速な展開：サービスを自動的かつ迅速に展開します。

フレッド・ジョージも同じことを言っています。競争に耐えるためには仕事をスピードアップする必要があります！彼は、サーバーのコミッションに必要な時間の回顧的分析を提供し、1990年代には6か月かかり、2010年にはクラウドサービスのおかげで30分、2015年にはDockerが新しいサーバーの立ち上げと立ち上げを可能にしたと述べていますすぐに。

Netflix Cloudの主要な専門家の1人であり、マイクロサービス開発の先駆者であるAdrian Cockcroftは、新しいテクノロジーの開発において最前線に立つことがいかに重要であるかを指摘し、新しいサーバーを非常に迅速に導入し、アプリケーションの新しいバージョンを展開します。 AdrianはDockerの大ファンです。このサービスを使用すると、サーバーを作成し、開発、テスト、および作業のための環境を数秒で展開できるためです。

より洗練された監視

監視は非常に重要です（ Rebecca Parsons ）。サーバーがクラッシュしたこと、一部のコンポーネントが応答を停止したこと、呼び出しが失敗したこと、および各マイクロサービス（ Fred George ）をすぐに見つける必要があります。迅速なデバッグのためのツールも必要です（ Martin Fowler ）。

強いdevops文化

監視と管理のためにdevopが必要であり、それらと開発者（ Martin Fowler ）の間には密接な関係と良好な相互作用が必要です。マイクロサービスを使用する場合、より多くを展開する必要があり、監視システムは複雑であり、発生する可能性のある障害の数は大幅に増加しています。したがって、会社では強力なdevops文化（ Rebecca Parsons ）が非常に重要です。

特徴

Martin FowlerとJames Lewisは、よく知られている記事とスピーチ（ Fowler 、 Lewis ）で、マイクロサービスを決定するための一連の特性を提供しています。

マイクロサービスとは何ですか？

個人的に、私はエイドリアン・コッククロフトの定義に完全に同意します：

コンテキストが制限された疎結合サービスに基づくアーキテクチャ。（コンテキストが制限された疎結合サービス指向アーキテクチャ。）

制限されたコンテキストは、ビジネスコンテキストの周囲の明確な境界の概念です。たとえば、電子商取引のフレームワークでは、「テーマ」、「支払いサービスプロバイダー」、「注文」、「配送」、「アプリケーションストア」の概念を使用します。これらはすべて限定されたコンテキストであり、マイクロサービスの候補を意味します。

マイクロサービスに関する有用な一般情報は、Sam Newmanの著書『Building Microservices』に記載されています。 James Lewisによると、マイクロサービスは次のことを行う必要があります。

交換が安い。
素早くスケーリング
障害に強い
作業が遅くなることはありません。

マイクロサービスの大きさは？

ジェームズ・ルイスは、サービスは「手に収まるほど大きい」、つまり一人が自分のデバイスと作業を完全に理解できるようにする必要があると主張しています。

マイクロサービスのサイズについてはさまざまな意見があります。 Martin Fowler は 、サービスに対する従業員の比率が 60から20から4から200の範囲にある場合について説明 しています 。たとえば、Amazonは「2つのピザチーム」アプローチを使用します。彼らは2つのピザを供給することができます。

フレッドジョージは、マイクロサービスを「非常に小さく」して、1人の開発者のみがマイクロサービスを作成して付随させるべきだと考えています。ジェームズ・ルイスも同じことを言っています。

私はジェームズ・ルイス、フレッド・ジョージ、エイドリアン・コッククロフトに同意します。 マイクロサービスは、1人が完全に理解できる限られた文脈に対応するべきだと私には思える。つまり、アプリケーションの機能が広くなればなるほど、マイクロサービスが増えるはずです。たとえば、Netflixには約800個あります ！（フレッドジョージ）

それにもかかわらず、マイクロサービスのライフサイクルの最初の両方で、後の限られたコンテキストは、1人が理解するには大きすぎることが判明する場合があります。そのような状況を特定し、これらのサービスをより小さなサービスに分割する必要があります。これは、進化的およびDDDアーキテクチャの概念と一致しており、タスクの深化やビジネス要件の変化に応じて、アーキテクチャが常に変更/リファクタリングされていることを意味します。 Rebecca Parsonsが言うように、「粉砕は非常に重要です」： マイクロサービスを開発するとき、その境界を決定することは最も困難です。作業の進歩に伴い、サービスを確実に結合または分割します。

サービスを介したコンポーネントビュー

コンポーネントはシステムの要素であり、 独立して交換、改善 （ Martin Fowler ）、 スケーリング （ Rebecca Parsons ）できます。
ソフトウェアを開発するとき、2種類のコンポーネントを使用します。

A. ライブラリ：アプリケーションで使用されるコードの一部で、他のライブラリによって補完または置換できます。アプリケーションの残りの部分に影響を与えることはできません。相互作用は、言語構成体を通じて発生します。ただし、 興味のあるライブラリが別の言語で書かれている場合、このコンポーネントを使用することはできません 。

B. サービス：アプリケーションの一部。実際には、独自のプロセスで実行される小さなアプリケーションです。相互作用は、プロセス間通信、Webサービスへの呼び出し、メッセージキューなどによって実行されます。独自のプロセスで実行されるため、別の言語で記述されたサービスを使用できます （このアプローチはChad Fowlerが推奨します）。
独立したスケーラビリティ-各サービスは、アプリケーションの他の部分から独立してスケーリングできます。

異質性

異質性とは、さまざまなプログラミング言語を使用してシステムを構築する機能です。このアプローチにはいくつかの利点があり（ Martin Fowler ）、 Chad Fowlerはシステムはデフォルトで異種でなければならない、つまり開発者は新しいテクノロジーを適用する必要があると考えています。

異種システムの利点：

異なる言語を使用して密接な関係を防ぎます。
開発者はテクノロジーを試すことができます。これにより、独自の価値が高まり、新製品を試すために他の会社に行くことができなくなります。

ルール。新しいテクノロジーを試す場合：

-リスクを軽減するには、小さなコード単位、モジュール/マイクロサービスを使用する必要があります。

-コード要素は使い捨てでなければなりません。

事業機会に応じた人材の組織化

開発チームに入ると、 使用されたテクノロジーに基づいてグループが自己組織化されます。その結果、プロジェクトはDBAチーム、サーバー側開発チーム、およびインターフェイス開発チームによって作成され、これらは互いに独立して行動しました。特定の分野の知識と開発努力がサブグループに分散されているため、このようなスキームは製品の品質に影響します。

マイクロサービスアプローチでは、注文、出荷、カタログなどのビジネスチャンスに基づいてチームを編成する必要があります。各チームには、必要なすべてのテクノロジー（インターフェイス、サーバーパーツ、DBA、QAなど）の専門家が必要です。これにより、各チームは、アプリケーションの特定の部分であるマイクロサービス（ Martin Fowler 、 Eric Evans ）の作成に集中するのに十分な知識を得ることができます。

このアプローチはコンウェイの法則と組み合わされており、高度に接続された個別のマイクロサービスが必要な場合、組織の構造は目的のコンポーネント構造を反映する必要があると規定されています。

システム開発組織...これらの組織内の相互作用を複製するアーキテクチャを作成します。

メルビン・コンウェイ、1967

プロジェクトではなく製品

以前は、このようなアプローチがありました。チームはある種の機能を作成し、それを別のチームをサポートするために渡します。

マイクロサービスの場合、チームは開発、保守、廃止を含むライフサイクル全体を通じて製品の責任を負う必要があります。これは「製品思考」を形成します。これは、技術製品とそのビジネス能力との強いつながりを意味します。つまり、直接的な関係が作成されています。つまり、アプリケーションがユーザーのビジネスチャンスの拡大をどのように支援するかです。

スマートエンドポイントとダムパイプ

繰り返しますが、古き良き時代には、企業はエンドポイントとビジネスロジック間の通信チャネルを形成するエンタープライズサービスバスアーキテクチャ（サービスバス）を使用していました。その後、このアプローチはスパゲッティボックスに変わりました。

マイクロサービスアーキテクチャは、ビジネスロジックをエンドポイントに転送し、HTTPなどの簡単な通信方法を使用します。

分散管理

重要なマイクロサービスの決定は、マイクロサービスを真に開発する人々によって行われなければなりません。ここで、重要な決定とは、プログラミング言語、展開方法、パブリックインターフェイス契約などの選択を意味します。

分散データ管理

従来のアプローチでは、アプリケーションにはデータベースが1つしかなく、アプリケーションのビジネスロジックのさまざまなコンポーネントがこのデータベースのフレームワーク内で「対話」します。他のコンポーネントに属するデータを直接読み取ります。また、一部のコンポーネントではこれが最良の状況ではない場合でも、すべてのコンポーネントが同程度のデータ整合性によって特徴付けられることを意味します（ Martin Fowler ）。

マイクロサービスアーキテクチャでは、各ビジネスコンポーネントがマイクロサービスである場合、すべてのコンポーネントには他のマイクロサービスでは利用できない独自のデータベースがあります。コンポーネントデータは、対応するコンポーネントインターフェイスを介してのみ使用できます（読み取りおよび書き込み用）。このため、データの安定性の程度はコンポーネント（ Martin Fowler 、 Chad Fowler ）によって異なります。

フレッドジョージの観点から見ると、これはマイクロサービスアーキテクチャの最初の課題です。

インフラストラクチャの自動化

継続的な展開 （ Martin Fowler 、 Rebecca Parsons 、 Chad Fowler 、 Eric Evans ）：

「青」と「緑」の展開： ダウンタイムゼロ 。
自動化：ボタンをクリックするだけで、複数のサーバーを展開できます。
Phoenixサーバー：クイックスタートとストップ。
監視：何かがうまくいかなかったときに気付き、デバッグできます。

故障保険（故障の設計）

アプリケーションが配布されるサーバー、特に異なるノードは遅かれ早かれ落ちます。したがって、アプリケーションアーキテクチャは、このような障害に耐える必要があります（ Martin Fowler ）。

Chaos monkeyはNetflixが作成したツールです。サーバーをオフにして、このタイプの障害に対するシステムの安定性を確認できます（ Martin Fowler ）。

Rebecca Parsonsは、サービス間でインプロセスインタラクションを使用しないことが非常に重要であると考えています。代わりに、通信にHTTPを使用しています。その結果、サービスの相互通信に障害が発生し、システムはこれに対応する必要があります。

進化的アーキテクチャ

アプリケーション全体のアーキテクチャは静的である必要はなく、ビジネスのニーズに応じた単純な開発の可能性が必要です。たとえば、次のことができます。

ビジネスロジックセット（制限されたコンテキスト）を個別のマイクロサービスに分離して転送することにより、単一のアプリケーションをマイクロサービスアプリケーションに変換（リファクタリング）する。
たとえば、異なるマイクロサービスを同時に頻繁に変更する必要がある場合などに、既存のマイクロサービスを組み合わせます。
既存のマイクロサービスを個別に開発する必要があり、可能な場合、または分離がビジネスロジックに深刻な影響を与えることがわかっている場合は、既存のマイクロサービスを分離します。
一定の時間機能するマイクロサービスを作成して、アプリケーションに一時的に何らかの機能を追加します。

フロントエンド/バックエンド

マイクロサービスアーキテクチャのフロントエンドとバックエンドを構造化するには、2つのアプローチがあります。

マイクロサービスのユーザーインターフェイスのすべての部分を分散させ、各マイクロサービス間の関係を維持します。これにより、フロントエンドとバックエンドの間のインプロセス相互作用を確立できます。ただし、可能な場合、UI接続を維持することは非常に困難です。 UIの国境を越えた変更の場合、複数のマイクロサービスを同時に更新し、相互接続を作成し、アーキテクチャ自体によって提供されるマイクロサービスの分離と独立性に違反する必要があります。それはほとんどアンチパターンであることが判明しました！
フロントエンドとバックエンドのコードベースを分散させ、アプリケーションUIをそのままにして、HTTP経由で通信できるようにします。マイクロサービスは互いに分離され、フロントエンドとバックエンドがさらに分離されます。ただし、UIは完全にサポートされ、接続を簡単に維持できます。この構造はレイチェル・マイヤーズによって推奨されており、私が理解しているように、これが唯一の方法です。この場合、フロントエンドとバックエンド間の相互作用には2つのオプションがあります。
1. 1つの大きな要求ではなく、多くの小さな非同期HTTP要求により、ブロックの可能性が排除されます（このアプローチはChad Fowlerが推奨しています）。
2. マイクロサービスエコシステム全体からデータを収集する特殊なサービス（ゲートウェイ/アグリゲーター/キャッシュ）への大きな要求。これにより、UIの複雑さが軽減されます。

危険

テクノロジーの俊敏性を管理する必要がある

マイクロサービスの利点の1つは、さまざまなテクノロジーを使用して同じ問題を解決できることです。たとえば、各マイクロサービスで、XML解析用の異なるライブラリまたは異なるデータストレージツールを使用します。しかし、機会そのものは、私たちがそれをするべきだという意味ではありません。豊富なテクノロジーとライブラリーが制御不能になる可能性があります。したがって、基本的なツールセットを選択し、本当に必要な場合にのみ他のツールを参照してください（ Rebecca Parsons ）。

インターフェイスの不安定性を管理する必要がある

マイクロサービスの開発の初期段階では、そのAPIは特に不安定です。しかし、マイクロサービスが十分に開発された後の段階でも、API、その入力と出力を変更する必要があります。他のアプリケーションはAPIの安定性に依存するため、変更を慎重に行ってください（ Rebecca Parsons ）。

データの一貫性を確保する

マイクロサービスには独自のデータウェアハウスがあります。多くの場合、あるマイクロサービスに属するデータは、別のクライアントマイクロサービスによって部分的または全体的にコピーされます。 プロバイダーのデータが変更されると、イベントがトリガーされ、クライアントマイクロサービスによってコピーされたデータの更新がトリガーされます。イベントはメッセージキューに入り、クライアントマイクロサービスが受信するのを待ちます。

このスキームは、目的のイベントを検出するまで、クライアントのマイクロサービスが古いデータを持つことを意味します。データに一貫性がありません。

もちろん、最終的に、変更はすべてのコピーに適用され、データの整合性が再び取れるようになります。これは結果整合性と呼ばれ、最終的には整合性です。つまり、短期間、データの一貫性が失われることがわかっています。この効果は、サーバー側からUXレベル（ Rebecca Parsons ）まで、アプリケーション開発中に重要です。

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

アプリケーションの作成を開始するとき、最初は単一のアーキテクチャに従う必要があります-その単純さからです。同時に、可能な限りモジュール化して、各コンポーネントを個別のマイクロサービス（ Rebecca Parsons ）に簡単に転送できるようにする必要があります。これは、単一のデプロイ可能なモジュール内の別個のコンポーネントのセットとしてアプリケーションを開発するというサイモンブラウンのアイデアと組み合わされています。

単一のアーキテクチャをマイクロサービスまたは個別のコンポーネントのセットに分解する場合、ソリューションをサポートするいくつかの側面を考慮する必要があります。

DDD（ Rebecca Parsons 、 Rachel Myers ）で定義されている限られたコンテキストを考えてください
- 各マイクロサービスは、ビジネスの概念の観点および技術的な観点から、限られたコンテキストでなければなりません。通常、マイクロサービス内では、コード要素間（データおよび/またはビジネスロジック間）の接続と、外部コード要素への複数の接続が必要です。
ビジネスチャンスについて考える（Rebecca Parsons： 1、2 ）
- 組織にはどのような価値ストリームがありますか？ビジネス製品？どのようなビジネスサービスが提供されますか？
消費者のニーズについて考える（Rebecca Parsons： 1、2、3 ）
- 製品を作成者としてだけでなく、消費者としても見ることができます。彼らは私たちのサービスに何を望んでいますか？彼らはそれをどのように使用しますか？彼らは何を期待していますか？
相互作用パターンを考えます。
- システムのどの部分が同じデータを使用できますか？どのビジネスロジックがより集中的に相互作用しますか？（レベッカパーソンズ： 1、2、3 ）
- 1つのマイクロサービスが他の多くのマイクロサービスに厳密に依存しているため、アーキテクチャに単一障害点がありますか？（レイチェルマイヤーズ）
データアーキテクチャについて考える（Rebecca Parsons： 1、2、3 、 Rachel Myers ）
- サービスには独自のデータがあり、独自のデータベースがあり、長期的には一貫性の原則から進む必要があります。 2つのデータ構造が互いに非常に依存している場合、それらを1つのマイクロサービスに保持すると、長期的に一貫性を保つためのメカニズムを作成する必要がなくなります。
相互接続された変更パターンを考えます（Rebecca Parsons： 1、2、3 、 Rachel Myers ）
- 2つのコード要素の同時変更を予測できる場合は、APIを変更するための不必要な作業を排除するために、1つのマイクロサービスにそれらを保存することをお勧めします。
サービスをマージおよび分割する準備をします （ Rebecca Parsons ）
- おそらくこれを時間通りに常に実行できるとは限りません。しかし、経験を積んでタスクを深くするにつれて、限られたコンテキストの場所をよりよく理解し始めます。ビジネスも変化し、すぐに適応する必要があります！したがって、このシステムにより、マイクロサービスを迅速に共有および統合できるようになります。
トレラントリーダーテンプレート（ Rebecca Parsons ）
- 下位互換性の重大な変更（下位互換性の破壊的な変更）が常に必要になる場合があります。ただし、これは最後の手段としてのみ行うことができます。サービスを常に変更しないようにするには、本当に重要なデータを変更する場合にのみサービスを変更する必要があるようにサービスを作成します。
ステートレスノードとフェニックスノード （レイチェルマイヤーズ、チェドファウラー、エリックエバンス）
- アプリケーションやサービスで静的ファイル（HTML、CSS、JS、画像）を複製しないでください。
- ユーザーインターフェイスアプリケーションは、マイクロサービスエコシステムから完全に分離する必要があります。
- 単一ノードを使用します。
- 不変の展開を使用する：既存のノードでソフトウェアをアップグレードしないでください。
構成の優先順位に関する規約 （ Chad Fowler ）
- アーキテクチャで採用されている構造と命名システムは、マイクロサービスエコシステム全体で同じである必要があります。
- マイクロサービスサンドボックスジェネレーターを作成して、使い慣れた構造が既に定義されている開始点を用意します。
マイクロサービス間の相互作用の最適化 （ Chad Fowler ）
- REST呼び出し用に最適化された基本的なHTTP RESTクライアントライブラリを作成し、それに基づいて特定のマイクロサービスクライアントを構築できます。他のマイクロサービスはそれを使用します。この最適化されたクライアントは、エコシステムで使用されるすべての言語に移植する必要があります。
サービス発見 （ Chad Fowler ）
- 各マイクロサービスは、他のマイクロサービスに連絡する方法を知っている必要があります。マイクロサービスの場所を変更すると、すべての場所ですぐに更新されるローカライズされた（各サービスの）構成を使用できます。
モニタリング （ Chad Fowler ）
- ネットワーク、マシン、アプリケーションのすべてを測定します。
- 新しいマイクロサービスを作成する場合、必要なすべての監視機能を装備する必要があります。
単一のアーキテクチャからマイクロサービスへの移行 （ Chad Fowler ）
- 少数の大きなクエリではなく、多数の小さなクエリを使用することをお勧めします（結合を削除します）。
- 個別のデータベース。
- マイクロサービス、プロトタイプの形で新しい機能を作成します。
- 古いシステムのコードを新しいマイクロサービスのAPI呼び出しに置き換えます。
- 異常な状態で、異常な負荷の下でテストします。
( )
- .
- .
- => (spot instances) AWS 85 95 % .
( )
- Docker.

おわりに

, . , (, ) , , , , .

, . , , , . .

便利なリンク

記事

Werner Vogels • 2008 • Eventually Consistent – Revisited

Oracle • 2012 • De-mystifying “eventual consistency” in distributed systems

• 2014 • Microservices

• 2015 • The State of the Art in Microservices

• 2015 • From Homogeneous Monolith to Radically Heterogeneous Microservices Architecture

• 2015 • DDD & Microservices: At Last, Some Boundaries!

• 2015 • Challenges in implementing Microservices

• 2015 • Microservices and the Inverse Conway Manoeuvre

- • 2014 • Real World Microservices

• 2015 • Microservices

• 2015 • Stop Building Services, Episode 1: The Phantom Menace

• 2015 • Evolutionary Architecture & Micro-Services

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

内容