Monolith(单体应用)架构
通常情况下，服务由多个模块所组成，各模块会根据自身所提供的功能不同具有一个明确的边界，在编译时，这些模块将被打包成为一个个jar包，并最终合并在一起形成一个war包(最终部署的时候只有一份war包，其他的以jar包的方式依赖)。接下来，我们需要将该war包上传到web容器中，解压war包，并重新启动服务器。
这种将所有的代码及功能都包含在一个war包中的项目组织方式被称为Monolith(单体应用)架构。
缺点
1、维护麻烦
即便是更改一行代码，也需要重新编译打包整个项目。如果代码量多，那么每次都会花大量的时间重新编译、测试和部署
2、技术选型固定
在项目变得越来越庞大的同时，为了满足更多的需求，所使用的技术也会越来越多，但是有点技术之间是不兼容的。例如，在一个项目中大范围地混合使用C++和Java几乎是不可能的事情。
在这种情况加，我们需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
3、可扩展性差
按照Monolith组织的代码将只能产生一个包含了所有功能的war包，因此在对服务容量进行扩展时，只能够重复的部署(集群)这些war包来扩展服务能力，而不能扩展出现瓶颈的某一个模块。
也就是说单体应用中多个模块的负载不均，导致我们扩容高负载的时候，也把低负载的容器扩容了，极大浪费了资源。
MicroService(微服务)架构
微服务架构是一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建，并能够被独立地部署到生产环境、类生产环境中。
微服务是一种架构风格，一个大型复杂软件应用由多个微服务组成。系统中各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一中服务。
注意
应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行架构
相对于单体架构而言微服务具有以下优势：
1、复杂度可控
将应用分解的同时，规避了原本复杂度的不断积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。
微服务由于体积小，复杂度低，所以每个微服务可以由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
2、独立部署
由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务并发变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一些列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
3、技术选型灵活
微服务架构下，技术选型时去中心化的。每个团队可以根据自身服务的需求和行业发展现状，自由选着最适合的技术栈。
由于每个微服务相对简单，故需要对技术栈进行升级是所面临的风险就较低，甚至完全重构一个微服务也是可行的。
4、容错
当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
5、扩展
单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
Monolith&MicroService的使用场景
微服务虽然有众多优点，但也不是所有项目都适合用微服务架构
从上图中可以看到，在刚开始的阶段，使用Microservice架构模式开发应用的效率明显低于Monolith。但是随着应用规模的增大，基于Microservice架构模式的开发效率将明显上升，而基于Monolith模式开发的效率将逐步下降。
这是因为Microservice是一个架构模式，而不是一个特定的技术解决方案。其并不会将开发中的各个难点全部转移，而只是允许通过更为合适的技术来适当简化单个子服务的开发，或者绕过开发中可能遇到的部分难点。但是为了支持各个子服务的运行，我们还需要创建一系列公共服务。这些公共服务需要在编写第一个子服务的同时进行。这是导致Microservice架构模式在开发初期会具有较低效率的一个原因。
然而使用特定技术并不会绕过开发中所能遇到的所有难点。由于在Microservice架构中，各个子服务都集中精力处理本身的业务逻辑，而所有的公共功能都交由公共服务来完成，因此公共服务在保持和各个子服务的松耦合性的同时还需要提供一个足够通用的，能够在一定程度上满足所有当前和未来子服务要求的解决方案。而这也是导致Microservice架构模式在开发初期会具有较低效率的另外一个原因。
而在开发的后期，随着Monolith模式中应用的功能逐渐变大，增加一个新的功能会影响到该应用中的很多地方，因此其开发效率会越来越差。反过来，由于Microservice架构模式中的各个子服务所依赖的公共服务已经完成，而且子服务本身可以选择适合自己的实现技术，因此子服务的实现通常只需要关注自身的业务逻辑即可。这也是Microservice架构模式在后期具有较高效率的原因。
当我们再次通过Microservice架构模式搭建应用的时候，其在开发时的效率劣势也将消失，原因就是因为在前一次基于Microservice架构模式开发的时候，我们已经创建过一次公共服务，因此在这个新的应用中，我们将这些公共服务拿来并稍事改动即可