开发在现在这种微服务架构体系中，业务代码还能使用各种设计模式吗？如工厂？

当然，您可以使用各种设计模式。Spring框架中有许多设计模式。只要你最后能遇到微服系统里的基论，你不是还在用他们吗？

先说设计模式。

设计模式不是一个框架或中间件技术，而是学习中代码的高级抽象总结。设计模式并不局限于某种编程语言。JavaScript有设计模式，Java也有设计模式，只是外观不同。

设计模式根据用途可以分为三类:结构模式、行为模式和创造模式。经典的设计模式有23种，每种设计模式都有多种实现，比如singleton模式(懒、饿、静态内部类、DCL等。)，或者题主说的工厂模式(工厂方法模式，工厂方法模式等。).

分布式微服务架构

随着越来越复杂项目的开发，在高开发效率和高并发的情况下要求高可用性，项目模块化和容错机制是必要的，分布式开发应运而生。将每个开发模块部署到一个独立的云服务主机上，就像很多人一起做不同的任务，但整个过程都是在相互合作中完成的，这与集群化的思想是相悖的。微服务是一种架构，也属于分布式范畴。比如SpringCloud就是微服务架构的体现。

Spring中常用的设计模式

Spring是学习Java语言的必经之路，SringMVC和SringBoot是Sring框架的衍生品。现在用SringBoot结合SpringCloud实现微服务和分发已经不是什么新技术了。它是启动或开发成本预算较小的公司中的第一个技术架构，易于使用，生态支持友好。

Spring框架中有许多设计模式。例如，工厂方法模式的BeanFactory根据传入的惟一ID获取Bean对象。例如，Spring中默认的Bean注释是singleton模式，这将提供一个全局访问点。可以设置singleton = "true | false "或者scope= "？指定范围。例如，如果RabbitMq需要ACK回调机制来确保消息被发送到交换机，那么rabbitmqTemplate不能是单例模式。它需要设置scope=SCOPE_PROTOTYPE，通过构造方法注入注释而不是自动编写。而在Aop中，所使用的代理模式通过使用Advice来增强代理类的功能等等。这些都没有因为微服务系统的出现而被抛弃。

从以上三个方面会发现，微服务的出现并不会导致现有的一些技术或理论被直接抛弃，而是会通过新的理论或思想来使用这些精华，尽可能接近CAP原理。