まず第一に、なぜ飼育係のサービスレジストリこれには適していませんか？
CAPの観点から
思考は、サービスレジストリシステムは、CPまたはAPシステムであり、CAPからの視点を考慮し、あるのでしょうか？
まず、サービスコール間のサービスのためのサービスレジストリ間違いなくサービスセンターとして登録されていない場合、サービスコールの間の問題に起因する問題があります。
また、ノード1、ノード2、ノード3、クラスタノードがある場合。利用可能なサービスのリストがIP1保存、IP2、IP3は、この時間は、ノード1にのみ保存されたIP1、IP2として、矛盾している場合を想像し、今回のサービスノードのノード1を読んで、そして意味は何ですか？
サービスを呼び出すノード1は、最大で、トラフィックヒットIP3、その後、node1およびその他のIP3後同期バックするだけでなく、一貫性のあるロード・バランシングは存在しません、このサービスは、実際には何も大きな影響です。
したがって、サービスセンターの導入は、登録APシステムであるべきです。
飼育係は、CPシステム、強い整合性でした。
シーン1、マスターがハングアップしたときに、この時間、サービスが利用可能なサービスを読み取る必要がある時に再選へのZooKeeperクラスタ必要は使用できません。サービスの可用性に影響を与えます
もちろん、あなたがローカルで利用可能なサービスのリストがキャッシュされたと言うことができます。しかし、この方法以下でも対処することは不可能です。
シナリオ2は、パーティションが利用可能です。ただ、明らかに不合理である、そこに3つの部屋があり、一つの部屋3室1,2ネットワークが切断された場合、登録センタ3部屋はまだ新しいマシンを登録することはできません、と思います
ビューのヘルスチェックの観点から
飼育係は、判定サービスのハートビートTCPを通じて利用可能です
しかし、TCPの活動は、サービスが利用可能であることを意味するものではありませんが、それはアクティブなTCPサービスがそれに利用できる示し、答えは例えば、何も明らかに：接続プールが満杯になった、DB等、ハングアップしません
理想的なレジストリは何それ、思考未満の下で
1、少なくとも、自動サービス登録、発見。登録までの新しいサービスを持っている場合に最良しかし、また、最後の呼び出しにプッシュ
2は、（サービスがエレガントな組立ラインをオフにできるように信号を送る）マニュアルなくすことができ、便利、最大登録済みのコンピュータに管理することができ、マシンをリストア
3、ヘルスチェックサービスは、実際にサービスが提供されて検出することができます
4、でも最高のポイント場合は、通話サービスを登録している他のサブスクリプションサービスがあるかどうかを確認することができます
5、我々はそんなに良くIPの外に加えて、他のいくつかの情報を、取ることができる場合
ZooKeeperの事実は、さらに私は、ボトルネックを考えていたよりも、最近の出会いで語りました
1. ZooKeeperの書き込みは、特定のノード、書き込み性能のボトルネック、キューパブリッシュするとき、現象が顕在化するの登録、起動アプリケーションは非常に遅くなったときに、拡張可能ではありません
2. ZooKeeperのは、部屋とは異なりユーレカ、ゾーンの概念を越えルーティングの問題があるこの部屋で、この部屋には、別の部屋にルーティングすることができたときに、ルーティング、ローカルルーティングを優先してサポートしていません。
あまりにも多くのノードは、サービス・ノードは、変更がある場合とき、あなたは即座に再生カードを発生します「群れ効果は雷が鳴っ」、および、3 ZooKeeperのマシンに通知する必要がある、と簡単な繰り返し通知へ
