服务定位器模式
服务定位器模式（Service Locator Pattern）是一种企业级设计模式，用于集中管理和查找服务或组件，隐藏服务创建和查找的复杂性。它通过一个中心化的服务定位器（Service Locator）提供对服务的访问，减少客户端与服务实现之间的耦合，适用于分布式系统或需要动态获取服务的场景（如 Java EE 应用中的 EJB 或 JNDI 查找）。
服务定位器模式的组成
服务定位器模式通常包含以下几个角色：
- 服务（Service）：提供特定功能的接口或类，通常是业务逻辑的实现。
- 具体服务（Concrete Service）：实现服务接口，包含具体的业务逻辑。
- 服务定位器（Service Locator）：核心组件，负责查找、缓存和返回服务实例。
- 客户端（Client）：通过服务定位器获取服务并调用其功能。
- 服务注册表（Service Registry）：存储服务实例或服务查找逻辑的容器（如 JNDI 或自定义缓存）。
工作原理
- 客户端向服务定位器请求特定服务。
- 服务定位器检查缓存，查看是否已有该服务的实例。
- 如果缓存中存在，直接返回服务实例；否则，通过服务注册表（如 JNDI、工厂方法）创建或查找服务实例，并将其缓存。
- 客户端使用返回的服务实例执行业务操作，无需关心服务的创建或查找细节。
UML 类图
┌────────────────┐
│ Client │
├────────────────┤
│ │
└────────────────┘
↑
│
┌────────────────┐
│ ServiceLocator │
├────────────────┤
│ getService() │
└────────────────┘
↑
│
┌────────────────┐ ┌────────────────┐
│ Service │ │ ServiceRegistry│
├────────────────┤ ├────────────────┤
│ doService() │<----->│ lookup() │
└────────────────┘ └────────────────┘
↑
│
┌────────────────┐
│ ConcreteService│
├────────────────┤
│ doService() │
└────────────────┘代码示例（以 Java 为例）
以下是一个服务定位器模式的实现，模拟查找不同类型的消息服务：
// 服务接口
interface MessageService {
void sendMessage(String message);
}
// 具体服务：邮件服务
class EmailService implements MessageService {
@Override
public void sendMessage(String message) {
System.out.println("通过邮件发送消息: " + message);
}
}
// 具体服务：短信服务
class SMSService implements MessageService {
@Override
public void sendMessage(String message) {
System.out.println("通过短信发送消息: " + message);
}
}
// 服务定位器
class ServiceLocator {
private static Map<String, MessageService> serviceCache = new HashMap<>();
public static MessageService getService(String serviceName) {
// 检查缓存
MessageService service = serviceCache.get(serviceName);
if (service != null) {
System.out.println("从缓存中获取服务: " + serviceName);
return service;
}
// 模拟服务注册表查找服务
if ("email".equalsIgnoreCase(serviceName)) {
service = new EmailService();
} else if ("sms".equalsIgnoreCase(serviceName)) {
service = new SMSService();
}
// 缓存服务实例
if (service != null) {
serviceCache.put(serviceName, service);
System.out.println("创建并缓存服务: " + serviceName);
} else {
System.out.println("服务未找到: " + serviceName);
}
return service;
}
}
// 客户端代码
class Client {
public void sendMessage(String serviceName, String message) {
MessageService service = ServiceLocator.getService(serviceName);
if (service != null) {
service.sendMessage(message);
}
}
}
// 测试代码
public class Main {
public static void main(String[] args) {
Client client = new Client();
// 首次获取邮件服务
client.sendMessage("email", "Hello via Email!");
// 再次获取邮件服务（从缓存）
client.sendMessage("email", "Another Email!");
// 获取短信服务
client.sendMessage("sms", "Hello via SMS!");
// 获取不存在的服务
client.sendMessage("phone", "Invalid Service!");
}
}输出：
创建并缓存服务: email
通过邮件发送消息: Hello via Email!
从缓存中获取服务: email
通过邮件发送消息: Another Email!
创建并缓存服务: sms
通过短信发送消息: Hello via SMS!
服务未找到: phone服务定位器模式的特点
- 优点：
- 解耦客户端与服务：客户端无需直接创建或查找服务，降低耦合。
- 提高复用性：服务定位器缓存服务实例，减少重复创建开销。
- 简化服务访问：隐藏服务查找的复杂性（如 JNDI 查找、远程调用）。
- 集中管理：服务查找逻辑集中在服务定位器，便于维护。
- 缺点：
- 服务定位器可能成为单点故障，需确保其健壮性。
- 缓存管理不当可能导致内存泄漏或过时服务实例。
- 隐藏了服务依赖关系，可能降低代码透明度。
- 在现代依赖注入框架（如 Spring）中，服务定位器模式的使用频率降低。
使用场景
- 需要集中管理服务查找的场景：
- Java EE 应用中的 EJB 或 JNDI 服务查找。
- 分布式系统中获取远程服务（如 RMI、Web 服务）。
- 需要缓存服务实例以提高性能的场景：
- 频繁访问的昂贵资源（如数据库连接、服务实例）。
- 需要屏蔽服务创建复杂性的场景：
- 客户端不关心服务实现细节，只需调用服务功能。
- 动态选择服务的场景：
- 根据配置或环境选择不同服务实现（如测试环境使用模拟服务）。
注意事项
- 与依赖注入（DI）的区别：
- 服务定位器模式要求客户端主动通过定位器获取服务，依赖关系不够透明。
- 依赖注入（DI，如 Spring）通过容器自动注入依赖，更加解耦且易于测试。
- 缓存管理：服务定位器应妥善管理服务实例的缓存，避免内存泄漏或缓存过时。
- 异常处理：服务定位器需处理服务不可用的情况，提供友好的错误信息。
- 与业务代表模式的结合：服务定位器常与业务代表模式结合使用，业务代表负责调用服务，定位器负责查找服务。
- 适用性：在现代框架（如 Spring、Guice）中，依赖注入通常更受欢迎，服务定位器适合传统或特定场景。
总结
服务定位器模式通过集中管理服务查找和缓存，简化了客户端与服务的交互，特别适合企业级应用中的服务访问场景（如 EJB、JNDI）。它通过解耦客户端与服务实现，提高了系统的可维护性和性能，但在现代依赖注入框架中逐渐被替代。设计时需注意缓存管理和异常处理，以确保系统的健壮性。