Oh, one more thing. There has actually been some discussion about making broker discovery pluggable so that you can integrate with frameworks like etcd and consul. If we go down that route, it might make sense to provide a plugin for Zookeeper, although I think you'd still want to keep the client from accessing the paths used by the brokers directly. See here for one JIRA: https://issues.apache.org/jira/browse/KAFKA-1793.
-Jason On Thu, Mar 3, 2016 at 4:51 PM, Jason Gustafson <ja...@confluent.io> wrote: > Hi Tian, > > Removing the client dependence on Zookeeper has been one of the main goals > of the Kafka team for a while now. It simplifies client development since > it's one less dependence and one less remote system they have to manage > interaction with. It also makes a lot of sense with the security features > released in 0.9. Fewer systems for the client to talk to makes its security > story a whole lot easier to tell. And if the broker is the only thing > talking to Zookeeper, then you can isolate it better. > > And I'm not sure it actually makes sense to try to decouple kafka clients > from kafka servers ;-) I consider the Zookeeper state as part of the > server's internals. Exposing it actually couples clients to those internals > and makes the server harder to change. > > -Jason > > On Tue, Mar 1, 2016 at 6:51 PM, 田守枝 <tianshou...@126.com> wrote: > >> Hi All: >> I want to known why use "bootstrap.servers" to establish the initial >> connection to the Kafka cluster when I initialize a Producer or Consumer？ >> Why not let producer or consumer connect to the zookeeper to get the >> broker's ip and port? I think this is one way to decouple the client and >> brokers! >> >> >> >> Tian >> Shouzhi >> >> >> >> 2016/3/2 >> >> >> > > >
