Service Discovery_システム設計ノート 7

一.アプリケーション層

シンプルな 3 層構造では、Web サービス層はリクエストを処理すると同時にビジネス機能も担います：

より優れた構造は Web 層とアプリケーション層（プラットフォーム層とも呼ぶ）を分離することです：

優位性は以下の通り：

アプリケーション層を単独で拡張可能：独立してマシンを追加したり、専用マシンに交換したりすることを許可
インフラストラクチャを复用：マルチエンドサポートを簡素化し、キャッシュ、データベースなどの処理をすべて复用可能
組織の拡張を容易に：1 つのチームがプラットフォーム自体の実装/最適化を担当し、他の複数のチームがプラットフォーム機能を利用して開発

アプリケーション層を分離した後、次に直面する問題はアプリケーション層内部でどのように職責を划分し、どのように協同作業するかで、也就是マイクロサービスアーキテクチャが解決しようとする問題です

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

マイクロサービスアーキテクチャはアプリケーションを一連の疎結合な細粒度サービスとして設計し、軽量な通信プロトコルを通じて組織することを提唱：

In a microservices architecture, an application is structured as a collection of loosely coupled services, which are fine-grained and the protocols are lightweight.

これらのサービスはすべて独立してデプロイ、独立して拡張可能で、各サービスは堅固なモジュール境界を持ち、異なるプログラミング言語を使用して異なるサービスを作成することも、異なるチームが管理することも許可：

P.S. マイクロサービスアーキテクチャに関するより多くの情報は、マイクロサービスアーキテクチャ（Microservices）を参照

マイクロサービスアーキテクチャの下で、アプリケーションは複数のサービスに拆分され、そ��ぞれ（異なるマシンの）異なるプロセスで実行：

各マイクロサービスが単一のマシンのみで実行される場合、1 つのマイクロサービスは静的設定表を通じて他の依存サービスを見つけることができ、进而サービス間通信を通じて協力を完了

しかし、実際のシナリオでは、1 つのマイクロサービスは通常複数のマシンにデプロイされ、必要に応じて動的に伸縮（マシンの増減）します。シンプルな静的設定では明らかに満足できないため、1 つのサービス登録照会メカニズムが必要です：

つまり Service Discovery です

三.Service Discovery

クライアント側 Service Discovery

クライアントがサービス登録表を照会し、目標サービスの一連のアドレスを取得し、ロードバランシング戦略に基づいてその中から 1 つを選択してリクエストを開始（つまりクライアント側ロードバランシング）

その中で、サービス登録表（service registry） は利用可能なすべてのサービスインスタンスを保存し、管理（登録/登録解除）と照会 API を提供：

The service registry is a database of available service instances. The service registry provides a management API and a query API. Service instances are registered with and deregistered from the service registry using the management API. The query API is used by system components to discover available service instances.

具体的には、サービスインスタンスを起動する時に、登録表にそのネットワーク位置を追加し、サービスを停止する時に記録を削除し、サービスインスタンスの実行期間中、ハートビートメカニズムを通じて周期的に登録情報を更新

P.S. 例えば Netflix Eureka は REST API を提供してサービスインスタンスの登録/登録解除、照会に使用：

Netflix Eureka provides a REST API for registering and querying service instances. A service instance registers its network location using a POST request. Every 30 seconds it must refresh its registration using a PUT request. A registration is removed by either using an HTTP DELETE request or by the instance registration timing out. As you might expect, a client can retrieve the registered service instances by using an HTTP GET request.

および配套の Netflix Ribbon、クライアント側ロードバランシングとして使用

このモードは比較的シンプルで、クライアントがより賢い（例えばアプリケーション固有の）ロードバランシング決定を行えますが、いくつかの欠点も存在：

クライアントが使用する各言語ごとに 1 つずつ実装する必要
高可用の登録サービスを自行で維持する必要
サービス発見関連ロジックがすべてクライアントで実装され、例えば再試行、クライアントが比較的重くなる

DNS-SD

特殊的、DNS をサービス登録表として使用でき、DNS-SD（DNS-based Service Discovery）と呼ぶ

DNS SRV 記録を通じてサービスからインスタンスへの 1 対多マッピングを完了：

SRV 記録（Service locator record）：通用サービス定位記録、サービスが所在するサーバー（ドメイン名とポート番号）を指定、主に SIP（Session Initiation Protocol、セッション開始プロトコル）に使用

（資源記録 | DNS_システム設計ノート 3 から抜粋）

例えば：

$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2
Server:		10.0.0.2
Address:	10.0.0.2#53

_http._tcp.backends.example.com	service = 0 2 8090 backend-0.example.com.
_http._tcp.backends.example.com	service = 0 1 8091 backend-1.example.com.
_http._tcp.backends.example.com	service = 10 1 8092 backend-2.example.com.

DNS を借助するとシンプルで操作しやすいですが、DNS の更新時効（キャッシュ問題）に制限されます

サーバー側 Service Discovery

もちろん、照会プロセスはサーバー側で完了することも：

クライアントがロードバランサーを通じて目標サービスにリクエストし、ロードバランサーが登録表を照会して利用可能なインスタンスのグループを取得し、ロードバランシング戦略に基づいてその中から 1 つを選択してリクエストを開始

P.S. 例えば AWS Elastic Load Balancer (ELB)

このモードでは、クライアントは各種言語、異なるフレームワークのためにサービス照会ロジックを実装する必要がなく、シンプルにロードバランサーにリクエストを開始すればよいですが、デプロイプラットフォームがこの能力を提供していない場合、このような高可用のシステムコンポーネントを自行で建立し維持する必要

四.サービス登録と登録解除

Service Discovery 中、サービスインスタンスはサービス登録表に登録し、時機に注销する必要があり、自登録と第三者登録の 2 種モードに分かれます

自登録モード

自登録モードでは、サービスインスタンスが自分をサービス登録表に登録し、そこから注销することを担当し、必要であれば、ハートビートリクエストを送信してアクティブを維持し、登録期限切れを回避

この方式は比較的シンプルで、他のシステムコンポーネントに依存しませんが、サービスインスタンスとサービス登録メカニズムが結合し、以致って登録ロジックを各種言語、異なるフレームワークのクライアントですべて 1 つずつ実装する必要

P.S. Netflix OSS Eureka client が採用しているのはこのモードで、Eureka クライアントがサービスインスタンスの登録と注销を処理

第三者登録モード

サービスインスタンスはもはや登録/注销を担当せず、サービス登記員（service registrar）に交由して処理し、サービスインスタンスと登録メカニズム間の結合関係を解除。登記員はデプロイプラットフォームを輪詢またはイベントを購読してサービスインスタンスの実行状態を追跡し、新しいサービスインスタンスを発見すれば登録し、サービスインスタンスが停止したのを発見すれば注销

P.S. Registrator がこのモードを採用し、Docker コンテナでデプロイされたサービスの自動登録/注销をサポート

特殊的、デプロイプラットフォームはサービスインスタンスの起動と停止を掌控しており、それが登録、注销を完了するのが最も適切。事実、Kubernetes や Marathon などのデプロイプラットフォームもサービス登録、照会の能力を提供。具体的には、クラスタ中の各ノードで実行されている代理サービスをサーバー側 Service Discovery 中のロードバランサーとして使用し、クライアントが代理にリクエストを送信し、代理サービスがクラスタ中の他のノード上の利用可能なインスタンスに転送

五.まとめ

マイクロサービスアーキテクチャはサービスの分割と依存関係の結合解除を担当し、Service Discovery はこれらのサービス間の通信問題を解決し、あるマイクロサービスが別のマイクロサービスを見つけられるようにします

実装上、クライアント側 Service Discovery とサーバー側 Service Discovery の 2 種に分かれ、違いは照会/選択ロジックがクライアント側かサーバー側で実装されるか。そしてサービスの登録/注销はサービス自身が完了（自登録）、またはデプロイプラットフォームなどの第三者が完了（第三者登録）