実験応用
クライアントは利用可能なアパートのリストを表示して予約し、サービスに自分のアパートを置くこともできます。
構築の古典的なアプローチでは、フレームワークが最も頻繁に選択され、コンポーネントがその内部に実装されます。 マイクロサービスの場合、コンポーネントごとに個別のアプリケーションが構築され、独自のツールセットが選択されます。 ほとんどの場合、コンポーネントはREST APIを介して対話します。
コンポーネント： C-アパートのデータ（コア）、1-予約、2-支払い、3-予約による予約、4-アパートの宿泊、5-コンテンツ管理。
マイクロサービスアプリケーションを作成する前に、ビジネスロジックを熟考し、アプリケーションを自給自足のコンポーネントに分割する必要があることに注意してください。 次に、マイクロサービスが優れている理由について説明します。
各タスクには独自のツールがあります。
ハンマーを使って釘を打ちます。 これは、IT製品の開発にも適用されます。
たとえば、アプリケーションの3番目のコンポーネントであるロギングを検討してください。 最も基本的な意味では、テキストを異なるファイルに書き込むだけです。
複雑なフレームワークとデータベースは必要ないことがわかりました。 実装には、ファイルへの書き込み用のシンプルなモジュール、rest-api、および開発とサポートのためのかなりの人/時間で十分です。
かけがえのない
多数のSaaSソリューションが毎日市場に登場し、さまざまな問題を解決しています。 また、独自のサービスを提供するよりもこのようなソリューションを使用する方が簡単だと理解している場合は、マイクロサービスの1つを削除して、SaaSサービスに置き換えることができます。 この場合、APIとの対話のみを変更する必要があります。
ここで、最も適切な例は、支払いサービス（2番目のコンポーネント）です。 ただし、SaaSソリューションから独自のソリューションへの移行について話す方が適切です。 たとえば、手数料の割合を減らすため。
各自に
1つのプロジェクト内で、さまざまなタイプのユーザーの対話ロジックを処理する必要があります。 プロジェクトのスタッフ（管理者やモデレーターなど）も例外ではありません（モジュール4および5）。
ただし、これらのグループのニーズは異なり、各グループごとに独自のインターフェイスが開発されていることに留意してください。 別のインターフェイスのロジックがアプリケーションのロジックと一致する場合、それは素晴らしいことです。 これにより、新しい定性レベルでタスクに取り組むことができます。
あなたが大きいときでも、あなたは小さいです
非常に優れたアーキテクチャであっても、20人以上の人が1つのプロジェクトのコードで作業すると、問題が生じます。 さらに多くのバグがあり、テストは拷問に変わります。 その結果、製品の開発は非常に難しく、更新を通じて質的に飛躍することはほとんど不可能です。
重要な各コンポーネントを個別のマイクロサービスに分離することにより、開発の品質を向上させるだけでなく、既存のタスクのフレームワーク内の開発者の数を減らし、解放された人/時間を新しい開発に費やすことができます。
その結果、6つのコンポーネントのそれぞれが1〜3人の開発者によって提供されます。 また、彼らの仕事では、彼らは並列マイクロサービスの同僚と交差しません。 また、バージョン管理のフレームワーク内でマイクロサービスを使用すると便利です。これは、クラシックAPIで簡単に実装できます。
まとめ
おそらく、これはあなたの使い慣れた開発エコシステムへの介入の場合のように、冗長で複雑に見えるでしょう。 ただし、マイクロサービスアーキテクチャは、少なくとも1回は無料で試してみる価値があります。
また、各新製品の基本機能は、既製のマイクロサービスから組み立てることができます。 そしてそれは素晴らしいです！
この概念の詳細な研究については、この出版物を読むことをお勧めします： habrahabr.ru/post/249183
好意
マイクロサービス設計