分散構成センターの比較 (Nacos と Apollo)

同社ではシステムをサービスに分割しているため、モジュール数が急増し、それに伴い設定ファイルの管理の難易度も高まってきたため、集中構成管理が可能なミドルウェアを導入したいと考えています。

以下は、市場で人気のある 2 つの製品、Naocs と Apollo をさまざまな側面から比較したものです。

1. 構成センター

1.1 構成とは何か

アプリケーションを起動して実行するときには、多くの場合、何らかの構成情報を読み取る必要があります。構成は基本的に、データベース接続パラメータ、起動パラメータなど、アプリケーションのライフサイクル全体に付随します。

構成には次の主な機能があります。

設定はプログラムから独立した読み取り専用変数です

プログラムの構成は読み取り専用です。プログラムは構成を読み取ることで動作を変更しますが、プログラムは構成を変更すべきではありません。

アプリケーションライフサイクル全体にわたる構成

構成はアプリケーションのライフサイクル全体にわたって実行されます。アプリケーションは起動時に構成を読み取って初期化され、実行時に構成に基づいて動作を調整します。

たとえば、サービスのポート番号は起動時に読み取る必要があり、システムは動作中にスケジュールされたタスクを実行するためのタイミング戦略を読み取る必要があります。

設定は複数の方法でロードできます

一般的なものには、プログラム内部のハードコード、構成ファイル、環境変数、起動パラメータ、データベースベースなどがあります。

構成にはガバナンスが必要

同じプログラムでも、異なる環境 (開発、テスト、本番) や異なるクラスター (異なるデータセンターなど) では異なる構成が必要になることが多いため、完璧な環境とクラスターの構成管理が必要です。

1.2 構成センターとは

分散サービスアーキテクチャでは、システムが単一のアプリケーションから分散システム上のサービスノードに分割される場合、構成が分散されるように構成ファイルも移行 (分割) する必要があります。それだけでなく、次の図に示すように、分散には冗長性も含まれています。

構成センターは、各アプリケーションから構成を分離し、構成を一元的に管理するため、アプリケーション自体が構成を管理する必要がありません。下記の通り

構成センターのサービスプロセスは次のとおりです。

1. ユーザーは構成センターで構成情報を公開および更新します。

2. サービス A とサービス B は、構成更新通知をタイムリーに受信し、構成センターから構成を取得します。

一般的に、構成センターは、さまざまなアプリケーション構成を統一的に管理する基本的なサービスコンポーネントです。

1.3 構成センターが必要な理由

分散型マイクロサービスの発展に伴い、サービスノードの数が増加し、構成上の問題が徐々に発生しています。

プログラム機能が複雑化するにつれて、プログラム構成が増加し、さまざまな機能スイッチ、パラメータ構成、サーバーアドレス、
多数のモジュールが独自の構成を使用しているため、操作や保守が煩雑になり、管理が混乱し、各ノードの構成ファイルに一貫性がなくなる可能性があります。
構成に対する期待もますます高まっています。構成の変更はリアルタイムで有効になり、グレースケールリリース、バージョン管理、環境の差別化、権限と監査メカニズムの改善が必要になります。

このような環境では、構成ファイルやデータベースなどの従来の方法では、開発者の構成管理のニーズを満たすことがますます難しくなってきています。

1.4 構成センターの概要

要約すると、従来の巨大なモノリシックアプリケーションが分散サービスアーキテクチャに移行する歴史的プロセスにおいて、構成センターはサービス指向開発に不可欠なシステムコンポーネントです。このような状況の中で、集中型構成サービス、つまり構成センターが誕生しました。認定された構成センターは、次の特性を満たす必要があります。

設定項目は読みやすく、変更も簡単です
分散環境におけるアプリケーション構成の管理性、つまりリモートで構成を管理する機能
リスク管理のための構成変更のレビューをサポート
設定変更の履歴を表示できます
異なる展開環境でのアプリケーション構成の分離

構成センター全体では、システムの実行中にプログラムの動作を動的に調整できます。

2. オープンソース構成センターの紹介

市場で人気のある構成センターは次のとおりです。

混乱

2014 年 7 月現在、Baidu のオープンソース構成管理センターにも構成管理機能が搭載されていますが、メンテナンスは行われていません。

Spring クラウド構成

2014 年 9 月、Spring Cloud は、Spring Cloud システムとシームレスに統合できるエコシステムコンポーネントをオープンソース化しましたが、これは Git または SVN に依存します。

アポロ

2016 年 5 月、Ctrip は標準化された権限とプロセスガバナンスを特徴とするオープンソース構成管理センターを開設しました。

ナコス

2018 年 6 月には、Alibaba のオープンソース構成センターでも RPC サービス検出を実行できるようになりました。

Disconf はメンテナンスされなくなり、Spring Cloud Config は Git または SVN に依存する必要があるためです。そこで、アポロとナコスだけ紹介します

2.1 ナコス

Nacos には登録センター + 構成センターが含まれます。以下では、構成センターについてのみ説明します。

2.1.1 はじめに

Nacos は、マイクロサービスのサービス検出、構成、管理を支援することに専念しています。 Nacos は、動的なサービス検出、サービス構成、サービスメタデータ、トラフィック管理を迅速に実装するのに役立つ、使いやすい機能のセットを提供します。

Nacos を使用すると、マイクロサービスプラットフォームをより俊敏かつ簡単に構築、提供、管理できるようになります。 Nacos は、「サービス」（マイクロサービスパラダイムやクラウドネイティブパラダイムなど）を中心とした最新のアプリケーションアーキテクチャを構築するためのサービスインフラストラクチャです。

Nacos ドキュメントセンターアドレス: https://nacos.io/zh-cn/docs/what-is-nacos.html

2.1.2 特徴

Nacos は、ほぼすべての主流のタイプのサービス検出、構成、および管理をサポートしています。ここでは、Nacos の構成センター機能についてのみ説明します。

動的構成サービスを使用すると、すべての環境のアプリケーション構成とサービス構成を集中的、外部的、動的に管理できます。
動的構成により、構成の変更が発生したときにアプリケーションやサービスを再展開する必要がなくなり、構成管理がより効率的かつ俊敏になります。
集中化された構成管理により、ステートレスサービスの実装や、オンデマンドでのサービスの弾力的な拡張が容易になります。
Nacos は、すべてのサービスとアプリケーションの構成を管理するのに役立つシンプルで使いやすい UI を提供します。
Nacos は、構成バージョンの追跡、カナリアリリース、ワンクリック構成ロールバック、クライアント構成更新ステータスの追跡など、すぐに使用できる一連の構成管理機能も提供しており、運用環境での構成変更をより安全に管理し、構成変更によってもたらされるリスクを軽減するのに役立ちます。

2.1.3 アーキテクチャ

Nacos 構成センターはサーバーとクライアントに分かれています。サーバーは Java で記述されており、クライアントに構成サービスを提供します。

クライアントは複数の言語で実装できます。クライアントはサービスモジュールとネストされます。 Nacos は SDK と OpenAPI を提供します。 SDK がない場合は、OpenAPI に従って、サービス登録と検出、および構成のプルロジックを手動で記述することもできます。

構成センターのアーキテクチャ図:

ユーザーは、Nacos Server コンソールを通じて複数のサービスの構成を集中管理できます。
各サービスは Nacos Server クラスターから独自の構成を取得し、構成の変更を監視します。

2.1.4 開発

Nacos Configuration Center は、Spring、Spring Boot、Spring Cloud との統合をサポートしており、XML またはアノテーションを通じて簡単に実装できます。デモ中の Spring プロジェクトと統合します。

1. サーバー

コンソール公開構成のスクリーンショット

Nacos サーバーは、キャッシュを使用するかどうかを制御するための useLocalCacheSwitch 構成を追加します。
リリース構成

2. クライアント

 <依存関係>
     <グループID>com.alibaba.nacos</グループID>
     <artifactId>nacos クライアント</artifactId>
     <バージョン>1.4.1</バージョン>
 </依存関係>
 <依存関係>
     <グループID>com.alibaba.nacos</グループID>
     <artifactId>nacos-spring-context</artifactId>
     <バージョン>1.0.0</バージョン>
 </依存関係>

 <! --NacosServerアドレス-->  
 <nacos:グローバル-properties server-addr= "192.168.134.128:8848" />
 <! --NacosServer で設定されたファイル-->  
 <nacos:property-source データ ID = "application.properties"   
グループ-id= "redirectpaymentservice"   
                       自動更新 = "true" />

 @サービス( "Tx2101" )
パブリッククラスTx2101はTxBaseを拡張します{ 
 
    @NacosValue(値 = "${useLocalCacheSwitch}" 、自動リフレッシュ = true )
    プライベートブール値 useLocalCacheSwitch; 
 
    @オーバーライド
パブリックドキュメントプロセス(ドキュメントドキュメント)はCodeExceptionをスローします{
        システム。 out .println( "キャッシュを更新するかどうか: " + useLocalCacheSwitch);
戻る ヌル;
    }
 }

構成を動的に更新するJavaコードを記述する
NacosServer 関連の設定を applicationContext.xml に追加します。
pom.xml は nacos-client 依存関係を追加します

3. 効果

キャッシュを更新するかどうか: false

キャッシュを更新するかどうか: true

Nacos サーバーで useLocalCacheSwitch の設定を変更した後、2101 インターフェイスに再度アクセスすると、次のように出力されます。
モジュールが起動したら、2101 インターフェイスにアクセスして以下を出力します。

2.1.5 グレースケール

Nacos サーバーの設定を変更した後、Beat リリースをチェックし、IP アドレスを指定して、リリースベータを選択します。

指定されたIPノードの構成のみが更新されます

2.1.5 デプロイメント

スタンドアロンモードでは、Nacos には依存関係がなく、デフォルトで組み込みデータベースをストレージエンジンとして使用しますが、MySQL に置き換えることもできます。クラスターモードでは、Nacos はストレージに MySQL に依存します。

実稼働環境で Nacos を使用する場合に高可用性を実現するには、スタンドアロンモードを使用することはできず、Nacos クラスターを構築する必要があります。

下の図は、ドメイン名 + VIP モードを通じて実装される、公式に推奨されているクラスターソリューションです。クライアント側で構成された Nacos。 Nacos クラスターを移行する場合、クライアント側の設定を変更する必要はありません。

クラスター展開アーキテクチャ図:

クラスター展開アーキテクチャ図

2.1.7 要約

Nacos は使いやすく、導入も簡単で、パフォーマンスが高く、基本的な構成管理を実装でき、非常に簡潔なコンソールを提供します。

ただし、権限の制御粒度は粗く、監査メカニズムはありません。

2.2 アポロ

2.2.1 はじめに

Apollo は、Ctrip のフレームワーク部門によって開発された分散構成センターです。さまざまなアプリケーション環境とクラスターの構成を一元的に管理できます。構成が変更されると、リアルタイムでアプリケーション側にプッシュできます。また、標準化された権限、プロセスガバナンス、その他の機能も備えており、マイクロサービス構成管理シナリオに適しています。

Apollo はサーバーとクライアントの 2 つの部分で構成されています。

サーバーは Spring Boot と Spring Cloud に基づいて開発されており、Tomcat などの追加のアプリケーションコンテナーをインストールする必要なく、パッケージ化後すぐに実行できます。 Java クライアントはいかなるフレームワークにも依存せず、すべての Java ランタイム環境で実行できます。また、Spring/Spring Boot 環境も適切にサポートされています。

ドキュメント: https://github.com/ctripcorp/apollo/wiki。

2.2.2 特徴

構成の特殊性のため、Apollo はガバナンス機能を備えた構成公開プラットフォームとして設計されました。現在、次の機能が提供されています:

さまざまな環境やクラスターの構成を一元管理
構成の変更はリアルタイムで有効になります（ホットリリース）
バージョンリリース管理
グレースケールリリース
権限管理、リリースレビュー、運用監査
クライアント構成情報の監視
Javaおよび.Netネイティブクライアントを提供する
オープンプラットフォームAPIを提供する
シンプルな導入

2.2.3 アーキテクチャ

アポロの建築を外部と内部から分析

アドレス: https://ctripcorp.github.io/apollo/#/zh/design/apollo-design

基本モデル

以下は、Apollo の基本モデルです。

ユーザーは構成センターで構成を変更して公開します
構成センターはApolloクライアントに構成の更新を通知します
Apolloクライアントは構成センターから最新の構成を取得し、ローカル構成を更新し、アプリケーションに通知します。

2.2.4 開発

Apollo は API モードと Spring 統合モードをサポートしています。

API は柔軟で、完全に機能し、構成値はリアルタイムで更新され (ホットパブリッシング)、すべての Java 環境をサポートします。

スプリングアクセスは簡単です。

コード内で直接使用します。例: @Value("${someKeyFromApollo:someDefaultValue}")
Spring 構成を直接ホストします。たとえば、apollo で spring.datasource.url=jdbc:mysql://localhost:3306/somedb?characterEncoding=utf8 を直接構成します。
プレースホルダーメソッド:
Spring Boot の @ConfigurationProperties アプローチ

Spring メソッドは API メソッドと組み合わせて使用することもできます。たとえば、Apollo Config オブジェクトを挿入することで、通常どおり API を通じて構成を取得できます。

以下は、デモとして Spring が Apollo を統合する方法の紹介です。

1. サーバー

コンソールは、キャッシュを使用するかどうかを制御するためのuseLocalCacheSwitch構成を追加します。
リリース構成

2. クライアント

 <依存関係>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>アポロクライアント</artifactId>
    <バージョン>1.1.0</バージョン>
 </依存関係>

 <アポロ:config/>

 -Dapp.id=RedirectPaymentService -Denv=DEV -Ddev_meta=http://localhost:8080

 @サービス( "Tx2101" )
パブリッククラスTx2101はTxBaseを拡張します{ 
 
    @Value( "${useLocalCacheSwitch:false}" )
    プライベートブール値 useLocalCacheSwitch; 
 
    @オーバーライド
パブリックドキュメントプロセス(ドキュメントドキュメント)はCodeExceptionをスローします{
        システム。 out .println( "キャッシュを更新するかどうか: " + useLocalCacheSwitch);
戻る ヌル;
    }
 }

構成を動的に更新するJavaコードを記述する
VMオプションの起動パラメータ
apollo 関連の設定を applicationContext.xml に追加する
pom.xml は apollo-client 依存関係を追加します

3. 効果

キャッシュを更新するかどうか: false

キャッシュを更新するかどうか: true

Apollo コンソールで useLocalCacheSwitch の設定を変更した後、2101 インターフェイスに再度アクセスすると、次のように出力されます。
モジュールが起動したら、2101 インターフェイスにアクセスして以下を出力します。

2.2.5 グレースケール

Apollo コンソールは、グレースケールバージョンを作成し、グレースケールルールを構成し、グレースケール IP または AppID を指定します。

指定されたIPノードまたはAppIDモジュールの構成が更新されます

2.2.6 デプロイメント

Apollo 高可用性アーキテクチャモジュールの概要:

上の図は、下から上に向かって見ることができるアポロの全体的なデザインを簡単に説明しています。

Config Service は、構成の読み取りやプッシュなどの機能を提供し、そのサービスオブジェクトは Apollo クライアントです。
管理サービスは、設定変更や公開などの機能を提供し、そのサービスオブジェクトはApollo Portal（管理インターフェース）です。
Config ServiceとAdmin Serviceはどちらもマルチインスタンスのステートレスなデプロイメントであるため、Eurekaに登録してハートビートを維持する必要があります。
Eureka のサービス検出インターフェースをカプセル化するために、Eureka 上に Meta Server を構築しました。
クライアントはドメイン名を介してメタサーバーにアクセスし、Config Service サービスリスト (IP + ポート) を取得し、IP + ポートを介してサービスに直接アクセスします。同時に、クライアント側では負荷分散とエラー再試行が実行されます。
ポータルはドメイン名を介してメタサーバーにアクセスし、管理サービスのサービスリスト (IP + ポート) を取得し、その後、IP + ポートを介してサービスに直接アクセスします。一方、ポータル側では負荷分散とエラー再試行が実行されます。
デプロイメントを簡素化するために、実際には Config Service、Eureka、Meta Server の 3 つの論理ロールを同じ JVM プロセスにデプロイします。

2.2.7 要約

Apollo には、対応する構成のリリースレビュー、権限管理、構成の継承などを含む、比較的完全な構成管理プロセスがあります。ただし、Apollo では、ユーザーが簡単な学習を行う必要があり、学習コストがかかります。

Appollo の展開は比較的複雑で、3 つのモジュールを同時に動作させる必要があります。実稼働の高可用性クラスターを展開するには、少なくとも 7 つのノードが必要です。

3. 結論

3.1 機能比較

3.2 結論

構成センターの観点から見ると、Nacos の読み取りおよび書き込みパフォーマンスが最も高く、次に Apollo が続きます。機能面では Apollo が最も充実していますが、Nacos には Apollo の構成管理機能のほとんどが備わっています。 Nacos の大きな利点は、登録センターと構成センターの機能を統合していることです。展開と操作は Apollo よりも直感的でシンプルです。したがって、アーキテクチャの複雑さが簡素化され、運用、保守、展開の作業が削減されます。

一般的に、Apollo と Nacos は幅広いエコシステムのサポートを備えており、構成管理プロセスで優れた機能を発揮します。 Apollo は Nacos よりも構成管理が包括的です。 Nacos は比較的使い方が簡単で、高いパフォーマンス要件のある大規模なシナリオに適しています。

現時点では、企業が頻繁に構成を変更せず、構成権限を厳密に管理せず、読み取りおよび書き込みパフォーマンスに一定の要件がある場合は Nacos を使用でき、そうでない場合は Apollo を使用できます。

<<: 2020年：世界のクラウドコンピューティングにおける11の主要年間トピックのレビュー

>>: 「江南春雲酒」ミニ番組が「自宅で過ごす旧正月」に温かさを添える