マイクロサービストピック08-SpringCloudサービスディスカバリ

序文

前の章では、SpringCloudの構成管理について説明しました。このセクションでは、マイクロサービストピックの内容、合計16のセクションを引き続き共有します。

• マイクロサービストピック01-春のアプリケーション
• マイクロサービストピック02-SpringWebMVCビューテクノロジー
• マイクロサービストピック03-REST
• マイクロサービストピック04-SpringWebFluxの原則
• マイクロサービストピック05-SpringWebFluxアプリケーション
• マイクロサービストピック06-クラウドネイティブアプリケーション
• マイクロサービストピック07-SpringCloud構成管理
• マイクロサービストピック08-SpringCloudサービスディスカバリ
• マイクロサービストピック09-SpringCloudの負荷分散
• マイクロサービストピック10-SpringCloudサービスサーキットブレーカー
• マイクロサービストピック11-SpringCloudサービスコール
• マイクロサービストピック12-SpringCloud Gateway
• マイクロサービストピック13-SpringCloud Stream（on）
• マイクロサービストピック14-SpringCloud Bus
• マイクロサービストピック15-SpringCloudStreamの実装
• マイクロサービストピック16-SpringCloudの全体的なレビュー

このセクションの要点は次のとおりです。

• Zookeeperクライアント：サービスディスカバリのアクティブ化、Eurekaクライアントの登録構成、APIの使用法など、ApacheZookeeperクライアントと組み合わせたSpringCloudDiscoveryの基本的な使用法を紹介します。
• Zookeeperサーバー：ApacheZookeeperサーバーをサービスレジストリとして構築する方法を紹介します

さまざまな登録センターの比較

比較のポイント	ユーレカ	Zookeeper	領事
操作とメンテナンスの知識	比較的なじみのない	に精通	ストレンジャー
一貫性（CAP）	AP（結果整合性）	CP（強い一貫性）	AP（結果整合性）
適合協定	HTTPスケジュールローテーション	ZAB	ラフト
通信方法	HTTPREST	カスタムプロトコル	HTTPREST
更新メカニズム	ピア2ピア（サーバー間）+スケジューラー（サーバーとクライアント）	ZKウォッチ	エージェントの監視方法
該当するスケール	20 K〜30 Kインスタンス（ノード）	10K〜20Kインスタンス（ノード）	<3Kインスタンス（ノード）
パフォーマンスの問題	シンプルな更新メカニズム、複雑な設計、大規模な場合の頻繁なGC	スケールが大きいと膨張が面倒でGCが多い	3Kノードを超えると、更新リストが遅くなります

SpringCloudのインフラストラクチャとしてZKが推奨される理由

CAP定理とも呼ばれるCAPの原則は、分散システムの整合性（Consistency）、可用性（Availability）、およびパーティション許容値（Partition許容値）を指します。CAPの原則は、これら3つの要素が同時に達成できるのは2つのポイントのみであり、3つすべてを処理することは不可能であることを意味します。

整合性モデル

Zookeeperは、CP：一貫性とパーティションの許容範囲を保証します。

上の図は、クライアントがアクセスするレジストリとしてZookeeperまたはEurekaを要求し、サーバーのアプリケーションインスタンスがハングした場合、レジストリの応答が異なる場合の状況を示しています。

• Zkの場合、CPの原則を保証するために、クライアントに返されるアプリケーションインスタンスの数は3-1 = 2になります。
• Eurekaの場合、APの原則を確実にするために、クライアントに返されるアプリケーションインスタンスはまだ3つありますが、デッドインスタンスにはアクセスできません。

Eurekaの場合、サーバー側のアプリケーションインスタンスがハングすると、上の図の状況の3分の1の確率があり、インスタンスを取得できないことは想像に難くありません。この状況を回避するために、次のことができます。通常、サービスを導入します。ゲートウェイは、このような問題を解決するために「読み取り/書き込み分離」アーキテクチャを実装します。

読み取りと書き込みの分離を実現するためのサービスゲートウェイに基づくアーキテクチャ

いわゆる「読み取り/書き込み分離」とは、次のことを指します。

• 書き込み：クライアントは、サービスのためにEurekaレジストリに直接登録します。
• 読み取り：サービスゲートウェイはEurekaレジストリからデータをプルするため、クライアントはサービスゲートウェイから間接的にデータをサブスクライブできます。

Eurekaレジストリはメモリベースの登録モデルに基づいていることがわかっています。サービス登録とサービス検出を分離する利点は、2つが並行しないようにすることです。クライアントのQPSが10w以上であるとすると、Eurekaレジストリはクライアントに直接公開されていると、間違いなくEurekaがハングアップします。

実際のビジネスシナリオでは、一般的に、サービス登録のリクエストは比較的少なく、必要な登録は1つだけで、サービスディスカバリが多くなります。Eurekaから取得されるデータの量は比較的多く、つまり、読み取りと書き込みが少なくなります。

上記の結論に基づいて、読み取りと書き込みが少ないため、読み取り中に記事を作成して、ゲートウェイの分散型高可用性を実現し、ゲートウェイによってプルされたデータをキャッシュに追加して、それを永続化できると考えます。データベース、つまりクライアントがデータを読み取るときに、データベースに間接的にアクセスできると同時に、サブデータベースやサブテーブルなどを使用できるため、Eurekaレジストリに基づくパフォーマンスを大幅に拡張できます。 。

メンテナンスに比較的精通している

動物園の飼育員の生態環境はより良い

• Zookeeperは、多くのシステムの構成情報を管理するために使用できます。たとえば、kafka、stormなどの多くの分散システムは、zookeeperを使用して一部のメタデータと構成情報を管理します。dubboレジストリはzookeeperもサポートしていますか？

• hadoop、hdfs、yarnなどの多くのビッグデータシステムは、飼育係に基づいたHA高可用性メカニズムの開発を選択しています。

• Zookeeperが分散ロックを実装することも比較的一般的な方法です。

単一の構成センターとサービスレジストリ

いわゆる簡略化とは、Zookeeperを登録センターとして使用することを指します。また、Zookeeperを構成センターとして使用することもできます。これは、Spring Cloudの従来の構成で、Eurekaを登録センターとして使用し、Git / JDBCを構成センターとして使用する場合です。

Spring Cloud Discovery

Zookeeperの実験を通じて、2つの効果を同時にテストできます。

• 登録の発見

• 構成管理

SpringCloudはZK依存関係を追加します

• 間違った構成（高ZKクライアントバージョン3.5、低サーバーバージョン3.4）

    <dependencies>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zookeeper-discovery</artifactId>
        </dependency>
    </dependencies>

• 正しく構成する

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zookeeper-all</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.apache.zookeeper</groupId>
            <artifactId>zookeeper</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.4.12</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
        </exclusion>
    </exclusions>
</dependency>

ZKを起動します

zkの使用法と原理については、前の配布トピックですでに述べましたが、ここではWindowsバージョンでレビューを行います！
Zookeeper公式ウェブサイトのダウンロード：zookeeper公式ウェブサイトのダウンロード

私が現在使用しているバージョンは3.5.8です。

1. デフォルトの構成ファイルを変更します

Zkはデフォルトでzoo.cfgファイルを読み取ります。公式ウェブサイトからダウンロードしたものは利用できません。ここにコピーをコピーしてzoo.cfg
ファイルを変更しましょう。zookeeper

ルートディレクトリに/ dataフォルダーを作成してデータを保存できます。

tickTime=2000
initLimit=10
syncLimit=5
# 这里需要使用 "//" 
dataDir=D://apache-zookeeper-3.5.8-bin//data
clientPort=2181

2. Zookeeperの開始と停止

まず、zkServer.shをダブルクリックしてサーバーを起動し、次にダブルクリックしてzkCli.shを起動し、コマンドラインを入力します。zookeeperを

停止すると、ポート2181を直接強制終了できます。

まず、ポート2181のプロセス番号を確認します。

netstat -aon | findstr“ 2181”

次に直接殺します：

taskkill / pid 10756 / F

3. zookeeperコマンドライン

コマンドls /を使用してノードを表示すると、ローカルlocalhost：2181サービスが正常に開始されていることがわかりました。

コアクラスを書く

1. ブートクラス。@ EnableDiscoveryClientをサービス検出クライアントとして使用します。

@SpringBootApplication
@EnableDiscoveryClient // 尽可能使用 @EnableDiscoveryClient
public class ZkDSClientApplication {
    
    

    public static void main(String[] args) {
    
    
        SpringApplication.run(ZkDSClientApplication.class, args);
    }
}

2. コントローラを書き込み、DiscoveryClientのAPIに従って、すべてのサービス名、ID、ホスト、ポート番号、およびその他の情報を返します

@RestController
public class ServiceController {
    
    

    @Autowired
    private DiscoveryClient discoveryClient;

    /**
     * 返回所有的服务名称
     *
     * @return
     */
    @GetMapping("/services")
    public List<String> getAllServices() {
    
    
        return discoveryClient.getServices();
    }

    @GetMapping("/service/instances/{serviceName}")
    public List<String> getAllServiceInstances(@PathVariable String serviceName) {
    
    
        return discoveryClient.getInstances(serviceName)
                .stream()
                .map(s ->
                        s.getServiceId() + " - " + s.getHost() + ":" + s.getPort()
                ).collect(Collectors.toList());
    }

}

インターフェースDiscoveryClientがorg.springframework.cloud.client.discoveryからのものであることに気づきました。

そして、機能は次のとおりです。

public interface DiscoveryClient {
    
    

	/**
	 * A human readable description of the implementation, used in HealthIndicator
	 * @return the description
	 */
	String description();

	/**
	 * Get all ServiceInstances associated with a particular serviceId
	 * @param serviceId the serviceId to query
	 * @return a List of ServiceInstance
	 */
	List<ServiceInstance> getInstances(String serviceId);

	/**
	 * @return all known service ids
	 */
	List<String> getServices();

}

その中で、ServiceInstance、どのプロパティとメソッドがあるか見てみましょう。

public interface ServiceInstance {
    
    
	// 实例 id
	String getServiceId();
	//主机地址
	String getHost();
	// 端口号
	int getPort();
	//是否是https请求
	boolean isSecure();
	// 服务的 uri
	URI getUri();
	//与服务实例关联的键值对元数据
	Map<String, String> getMetadata();
	//实例方案
	default String getScheme() {
    
    
		return null;
	}
}

セットアップ構成ファイル

spring.application.name = spring-cloud-service-discovery-client

# 服务端口
server.port = 7070

# 管理端口
management.server.port = 7071

# 开放 所有Web 管理 Endpoints
management.endpoints.web.exposure.include = *

結果テスト

• まず、サービス検出の効果を確認します。

スタートアッププロジェクト：

ポート7070をサービスポートとして使用し、zookeeperノードで登録が成功したかどうかを確認します。ZKノードパス

（/ services / spring-cloud-service-discovery-client /）
は次のように結論付けることができます。ZKサービス検出ノードのルール（/services/{spring.application.name}/{serviceId_UUID}/）。

• 次に、サービス登録の効果を見てください。

ブラウザに直接アクセスします：http：// localhost：7071 / actuator / env

以前に作成されたコントローラーに基づいて、次のサイトにアクセスしてみましょう。

http：// localhost：7070 / services
（すべてのサービス名を返します）

http：// localhost：7070 / service / instances / spring-cloud-service-discovery-client
（インスタンスを指定して詳細情報を取得します）

追記

Eureka 2.0はオープ​​ンソースではなく、Eureka1.xは引き続き使用できます。

このセクションのコードアドレス：https：//github.com/harrypottry/microservices-project/tree/master/spring-cloud-project/spring-cloud-service-discovery-client

アーキテクチャに関する知識の詳細については、Javaに関するこのシリーズの記事に注意してください：Javaアーキテクトの成長への道