コンテキスト
分散技術の成熟、分散技術の普及
構成管理の実装の下に分散クラスタ、現在の時代では、新しいインフラストラクチャの背景の国の提唱と組み合わせて、分散の時代となっている、クラウドサービスと仮想化も高尚な言葉から地に足のついた技術に変更されました。現在、各企業のサービスは、断片化された分散複数の小さなマシンで展開することができ、対処するために大規模なコンピュータを使用しないようにしよう、非常に古典的な理由は、単一障害点です。
設定ファイルに分散クラスタは、統一された管理する必要があります
さて、JavaWebを例に取ると、JavaWebサービスの分散展開を持って、これらのサービスは、最も単純なCRUD作業を実行し、次の接続はMySQLですが、今、あなたは分散展開の各サーバー上で同じ設定ファイルを記述する必要があります。
jdbc.user=root
jdbc.password=123456
jdbc.driver=com.mysql.cj.jdbc.Driver
jdbc.url=jdbc:mysql://xxx.xxx.xxx.xxx:3306/database?useUnicode=true&characterEncoding=utf8
このとき、いくつかの問題に直面します：
- 自分のクラスタ構成を統一された方法で見るには？
- 接続するDBを変更する必要がある場合、1つ1つsshで接続する必要がありますか？
単純な解決策は、各サーバーの適切な場所に設定ファイルを一括アップロードし、サービスを再起動するスクリプトを書くことです。しかし、これの問題点は、設定を統一的に管理・閲覧する方法がないことと、アップロードに失敗する問題があることです。
設定のプロパティはdubboレジストリに似ており、分散サービスにおける設定ファイルの一貫性を保証していることがわかります。
設定管理ファイルのいくつかの実装オプション
これらの構成保存方法の比較については、別のピットで検討します。今回はまず、ZooKeeperの機能がどのように可用性の高い構成管理システムを保証し、実現するかを説明します。
ZooKeeperの採用で考えられる問題点
ZooKeeperはCAPの原理でしかCPを満たすことができないため、マスターノードに障害が発生するとzkのサービス選択プロセス全体が利用できなくなり、zkは安定性に問題が生じます。
解決策は、zkクラスタとユーザの間にキャッシュ層を構築することです。
一般的な構造
zk クラスタの構築
zookeeper.apache.org/
まず最初に、zk クラスタを構築する必要があります。公式オンラインチュートリアルを参照してください。
クライアント側の開発
- zkClient 操作のカプセル化、ファイルキャッシュ+メモリキャッシュ機能の設定のサポート
- 時間内にキャッシュをリフレッシュするために、zkClient のウォッチャー購読メカニズムを通してzk ノード変更イベントを購読します。
開発マネージャ
管理側の機能は、zk ファイルの表示と変更のロジックをカプセル化することで、設定ファイルの統一的な管理を容易にします：
- 許可制御は、CASシステムを介してアカウントシステムを確立するために、管理側は<账户名-账户角色>、アカウントのさまざまな役割のマッピング関係を維持する<账户名-账户角色>ために、別の操作権限を公開します。
- ビューのディレクトリ構造とビューのファイル、すなわち、zkのlsとgetコマンド。
- zk の delete コマンド。
- zk が指定した場所にあるファイルを変更すること。
- ロールバック操作に対する設定のサポート、つまり、zk パスによるバージョン番号のサポート、元の設定のコピーをコピーアウトして設定変更を実行する release 操作。
参照
[1] PaxosからZooKeeperへ 分散一貫性の原則と実践
[2] サービスレジストリ、Eureka vs. ZooKeeper
[3] ZooKeeper 公式ドキュメント [OL]. zookeeper.apache.org/doc/
