服务定位器模式

这种设计模式引入一个强大的抽象层，此层对获得服务的过程进行封装。该模式使用一个名为服务定位器的注册中心来进行服务的定位发现，对服务器进行请求，可以获得使用某种服务的所有必要信息。

此模式中包含三个角色：客户端、服务定位器、服务。

此模式的优势：

1. 服务定位器可以作为简单的“运行时链接器”使用。组件可以在运行时加入到应用中，整个应用不需要重新编译，某些情况下甚至不需要重启应用
2. 服务定位器可以在运行时动态添加、替换、移除服务，例如替换掉一个XML解析器的实现
3. 应用和库可以完全隔离，它们仅仅通过服务定位器交互

此模式的缺点：

1. 服务定位器对于系统的其它部分是黑盒。服务定位器发生错误将难以检测和恢复，从而导致整个系统的可靠性下降
2. 服务定位器通常是单例的，这可能导致性能瓶颈
3. 服务定位器可能是一个安全风险点，因为它允许外部代码的注入
4. 服务定位器隐藏了它的类依赖，某些本应该在编译器暴露的错误以运行时错误的形式出现
5. 增加了测试的难度，因为所有测试用例都需要和服务定位器交互，才能获得一个服务的Mock

Java命名和目录服务可以认为是服务定位器模式的实现。此服务就相当于一个定位器，它提供了发布、获取服务的接口。

ZooKeeper可以作为服务定位器使用，但这是一种变体：

1. 定位器不是单例的，ZooKeeper通常是集群部属，避免了单点故障
2. ZooKeeper都用于分布式架构中，所谓服务也需要远程调用，而不是进程内基于内存地址的直接调用