这的确是个好问题，我认真思考了下，有以下几个原因：
本回答涉及到CAP，如未了解，请先阅读：全网对CAP最深层的思考
ZooKeeper不仅仅是一个注册中心
以下介绍取自ZooKeeper官网：zookeeper.apache.org/
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.
从上述介绍来看，ZooKeeper是一个维护配置信息、命名、提供分布式锁服务和提供组服务的集中式服务，而不仅用于注册中心。这些功能明显要求ZooKeeper的数据安全性要很高，不能因为重启后导致数据丢失，这势必需要将数据落盘。
将数据落盘的要求，明显独立部署更合适，如果ZooKeeper作为依赖的方式去实现，则需要依赖于业务系统实现落盘操作。
ZooKeeper是CP架构，Eureka是AP架构
配置信息、锁服务对数据的正确性远高于注册中心，所以ZooKeeper必须要选择一个数据更为靠谱的系统架构，即：CAP中CP架构系统。在ZooKeeper在发生分区容错，面临选择C或者A的关键时刻，它选择了C。这意味着ZooKeeper集群，为了保证数据的正确性，将不会向外提供服务。
基于上述分析，倘若ZooKeeper选择依赖的方式，且还选择了CP架构，那么这要求所依赖的应用不能向外提供服务，这种设计明显是不对的。
而Eureka各节点互相独立、平等的，各节点都提供查询和注册服务，这与我们的业务节点相呼应，业务系统不会因为Eureka而拒绝提供业务服务。另外对于注册中心来说，选择AP架构是正确的选择，注册中心要求的可用性更高，反而能够接受适当的过期的数据。
