まず、問題を解決します
- 上記のように、アプリケーションは、サービスサイトを呼び出して、上流のサービスは、基本サービスの依存関係は非常に複雑になることができます呼び出します。どのように呼び出し側が下流サービスのクラスタ構成を維持しますか？場合は、サービスノードクラスタの減少、認知があるかどうか、発信者？
第二に、最初の「設定所持」アーキテクチャ
- それぞれの各レコードは、プログラムの欠陥の下流ノード構成情報と呼ばれ、下流の設定ファイルを持っている：地獄は私だったのはなぜ呼び出し側の痛みは、音量の変化は、あなたが設定し、再起動を修正していますか？このことは、不合理下流カップリングを配置することにより、典型的な「逆依存」アーキテクチャです。第二の問題：サービス側の痛み、多くの場合のみ、次の方法の上流に位置する、彼自身を呼び出すためにどのように多くの上流のか分からないTA：
- グループが叫びました
- メールお問い合わせ
- 担当者を見つけるために、マシンの担当者を見つけるために、運用、保守を依頼し、機械を通して、対応する通話サービスを介してIP、接続することにより、IP検索
第三に、中期：「グローバル」アーキテクチャ
例えば/opt/global.conf（1）運用保守レベルノルム、新しいグローバルコンフィギュレーションファイル、（2）サービス側は、ユニバーサルサービス、global.conf年のクラスタ構成情報であれば、（3）発信者のために発信者所有の禁止設定がglobal.confから読み取る必要があり、一般的に下流に配置され;
利点：
（1）下流側の体積変化、それぞれの上流を変更することなく、構成global.confを変更するのみ必要がある場合、
（2）次の呼び出し側自動的にクラスタに移行し、再起動時には、拡張後に出てくる;
（3）コストを変更する非常に小さく、それは違っていたコンフィギュレーションファイルのディレクトリを読み込み、
グローバルコンフィギュレーションは、任意の欠如を持っていますか？
呼び出し側が再起動していない場合は、上がる新しいクラスタトラフィックに移行する方法はありません。
第四に、最終版：「Configuration Centerの」アーキテクチャ
- これに対し、「グローバル設定」および「Configuration Centerの」組織図、あなたが設定は静的から動的なファイルサービスへのアップグレードができます：
（1）全体構成のセンターサブシステムは、ZK、CONF-センターが提供する、DBはconf-、記憶するように構成されました;ウェブは、背景組成配置
構成中心における背景セットを介して、（2）すべてのダウンストリームサービス構成と、
（3）すべての、プル構成に必要な上流の中央レジスタを設定する必要、サービス構成情報の下流プル（IP1 / IP2 / IP3 ）、
（4）バックグラウンドCONF-Web構成設定、IP4 / IP5を追加し、IP1を減らす;
（5）CONFサービスセンターは、発信者の設定に関連する構成登録済みの懸念を変更するためにプッシュされる;
（6）ダイナミックリンクに関連してセル組立、自動伸縮能力を完了し、
「コンフィギュレーション・センター」アーキテクチャそれは何が良いのですか？
（1）発信者が再起動する必要はありません。
、サービング中心から（2）は、上流側が明らかにそれによって、発信者に係る実施形態を制限する、依存関係を知っている配置
（3）が構成中心からグローバルアーキテクチャの依存関係を取得することは容易です。
"コンフィギュレーション・センター「アーキテクチャは、何も不足していますか？
その結果、システムの複雑さは比較的高く、
中央の高い信頼性要件の第二に、構成、グローバル吊り吊り。
何が実際に痛みのポイントを解決するために起こっていますか？
痛み上流：下流の拡大は、設定を変更して上流を再起動し、
痛みの下流：自分自身に依存しているか分からない、
サービス管理を実現するために、短いでは、難しいです。
正確にどのように痛みのポイントを解決するには？
まず、「構成所持」アーキテクチャ;
第二に、「グローバル・プロファイル」アーキテクチャ;
第三に、「Configuration Centerの」アーキテクチャ。