マイクロサービスアーキテクチャ：
私から 、マイクロサービスアーキテクチャの基本を理解している必要があります。しかし、プロであること 基本以上のものが必要になります。 このブログでは、アーキテクチャの概念を深く掘り下げ、UBERのケーススタディを使用してそれらを実装します。
このブログでは、次のことについて学びます。
- マイクロサービスアーキテクチャの定義
- マイクロサービスアーキテクチャの重要な概念
- マイクロサービスアーキテクチャの長所と短所
- UBER –ケーススタディ
あなたは参照することができます 、マイクロサービスの基本と利点を理解する。
マイクロサービスの定義を説明した場合にのみ公平になります。
マイクロサービスの定義
そのため、マイクロサービス、別名マイクロサービスアーキテクチャの適切な定義はありませんが、さまざまな操作を実行する、個別にデプロイ可能な小さなサービスで構成されるフレームワークであると言えます。
マイクロサービスは、完全に独立したデプロイ可能なサービスとして実装し、さまざまなテクノロジースタックに実装できる単一のビジネスドメインに焦点を当てています。
図1： モノリシックアーキテクチャとマイクロサービスアーキテクチャの違い–マイクロサービスアーキテクチャ
値による受け渡しと参照による受け渡しjava
モノリシックアーキテクチャとマイクロサービスアーキテクチャの違いを理解するには、上の図を参照してください。両方のアーキテクチャの違いをよりよく理解するには、以前のブログを参照してください。
理解を深めるために、マイクロサービスアーキテクチャのいくつかの重要な概念について説明します。
マイクロサービスアーキテクチャの重要な概念
マイクロサービスを使用して独自のアプリケーションの構築を開始する前に、アプリケーションの範囲と機能について明確にする必要があります。
以下は、マイクロサービスについて説明する際に従うべきガイドラインです。
マイクロサービスを設計する際のガイドライン
- 開発者として、アプリケーションを構築する場合は、ドメインを分離し、機能を明確にします。
- 設計する各マイクロサービスは、アプリケーションの1つのサービスのみに集中する必要があります。
- 各サービスが個別にデプロイできるようにアプリケーションを設計したことを確認してください。
- マイクロサービス間の通信がステートレスサーバーを介して行われていることを確認してください。
- 各サービスは、独自のマイクロサービスを使用して、さらに小さなサービスにリファクタリングできます。
これで、マイクロサービスを設計する際の基本的なガイドラインを読み終えたので、マイクロサービスのアーキテクチャを理解しましょう。
マイクロサービスアーキテクチャはどのように機能しますか？
一般的なマイクロサービスアーキテクチャ（MSA）は、次のコンポーネントで構成されている必要があります。
- クライアント
- IDプロバイダー
- ゲートウェイAPI
- メッセージングフォーマット
- データベース
- 静的コンテンツ
- 管理
- サービスディスカバリ
下の図を参照してください。
図2： マイクロサービスのアーキテクチャ–マイクロサービスアーキテクチャ
アーキテクチャが少し複雑に見えることは知っていますが、私あなたのためにそれを単純化してください。
1.クライアント
アーキテクチャは、検索、ビルド、構成などのさまざまな管理機能を実行しようとするさまざまなデバイスからのさまざまなタイプのクライアントから始まります。
2.アイデンティティプロバイダー
次に、クライアントからのこれらの要求は、クライアントの要求を認証し、APIGatewayに要求を伝達するIDプロバイダーに渡されます。リクエストは、明確に定義されたAPIゲートウェイを介して内部サービスに伝達されます。
3.APIゲートウェイ
クライアントはサービスを直接呼び出さないため、API Gatewayは、クライアントが適切なマイクロサービスにリクエストを転送するためのエントリポイントとして機能します。
APIゲートウェイを使用する利点は次のとおりです。
- すべてのサービスは、クライアントが知らなくても更新できます。
- サービスは、Web対応ではないメッセージングプロトコルを使用することもできます。
- API Gatewayは、セキュリティの提供、負荷分散などの分野横断的な機能を実行できます。
クライアントの要求を受信した後、内部アーキテクチャは、クライアントの要求を処理するためにメッセージを介して相互に通信するマイクロサービスで構成されます。
4.メッセージングフォーマット
それらが通信するメッセージには2つのタイプがあります。
- 同期メッセージ： クライアントがサービスからの応答を待つ状況では、マイクロサービスは通常、 REST（Representational State Transfer） ステートレスのクライアントサーバーに依存しているため、 HTTPプロトコル 。このプロトコルは分散環境であるため使用され、すべての機能は操作を実行するためのリソースで表されます
- 非同期メッセージ： クライアントがサービスからの応答を待たない状況では、マイクロサービスは通常、次のようなプロトコルを使用する傾向があります。 AMQP、STOMP、MQTT 。メッセージの性質が定義されており、これらのメッセージは実装間で相互運用可能である必要があるため、これらのプロトコルはこのタイプの通信で使用されます。
頭に浮かぶかもしれない次の質問は、マイクロサービスを使用するアプリケーションがデータをどのように処理するかということです。
5.データ処理
各マイクロサービスは、データをキャプチャしてそれぞれのビジネス機能を実装するためのプライベートデータベースを所有しています。また、マイクロサービスのデータベースは、サービスAPIを介してのみ更新されます。次の図を参照してください。
図3： データを処理するマイクロサービスの表現–マイクロサービスアーキテクチャ
マイクロサービスによって提供されるサービスは、さまざまなテクノロジースタックのプロセス間通信をサポートするリモートサービスに引き継がれます。
6.静的コンテンツ
マイクロサービスは内部で通信した後、静的コンテンツをクラウドベースのストレージサービスにデプロイします。クラウドベースのストレージサービスは、マイクロサービスを介してクライアントに直接配信できます。 コンテンツ配信ネットワーク（CDN） 。
上記のコンポーネントとは別に、一般的なマイクロサービスアーキテクチャに表示されるコンポーネントがいくつかあります。
7.管理
このコンポーネントは、ノード上のサービスのバランスを取り、障害を特定する役割を果たします。
8.サービスディスカバリ
ノードが配置されているサービスのリストを維持するため、マイクロサービス間の通信ルートを見つけるためのガイドとして機能します。
新しいアップデートを入手するには、YouTubeチャンネルに登録してください。
それでは、このアーキテクチャの長所と短所を調べて、このアーキテクチャをいつ使用するかをよりよく理解しましょう。
マイクロサービスアーキテクチャの長所と短所
以下の表を参照してください。
| マイクロサービスアーキテクチャの長所 | マイクロサービスの短所 建築 |
| さまざまなテクノロジーを自由に使用できます | トラブルシューティングの課題が増える |
| 各マイクロサービスは、単一のビジネス機能に重点を置いています | リモート呼び出しによる遅延が増加します |
| 個々の展開可能なユニットをサポート | 構成およびその他の操作に対する労力の増加 |
| 頻繁なソフトウェアリリースを許可します | 取引の安全性を維持するのが難しい |
| 各サービスのセキュリティを確保します | さまざまなサービス境界を越えてデータを追跡するのは難しい |
| 複数のサービスが並行して開発および展開されます | サービス間でコードを移動するのが難しい |
UBERの以前のアーキテクチャと現在のアーキテクチャを比較して、マイクロサービスについて詳しく理解しましょう。
UBERケーススタディ
UBERの以前のアーキテクチャ
多くの新興企業と同様に、UBERは、単一の都市で単一のサービスを提供するために構築されたモノリシックアーキテクチャから旅を始めました。当時、コードベースが1つあれば問題は解決したようで、UBERのコアビジネスの問題は解決しました。しかし、UBERが世界中に拡大し始めると、スケーラビリティと継続的インテグレーションに関してさまざまな問題に直面しました。
図4： UBERのモノリシックアーキテクチャ–マイクロサービスアーキテクチャ
Javaのハッシュマップとハッシュテーブル
上の図は、UBERの以前のアーキテクチャを示しています。
- 乗客とドライバーが接続するRESTAPIが存在します。
- 3つの異なるアダプターがAPIとともに使用され、請求、支払い、タクシーの予約時に表示される電子メール/メッセージの送信などのアクションを実行します。
- すべてのデータを格納するMySQLデータベース。
したがって、ここで気付いた場合、乗客管理、請求、通知機能、支払い、旅行管理、ドライバー管理などのすべての機能が単一のフレームワーク内で構成されています。
問題文
UBERが世界的に拡大し始めた一方で、この種のフレームワークはさまざまな課題をもたらしました。以下は、いくつかの顕著な課題です
- 単一の機能を更新するには、すべての機能を再構築、展開、およびテストする必要がありました。
- 開発者はコードを何度も変更する必要があったため、単一のリポジトリでバグを修正することは非常に困難になりました。
- 世界中で新機能が導入されると同時に機能をスケーリングすることは、一緒に処理するのが非常に困難でした。
解決
このような問題を回避するために、UBERはアーキテクチャを変更し、Amazon、Netflix、Twitterなどの他の急成長企業をフォローすることにしました。したがって、UBERは、モノリシックアーキテクチャを複数のコードベースに分割して、マイクロサービスアーキテクチャを形成することを決定しました。
UBERのマイクロサービスアーキテクチャを確認するには、下の図を参照してください。
図5： UBERのマイクロサービスアーキテクチャ–マイクロサービスアーキテクチャ
- ここで観察される主な変更は、すべてのドライバーと乗客が接続されるAPIゲートウェイの導入です。 API Gatewayから、乗客管理、ドライバー管理、旅行管理など、すべての内部ポイントが接続されます。
- ユニットは、個別の機能を実行する個別の展開可能なユニットです。
- 例：課金マイクロサービスの内容を変更する場合は、課金マイクロサービスのみをデプロイするだけで、他のマイクロサービスをデプロイする必要はありません。
- すべての機能が個別にスケーリングされるようになりました。つまり、各機能間の相互依存性が削除されました。
- たとえば、タクシーを検索する人の数は、実際にタクシーを予約して支払いをする人よりも比較的多いことは誰もが知っています。これにより、乗客管理マイクロサービスで動作するプロセスの数が、支払いで動作するプロセスの数よりも多いことが推測されます。
これで仕方、UBERはシフトの恩恵を受けましたそのモノリシックからマイクロサービスまでのアーキテクチャ。
マイクロサービスアーキテクチャに関するこの投稿をお楽しみいただけたでしょうか。実践的なブログも追加する予定です。
マイクロサービスの詳細に興味がありますか？
マイクロサービスを学び、独自のアプリケーションを構築したい場合は、 インストラクター主導のライブトレーニングと実際のプロジェクト経験が付属しています。このトレーニングは、マイクロサービスを深く理解し、主題をマスターするのに役立ちます。
質問がありますか？ 」のコメントセクションでそれについて言及してください マイクロサービスアーキテクチャ 」と私はあなたに戻ります。