自我介绍
我作为一名咸鱼程序员(非闲鱼)，在实际的工作中我从来没有去深入的了解过Spring的原理、我从事了六年的Java开发，在2017年到2019年短短两年之内跳槽了多家公司。我从事过技术经理(面向开发基础)，我以前认知中如果单个服务无法承载我当前的项目内容我只会去选择不同的集群架构(针对于集群垂直化架构方案)，所以我为了运行的效率以及开发的效率学习了多门开发语言(无法面试、仅仅用于开发过程)并使用不同语言对应的框架进行项目集群数据获取。
架构的发展过程
回到主题，Java的架构发展过程，从我当初学习开始，我们当初学习的Java框架有SpringMVC、Status2、Hibernate、MyBatis。在学习时开发的Demo项目就是单体架构的项目，就是一个jar||war打天下，一个包丢到tomcat即可的项目。再到后来我参加了工作，在实际开发中我们将对应的应用拆分成了用户端与服务后台端，并通过Nginx做tomcat集群，将对应的项目放入不同的tomcat中管理。虽然当时已经有了Spring Boot以及微服务的对应理论但是我当时作为一个菜鸟并且项目为了追求稳定使用的还是那么老套的架构方案。再之后的一次跳槽后我接触到了Spring Boot与Dubbo整合进行的微服务架构模式的项目(戏称SOA)因为整个架构仅仅只是拆分了对应的商品、用户、订单、库存服务。
下面进入正题，什么是单体架构、什么是集群及垂直化架构、什么是SOA架构、什么是微服务架构？
单体架构
单体架构指单独的一个项目也就是一个项目开发中没有进行任何的拆分，将所有的服务都揉在一个项目之中。(即当项目发布时只有一个jar包或者war包的项目)
这样的架构在初期用户量不大的情况下是足以支撑起整个业务的
通常是Controller->Logic->Service->Mapper->DB全整在一个项目
集群及垂直化架构
在项目不断的壮大时，我们所有的业务(用户系统、后台管理系统)等业务系统如果还放在同一个项目时会导致服务器的压力不断的增大，一台服务器无法进行大量用户的访问，以及因为产品需要满足不同的需求来留住用户，使得业务不断的越来越复杂。服务器的负载越来越高的时候我们项目的jar包或war包可能会达到几G升至上十G，这样对于项目的维护以及业务的拓展存在了很大的影响。
这时我们通过将对应的一个项目拆分成不同的系统，多个项目并发布到不同的服务器，通过降低业务的耦合度来拆分并横向的将对应的系统放入服务器集群当中。
拆分为多个项目可以理解为将本来的一个整站拆分成多个网站并发不到多个服务器
SOA(面向服务)架构
在集群及垂直化架构当中我们发现有很多的代码是重复的，可复用的代码，以及在缓存过程中发现当用户下单时库存减少了但是在后台查看时因为缓存等问题并没有同步。所以为了节省代码量去达到可复用、并且防止数据同步存在的延迟性，将所有的服务进行了进一步的拆分
通常是
A系统:Controller->Logic->ESB(企业服务总线)->Service->Mapper->DB
B系统:Controller->Logic->ESB(企业服务总线)->Service->Mapper->DB
ESB(所有的服务处理逻辑揉成的一个或多个服务)
所有的服务调用同一个ESB再由ESB调用对应的服务及数据库
微服务架构
可以理解为跟细粒的SOA架构，将原本的多个服务拆分成跟多的单独的服务进行强有效的解耦架构
