单体架构单体架构意味着所有的业务模块都耦合在一个项目中，开发和部署都在一起。如果有一个模块需要在线升级，那么所有模块都应该在前期一起启动和停止。单体架构的项目组成员需要全栈，因为前端和后端数据库都是一波人在管。后来开始逻辑分层，团队也分为前端UI团队，后端DBA团队，每个团队都有自己的职责。
软件产品架构中什么是单体架构SOA架构微服务架构？
软件产品架构是不断迭代演化的，从单体服务架构发展到现在的服务化微服务的架构。单体架构单体架构就是所有的业务模块都是耦合在一个项目中，开发部署都在一起如果其中一个模块需要上线升级，那么所有模块都要一起启停在早期，单体架构的项目团队成员需要是全栈，因为前端后端数据库都是一波人负责，后来开始进行了逻辑分层，团队也分成了前端 UI 团队后端和 DBA 团队，每个团队都有自己负责的职责。
然而随着业务逻辑越来越复杂，模块和模块之间的耦合度越来越高另外随着用户和数据量的增多，单体架构也不再能够支撑高并发和大数据。SOA 架构为了解决上面的问题，SOA 出现了。SOA 代表了面向服务的架构，SOA 将应用程序的业务模块进行拆分，形成独立的应用系统，系统和系统之间通过明确的接口串联起来每个系统内部结构和逻辑发生改变，并不影响对外提供的服务，只要保持接口不变，服务内部对外是透明的SOA 架构中，服务定义标注的接口，可以提供给多个调用方使用，增加了服务的重用性。
SOA 架构时代有两个很重要技术实现方式Web Service 和 ESB 前者提供了标准的数据传输协议，后者实现了服务编排和协议转换。微服务架构但是随着用户和数据量的进一步增长，SOA 也暴露出来一些缺点，比如 SOAP 协议XML较重服务管理不完善ESB本身就比较重，而且它本身算是一个单点，在软件架构中，单点意味着风险。
在微服务的架构中，各个微服务可以独立开发，独立部署微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署每个团队的技术栈也可以不相同，只要遵守接口协议即可。
至于微服务和 SOA 架构的区别，我是这样理解的SOA 架构和微服务架构都属于分布式架构，分布式的思想就是把不同的业务模块，部署在不同的服务器上，以应对高并发的问题SOA 是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合编排实现业务流程微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线去中心化，部署粒度更细，服务扩展更灵活。
Spring Cloud微服务架构中，都有哪些组件？它们合是做什么用的？
Spring Cloud就是一套微服务的解决方案，它包含了众多的组件帮助开发人员完成微服务架构的搭建，下面说说Spring Cloud中有哪些组件，以及各个组件充当了角色。Eureka服务注册中心在传统的架构中，A系统调用B系统的接口，要知道B接口的地址或B系统负载均衡的地址，通常这个地址是配置在A系统中的而在微服务的架构中，一个大项目会被拆分成N多个比较小的应用，让A系统去记录每个外部服务的地址是不现实的这时候就需要有一个地方，保存每个服务的信息，这样才能让应用彼此知道对方这个就是注册中心。
例如，当应用程序A启动时，它希望向注册中心发送服务名称和IP端口号等信息。如果应用B想使用应用A的服务，它会去注册中心查询应用A的X服务地址是什么。现在Spring宣布Eureka2.x不在维护期。可以选择Eureka1或者其他已经比较稳定的组件，比如Consul。Fegin是一个声明性的Web服务客户端，它使得客户端代码的开发更加容易。
