当然能使用各种设计模式，Spring框架中有很多设计模式的体现，只要能在微服务体系中最终满足BASE理论，不还是照样在使用？

先说说设计模式

设计模式不是一种框架或中间件技术，而是对学习工作中代码进行高层次抽象的总结。 设计模式不限于某种编程语言，JavaScript有设计模式，Java也有设计模式，只是表象不同而己。

根据用途可将设计模式分为三类：结构型模式、行为型模式和创建型模式。 经典设计模式有23种，每一个设计模式也有多种实现，例如单例模式（懒汉、饿汉、静态内部类和DCL等），还是题主说到的工厂模式（简单工厂模式、工厂方法模式等）等。

分布式与微服务架构

随着开发的项目越来越繁杂，开发效率和高并发情况下要求高可用，项目模块化与容错机制就显得很有必要，分布式孕育而生。 将每个开发模块部署到独立的云服务主机上，就好像多个人在一起做不同分工的事，但是整个过程是相互协作完成，这和集群的理念相反。 而微服务算是一种架构，也属于分布式范畴，例如SpringCloud就是微服务架构的一种体现。

Spring中常用的设计模式

学习Java语言，Spring是必经之路，SringMVC和SringBoot等都是Sring框架的衍生品。 现在使用SringBoot结合SpringCloud实现微服务与分布式不是什么新鲜技术，在初创或者开发成本预算不多的公司已经是首先技术架构，上手容易，生态支持友好。

Spring框架中有很多设计模式体现。 例如简单工厂模式之BeanFactory，根据传入一个唯一的标识来获得Bean对象。 再比如Spring下默认的Bean注解均为单例模式，将提供一个访问它的全局访问点，你可以通过设置singleton=“true|false”或者 scope="?"来指定作用范围，例如RabbitMq需要ACK回调机制确保消息发送到交换机的话，rabbitmqTemplate就不能为单例模式，需要设置scope=SCOPE_PROTOTYPE，并通过构造方法注入而非Autowrite注解。 还有在Aop中，使用Advice来增强被代理类的功能而使用到的代理模式等等。 这些都没有因为微服务体系的出现而被舍弃掉。

从以上三个方面阐述就会发现，微服务出现并不会导致现有一些技术或理论直接被弃用，而是通过新的理论或思想将这些精髓沿用，尽可能去靠近CAP原则。