版权所有，转载请注明原作者，严禁复制转载
Level1 传统架构
就是大家众所周知的SSM或SSH了，
优点：三层架构职责清晰
缺点：依赖库管理难度大，协同开发代码冲突和功能扩展性差，牵一发动全身。
Level2 Maven聚合架构
对于五花八门的传统架构框架依赖包，是时候使用Maven进行依赖库的版本控制和管理了，再也不用到处收集粘贴依赖包了，版本冲突也基于Maven依赖树快速定位和解决冲突，对于多人开发代码冲突问题也提出了SVN和GIT作为集中式和分布式代码版本控制
优点：项目依赖库结构清晰，对依赖库进行统一管理和维护，极大避免依赖冲突，父子项目和版本控制非常灵活。
缺点：功能仍然过于集中，拆分的只是三层架构中的层而不是业务模块，多人协同开发难度大，非常容易版本冲突且功能过于耦合，可扩展性仍然没有得到改善。
Level3 SpringBoot分布式架构
彻底根据业务模块和功能对项目进行拆分，对业务模块单独拆分后再基于Maven聚合架构按照三层架构原则进行拆分，分布式项目和项目之间基于Maven传递依赖关系实现模块调用，最终打包成一个项目发布部署和运行。
优点：职责划分清晰，不同模块由不同人员开发，最终统一合并在一起打一个包发布和部署
缺点：可复用性差，且基于Maven传递模块和模块之间的依赖关系导致模块和模块之间耦合度很高，如果项目业务复杂规模庞大，每个项目模块还是需要多人协同开发且已经开发的模块只能作为最终项目的一个组成部分或者叫一个填充因子，必须最终作为外部项目的一个组成部分，一旦功能模块需要进行更加细致或更多业务完善可能会导致其他模块也需要做出相应调整，同时如果考虑容灾问题，如果一个模块非常核心也就是引用和被引用非常多其他模块，一旦这个模块出现问题将会传染其他模块，最终导致整个项目无法正常保持研发进度和发布进度，而且每个模块不能单独拆分，就像链表，中间一旦断开一节，整个链表就无法组装，如果也没有标准化设计模块，这一节还只能在这个链表上使用，功能完全受限于这个链表，不能在其他链表复用。
Level4: SOA服务架构
把业务逻辑代码单独提取出来并按照业务拆分成多个项目，每个项目就是一个服务，基于rpc远程调用机制和http协议实现服务之间的相互调用
优点：基于分布式架构，把每个业务功能模块定义为多个平台，每个业务功能模块的业务逻辑单独拆分成项目作为服务，彻底实现了单一职责功能，且每个服务都有不同的开发人员完成，极大减少了多人协作版本冲突问题，同时服务和服务之间相互独立，互不干涉，单独部署和运行，一个服务出现问题不会影响其他服务，也就不会影响平台和项目的运行，可扩展性，容灾性很高，彻底实现高可用。基于注册中心统一调度和管理服务，服务提供者把服务发布到注册中心，服务消费者基于rpc远程调用机制和SOAP协议通信机制直接访问注册中心对应serviceid的服务访问地址，实现服务和服务之间相互调用，如果按照标准化设计基础设施和服务接口，服务还可以再划分为公共服务和自定义服务，公共服务可以单独剥离出来使用，提高代码可复用性。
缺点：随着软件规模的日益庞大，一个项目的服务可能也会越来越多，也就导致服务治理逐渐混乱，甚至服务和服务之间依赖关系复杂也会导致服务调度出现问题，如果注册中心没有做集群，一旦注册中心出现问题，提供者和消费者无法正常运作，项目就会出现无可挽回的严重问题，所以对于SOA架构和微服务架构来说，注册中心搭建的时候一般情况下是必须做集群的，否则整个服务架构体系就会存在重大隐患。一旦注册中心出现问题，对于正常运行的项目来说就是毁灭性的打击，所以也就导致项目发布和生产，配置，维护成本极高。同时服务日益增加也就导致每个服务的业务功能也会越来越复杂，开发人员职责划分也会越来越模糊，工作量也会逐渐变成没有使用SOA架构之前，一夜回到解放前。所以对于大规模和业务复杂的项目，且开发团队人数比较大的情况下，SOA架构也会出现职责划分和任务分配不均匀的问题，当然，大厂微服务架构也就应运而生了。
Level5 微服务架构
简单来说，就是对SOA架构中的服务进行更加细粒度的划分，把每个服务也拆分成更加详细的多个子服务，服务和服务之间仍然相互独立，互不干涉，单独部署运行，提高开发敏捷性，同时由于微服务架构的负载均衡机制都是在本地基于http协议实现的，所以负载均衡调度更加灵活，本地httpclient只做负载均衡，相比较nginx而言更加轻巧，少了很多条条框框和复杂配置信息，SOA架构和微服务架构都是基于http协议通信，但是区别在于数据传输载体，SOA架构是基于SOAP实现，数据载体是XML，但是微服务架构基于REST通信机制实现，封装了大量的Restful接口，使用json作为数据传输载体。XML和json的传输带宽占用和数据格式的解析复杂度来比较，很明显json轻量级数据交换格式更胜一筹，所以微服务架构也使得服务和服务之间调用和通信更加轻便，微服务架构是轻量级的，对于开发任务分配也更加细致合理，且容灾性提到了最高，在SOA架构基础上更上一层，SOA架构中一个服务坏了不会影响其他服务，但是微服务架构中一个子服务坏了也不会影响一个服务的运行，把微服务出现问题的容灾性提到最高，由于粒度更细，所以损伤程度也降到最小，对于大规模软件系统和开发人员而言，微服务架构是最优解决方案，但是如果软件系统不是很大且开发成本比较低的情况下，还是推荐SOA架构，因为微服务架构粒度细，也就导致配置和维护工作量更大，对于一般软件系统而言，如果使用微服务架构有点头重脚轻感觉，反而拖慢整体研发进度。微服务架构中首选基于SpringBoot2.0的完整微服务框架SpringCloud提供了完备的一整套微服务处理体系，比如服务治理，动态网关，智能路由等，用来开发微服务架构项目再适合不过了
JavaEE架构演变那些事儿：
20世纪80年代，EJB+JDBC的提出，反响强烈
到20世纪90年代，Spring正式亮相在公众视野，成为广大开发者津津乐道的里程碑，迅速火爆全球JavaEE开发项目
到了21世纪，架构演变速度可以说是光阴似箭，日月如梭，忽如一夜春风来
Spring框架家族新添MVC核心成员：SpringMVC横空出世，与此同时，面相OGNL的Struts横空出世，在视图层框架中，SpringMVC有了竞争对手
ORM框架也告别了JDBC时代，正式开启IBatis时代，与此同时，推出了纯OOP的ORM框架-Hibernate横空出世，IBatis也有了强劲竞争对手
随着三层架构概念的提出，这些框架已经不能单独满足企业开发需求，所以想到了合作和资源整合，但是每个领域的框架都是劲敌，谁也不愿意让着谁，那这下怎么办呢？
Spring就主动站了出来，作为中间者的角色包容了每个领域的框架，以绿草丛的角色海纳百川，包容万物，MBC框架，ORM框架都集成了进来，所以就演变成两种组合：
Spring+Struts+Hibernate，即SSH架构
Spring+SpringMVC+MyBatis，即SSM架构
因为Struts简便的语法表达式和Hibernate自动生成SQL的方便，SSH迅速占领开发市场
后来，在实际开发中，越来越多开发者发现Struts安全漏洞百出，并且值栈开销太大，虽然Struts2进行了修补，但是仍然存在不少安全隐患，再来看Hibernate呢，虽然用起来方便，你可以没有SQL基础，但是对你的OOP思想要求是非常高的，随着项目规模复杂度升级，持久层依赖关系越来越多，Hibernate关联映射机制经常让开发者陷入混乱，很难快速定位持久层模块之间的依赖关系。所以后来，SSH逐渐也退出了JavaEE历史舞台
再来看看SSM，则发展的越来越迅猛，首先SpringMVC本身就是从Spring Web模块抽出来的，继承了Spring家族先天的优势-容器化和单例，注解驱动，极大简化Web层开发流程，代码简洁程度一下子提升不少，并且安全性也是十分优越的，除非你质疑Sprin的安全性。IBatis随着这些年的升级，已经变成了MyBatis，由于MyBatis一直和Spring保持紧密关系，所以跟Spring集成更加方便快捷，虽然要求开发人员有SQL基础，但是内置了大量标签元素和注解，可以很方便建立映射关系和关联关系，并且提供了一系列参数绑定方式，即可以确保高效，又可以保证安全，防止SQL注入。
Spring+SpringMVC+MyBatis迅速以SSM的身份占领全球开发技术市场，成为所有JavaEE开发者必备的技能，这一火就火到了现在，基本已经占领了JavaEE，J2EE传统架构的所有市场，Spring也已经到了5，6，7代，MyBatis也已经到了2，3代，还有MyBatis-Plus，已经最近很火的lombok注解框架
15年开始，Maven聚合架构初露头衔，因为Maven可以使用远程仓库，镜像，本地仓库管理所有框架的依赖包，并且支持模块化和父子工程开发，简化了传统架构框架搭建难度，在依赖库管理层面上统一托管，一定程度上保证依赖库的运行稳定
16年，17年，分布式架构首次提出，它认为Maven聚合工程虽然模块化开发，但是整体还是延续三层架构开发模式，并不能按照功能进行拆分和功能模块彻底解耦，随着业务需求复杂度升级，每个项目的功能模块越来越多，所以分布式架构就是提倡按功能拆分项目模块，不同开发人员只需要关注他的模块开发，对于模块中有依赖关系的情况，可以使用中间件，Maven依赖建立依赖关系，实现模块之间既能解耦，又能内聚，典型的好内聚，低耦合设计思想。最后统一整合在一起，构建整个项目和打包发布。分布式架构的一站式解决方案-SpringBoot正式亮相在开发者群体中，提出约定大于配置，简化Spring框架搭建和使用流程，集成多种starter组件，基本实现即拆即用，SpringBoot迅速成为分布式架构首选框架
转眼来到了17年和18年，SOA架构正式提出，它的口号是一切都是服务，面相服务开发，它提出分布式架构中存在的问题：各功能模块之间依赖关系增多，导致一旦哪个模块出现问题就会牵一发动全身一旦出现问题也会直接影响其他依赖的模块正常运行，甚至导致系统崩溃。但是面向服务开发就不一样，每个功能项目作为服务进行开发。使用注册中心来统一进行服务注册和发现，管理服务和治理服务，提供了容灾机制，引入负载均衡的概念来减轻服务器访问压力，一旦某个服务出现问题，则可以切换到其他备胎服务（集群中的其他节点）来迅速替补原服务正常运行，服务和服务之间相互独立，相互依赖，但是一个服务出问题不会影响其他服务运行，保证整个系统在各种极端情况下能稳定正常运行。随着SOA架构的出现，面向服务的框架Dubbo/Dubbox迅速出现在广大开发人员视野，基于RPC远程调用机制，把服务分为生产者和消费者，使用注册中心统一管理和调度服务，成为SOA架构的核心开发框架。
到了19年，微服务架构提出，SpringCloud全家桶微服务框架正式火热起来，微服务架构认为随着项目体量迅速扩大，对高可用，高并发要求越来越强烈，传统SOA面向服务架构已经不能解决问题，因此需要对SOA架构中的每个服务进行更加细粒度拆分，使得每块业务的开发人员能够更加专注于自己业务模块的开发，保证开发模块的高可用，能够抗住高并发，并且可以迅速进行项目版本迭代。到19年末，SpringCloudAlibaba框架正式亮相在公众事业，这是一款国人自研发的基于微服务结构的云原生框架，提倡服务器上云的概念，整合各种中间件来简化开发流程，提供了更多集群实现高可用的选择方案，对于高并发而言可以使用流量消锋，接口限流等方式来实现高并发，对于发布环境和部署环节也提供了一站式自动化解决方案，极大简化人力物力，逐步引入大数据和机器学习相关技能作为底层实现的中间件，提倡敏捷开发来实现开发，测试，运维一体化协同工作，极大提高项目设计，开发，部署，发布全产业链各个环节的稳定性，实现高效协同开发，尽可能保证服务在云上安全，稳定，高效运行。
随着这些所有经历的项目架构不同，我深切感受到每个架构在开发过程中不同项目中的核心地位，也逐步从技术越多越好转变为技术越精越好，越能符合真实业务场景越好，技术和业务需要有机结合融为一体。
2023年一年更新两套架构和开发思想(DDD和ServiceMesh)，这也是敲响了警钟，让我深刻意识到，技术发展迅猛，不学习，不好好学习，不高效学习，终将都会被淘汰，所以，我们要更加精益求精的打磨技术沉淀，让技术和业务真正融为一体，期待技术全球化，数智全民化早日到来，能够给人们生活带来更多丰富多彩，提升人类文明发展进程，这不是任务，更不是工作，而是使命，已经深深烙印在内心深处的使命和责任
我相信，并且坚信，祖国和全球的IT事业一定会因为你我的共同努力发展的越来越好
技术改变生活，代码照亮现实，加油