結構型模式-架構解耦與擴展實踐 Detail - 設計模式晴空月明 Blog

結構型模式聚焦於對象間的組合關係，通過優化類與對象的裝配方式，實現系統的靈活性與可擴展性。在分佈式系統中，由於多節點協作、跨網絡通信及異構環境集成等特性，傳統結構型模式需進行適應性改造，以應對分佈式特有的複雜性（如網絡延遲、節點故障、協議異構）。本文系統解析適配器、橋接、組合、裝飾器、外觀、享元、代理七大結構型模式在分佈式場景下的演化與實踐。

一、適配器模式：異構系統的橋樑

1.1 模式核心與分佈式適配場景

適配器模式通過封裝不同接口，使不兼容的類可以協同工作。在分佈式系統中，該模式常用於異構系統集成（如多註冊中心適配、跨協議通信）。

1. 多註冊中心適配（Nacos/Eureka/Consul）

// 目標接口：統一服務發現接口 
public interface ServiceDiscovery { 
   List<String> getServiceInstances(String serviceName); 
} 

// 適配者1：Nacos客户端 
public class NacosServiceDiscovery { 
   public List<Instance> getInstances(String serviceName) { 
       // Nacos SDK調用邏輯 
   } 
} 

// 適配者2：Eureka客户端 
public class EurekaServiceDiscovery { 
   public List<InstanceInfo> getInstances(String serviceName) { 
       // Eureka SDK調用邏輯 
   } 
} 

// 適配器：Nacos適配器 
public class NacosAdapter implements ServiceDiscovery { 

   private NacosServiceDiscovery nacosDiscovery; 

   @Override 
   public List<String> getServiceInstances(String serviceName) { 
       List<Instance> nacosInstances = nacosDiscovery.getInstances(serviceName); 
       // 轉換為統一格式（IP:端口） 
       return nacosInstances.stream() 
           .map(inst -> inst.getIp() + ":" + inst.getPort()) 
           .collect(Collectors.toList()); 
   } 
} 

// 客户端使用 
public class ServiceConsumer { 
   private ServiceDiscovery discovery; 
   // 通過配置注入具體適配器（NacosAdapter/EurekaAdapter） 
   public ServiceConsumer(ServiceDiscovery discovery) { 
       this.discovery = discovery; 
   } 

   public void invokeService(String serviceName) { 

       List<String> instances = discovery.getServiceInstances(serviceName); 

       // 負載均衡調用 
   } 
}

2. 關鍵價值

接口統一：屏蔽不同註冊中心的 API 差異，業務代碼依賴抽象接口。
平滑遷移：切換註冊中心時只需替換適配器，無需修改業務邏輯（如從 Eureka 遷移到 Nacos）。

二、橋接模式：分佈式服務的抽象與實現分離

2.1 模式核心與分佈式應用

橋接模式通過分離抽象層與實現層，使二者可獨立演化。在分佈式系統中，該模式常用於解耦業務邏輯與底層通信協議（如 HTTP/RPC/Kafka）。

1. 消息發送的橋接設計

// 抽象層：消息發送器 
public abstract class MessageSender { 

   protected MessageChannel channel; // 橋接的實現層 
   public MessageSender(MessageChannel channel) { 
       this.channel = channel; 
   } 

   public abstract void send(Message message); 
} 

// 具體抽象：業務消息發送器 
public class BusinessMessageSender extends MessageSender { 

   public BusinessMessageSender(MessageChannel channel) { 
       super(channel); 
   } 

   @Override 
   public void send(Message message) { 
       // 業務邏輯：添加統一消息頭 
       message.addHeader("type", "business"); 
       channel.send(message); // 委託給實現層 
   } 
} 

// 實現層接口：消息通道 
public interface MessageChannel { 

   void send(Message message); 
} 


// 具體實現：Kafka通道 
public class KafkaChannel implements MessageChannel { 

   @Override 
   public void send(Message message) { 

       // Kafka SDK發送邏輯 
   } 
} 

// 具體實現：RabbitMQ通道 
public class RabbitMqChannel implements MessageChannel { 

   @Override 
   public void send(Message message) { 

       // RabbitMQ SDK發送邏輯 
   } 
} 

// 使用示例 
public class MessageService { 

   public void sendOrderMessage(Message message) { 

       // 橋接：業務邏輯與通信協議分離 
       MessageSender sender = new BusinessMessageSender(new KafkaChannel()); 

       sender.send(message); 
   } 
}

2. 分佈式場景優勢

多協議適配：同一業務邏輯可通過不同通道發送（如核心消息用 Kafka，普通消息用 RabbitMQ）。
擴展便捷：新增協議（如 RocketMQ）只需實現MessageChannel，無需修改抽象層。

三、組合模式：分佈式集羣的樹形結構管理

3.1 模式核心與集羣管理

組合模式通過樹形結構統一處理單個對象與對象集合，在分佈式系統中常用於集羣節點管理、服務拓撲維護等場景。

1. 集羣節點的組合設計

// 抽象組件：集羣節點 
public abstract class ClusterNode { 

   protected String nodeId; 
   protected String address; 

   public ClusterNode(String nodeId, String address) { 

       this.nodeId = nodeId; 
       this.address = address; 

   } 

   public abstract void start(); 
   public abstract void stop(); 

   public abstract List<ClusterNode> getChildren(); 

} 

// 葉子節點：單個服務實例 
public class ServiceNode extends ClusterNode { 

   public ServiceNode(String nodeId, String address) { 

       super(nodeId, address); 
   } 

   @Override 
   public void start() { 

       // 啓動單個服務實例（如調用API啓動容器） 
   } 

   @Override 
   public void stop() { 

       // 停止單個實例 
   } 


   @Override 
   public List<ClusterNode> getChildren() { 

       return Collections.emptyList(); // 葉子節點無children 
   } 
} 

// 組合節點：節點組（如機房/機架） 
public class NodeGroup extends ClusterNode { 

   private List<ClusterNode> children = new ArrayList<>(); 

   public NodeGroup(String nodeId, String address) { 

       super(nodeId, address); 
   } 

   public void addNode(ClusterNode node) { 
       children.add(node); 
   } 


   @Override 
   public void start() { 

       // 遞歸啓動所有子節點 
       children.forEach(ClusterNode::start); 
   } 


   @Override 
   public void stop() { 

       // 遞歸停止所有子節點 
       children.forEach(ClusterNode::stop); 
   } 

   @Override 
   public List<ClusterNode> getChildren() { 
       return children; 
   } 
} 


// 使用示例：管理跨機房集羣 
public class ClusterManager { 

   public void manageCluster() { 

       // 構建樹形結構：機房1 -> 機架1 -> 服務實例1/2 
       ClusterNode rack1 = new NodeGroup("rack-1", "dc1-rack1"); 
       rack1.addNode(new ServiceNode("service-1", "10.0.0.1:8080")); 
       rack1.addNode(new ServiceNode("service-2", "10.0.0.2:8080")); 
       ClusterNode dc1 = new NodeGroup("dc-1", "datacenter-1"); 
       dc1.addNode(rack1); 
       // 啓動整個機房的節點 
       dc1.start(); 
   } 
}

2. 分佈式場景價值

統一操作：對單個節點和節點組執行相同操作（如start()/stop()），簡化集羣管理。
拓撲可視化：通過getChildren()遞歸遍歷，可生成集羣拓撲圖（如展示機房 - 機架 - 實例的層級關係）。

四、裝飾器模式：分佈式服務的動態增強

4.1 模式核心與服務增強

裝飾器模式通過包裝對象動態添加功能，在分佈式系統中常用於服務調用的橫切邏輯增強（如日誌、監控、熔斷）。

1. 服務調用的裝飾器鏈

// 核心接口：服務調用器 
public interface ServiceInvoker { 

   Object invoke(String serviceName, String method, Object[] params) throws Exception; 

} 


// 基礎實現：REST調用器 
public class RestInvoker implements ServiceInvoker { 

   @Override 
   public Object invoke(String serviceName, String method, Object[] params) { 

       // 調用REST API的邏輯 
       return restTemplate.postForObject("/" + serviceName + "/" + method, params, Object.class); 

   } 
} 


// 裝飾器1：日誌裝飾器 
public class LoggingDecorator implements ServiceInvoker { 

   private ServiceInvoker invoker; 
   public LoggingDecorator(ServiceInvoker invoker) { 
       this.invoker = invoker; 
   } 


   @Override 
   public Object invoke(String serviceName, String method, Object[] params) throws Exception { 

       long start = System.currentTimeMillis(); 
       log.info("調用開始：{}#{}", serviceName, method); 

       try { 
           Object result = invoker.invoke(serviceName, method, params); 
           log.info("調用成功，耗時：{}ms", System.currentTimeMillis() - start); 

           return result; 
       } catch (Exception e) { 
           log.error("調用失敗", e); 
           throw e; 
       } 
   } 
} 


// 裝飾器2：熔斷裝飾器 
public class CircuitBreakerDecorator implements ServiceInvoker { 

   private ServiceInvoker invoker; 
   private CircuitBreaker circuitBreaker; 

   public CircuitBreakerDecorator(ServiceInvoker invoker) { 

       this.invoker = invoker; 
       this.circuitBreaker = CircuitBreaker.ofDefaults("serviceInvoker"); 

   } 

   @Override 
   public Object invoke(String serviceName, String method, Object[] params) throws Exception { 

       return Try.ofSupplier(() -> invoker.invoke(serviceName, method, params)).recover(circuitBreaker, e -> fallback(serviceName, method)).get(); 

   } 

   private Object fallback(String serviceName, String method) { 

       return "服務暫時不可用，請稍後重試"; 
   } 
} 

// 使用示例：構建裝飾器鏈 
public class InvokerClient { 
   public ServiceInvoker buildInvoker() { 
       // 基礎調用器 -> 日誌裝飾器 -> 熔斷裝飾器 
       return new CircuitBreakerDecorator(new LoggingDecorator(new RestInvoker()) ); 
   } 
}

2. 分佈式場景優勢

動態組合：按需組合裝飾器（如生產環境添加熔斷 + 監控，測試環境添加日誌 + 模擬延遲）。
無侵入增強：核心調用邏輯與橫切邏輯分離（如RestInvoker無需包含日誌或熔斷代碼）。

五、外觀模式：分佈式系統的統一入口

5.1 模式核心與網關設計

外觀模式通過提供統一接口封裝子系統複雜性，在分佈式系統中常用於 API 網關、服務聚合等場景。

1. 訂單服務的外觀設計

// 子系統1：庫存服務 
public class InventoryService { 

   public boolean deduct(Long productId, int quantity) { /* 扣減庫存 */ } 
} 

// 子系統2：支付服務 
public class PaymentService { 

   public String pay(Long orderId, BigDecimal amount) { /* 發起支付 */ } 

} 


// 子系統3：物流服務 
public class LogisticsService { 

   public void createDelivery(Long orderId, String address) { /* 創建物流單 */ } 

} 

// 外觀類：訂單流程管理器 
public class OrderFacade { 

   private InventoryService inventoryService; 
   private PaymentService paymentService; 
   private LogisticsService logisticsService; 

   // 封裝複雜流程為簡單接口 
   public OrderResult createOrder(OrderDTO order) { 
       // 1. 扣減庫存 
       boolean inventoryOk = inventoryService.deduct(order.getProductId(), order.getQuantity()); 
       if (!inventoryOk) { 
           return OrderResult.fail("庫存不足"); 
       } 
       // 2. 創建訂單記錄（本地事務） 
       Long orderId = orderRepository.save(order).getId(); 

       // 3. 發起支付 
       String payResult = paymentService.pay(orderId, order.getAmount()); 

       if (!"SUCCESS".equals(payResult)) { 
           // 支付失敗，回滾庫存 
           inventoryService.refund(order.getProductId(), order.getQuantity()); 
           return OrderResult.fail("支付失敗"); 
       } 
       // 4. 創建物流單 
       logisticsService.createDelivery(orderId, order.getAddress()); 
       return OrderResult.success(orderId); 
   } 
} 

// 客户端使用 
public class OrderController { 

   @Autowired 
   private OrderFacade orderFacade; 

   @PostMapping("/orders") 
   public OrderResult createOrder(@RequestBody OrderDTO order) { 

       // 調用外觀接口，無需關注子系統細節 
       return orderFacade.createOrder(order); 
   } 
}

2. 分佈式場景價值

簡化調用：客户端只需調用OrderFacade.createOrder()，無需逐個調用庫存、支付、物流服務。
事務協調：外觀類可封裝分佈式事務邏輯（如支付失敗時回滾庫存），避免客户端處理複雜協調。

六、享元模式：分佈式資源的高效複用

6.1 模式核心與連接池設計

享元模式通過共享細粒度對象減少資源消耗，在分佈式系統中常用於連接池、線程池、緩存池等場景。

1. 數據庫連接池的享元實現

// 享元接口：數據庫連接 
public interface DbConnection { 
   void execute(String sql); 
   void close(); // 歸還到池，而非真正關閉 
   boolean isActive(); 
} 

// 具體享元：MySQL連接 
public class MySqlConnection implements DbConnection { 

   private Connection connection; // 實際JDBC連接 
   private boolean inUse; // 是否被佔用 
   public MySqlConnection(Connection connection) { 
       this.connection = connection; 
   } 

   @Override 
   public void execute(String sql) { /* 執行SQL */ } 

   @Override 
   public void close() { 
       this.inUse = false; // 標記為可用，歸還到池 
   } 

   @Override 
   public boolean isActive() { /* 檢查連接是否有效 */ } 

   // 內部狀態設置（由連接池管理） 
   public void setInUse(boolean inUse) { 
       this.inUse = inUse; 
   } 
} 

// 享元工廠：連接池 
public class ConnectionPool { 

   private List<DbConnection> connections = new ArrayList<>(); 
   private String url; 
   private String username; 
   private String password; 
   private int maxSize = 10; // 最大連接數 
   public ConnectionPool(String url, String username, String password) { 

       this.url = url; 
       this.username = username; 
       this.password = password; 
       initialize(); 
   } 

   // 初始化連接池 
   private void initialize() { 
       for (int i = 0; i < maxSize; i++) { 
           Connection jdbcConn = DriverManager.getConnection(url, username, password); 
           connections.add(new MySqlConnection(jdbcConn)); 
       } 
   } 

   // 獲取連接（享元模式核心：複用現有連接） 
   public synchronized DbConnection getConnection() throws Exception { 

       // 查找可用連接 
       for (DbConnection conn : connections) { 
           if (!conn.isActive()) { 
               conn.setInUse(true); 
               return conn; 
           } 
       } 

       // 無可用連接，若未達上限則創建新連接 
       if (connections.size() < maxSize) { 
           DbConnection newConn = new MySqlConnection(DriverManager.getConnection(url, username, password)); 

           newConn.setInUse(true); 
           connections.add(newConn); 
           return newConn; 
       } 
       throw new Exception("連接池已滿"); 
   } 
}

2. 分佈式場景價值

資源複用：避免頻繁創建銷燬數據庫連接（創建成本高，約 10-100ms），提升系統性能。
限流保護：通過maxSize控制併發連接數，防止數據庫被壓垮。

七、代理模式：分佈式服務的透明代理

7.1 模式核心與遠程代理

代理模式通過代理對象控制對目標對象的訪問，在分佈式系統中常用於遠程代理（RPC 調用）、安全代理（權限控制）等場景。

1. RPC 服務的動態代理實現

// 服務接口 
public interface UserService { 

   User getUser(Long id); 
} 


// 遠程代理：客户端代理 
public class RpcProxy implements InvocationHandler { 

   private String serviceUrl; // 服務端地址 
   public RpcProxy(String serviceUrl) { 
       this.serviceUrl = serviceUrl; 
   } 

   // 創建代理實例 
   public <T> T createProxy(Class<T> serviceInterface) { 

       return (T) Proxy.newProxyInstance( 
           serviceInterface.getClassLoader(), 
           new Class[]{serviceInterface}, 
           this 
       ); 
   } 

   @Override 
   public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { 

       // 1. 封裝RPC請求（服務名、方法名、參數） 
       RpcRequest request = new RpcRequest( 
           method.getDeclaringClass().getName(), 
           method.getName(), 
           args 
       ); 

       // 2. 發送請求到服務端 
       RpcClient client = new RpcClient(serviceUrl); 
       RpcResponse response = client.send(request); 
       // 3. 處理響應 
       if (response.hasError()) { 
           throw response.getError(); 
       } 
       return response.getResult(); 
   } 
} 

// 客户端使用 
public class Client { 

   public static void main(String[] args) { 
       // 創建代理對象 
       RpcProxy proxy = new RpcProxy("http://user-service:8080/rpc"); 
       UserService userService = proxy.createProxy(UserService.class); 

       // 透明調用遠程服務（彷彿調用本地方法） 
       User user = userService.getUser(1L); 
   } 
}

2. 分佈式場景價值

透明遠程調用：客户端通過代理像調用本地方法一樣調用遠程服務，無需關注網絡通信細節。
中間層增強：代理可添加超時控制、重試、負載均衡等邏輯（如RpcProxy中實現失敗重試）。

八、面試高頻問題深度解析

8.1 基礎概念類問題

Q：適配器模式與代理模式的核心區別？在分佈式服務集成中如何選擇？

A：

維度	適配器模式	代理模式
核心目標	解決接口不兼容問題	控制對目標對象的訪問（如遠程調用、權限控制）
接口關係	適配者與目標接口不同	代理與目標接口相同
適用場景	異構系統集成（如多註冊中心適配）	遠程調用、權限控制、延遲加載

分佈式選擇：

集成異構系統（如不同協議、不同 API 的服務）時用適配器模式；需要透明訪問遠程服務或添加橫切邏輯（如超時控制）時用代理模式。

Q：裝飾器模式與代理模式都能增強對象功能，如何區分使用場景？

A：

裝飾器模式：強調動態組合功能（如為服務調用添加日誌 + 熔斷 + 監控，組合順序可調整），核心是 “增強”。
代理模式：強調控制訪問（如遠程代理控制遠程服務的訪問，安全代理控制權限），核心是 “控制”。
分佈式場景示例：
- 為 RPC 調用添加日誌和監控 → 裝飾器模式（功能組合）。
- 限制只有管理員能調用敏感接口 → 代理模式（訪問控制）。

8.2 實戰設計類問題

Q：如何用外觀模式設計一個電商訂單的分佈式事務協調器？

A：

子系統：訂單服務、庫存服務、支付服務、物流服務，每個服務有獨立的本地事務。
外觀類：OrderTransactionFacade，提供createOrder()方法封裝完整流程。
協調邏輯：

採用 SAGA 模式，分步執行本地事務（創建訂單→扣減庫存→支付→創建物流單）。
每個步驟失敗時調用補償事務（如支付失敗則回滾庫存和訂單）。
客户端：只需調用facade.createOrder()，無需感知分佈式事務細節。

Q：分佈式緩存系統中，如何用享元模式優化緩存節點的資源佔用？

A：

享元對象：緩存連接（如 Redis 連接），將連接的 “主機 / 端口” 作為內部狀態，“是否可用” 作為外部狀態。
享元工廠：CacheConnectionPool，維護連接池，複用空閒連接（而非每次創建新連接）。
資源控制：通過maxConnections限制總連接數，避免緩存服務器連接過載。
回收機制：定期檢測空閒連接，關閉超過閾值的閒置連接（如 5 分鐘未使用）。

總結：結構型模式的分佈式設計原則

核心選型策略

分佈式挑戰	推薦模式	解決思路
異構系統集成（多協議 / 多註冊中心）	適配器模式	統一接口，屏蔽差異
服務調用的橫切邏輯增強	裝飾器模式	動態組合日誌、熔斷、監控等功能
遠程服務的透明訪問	代理模式	封裝網絡通信，模擬本地調用
複雜流程的簡化與協調	外觀模式	提供統一入口，封裝分佈式事務等複雜邏輯
集羣節點的層級管理	組合模式	樹形結構統一管理單機與集羣

分佈式環境的設計要點

網絡容錯：所有模式實現需考慮網絡延遲、超時和重試（如代理模式中添加 RPC 超時控制）。
狀態一致性：組合模式和享元模式需處理分佈式狀態同步（如集羣節點狀態的一致性）。
性能權衡：代理、適配器等模式可能引入額外開銷，需避免過度設計（如輕量級場景可簡化模式實現）。

通過掌握結構型模式在分佈式系統中的演化與實踐，不僅能在面試中清晰解析架構設計問題，更能在實際項目中構建鬆耦合、可擴展的分佈式架構，體現高級程序員的系統設計能力。

晴空月明 Blog

@_wss

Tags

架構 (51)

設計模式 (50)

框架 (31)

代碼規範 (21)

Stories

結構型模式-架構解耦與擴展實踐 - Stories Detail

一、適配器模式：異構系統的橋樑

1.1 模式核心與分佈式適配場景

1. 多註冊中心適配（Nacos/Eureka/Consul）

2. 關鍵價值

二、橋接模式：分佈式服務的抽象與實現分離

2.1 模式核心與分佈式應用

1. 消息發送的橋接設計

2. 分佈式場景優勢

三、組合模式：分佈式集羣的樹形結構管理

3.1 模式核心與集羣管理

1. 集羣節點的組合設計

2. 分佈式場景價值

四、裝飾器模式：分佈式服務的動態增強

4.1 模式核心與服務增強

1. 服務調用的裝飾器鏈

2. 分佈式場景優勢

五、外觀模式：分佈式系統的統一入口

5.1 模式核心與網關設計

1. 訂單服務的外觀設計

2. 分佈式場景價值

六、享元模式：分佈式資源的高效複用

6.1 模式核心與連接池設計

1. 數據庫連接池的享元實現

2. 分佈式場景價值

七、代理模式：分佈式服務的透明代理

7.1 模式核心與遠程代理

1. RPC 服務的動態代理實現

2. 分佈式場景價值

八、面試高頻問題深度解析

8.1 基礎概念類問題

8.2 實戰設計類問題

總結：結構型模式的分佈式設計原則

核心選型策略

分佈式環境的設計要點

Add a new Comments