DEV Community: 架构师小白

状态模式深度指南：构建可动态切换行为的艺术

架构师小白 — Fri, 26 Jun 2026 01:06:34 +0000

状态模式深度指南：构建可动态切换行为的艺术

概述

状态模式（State Pattern）是一种行为型设计模式，它允许对象在内部状态改变时改变其行为。看起来对象似乎修改了其类。这种模式是解决复杂状态转换逻辑的利器，特别适合用于工作流引擎、游戏开发、订单处理系统等场景。

核心概念

状态模式的核心思想是：将每个状态封装为独立的类，对象的行为取决于其当前状态，而状态之间的转换由状态类自己管理。

关键角色

Context（上下文）：维护当前状态的实例，负责将请求委托给状态对象处理
State（抽象状态）：定义所有具体状态的共同接口
ConcreteState（具体状态）：实现各个具体状态的行为，并负责状态转换

为什么需要状态模式？

传统方式的困境

想象一个订单系统，订单有多种状态：待支付、待发货、已发货、已完成、已取消。每个状态下可以执行不同的操作。

// 传统的if-else方式
class Order {
    public void process() {
        if (status.equals("待支付")) {
            // 处理支付逻辑
        } else if (status.equals("待发货")) {
            // 处理发货逻辑
        } else if (status.equals("已发货")) {
            // 处理签收逻辑
        }
        // ... 越来越多的条件判断
    }
}

这种方式的问题：

代码膨胀：每个方法都包含大量if-else
难以维护：新增状态需要修改多个方法
违反开闭原则：无法在不修改现有代码的情况下添加新状态
状态逻辑分散：状态转换规则散落在各处

状态模式的解决方案

状态模式通过将每个状态封装为独立类，让每个状态负责自己的行为和转换逻辑，从而解决上述问题。

实战案例：订单状态管理系统

1. 定义抽象状态接口

public interface OrderState {
    void pay(OrderContext context);
    void ship(OrderContext context);
    void deliver(OrderContext context);
    void cancel(OrderContext context);
    String getStatusName();
}

2. 创建具体状态类

// 待支付状态
public class PendingPaymentState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        System.out.println("订单支付成功！");
        context.setState(new PendingShipmentState());
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("订单未支付，无法发货");
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单未发货，无法签收");
    }

    @Override
    public void cancel(OrderContext context) {
        System.out.println("订单已取消");
        context.setState(new CancelledState());
    }

    @Override
    public String getStatusName() {
        return "待支付";
    }
}

// 待发货状态
public class PendingShipmentState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已支付");
    }

    @Override
    public void ship(OrderContext context) {
        System.out.println("商品已发货！");
        context.setState(new ShippedState());
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单未发货");
    }

    @Override
    public void cancel(OrderContext context) {
        System.out.println("取消发货，订单退款中");
        context.setState(new CancelledState());
    }

    @Override
    public String getStatusName() {
        return "待发货";
    }
}

// 已发货状态
public class ShippedState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已支付");
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("商品已发货");
    }

    @Override
    public void deliver(OrderContext context) {
        System.out.println("订单已完成！");
        context.setState(new CompletedState());
    }

    @Override
    public void cancel(OrderContext context) {
        throw new IllegalStateException("商品已发出，无法取消");
    }

    @Override
    public String getStatusName() {
        return "已发货";
    }
}

// 已完成状态
public class CompletedState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已完成");
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("订单已完成");
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单已完成");
    }

    @Override
    public void cancel(OrderContext context) {
        throw new IllegalStateException("已完成订单无法取消");
    }

    @Override
    public String getStatusName() {
        return "已完成";
    }
}

// 已取消状态
public class CancelledState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public void deliver(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public void cancel(OrderContext context) {
        throw new IllegalStateException("订单已取消");
    }

    @Override
    public String getStatusName() {
        return "已取消";
    }
}

3. 创建上下文类

public class OrderContext {
    private OrderState state;
    private String orderId;

    public OrderContext(String orderId) {
        this.orderId = orderId;
        this.state = new PendingPaymentState(); // 初始状态
    }

    public void setState(OrderState state) {
        this.state = state;
        System.out.println("订单状态变更为: " + state.getStatusName());
    }

    public OrderState getState() {
        return state;
    }

    // 委托给当前状态处理
    public void pay() {
        state.pay(this);
    }

    public void ship() {
        state.ship(this);
    }

    public void deliver() {
        state.deliver(this);
    }

    public void cancel() {
        state.cancel(this);
    }
}

4. 客户端使用

public class Client {
    public static void main(String[] args) {
        OrderContext order = new OrderContext("ORDER-001");

        order.pay();        // 支付 -> 待发货
        order.ship();       // 发货 -> 已发货
        order.deliver();    // 签收 -> 已完成
    }
}

输出：

订单支付成功！
订单状态变更为: 待发货
商品已发货！
订单状态变更为: 已发货
订单已完成！
订单状态变更为: 已完成

状态模式的优缺点

优点

单一职责：每个状态类只负责自己的行为和状态转换
开闭原则：新增状态只需添加新的状态类，不影响现有代码
消除条件判断：用多态替代大量的if-else
状态转换明确：状态转换逻辑集中在状态类中，便于管理和调试

缺点

类数量增加：每个状态都需要一个独立类
学习曲线：对于新手来说，代码结构需要理解时间
过度设计：对于简单场景可能过于复杂

状态模式 vs 策略模式

这两个模式结构非常相似，但意图不同：

特性	状态模式	策略模式
意图	对象行为随状态自动改变	算法/策略可替换
参与者	上下文知道状态，状态知道转换	上下文选择策略，策略相互独立
改变时机	状态类内部决定转换	客户端决定使用哪个策略
耦合度	状态类之间有依赖	策略类之间通常独立

简单来说：策略模式是"我不变，但你可以换策略"，状态模式是"我变了，所以行为也变"。

实际应用场景

工作流引擎：审批流程、状态流转
游戏开发：角色状态（站立、跑步、跳跃、攻击）
订单系统：订单生命周期管理
ATM机：不同状态下的操作行为
网络协议：TCP连接状态管理

状态机与状态模式

对于更复杂的状态转换，建议引入状态机框架：

// 使用Spring Statemachine
@Configuration
@EnableStateMachine
public class OrderStateMachineConfig extends StateMachineConfigurerAdapter<OrderStates, OrderEvents> {

    @Override
    public void configure(StateMachineStateConfigurer<OrderStates, OrderEvents> states) throws Exception {
        states
            .withStates()
            .initial(OrderStates.PENDING_PAYMENT)
            .states(EnumSet.allOf(OrderStates.class))
            .end(OrderStates.COMPLETED)
            .end(OrderStates.CANCELLED);
    }

    @Override
    public void configure(StateMachineTransitionConfigurer<OrderStates, OrderEvents> transitions) throws Exception {
        transitions
            .withExternal()
                .source(OrderStates.PENDING_PAYMENT)
                .target(OrderStates.PENDING_SHIPMENT)
                .event(OrderEvents.PAY)
            .and()
            .withExternal()
                .source(OrderStates.PENDING_SHIPMENT)
                .target(OrderStates.SHIPPED)
                .event(OrderEvents.SHIP);
    }
}

总结

状态模式是处理复杂状态逻辑的利器，它将状态转换封装到独立的状态类中，使得代码更加清晰、易于维护。当你的系统有以下特征时，考虑使用状态模式：

对象行为依赖其内部状态
状态转换逻辑复杂，包含大量条件判断
需要在不修改现有代码的情况下添加新状态
状态转换需要被明确跟踪和管理

掌握状态模式，让你的代码更具可维护性和扩展性！

参考资源：

《设计模式：可复用面向对象软件的基础》
Spring Statemachine 官方文档

迭代器模式深度指南：遍历集合的艺术

架构师小白 — Thu, 25 Jun 2026 01:05:58 +0000

迭代器模式深度指南：遍历集合的艺术

迭代器模式是一种行为设计模式，提供了一种顺序访问集合元素的方法，而无需暴露集合的底层表示。

为什么需要迭代器模式？

直接遍历暴露了内部结构：

for i in range(len(collection)):
    print(collection[i])

问题：

耦合性高：代码与特定数据结构绑定
缺乏灵活性：数据结构改变，遍历代码也要修改
无法复用：每种数据结构都需要独立的遍历逻辑

迭代器模式的核心结构

角色	职责
Iterator	定义访问和遍历元素的接口
ConcreteIterator	实现迭代器接口，记录当前位置
Aggregate	定义创建迭代器对象的接口
ConcreteAggregate	实现创建迭代器接口

Python 实现

基础迭代器

class Book:
    def __init__(self, title, author):
        self.title = title
        self.author = author

class LibraryIterator:
    def __init__(self, books):
        self._books = books
        self._position = 0

    def __iter__(self):
        return self

    def __next__(self):
        if self._position >= len(self._books):
            raise StopIteration
        book = self._books[self._position]
        self._position += 1
        return book

class Library:
    def __init__(self):
        self._books = []

    def add_book(self, book):
        self._books.append(book)

    def __iter__(self):
        return LibraryIterator(self._books)

# 使用
library = Library()
library.add_book(Book("设计模式", "GoF"))
library.add_book(Book("重构", "Martin Fowler"))

for book in library:
    print(f"{book.title} - {book.author}")

生成器实现

class Library:
    def __init__(self):
        self._books = []

    def add_book(self, book):
        self._books.append(book)

    def __iter__(self):
        for book in self._books:
            yield book

实际应用场景

1. 惰性加载分页数据

class LazyPageIterator:
    def __init__(self, fetch_func, page_size=10):
        self._fetch_func = fetch_func
        self._page_size = page_size
        self._current_page = 0
        self._current_data = []
        self._position = 0
        self._exhausted = False

    def __iter__(self):
        return self

    def __next__(self):
        if self._position >= len(self._current_data):
            if self._exhausted:
                raise StopIteration
            self._current_page += 1
            self._current_data = self._fetch_func(
                self._current_page, 
                self._page_size
            )
            if not self._current_data:
                self._exhausted = True
                raise StopIteration
            self._position = 0

        item = self._current_data[self._position]
        self._position += 1
        return item

2. 组合模式深度优先遍历

class FileSystemNode:
    def __init__(self, name):
        self.name = name
        self.children = []

    def add(self, node):
        self.children.append(node)

class CompositeIterator:
    def __init__(self, node):
        self._stack = [node]

    def __iter__(self):
        return self

    def __next__(self):
        if not self._stack:
            raise StopIteration
        node = self._stack.pop(0)
        for child in reversed(node.children):
            self._stack.insert(0, child)
        return node.name

迭代器模式 vs for 循环

特性	迭代器模式	for 循环
内存效率	惰性加载，按需获取	一次性加载
状态管理	自动记录当前位置	需要手动管理索引
解耦	与数据结构解耦	依赖数据结构

Python 迭代器协议

class MyIterator:
    def __init__(self, data):
        self._data = data
        self._index = 0

    def __iter__(self):
        return self

    def __next__(self):
        if self._index >= len(self._data):
            raise StopIteration
        result = self._data[self._index]
        self._index += 1
        return result

最佳实践

优先使用生成器：yield关键字让迭代器更简洁
遵循单一职责：迭代器只负责遍历
支持多种遍历方式：前向、反向、过滤等
文档化遍历行为：明确遍历顺序和终止条件

总结

迭代器模式：

解耦数据结构和遍历逻辑
简化客户端代码
提高可维护性和可测试性
支持惰性加载和流式处理

理解这一模式能帮助我们更好地使用语言特性，在需要时自定义遍历逻辑，设计更优雅的API。

参考资料：

《设计模式：可复用面向对象软件的基础》
Fluent Python - Luciano Ramalho

工厂模式深度指南：创建对象的艺术

架构师小白 — Wed, 24 Jun 2026 01:06:26 +0000

工厂模式深度指南：创建对象的艺术

在软件设计中，创建对象是一个最基本也最常见的需求。当对象的创建逻辑变得复杂，或者对象的创建方式需要灵活切换时，直接使用 new 关键字就不是最佳选择了。工厂模式（Factory Pattern）作为一种创建型设计模式，提供了创建对象的统一接口，让对象的创建与使用解耦。

什么是工厂模式？

工厂模式是一种创建型设计模式，它定义了一个创建对象的接口，但让子类决定实例化哪个类。工厂方法让类的实例化延迟到子类。

简单工厂（Simple Factory）

最简单的工厂形式，通常用一个静态方法根据参数创建不同的对象：

class Product:
    def operation(self):
        pass

class ProductA(Product):
    def operation(self):
        return "Product A"

class ProductB(Product):
    def operation(self):
        return "Product B"

class SimpleFactory:
    @staticmethod
    def create_product(product_type):
        if product_type == "A":
            return ProductA()
        elif product_type == "B":
            return ProductB()
        raise ValueError(f"Unknown product type: {product_type}")

工厂方法模式（Factory Method Pattern）

将对象的创建委托给子类，让子类决定创建哪个对象：

from abc import ABC, abstractmethod

class Creator(ABC):
    @abstractmethod
    def factory_method(self):
        pass

    def some_operation(self):
        product = self.factory_method()
        return f"Creator: {product.operation()}"

class ConcreteCreatorA(Creator):
    def factory_method(self):
        return ProductA()

class ConcreteCreatorB(Creator):
    def factory_method(self):
        return ProductB()

抽象工厂模式（Abstract Factory Pattern）

提供一个创建一系列相关对象的接口，而无需指定它们具体的类：

class AbstractFactory(ABC):
    @abstractmethod
    def create_product_a(self):
        pass

    @abstractmethod
    def create_product_b(self):
        pass

class ConcreteFactory1(AbstractFactory):
    def create_product_a(self):
        return ProductA1()

    def create_product_b(self):
        return ProductB1()

class ConcreteFactory2(AbstractFactory):
    def create_product_a(self):
        return ProductA2()

    def create_product_b(self):
        return ProductB2()

实际应用场景

1. 日志框架

public interface LoggerFactory {
    Logger createLogger();
}

public class FileLoggerFactory implements LoggerFactory {
    @Override
    public Logger createLogger() {
        return new FileLogger();
    }
}

public class DatabaseLoggerFactory implements LoggerFactory {
    @Override
    public Logger createLogger() {
        return new DatabaseLogger();
    }
}

2. 支付系统

根据用户选择的支付方式创建不同的支付处理器：

public interface PaymentFactory {
    PaymentProcessor createProcessor();
}

public class AlipayFactory implements PaymentFactory {
    public PaymentProcessor createProcessor() {
        return new AlipayProcessor();
    }
}

public class WechatPayFactory implements PaymentFactory {
    public PaymentProcessor createProcessor() {
        return new WechatPayProcessor();
    }
}

3. 图表库

根据配置创建不同类型的图表：

class ChartFactory {
  static createChart(type) {
    switch(type) {
      case 'line': return new LineChart();
      case 'bar': return new BarChart();
      case 'pie': return new PieChart();
      default: throw new Error('Unknown chart type');
    }
  }
}

工厂模式的优缺点

优点

解耦：将对象的创建与使用分离
可扩展：新增产品类型只需添加新的工厂类
测试友好：可以轻松mock工厂创建的对象
代码复用：创建逻辑可以在多个地方复用

缺点

类数量增加：每种产品都需要对应的工厂类
复杂度上升：引入额外的抽象层
过度设计风险：对于简单场景可能过度复杂

何时使用工厂模式？

对象的创建逻辑复杂或有多种变体
需要在不同环境/配置下创建不同对象
对象的创建涉及第三方库或外部资源
需要统一创建接口以便后续替换实现
对象的创建逻辑可能频繁变化

总结

工厂模式是软件开发中最常用的设计模式之一。它通过封装对象的创建过程，实现了对象创建与使用的解耦，让代码更加灵活、可维护和可测试。

在实际项目中，不要过度追求设计模式的完美使用，要根据具体场景选择合适的方案。对于简单的对象创建，直接使用 new 或简单的工厂方法即可；对于复杂的创建逻辑，再考虑使用完整的工厂方法或抽象工厂模式。

标签: 设计模式, 软件架构, 后端开发, Python, Java

混沌工程深度指南：构建反脆弱系统的核心实践

架构师小白 — Tue, 23 Jun 2026 01:07:33 +0000

混沌工程深度指南：构建反脆弱系统的核心实践

引言

在分布式系统日益复杂的今天，系统崩溃不再是如果的问题，而是何时的问题。传统的测试方法只能验证已知的场景，而混沌工程则通过主动注入故障来发现系统的隐藏弱点，让系统在面对真实故障时更加健壮。

本文将深入探讨混沌工程的核心原则、实施步骤，并通过实际案例展示如何构建一个反脆弱的系统。

什么是混沌工程？

混沌工程起源于Netflix在2010年创建的Chaos Monkey工具。最初，它是为了确保Netflix的流媒体服务能够在任意组件故障时保持可用。经过多年发展，混沌工程已经成为一门系统性的学科，被Google、Amazon、Microsoft等科技巨头广泛采用。

混沌工程的核心思想是不要等到故障发生时才被动应对，而是主动制造故障，在受控环境中学习和改进。

混沌工程的核心原则

1. 建立稳定状态假设

在注入故障之前，首先需要定义什么是正常行为。这包括关键指标、业务指标、系统指标等。只有明确了稳定状态，才能判断故障的影响程度。

2. 注入真实世界的故障

故障注入应该模拟真实世界可能发生的情况：网络延迟和丢包、服务器宕机和重启、磁盘空间不足、内存泄漏、数据库连接池耗尽、第三方服务不可用等。

3. 在生产环境进行实验

测试环境与生产环境的差异往往导致问题被忽视。混沌工程强调在生产环境进行实验，但需要控制爆炸半径、设置自动停止条件、准备回滚方案、选择低峰期进行实验。

4. 持续自动化实验

手动实验难以规模化。混沌工程应该是自动化的，包括定期执行故障注入、自动收集和分析结果、自动警报和通知、与CI/CD流程集成。

实施混沌工程的步骤

步骤1：选择故障注入点

从最关键、最脆弱的组件开始：核心业务逻辑服务、数据库和存储、负载均衡器、缓存层、第三方集成。

步骤2: 设计实验

一个完整的混沌实验包含假设、变量、度量、停止条件。

步骤3：执行监控

在实验过程中，密切监控服务可用性、错误率、响应延迟、业务指标等。

步骤4：分析和改进

实验后，分析是否在预期范围内、有哪些意外发现、需要做什么改进、如何防止再次发生。

实践案例

实验一：数据库故障注入

假设：如果订单服务的主数据库不可用，订单创建会失败吗？

实验：停止订单服务的数据库连接，观察订单创建的成功率，检查是否有降级机制。

预期：系统应该能够使用备用数据库，或者将订单暂存本地稍后同步，用户收到明确的通知。

实验二：网络延迟注入

假设：如果支付服务响应延迟，用户会等待多久？

实验：在支付服务注入延迟，观察用户等待时间，检查是否有超时机制。

预期：超时后返回明确错误，有重试机制，不阻塞用户流程。

实验三：服务实例故障

假设：如果某个服务实例宕机，请求会失败吗？

实验：杀死一个服务实例，观察请求是否自动路由到其他实例。

预期：负载均衡自动移除故障实例，请求自动路由到健康实例。

混沌工程工具生态

开源工具

Chaos Monkey (Netflix) - 随机终止EC2实例
LitmusChaos - Kubernetes原生混沌工程框架
Chaos Mesh - 云原生混沌工程平台
Pumba - Docker容器混沌实验

商业工具

Gremlin - 企业级混沌工程平台
ChaosIQ - Azure混沌工程支持

最佳实践建议

1. 从小处着手

不要一开始就大规模注入故障。从一个服务、一个用户开始，逐步扩大范围。

2. 建立安全网

设置自动停止条件，准备回滚方案，有明确的升级流程。

3. 全员参与

混沌工程不只是运维的事，开发人员、测试人员、产品人员都需要参与。

4. 文档化和分享

每个实验都是学习机会，记录实验假设和结果，分享发现和改进，建立组织知识库。

常见误区

1. 混沌工程就是制造混乱

真相：混沌工程是有控制、有计划的实验，目的是学习和改进。

2. 只在生产环境做

真相：可以在预发布环境进行实验，但最终需要在生产环境验证。

3. 一次性活动

真相：混沌工程是持续的过程，需要定期执行。

4. 只关注技术指标

真相：也要关注业务指标，确保故障不影响业务目标。

总结

混沌工程不是让系统更加不稳定，而是让系统在面对真实故障时更加健壮。通过主动注入故障，我们能够发现隐藏的弱点、验证容灾能力、建立信心、持续改进。

在分布式系统时代，混沌工程已经成为构建可靠系统的必备实践。从今天开始，选择一个服务，设计你的第一个混沌实验吧！

参考资源

Chaos Monkey: https://github.com/Netflix/chaosmonkey
LitmusChaos: https://litmuschaos.io
Chaos Mesh: https://chaos-mesh.org
Principles of Chaos Engineering: https://principlesofchaos.org

如果你觉得这篇文章有帮助，欢迎在评论区分享你的混沌工程实践经验！

外观模式深度指南：简化复杂系统的艺术

架构师小白 — Sun, 21 Jun 2026 01:02:45 +0000

外观模式深度指南：简化复杂系统的艺术

什么是外观模式？

外观模式（Facade Pattern）是一种结构型设计模式，它为复杂的子系统提供一个统一的接口，使子系统更容易使用。外观模式的核心思想是封装复杂，暴露简单。

为什么需要外观模式？

在实际软件开发中，我们经常面对这样的情况：一个系统由多个类组成，这些类之间相互依赖，形成了一个复杂的关系网。当客户端需要使用这个系统时，它需要了解所有类的接口和交互方式，这增加了学习和使用成本。

外观模式通过提供一个统一的接口来解决这个问题。客户端只需要与外观对象交互，而不需要了解子系统内部的复杂实现。

外观模式的结构

外观模式包含以下角色：

外观（Facade）：为子系统提供一个统一的接口，负责将客户端请求转发给子系统。
子系统（Subsystem）：实现子系统的功能，处理外观对象转发的请求。

# 外观模式示例代码
class SubsystemA:
    def operation_a(self):
        return "子系统A操作"

class SubsystemB:
    def operation_b(self):
        return "子系统B操作"

class SubsystemC:
    def operation_c(self):
        return "子系统C操作"

class Facade:
    def __init__(self):
        self.subsystem_a = SubsystemA()
        self.subsystem_b = SubsystemB()
        self.subsystem_c = SubsystemC()

    def operation(self):
        result = []
        result.append(self.subsystem_a.operation_a())
        result.append(self.subsystem_b.operation_b())
        result.append(self.subsystem_c.operation_c())
        return " ".join(result)

外观模式的应用场景

为复杂的库或框架提供简化的接口：如为第三方库提供统一的封装。
分层架构：在每一层提供外观服务，简化层间交互。
系统集成：将多个系统的接口整合为一个统一的接口。

外观模式的优点

简化接口：客户端只需要与外观对象交互，不需要了解子系统细节。
解耦：将客户端与子系统解耦，子系统变化不影响客户端。
分层：支持将系统分层，每层使用外观服务。

注意事项

外观模式不是禁止客户端直接访问子系统对象。在需要精细控制时，客户端仍然可以直接访问子系统，只是外观模式提供了一个更简单的入口。

总结

外观模式是一种简单但强大的设计模式，它通过提供一个统一的接口来简化复杂系统的使用。在实际开发中，我们应该在需要简化复杂子系统时使用外观模式，但要避免过度使用导致外观对象变成上帝对象。

参考阅读

《设计模式：可复用面向对象软件的基础》
《Head First 设计模式》

适配器模式深度指南：构建兼容并蓄的软件系统

架构师小白 — Sat, 20 Jun 2026 01:03:16 +0000

适配器模式深度指南：构建兼容并蓄的软件系统

概述

适配器模式（Adapter Pattern）是设计模式中最具实用价值的一种结构型模式，它的核心作用是将一个类的接口转换成客户端所期望的另一个接口，从而使原本不兼容的两个类能够协同工作。

想象一下，你有一个欧洲标准的电源插头，却要插入美国标准的插座——这时你需要的就是一个适配器。软件世界中的适配器模式正是解决这个问题的。

为什么需要适配器模式

在实际项目中，我们经常会遇到以下情况：

遗留系统集成：旧系统提供了A接口，但新系统需要B接口
第三方库整合：不同第三方库提供不同的接口规范
模块解耦：希望在不修改原有代码的情况下，让新模块能够调用旧模块

适配器模式让这些问题迎刃而解，它是一种向后兼容的利器。

适配器模式的结构

类适配器（通过继承）

# 目标接口
class Target:
    def request(self):
        return "Target: Default behavior"

# 需要适配的类
class Adaptee:
    def specific_request(self):
        return ".eetpadA eht fo roivaC"

# 适配器（使用继承）
class Adapter(Target, Adaptee):
    def request(self):
        return self.specific_request()[::-1]  # 反转字符串

对象适配器（通过组合）

class Adapter(Target):
    def __init__(self, adaptee):
        self.adaptee = adaptee

    def request(self):
        return self.adaptee.specific_request()[::-1]

推荐使用对象适配器，因为它遵循组合优于继承的原则，更加灵活。

真实世界中的应用案例

案例1：支付系统整合

# 旧的支付API
class LegacyPaymentAPI:
    def pay(self, amount, currency):
        return f"Paid {amount} {currency} via legacy system"


# 新的统一支付接口
class PaymentGateway:
    def process_payment(self, amount):
        raise NotImplementedError

# 适配器
class PaymentAdapter(PaymentGateway):
    def __init__(self, legacy_api):
        self.legacy = legacy_api

    def process_payment(self, amount):
        # 转换 currency 和接口格式
        return self.legacy.pay(amount, "USD")

案例2：日志框架统一

# 不同的日志库有不同的接口
class LoggerA:
    def info(self, msg): print(f"INFO: {msg}")

class LoggerB:
    def log(self, level, msg): print(f"[{level}] {msg}")

# 统一接口
class UnifiedLogger:
    def log(self, message): pass

# 适配器
class LoggerBAdapter(UnifiedLogger):
    def __init__(self, logger_b):
        self.logger_b = logger_b

    def log(self, message):
        self.logger_b.log("INFO", message)

案例3：数据库适配器

在ORM框架中，适配器模式让开发者可以用统一的API操作不同的数据库：

SQLite → MySQL → PostgreSQL
底层的差异被适配器层完��屏蔽

适配器模式 vs 装饰器模式

特性	适配器模式	装饰器模式
目的	接口转换	动态增强功能
原接口	不兼容	兼容
使用场景	集成遗留系统	功能扩展
运行时	通常编译时确定	运行时动态添加

最佳实践

优先使用对象适配器：组合优于继承，更灵活
保持适配器简洁：只做接口转换，不做业务逻辑
考虑外观模式：如果需要为多个类提供统一接口，可以结合外观模式
测试适配器：确保适配器正确转换了所有必要的接口

总结

适配器模式是一种看似简单但极其强大的设计模式：

✅ 让不兼容的接口能够协同工作
✅ 实现系统间的松耦合
✅ 便于后续维护和扩展
✅ 遵循"开闭原则"——不修改原有代码的情况下扩展功能

正如现实中的电源适配器让不同国家的电器都能正常使用一样，软件中的适配器模式让你的系统能够优雅地集成各种组件，无论它们原本是否"兼容"。

关注我，了解更多软件架构设计与实战经验！

洋葱架构深度指南：构建可测试可维护软件的精髓之道

架构师小白 — Fri, 19 Jun 2026 01:05:22 +0000

洋葱架构深度指南：构建可测试可维护软件的精髓之道

洋葱架构（Onion Architecture）是一种将系统组织为同心层结构的架构模式，核心原则是"依赖指向中心"——外层依赖内层，内层完全独立于外层。

为什么需要洋葱架构？

传统的三层架构（表现层、业务逻辑层、数据访问层）存在一个根本性问题：业务逻辑层依赖数据访问层，这导致：

更换数据库需要修改业务代码
单元测试难以进行（难以mock数据层）
业务逻辑与基础设施紧耦合

洋葱架构通过依赖倒置原则解决这些问题。

洋葱架构的核心层次

┌─────────────────────────────────────┐
│         基础设施层 (Infrastructure)   │ ← 数据库、API客户端、文件系统
├─────────────────────────────────────┤
│         应用层 (Application)        │ ← 用例、编排、事务管理
├─────────────────────────────────────┤
│         领域层 (Domain)              │ ← 实体、值对象、领域服务
├─────────────────────────────────────┤
│         核心层 (Core)                 │ ← 业务规则、接口抽象
└─────────────────────────────────────┘

1. 核心层（Domain Core）

最内层，完全独立，不依赖任何外部：

# 领域实体
class Order:
    def __init__(self, order_id, items):
        self.id = order_id
        self.items = items
        self.status = "pending"

    def total(self):
        return sum(item.price * item.quantity for item in self.items)

    def can_cancel(self):
        return self.status == "pending"

2. 领域层（Domain）

定义业务接口，不实现：

# 领域接口（抽象）
class IOrderRepository:
    def save(self, order: Order): pass
    def find_by_id(self, order_id): pass

class IPaymentService:
    def process_payment(self, order: Order): pass

3. 应用层（Application）

用例（Use Cases）所在，协调领域对象：

class CreateOrderUseCase:
    def __init__(self, order_repo: IOrderRepository):
        self.order_repo = order_repo

    def execute(self, order_data):
        # 创建订单
        order = Order(order_data["id"], order_data["items"])
        self.order_repo.save(order)
        return order

4. 基础设施层（Infrastructure）

实现领域层定义的接口：

class PostgresOrderRepository(IOrderRepository):
    def __init__(self, db_connection):
        self.db = db_connection

    def save(self, order):
        # 实际的数据库操作
        self.db.insert("orders", order.__dict__)

依赖流向：关键原则

所有依赖都指向内层，通过依赖注入实现：

表现层 → 应用层 → 领域层 → 基础设施层
   ↑         ↑         ↑         ↓
   └─────────┴─────────┴─────────┘
              依赖注入

依赖注入示例：

# 运行时注入实现
order_repo = PostgresOrderRepository(db_connection)
create_order = CreateOrderUseCase(order_repo)

实战：用DI容器管理依赖

from injector import Injector

# 注册绑定
injector = Injector()
injector.bind(IOrderRepository, to=PostgresOrderRepository)
injector.bind(IPaymentService, to=StripePaymentService)

# 注入使用
order = injector.get(CreateOrderUseCase).execute(data)

洋葱架构 vs 传统分层

维度	三层架构	洋葱架构
依赖方向	上层→下层	外层→内层
业务逻辑	在Service层	在Domain层
可测试性	困难	容易
替换数据库	修改业务代码	仅替换Infrastructure
依赖注入	可选	必需

何时使用洋葱架构？

✅ 适合场景：

中大型复杂业务系统
需要频繁更换数据存储
高度可测试性要求
微服务内部架构

❌ 不适合场景：

简单CRUD应用
快速原型验证
小型脚本工具

总结

洋葱架构的核心理念：

让核心业务逻辑完全独立于基础设施

通过依赖指向中心的组织方式，我们实现了：

🎯 高度可测试
🔄 易于替换组件
📦 清晰的责任边界
🛠 长期可维护

这是构建企业级应用的坚实基础。

下期预告：六边形架构（Hexagonal Architecture）与洋葱架构的对比与融合。

如果你觉得这篇文章有帮助，欢迎关注、点赞、转发！我是@甜心，上午好！🍬

Kubernetes架构设计模式深度指南：构建云原生应用的核心实践

架构师小白 — Thu, 18 Jun 2026 01:05:42 +0000

Kubernetes架构设计模式深度指南：构建云原生应用的核心实践

Kubernetes已成为现代云原生应用的标准部署平台，但如何有效利用K8s的架构能力构建可靠、可扩展的系统，是每个开发者都需要掌握的技能。

引言

Kubernetes不仅仅是一个容器编排工具，更是一个完整的分布式系统管理平台。掌握K8s架构设计模式，能够帮助开发者构建更加健壮、可维护的云原生应用。

一、Kubernetes核心概念回顾

1.1 Pod：最小的调度单元

Pod是Kubernetes中最基本的部署单元，一个Pod可以包含一个或多个容器。最佳实践是单容器单职责，但在实际场景中，常常需要将紧密耦合的容器放在一起。

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    ports:
    - containerPort: 8080

1.2 ReplicaSet与Deployment

ReplicaSet：确保指定数量的Pod副本运行
Deployment：管理Pod的声明式更新，支持滚动更新和回滚

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: myapp:v2
        ports:
        - containerPort: 8080

二、Kubernetes架构设计模式

2.1 sidecar模式

Sidecar模式是将辅助功能（日志收集、配置管理、监控）与主应用分离的架构模式。

典型应用场景：

日志收集（fluentd sidecar）
配置同步（config-loader sidecar）
代理服务（envoy sidecar）

apiVersion: v1
kind: Pod
metadata:
  name: webapp-with-sidecar
spec:
  containers:
  # 主应用容器
  - name: webapp
    image: mywebapp:latest
    ports:
    - containerPort: 8080
  # Sidecar容器 - 日志收集
  - name: log-collector
    image: fluentd:latest
    volumeMounts:
    - name: logs
      mountPath: /var/log/app

优势：

关注点分离，主应用无需关心基础设施逻辑
可独立升级sidecar而不影响主应用
复用性强，不同应用可以使用相同的sidecar

2.2 Ambassador模式

Ambassador模式使用一个代理容器来抽象外部服务的访问，类似于外观模式。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-ambassador
spec:
  containers:
  - name: app
    image: myapp:latest
  - name: proxy
    image: envoy-proxy:latest
    env:
    - name: UPSTREAM_SERVICE
      value: "external-service:8080"

优势：

简化主应用的外部通信逻辑
可以在代理层做流量控制、熔断、限流
易于切换外部服务地址

2.3 Adapter模式

Adapter模式用于统一不同服务的接口，使得不同服务可以以统一的方式被访问。

apiVersion: v1
kind: Pod
metadata:
  name: legacy-app-adapter
spec:
  containers:
  - name: legacy-app
    image: legacy:v1
  - name: adapter
    image: api-adapter:latest
    ports:
    - containerPort: 8080

典型场景：

旧系统适配新接口
统一不同服务的输出格式
数据格式转换

2.4 Leader Election模式

在分布式系统中，常需要leader来协调任务。使用K8s的Lease API实现leader选举：

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  name: my-app-leader
  namespace: default
spec:
  holderIdentity: pod-1
  leaseDurationSeconds: 15
  acquireTime: "2024-01-01T00:00:00Z"
  renewTime: "2024-01-01T00:00:10Z"
  leaderTransitions: 0

2.5 Stateful Workload模式

对于有状态应用，使用StatefulSet：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  serviceName: database
  replicas: 3
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      labels:
        app: database
    spec:
      containers:
      - name: db
        image: postgres:14
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

三、高可用架构实践

3.1 滚动更新与回滚

使用Deployment的滚动更新策略：

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

maxSurge：允许超过期望的Pod数量
maxUnavailable：更新期间不可用的Pod数量

3.2 探针与健康检查

K8s提供三种探针：

livenessProbe：检查应用是否存活，失败会重启容器
readinessProbe：检查是否可以接收流量，影响ServiceEndpoint
startupProbe：检查应用是否启动完成

spec:
  containers:
  - name: app
    image: myapp:latest
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

3.3 资源限制与QoS

设置资源请求和限制，确保应用获得所需资源：

spec:
  containers:
  - name: app
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

四、服务网格集成

4.1 Service Mesh架构

使用Istio或Linkerd构建服务网格，实现：

mTLS加密
流量管理
可观测性
故障注入

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - match:
    - headers:
        version:
          exact: v2
    route:
    - destination:
        host: my-service
        subset: v2
      weight: 50
  - route:
    - destination:
        host: my-service
        subset: v1
      weight: 50

五、最佳实践总结

使用Deployment管理无状态应用 - 利用声明式更新和滚动部署
正确配置健康检查 - liveness和readiness探针缺一不可
设置资源限制 - 防止资��争抢，确保QoS
使用Sidecar模式分离关注点 - 日志、监控、配置等作为sidecar
利用Service Mesh实现服务治理 - 关注安全、可观测性
使用Namespace隔离环境 - dev/staging/prod分离
实施资源配额 - 防止单租户占用全部资源

结语

Kubernetes为云原生应用提供了丰富的架构原语。掌握这些设计模式，能够帮助开发者构建更加可靠、可维护的系统。从简单的Pod部署到复杂的服务网格，每一层都有其架构价值。

持续学习，深入实践，在项目中不断应用这些模式，才能真正掌握云原生架构的精髓。

推荐资源：

Kubernetes官方文档
《Kubernetes Patterns》
CNCF云原生架构实践

如果你觉得这篇文章有帮助，欢迎关注、收藏、转发！

事件溯源模式深度指南：构建可追溯系统的核心艺术

架构师小白 — Tue, 16 Jun 2026 01:08:01 +0000

引言

在分布式系统和微服务架构中，如何可靠地保存业务状态变更历史，如何实现精确的业务回滚和审计，成为了架构设计中的核心挑战。事件溯源（Event Sourcing）模式作为一种独特的状态管理方法，通过持久化业务事件而非当前状态，为系统提供了完整的历史追溯能力。

本文将深入探讨事件溯源模式的核心概念、实现机制、优势与挑战，以及在实际项目中的最佳实践。

什么是事件溯源？

事件溯源是一种架构模式，它不直接存储对象的当前状态，而是存储表示状态变更的事件序列。系统的当前状态通过重放（replay）所有历史事件来重建。

核心概念

事件（Event）：表示已发生的业务动作，如订单已创建、支付已完成、库存已扣减等。
事件存储（Event Store）：专门用于持久化事件的数据库或存储系统。
聚合根（Aggregate Root）：业务实体的核心，通过事件驱动其状态变更。
命令（Command）：触发状态变更的请求，经过验证后转换为事件。

简单示例

# 传统方式：直接存储状态
class BankAccount:
    def __init__(self):
        self.balance = 0

    def deposit(self, amount):
        self.balance += amount

    def withdraw(self, amount):
        self.balance -= amount

# 事件溯源方式：存储事件
class BankAccount:
    def __init__(self, events=None):
        self.balance = 0
        self.events = events or []

    def deposit(self, amount):
        # 不直接修改状态，而是创建事件
        event = DepositEvent(amount=amount, timestamp=datetime.now())
        self.events.append(event)
        self.apply(event)

    def withdraw(self, amount):
        event = WithdrawEvent(amount=amount, timestamp=datetime.now())
        self.events.append(event)
        self.apply(event)

    def apply(self, event):
        if isinstance(event, DepositEvent):
            self.balance += event.amount
        elif isinstance(event, WithdrawEvent):
            self.balance -= event.amount

    # 从事件历史重建状态
    @classmethod
    def from_events(cls, events):
        account = cls(events)
        for event in events:
            account.apply(event)
        return account

事件溯源的核心机制

1. 命令处理流程

用户请求 → 命令验证 → 命令处理 → 生成事件 → 事件存储 → 状态更新

命令验证：检查命令的合法性（如余额是否充足）
生成事件：将命令转换为不可变的事件
事件存储：将事件持久化到事件存储区
状态更新：通过事件处理器更新读模型

2. 事件存储的特性

追加写入（Append-only）：事件只能添加，不能修改或删除
不可变性：事件一旦创建就不可更改
有序性：事件按时间顺序存储
幂等性：相同的事件可以安全地重放

3. 投影（Projection）

投影是将事件转换为读模型的机制：

class AccountBalanceProjection:
    def project(self, events):
        balance = 0
        for event in events:
            if event.type == DEPOSITED:
                balance += event.amount
            elif event.type == WITHDRAWN:
                balance -= event.amount
        return {balance: balance}

事件溯源的优势

1. 完整的历史追溯

记录每个状态变更的完整历史
支持任意时间点的状态回滚
满足审计和合规要求

2. 时间旅行（Time Travel）

# 查询任意历史时刻的状态
account_at_jan_1 = Account.replay_events(events, until=datetime(2026, 1, 1))
account_at_jun_1 = Account.replay_events(events, until=datetime(2026, 6, 1))

3. 更好的性能优化

写操作总是追加，无需锁竞争
可以异步批量处理事件
支持事件分区和并行处理

4. 复杂的业务逻辑支持

事件是业务领域的自然表达
支持复杂的业务规则和流程
便于业务分析和优化

5. 跨服务事件共享

事件可以发布到多个服务
支持不同的读模型和视图
解耦读写操作

事件溯源的挑战

1. 事件版本的演进

事件模式可能随业务变化而演进：

# 版本1的事件
class OrderCreatedEvent:
    def __init__(self, order_id, product_id, quantity):
        self.order_id = order_id
        self.product_id = product_id
        self.quantity = quantity

# 版本2：新增字段
class OrderCreatedEvent:
    def __init__(self, order_id, product_id, quantity, customer_id):
        self.order_id = order_id
        self.product_id = product_id
        self.quantity = quantity
        self.customer_id = customer_id  # 新增字段

# 版本兼容处理
class EventUpgrader:
    def upgrade(self, event, target_version):
        if event.version == 1 and target_version == 2:
            event.customer_id = unknown
            event.version = 2
        return event

2. 大规模事件处理

快照（Snapshot）：定期创建状态快照，避免全量重放
分段重放：按时间范围分段加载事件
事件压缩：合并旧事件为单个状态事件

3. 最终一致性

事件溯源天然是最终一致的：

事件存储是同步的
读模型更新可以是异步的
需要处理一致性问题

4. 调试和测试

事件重放可以用于调试
可以从生产事件中创建测试场景
支持离线分析和问题定位

事件溯源的最佳实践

1. 事件设计原则

使用业务语言：事件名应该反映业务动作
包含足够上下文：事件应包含重建状态所需的全部信息
保持事件小巧：避免在事件中存储大型对象

2. 命令验证

class PlaceOrderCommand:
    def validate(self, aggregate):
        errors = []
        for item in self.items:
            if not product_repository.exists(item.product_id):
                errors.append(f商品 {item.product_id} 不存在)
        for item in self.items:
            available = inventory.get(item.product_id)
            if available < item.quantity:
                errors.append(f商品 {item.product_id} 库存不足)
        if errors:
            raise CommandValidationError(errors)
        return True

3. 异步投影更新

class EventPublisher:
    def __init__(self, event_store, message_bus):
        self.event_store = event_store
        self.message_bus = message_bus

    def publish(self, event):
        self.event_store.append(event)
        self.message_bus.publish(
            topic=event.event_type,
            message=event.to_dict(),
            delivery=at_least_once
        )

4. 幂等性处理

class IdempotentEventHandler:
    def __init__(self, processed_event_ids):
        self.processed = processed_event_ids

    def handle(self, event):
        if event.event_id in self.processed:
            return
        self.process_event(event)
        self.processed.add(event.event_id)

事件溯源的实现框架

1. EventStoreDB

from eventstore import EventStore
client = EventStore()
client.append_to_stream(stream_name=order-123, events=[OrderCreatedEvent(...)])
events = client.read_stream(order-123)

2. 自定义实现

class InMemoryEventStore:
    def __init__(self):
        self.streams = {}

    def append(self, stream_id, event):
        if stream_id not in self.streams:
            self.streams[stream_id] = []
        self.streams[stream_id].append(event)

    def read(self, stream_id):
        return self.streams.get(stream_id, [])

3. 与ORM集成

class Event(Base):
    __tablename__ = events
    id = Column(Integer, primary_key=True)
    aggregate_id = Column(String, indexed=True)
    event_type = Column(String)
    event_data = Column(JSON)
    created_at = Column(DateTime, default=datetime.now)

事件溯源 vs 传统CRUD

特性	传统CRUD	事件溯源
状态存储	当前状态	事件序列
历史记录	通常无	完整保留
回滚能力	有限	完全支持
审计追踪	需额外实现	原生支持
写入性能	需要锁竞争	追加写入
复杂度	较低	较高

事件溯源的典型应用场景

1. 金融系统

交易记录和账户流水
审计合规要求
欺诈检测

2. 订单处理系统

订单生命周期追踪
状态变更历史
退款和售后处理

3. 库存管理系统

库存变更历史
盘点记录
追溯来源

4. 审计日志系统

合规审计
操作追溯
故障分析

总结

事件溯源模式通过持久化业务事件而非状态，为系统提供了：

完整的可追溯性：保存业务状态变更的完整历史
强大的回滚能力：支持任意时间点的状态恢复
灵活的投影支持：支持多种读模型和业务视图
更好的性能：写操作无需锁竞争

同时也需要注意：

事件版本演进的管理
大规模事件处理的性能优化
最终一致性带来的复杂性

在实际项目中，事件溯源常常与CQRS模式、Saga模式配合使用，构建完整的响应式系统。掌握事件溯源，将帮助你设计出更可靠、更可追溯的软件系统。

参考资料

标签: 架构设计模式事件溯源 DDD

管道过滤器模式深度指南：数据流处理的优雅架构艺术

架构师小白 — Mon, 15 Jun 2026 01:00:54 +0000

管道过滤器模式深度指南：数据流处理的优雅架构艺术

在软件架构中，有一个模式如同工业流水线一样，将复杂的处理过程分解为一系列独立的处理单元，每个单元专注完成单一职责。这就是管道过滤器模式（Pipeline Filter Pattern）——一种让数据处理更清晰、更可维护的架构设计模式。

什么是管道过滤器模式？

管道过滤器模式是一种数据流处理架构模式，其核心思想是将一个复杂的处理任务拆分为多个独立的处理步骤（过滤器），这些步骤通过管道（Pipeline）串联起来，数据像水流一样依次经过每个过滤器进行处理。

核心组件

过滤器（Filter）：独立的数据处理单元，负责完成单一的转换或处理任务
管道（Pipeline）：连接各个过滤器的通道，负责数据的传递和管理
数据源（Source）：数据的输入源头
数据汇（Sink）：处理结果的输出终点

工作原理

[数据源] → [Filter 1] → [Filter 2] → [Filter 3] → [数据汇]
              ↓            ↓            ↓
           管道1       管道2       管道3

数据从源进入管道后，依次经过每个过滤器。每个过滤器：

接收输入数据
执行特定的转换或处理
将结果传递给下一个过滤器
不关心上下游的具体实现

代码实现

Java 实现

// 基础过滤器接口
public interface Filter<T> {
    T process(T input);
}

// 管道实现
public class Pipeline<T> {
    private final List<Filter<T>> filters = new ArrayList<>();

    public Pipeline<T> addFilter(Filter<T> filter) {
        filters.add(filter);
        return this;
    }

    public T process(T input) {
        T result = input;
        for (Filter<T> filter : filters) {
            result = filter.process(result);
        }
        return result;
    }
}

// 具体过滤器示例
public class UpperCaseFilter implements Filter<String> {
    @Override
    public String process(String input) {
        return input.toUpperCase();
    }
}

public class TrimFilter implements Filter<String> {
    @Override
    public String process(String input) {
        return input.trim();
    }
}

public class ReverseFilter implements Filter<String> {
    @Override
    public String process(String input) {
        return new StringBuilder(input).reverse().toString();
    }
}

// 使用示例
public class Main {
    public static void main(String[] args) {
        Pipeline<String> pipeline = new Pipeline<>();
        pipeline.addFilter(new TrimFilter())
                .addFilter(new UpperCaseFilter())
                .addFilter(new ReverseFilter());

        String result = pipeline.process("  hello world  ");
        System.out.println(result); // 输出: DLROW OLLEH
    }
}

Go 实现

// 过滤器类型
type Filter func([]byte) []byte

// 管道
type Pipeline []Filter

func NewPipeline(filters ...Filter) Pipeline {
    return filters
}

func (p Pipeline) Process(data []byte) []byte {
    result := data
    for _, filter := range p {
        result = filter(result)
    }
    return result
}

// 具体过滤器
func TrimFilter() Filter {
    return func(data []byte) []byte {
        return bytes.TrimSpace(data)
    }
}

func UpperCaseFilter() Filter {
    return func(data []byte) []byte {
        return bytes.ToUpper(data)
    }
}

func ReverseFilter() Filter {
    return func(data []byte) []byte {
        for i, j := 0, len(data)-1; i < j; i, j = i+1, j-1 {
            data[i], data[j] = data[j], data[i]
        }
        return data
    }
}

// 使用示例
func main() {
    pipeline := NewPipeline(TrimFilter(), UpperCaseFilter(), ReverseFilter())
    result := pipeline.Process([]byte("  hello world  "))
    fmt.Println(string(result)) // 输出: DLROW OLLEH
}

适用场景

非常适合

数据处理流水线：日志处理、ETL、图像处理
请求/响应处理链：Web 请求的认证、验证、转换
函数式编程组合：多个函数组合成管道
流式数据处理：音频/视频流处理

不适合

需要强耦合的处理逻辑
处理步骤之间需要共享大量状态
步骤之间有复杂的依赖关系

优缺点分析

优点

单一职责：每个过滤器只关心自己的处理逻辑
可复用：过滤器可以自由组合
可测试：每个过滤器独立测试
可扩展：新增过滤器无需修改现有代码
清晰的数据流：处理过程一目了然

缺点

性能开销：数据需要多次传递
调试困难：问题可能在多个过滤器中
状态管理复杂：需要通过上下文传递
不适合强耦合场景

实际应用案例

1. Java Servlet 过滤器链

@WebFilter("/*")
public class LoggingFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse res, 
                        FilterChain chain) {
        System.out.println("Request: " + req.getRemoteAddr());
        chain.doFilter(req, res); // 传递给下一个过滤器
        System.out.println("Response: " + res.getContentType());
    }
}

2. Angular 管道

@Pipe({
  name: myPipe
})
export class MyPipe implements PipeTransform {
  transform(value: string, arg1: string): string {
    return value + arg1;
  }
}

// 使用
// {{ hello | myPipe:world }} -> helloworld

3. Unix 命令管道

# 经典的数据流处理管道
cat log.txt | grep "ERROR" | sort | uniq | wc -l

最佳实践

保持过滤器简单：一个过滤器只做一件事
使用泛型：提高类型安全性
添加错误处理：考虑在管道中添加异常处理过滤器
异步处理：对于耗时操作，考虑异步管道
监控与日志：在关键节点添加监控

总结

管道过滤器模式是处理数据流的绝佳选择，特别适合：

需要将复杂处理分解为简单步骤的场景
需要高度可复用和可组合的处理逻辑
需要清晰数据流的系统

通过合理运用这一模式，我们可以构建出更清晰、更易维护的数据处理系统。

关注我，获取更多软件架构知识！

代理模式深度指南：控制对象访问的艺术

架构师小白 — Sun, 14 Jun 2026 01:03:02 +0000

代理模式深度指南：控制对象访问的艺术

在软件开发中，我们经常需要控制对某个对象的访问。代理模式提供了一种优雅的解决方案，通过引入一个代理对象来间接访问真实对象，从而实现访问控制、延迟加载、功能增强等多种高级特性。

什么是代理模式？

代理模式（Proxy Pattern）是一种结构型设计模式，它为另一个对象提供一个替身或占位符，以控制对这个对象的访问。代理对象可以在不改变真实对象接口的前提下，执行额外的逻辑。

核心组成

抽象主题（Subject）：真实对象和代理对象的共同接口
真实主题（Real Subject）：被代理的真实对象
代理（Proxy）：持有真实对象的引用，负责控制和管理访问

代理模式的类型

1. 远程代理

为位于不同地址空间的对象提供本地代表。

class RemoteProxy:
    def __init__(self, host, port):
        self.host = host
        self.port = port
        self._stub = None

    def _connect(self):
        if not self._stub:
            self._stub = self._create_stub()
        return self._stub

    def request(self, method, *args):
        stub = self._connect()
        return stub.invoke(method, *args)

2. 虚代理

延迟加载大型对象，只在真正需要时才创建真实对象。

class VirtualProxy:
    def __init__(self, file_path):
        self.file_path = file_path
        self._real_object = None

    @property
    def real_object(self):
        if self._real_object is None:
            print("正在加载大型对象...")
            self._real_object = HeavyObject(self.file_path)
        return self._real_object

    def get_data(self):
        return self.real_object.get_data()

3. 保护代理

控制对真实对象的访问权限。

class ProtectionProxy:
    def __init__(self, real_subject, user_role):
        self.real_subject = real_subject
        self.user_role = user_role

    def request(self):
        if self.user_role == "admin":
            return self.real_subject.request()
        return "权限不足，拒绝访问"

4. 智能引用

在访问对象时执行额外的操作，如计数、缓存等。

class SmartProxy:
    def __init__(self, real_subject):
        self.real_subject = real_subject
        self.access_count = 0

    def request(self):
        self.access_count += 1
        print(f"对象被访问了 {self.access_count} 次")
        return self.real_subject.request()

实际应用场景

场景一：图片懒加载

from typing import Optional

class Image:
    def __init__(self, path: str):
        self.path = path
        self._data: Optional[bytes] = None

    def load(self) -> bytes:
        if self._data is None:
            print(f"Loading image from {self.path}...")
            with open(self.path, rb) as f:
                self._data = f.read()
        return self._data

    def display(self):
        print(f"Displaying image: {self.path}")

class ImageProxy:
    def __init__(self, path: str):
        self.path = path
        self._image: Optional[Image] = None

    def display(self):
        if self._image is None:
            self._image = Image(self.path)
        self._image.display()

# 使用
proxy = ImageProxy("photo.jpg")
proxy.display()  # 首次显示时才加载

场景二：API 限流保护

import time
from collections import deque

class RateLimiter:
    def __init__(self, max_requests: int, window_seconds: int):
        self.max_requests = max_requests
        self.window_seconds = window_seconds
        self.requests = deque()

    def allow(self) -> bool:
        now = time.time()
        while self.requests and self.requests[0] < now - self.window_seconds:
            self.requests.popleft()

        if len(self.requests) < self.max_requests:
            self.requests.append(now)
            return True
        return False

class APIService:
    def __init__(self):
        self.data = {"users": [1, 2, 3]}

    def get_users(self):
        return self.data["users"]

class APIServiceProxy:
    def __init__(self, service: APIService, limiter: RateLimiter):
        self.service = service
        self.limiter = limiter

    def get_users(self):
        if self.limiter.allow():
            return self.service.get_users()
        raise Exception("Rate limit exceeded")

场景三：数据库连接池

class DatabaseConnection:
    def __init__(self):
        print("创建新的数据库连接...")
        time.sleep(0.1)

    def query(self, sql: str):
        return f"Result: {sql}"

class ConnectionPool:
    def __init__(self, max_size: int = 5):
        self.max_size = max_size
        self.available = []
        self.in_use = []

    def acquire(self) -> DatabaseConnection:
        if self.available:
            conn = self.available.pop()
        elif len(self.in_use) < self.max_size:
            conn = DatabaseConnection()
        else:
            raise Exception("No available connections")
        self.in_use.append(conn)
        return conn

    def release(self, conn: DatabaseConnection):
        if conn in self.in_use:
            self.in_use.remove(conn)
            self.available.append(conn)

代理模式 vs 装饰器模式

特性	代理模式	装饰器模式
目的	控制访问	动态添加功能
关系	代理与真实对象通常有相同接口	装饰器包装对象
创建时机	可在运行时创建真实对象	通常在设计时确定
透明性	对客户端透明	透明添加功能

总结

代理模式是一种强大的设计模式，它能够帮助我们：

✅ 控制访问：实现权限验证、限流等
✅ 延迟加载：提高系统性能
✅ 功能增强：在访问前后执行额外操作
✅ 解耦：分离访问逻辑和业务逻辑

在实际开发中，代理模式广泛用于缓存、远程调用、懒加载、事务管理等场景。理解代理模式，能够帮助你设计出更加优雅和高效的架构。

推荐阅读：

《设计模式》 - Erich Gamma 等著
Clean Code - Robert C. Martin 著

如果你喜欢这篇文章，欢迎关注我的更多内容！🚀

享元模式深度指南：内存优化的核心艺术

架构师小白 — Sat, 13 Jun 2026 01:06:23 +0000

享元模式深度指南

享元模式（Flyweight Pattern）是一种结构型设计模式，其核心思想是共享细粒度对象，以支持大量细粒度对象的高效运行。

核心概念

Flyweight（享元）：享元接口
ConcreteFlyweight（具体享元）：实现享元接口
FlyweightFactory（享元工厂）：创建和管理享元对象

内部状态 vs 外部状态

内部状态：存储在享元对象中，可被多个对象共享
外部状态：存储在客户端，由客户端维护

实战案例

文本编辑器字符处理

interface Glyph {
    void draw(Window window);
}

class CharacterA implements Glyph {
    private char symbol = 'A';
    public void draw(Window w) { w.render(symbol); }
}

class GlyphFactory {
    private Map<Character,Glyph> pool = new HashMap<>();
    public Glyph get(char key) {
        return pool.computeIfAbsent(key, k->new CharacterA());
    }
}

游戏子弹系统

class BulletType {
    private String shape, color;
    private int damage;
    public BulletType(String s, String c, int d) {
        shape=s; color=c; damage=d;
    }
}

class Bullet {
    private BulletType type;
    private double x, y;
    public Bullet(BulletType t, double x, double y) {
        this.type=t; this.x=x; this.y=y;
    }
}

数据库连接池

class ConnectionPool {
    private List<Connection> available = new ArrayList<>();
    public ConnectionPool(String url, int size) throws SQLException {
        for(int i=0;i<size;i++) available.add(DriverManager.getConnection(url));
    }
}

何时使用

大量相似对象（数十万级）
对象创建成本高
内存受限
状态可分离

注意事项

线程安全：享元对象被多线程共享
对象池管理：合理设置池大小
权衡：少量对象时避免过度设计

总结

享元模式是优化内存的利器，适用于：

游戏开发（粒子、子弹）
图形编辑器
缓存系统
连接池

掌握享元模式，设计高性能高可扩展系统。

推荐阅读：《设计模式》- Erich Gamma