前書き
建築スタイルの選択は、情報システムを構築する上での基本的な技術的解決策の1つです。このシリーズの記事では、アプリケーションを構築するための最も人気のあるアーキテクチャスタイルを分析し、いつ最も好ましいアーキテクチャスタイルであるかという質問に答えることを提案します。その過程で、モノリスからマイクロサービスまでの建築スタイルの開発を説明する論理的な連鎖をたどろうとします。
前回は、さまざまな種類のモノリスと、コンポーネントを使用してそれらを構築する方法（アセンブリコンポーネントと展開コンポーネントの両方）について説明しました。私たちはサービス指向のアーキテクチャを扱ってきました。
最後に、マイクロサービスアーキテクチャの主な特性を定義します。
アーキテクチャの関係
以前の定義記事のデータに基づくと、すべてのサービスがコンポーネントですが、すべてのサービスがマイクロサービスであるとは限らないことを理解する必要があります。
マイクロサービスアーキテクチャの特徴
マイクロサービスアーキテクチャの主な特徴は次のとおりです。
- ビジネス機能を中心に編成
- プロジェクトではない製品
- スマートエンドポイントとダムパイプ
- 分散型ガバナンス
- 分散型データ管理
- インフラストラクチャの自動化
- 失敗のための設計
- 進化的デザイン
マイクロサービスはサービスの特殊なケースであるため、最初のポイントはサービス指向アーキテクチャにあります。その他の点については、別途検討する必要があります。
ビジネス機能を中心に編成
ここで、コンウェイの法則を思い出す必要があります。システムを作成する組織は、そのアーキテクチャを編成し、これらの組織内の相互作用の構造をコピーします。例として、コンパイラを作成した場合を思い出すことができます。7人のチームが7パスのコンパイラを開発し、5人のチームが5パスのコンパイラを開発しました。
モノリスとマイクロサービスについて話している場合、開発が機能部門（バックエンド、フロントエンド、データベース管理者）によって編成されていると、古典的なモノリスが得られます。
マイクロサービスを利用するには、チームをビジネスチャンス（注文、出荷、カタログチーム）ごとに編成する必要があります。この組織により、チームはアプリケーションの特定の部分の作成に集中できます。
プロジェクトではない製品
マイクロサービスアーキテクチャの場合、チームが開発した機能を他のチームに転送するプロジェクトアプローチは完全に不適切です。チームは、ライフサイクル全体を通じてシステムをサポートする必要があります。マイクロサービス採用の旗艦の1つであるAmazonは、「構築し、実行する」と述べています。製品アプローチにより、チームはビジネスのニーズを感じることができます。
スマートエンドポイントとダムパイプ
SOAアーキテクチャは、通信チャネル、特にエンタープライズサービスバス（エンタープライズサービスバス）に多くの注目を集めています。これはしばしば誤ったスパゲッティボックスにつながります。つまり、モノリスの複雑さがサービス間の接続の複雑さに変わります。マイクロサービスアーキテクチャは、単純な通信方法のみを使用します。
分散型ガバナンス
マイクロサービスの重要な決定は、実際にマイクロサービスを開発する人々が行う必要があります。ここで重要な決定とは、
プログラミング言語、展開方法、パブリックインターフェイス契約などの選択を意味します。
分散型データ管理
アプリケーションが単一のデータベースに依存する標準的なアプローチでは、特定の各サービスの詳細を考慮に入れることはできません。MSAは、さまざまなテクノロジを使用するまで、分散型のデータ管理を想定しています。
インフラストラクチャの自動化
MSAは、継続的な展開および配信プロセスをサポートします。これは、プロセスを自動化することによってのみ実行できます。同時に、多数のサービスの展開はもはや恐ろしいもののようには見えません。展開プロセスは退屈になるはずです。2番目の側面は、製品環境でのサービス管理に関連しています。自動化がなければ、異なるオペレーティング環境で実行されているプロセスを管理することは不可能になります。
失敗のための設計
多くのMSAサービスは失敗する傾向があります。同時に、分散システムでのエラー処理は簡単な作業ではありません。アプリケーションアーキテクチャは、このような障害に対して回復力がなければなりません。Rebecca Parsonsは、サービス間のインプロセス通信を使用しないことが非常に重要であると考えています。代わりに、通信にHTTPを使用しますが、これは信頼性がほとんどありません。
進化的デザイン
MSAシステムアーキテクチャは進化する必要があります。必要な変更を1つのサービスの境界に制限することが望ましいです。他のサービスへの影響も考慮する必要があります。従来のアプローチは、バージョンコントロールを使用してこの問題を修正することですが、MSAは
、最後の手段としてバージョンコントロールを使用することをお勧めします。
結論
上記のすべての後で、マイクロサービスとは何かを定式化できます。マイクロサービスアーキテクチャは、単一のアプリケーションを小さなサービスのコレクションとして開発するためのアプローチであり、各サービスは独自のプロセスで実行され、軽量のメカニズム（多くの場合HTTPリソースAPI）を介して相互作用します。これらのサービスはビジネス機能に基づいて構築されており、完全に
自動化された展開エンジンを使用して個別に展開できます。これらのサービスには最低限の集中管理があり、さまざまなプログラミング言語で記述でき、さまざまなストレージテクノロジーを使用できます。パート2を読む
