第三十章：总结与展望：三种模式的优缺点总结、设计模式在微服务与云原生架构中的新趋势

好，终于到了这门课的最后一章。说实话，每次写总结章节，我都有点感慨。从单例模式的第一行代码，到工厂模式的层层抽象，再到观察者模式的事件驱动——我们一路走来，其实都是在跟“变化”做斗争。

这一章，我不打算再讲新语法了。咱们坐下来，聊聊这三种模式到底好在哪、坑在哪，以及——在微服务和云原生的浪潮下，设计模式这个“老家伙”是不是还管用。

三种模式的优缺点：我踩过的坑和真香时刻

先说说单例模式。嗯，这个模式我最早接触是在做嵌入式系统的时候。那时候内存金贵，一个日志管理器只允许一个实例，没毛病。但后来做Java Web，我发现很多人把数据库连接池也搞成单例——这就有点危险了。

它的优点很明显：

• 保证一个类只有一个实例，节省内存
• 提供全局访问点，方便调用
• 可以控制实例的创建时机（懒加载）

但缺点也让人头疼：

• 破坏了单一职责原则——一个类既要管业务，又要管实例创建
• 在多线程环境下，如果不加锁，很容易出问题。我曾经在双11压测时，就因为一个懒汉式单例没加双重检查锁，导致系统创建了多个实例，数据全乱了
• 单元测试困难——单例的全局状态很难被mock

再说工厂模式。这个模式我特别喜欢，因为它把“创建对象”这件事从业务代码里抽出来了。你想想看，如果你的代码里到处都是 new XXX()，一旦构造函数变了，你得改多少地方？

优点：

• 客户端不需要知道具体实现类，只需要知道产品接口
• 新增产品类型时，只需要新增工厂类，不需要修改现有代码（开闭原则）
• 可以集中控制对象的创建逻辑，比如做缓存、做校验

缺点：

• 类的数量会爆炸——每加一个产品，就要加一个工厂类
• 抽象层次变高，新手容易看不懂
• 如果产品结构不复杂，用工厂模式反而过度设计

我记得有一次重构一个支付系统，原来有支付宝、微信、银联三种支付方式，代码里全是if-else。我用简单工厂模式一重构，代码瞬间清爽了。但后来接入第8种支付方式时，工厂类变得臃肿不堪——最后还是换成了工厂方法模式才搞定。

最后是观察者模式。这个模式在事件驱动系统里简直是神兵利器。你想想看，一个按钮点击，要触发日志、统计、通知、动画……如果用硬编码，那代码得写成什么样？

优点：

• 发布者和订阅者之间是松耦合的，可以独立变化
• 支持广播通信，一个事件可以通知多个对象
• 可以动态添加或删除观察者，灵活性高

缺点：

• 如果观察者太多，通知顺序可能不可控
• 如果观察者处理逻辑太重，会影响发布者的性能
• 容易产生循环依赖——A通知B，B又通知A，死循环了

三种模式对比：一张表说清楚

维度	单例模式	工厂模式	观察者模式
核心目的	控制实例数量	封装对象创建	解耦通知机制
适用场景	配置管理、日志、连接池	复杂对象创建、产品族管理	事件驱动、UI交互、消息推送
主要优点	节省资源、全局访问	解耦创建、易于扩展	松耦合、支持广播
主要缺点	线程安全、测试困难	类数量膨胀、过度设计	性能问题、循环依赖
我的推荐指数	⭐⭐⭐（慎用）	⭐⭐⭐⭐（常用）	⭐⭐⭐⭐⭐（强烈推荐）

设计模式在微服务与云原生架构中的新趋势

好，聊完了三种模式的优缺点，咱们把眼光放远一点。现在大家都在谈微服务、云原生、容器化——设计模式是不是过时了？

我的答案是：设计模式的思想永不过时，但实现方式必须进化。

举个例子。在单体应用里，单例模式就是new一个对象。但在微服务里，一个服务实例本身就是“单例”的——你部署一个服务，它只有一个进程。那单例模式去哪了？它变成了服务注册与发现。你想想看，Eureka、Consul这些注册中心，本质上就是在管理“服务实例”这个单例。

工厂模式呢？在云原生里，它变成了容器编排和工厂流水线。Kubernetes的Pod模板、Helm的Chart、甚至Dockerfile，都是在“生产”服务实例。你定义好模板，系统自动帮你创建——这不就是抽象工厂模式吗？

观察者模式就更明显了。在微服务架构里，事件驱动架构（EDA）已经成为标配。Kafka、RabbitMQ、NATS这些消息中间件，本质上就是观察者模式的分布式实现。服务A发布一个“订单创建”事件，服务B、C、D各自订阅并处理——这不就是一对多通知吗？

我个人觉得，未来设计模式的发展方向有两个：

第一，从“代码级”向“架构级”演进。以前我们是在一个类里用单例，现在是在整个系统里用服务发现。以前我们是在一个方法里用工厂，现在是在CI/CD流水线里用模板。设计模式的思想没变，但作用范围从“函数”变成了“服务”。

第二，从“手动实现”向“框架内置”演进。你想想看，Spring的IoC容器不就是工厂模式吗？你只需要配置Bean，容器自动帮你创建和管理。Kubernetes的Operator模式，本质上也是工厂模式——你定义CRD，Operator自动创建Pod。设计模式正在被框架和平台“内化”，你甚至不需要写代码，只需要写配置。

一张图看懂：三种模式在云原生中的演化

下面这张图，是我自己画的。它展示了三种经典设计模式在微服务和云原生架构下的新形态。你看完应该能明白——设计模式不是过时了，而是换了一副面孔。

写在最后

说实话，设计模式这门课，我讲了十几年。每次讲都有新感悟。以前我觉得设计模式是“套路”，后来觉得是“思想”，现在我觉得——设计模式是经验的结晶。

你想想看，单例模式解决的是“资源冲突”，工厂模式解决的是“变化隔离”，观察者模式解决的是“耦合通知”。这些问题，不管技术怎么变，永远存在。所以设计模式不会过时，它只会换一种形式存在。

最后送大家一句话：不要为了用模式而用模式，要为了解决问题而用模式。如果你在写代码时觉得“这里好乱”、“这里好难扩展”，那大概率是某个设计模式能帮到你。去翻翻GoF那本书，或者看看我这门课的笔记——答案就在那里。

好了，这门课到这里就结束了。感谢你一路读下来。如果有什么问题，欢迎在公众号留言。咱们江湖再见。