1、单体架构
在早期的web应用程序中，绝大部分的项目都采用这种架构，将所有的服务器端功能模块打包成一个Monnolith（巨石型）应用。
优势：容易搭建开发环境、方便测试和部署
缺陷：进行局部改动就要重新部署，编译时间过长。技术栈也不易于扩展，只能不断的在原有基础上进行局部优化。，比如说应用的某部分场景需要处理高并发，使用Go会比较适合，但是单体架构并不支持多语言技术栈，只能继续在原来的技术上寻求合适的了。
2、垂直分层架构
随着访问量逐渐增大，单体架构只能通过增加机器的方式来提高性能，但是作用会越来越小，无论从成本还是难度上都会形成举步维艰的境况，性价比越来越低。这时候，往往会演化为垂直架构。
垂直架构就是彼此存在依赖关系的组件组成的架构，MVC就是一种常见的三层架构模式：数据访问层、服务层、Web层
优势：架构简单，前期开发成本低、周期短，通过拆分，原来的单体项目不至于无限扩大。
缺点：同样存在全部功能集成在一个工程中的问题，不易开发、扩展以及维护，只能通过扩展机器，增加集群节点来实现性能提升，成本可想而知。
3、SOA 面向服务架构
当垂直架构拆分的应用越来越多，就会出现多个应用都会依赖的业务逻辑组件， 这时候，就需要将这些可以通用的组件独立出来，并定义好服务间交互的接口，向外提供呢李，让其他服务调用。所以SOA面向服务架构就应运而生，它带来了模块化开发、分布式扩展部署和服务接口定义等概念。
优势：提高开发效率，提高系统的可复用性和可维护性，采用ESB（服务总线）减少系统中的接口耦合，可借助现有的应用来组合产生新服务，提供给企业更好的灵活性来构建应用程序和业务流程
缺点：可能也不能称为缺点，只是有它不适用的场景。SOA比较适用于大型软件服务企业对外提供服务的场景，但是对一般业务场景并不适用，因为它的一套定义、注册和调用流程都需要较为繁琐的编码或者配置实现，并且业务总线也容易导致系统的单点风险并拖累整体性能。
4、微服务架构
这种架构，就比较适合中小型企业，这些企业没有能力也无需构建SOA所依赖的ESB。它的理念，就是业务系统彻底地组件化和服务化，形成多个可以独立开发、独立部署和独立维护的服务或者应用的集合，以应对更快的需求变成和更短的开发迭代周期。
微服务提倡将大型复杂软件应用拆分成多个微服务。每个微服务可单独部署，各个服务之间是松耦合的。每个服务仅仅关注完成单一职责。一般情况下，每个职责就代表一个小的高内聚的业务能力。
微服务不仅仅代表着技术架构的变化，它还需要每一个开发团队形成适合微服务开发的组织架构和沟通方式。这也是微服务架构可以减少不必要的沟通，提升沟通效率、开发效率的关键原因
微服务继承了SOA的很多优点和理念，，但是不能简单的说一种架构比另一种架构更好。主要是区别在应用场景，微服务更适合于较小和良好的分割式Web业务系统。微服务专注于以自治的方式来产生价值。SOA尝试将应用集成，微服务关注的则是完全分离，着重于分散管理、代码复用和自动化执行。
