单体架构
一个归档包（例如war格式）包含所有功能的应用程序，通常称为单体应用。
如图：
尽管该应用已经使用了MVC分层与模块化，但是由于所有部件最终都打包在一个war包中，该war包包含了整个系统所有的业务功能，这样的应用系统称为单体应用。
单体架构的缺陷：
1.复杂度高：随着代码的增多，会导致业务模块边界模糊、依赖关系不清、代码耦合严重、代码质量参差不齐、混乱的堆叠在一起，每改一个小bug都有可能会影响到其他地方。
2.发布频繁：每个功能的迭代或bug的修复都需要重新部署整个应用，风险高，不利于线上系统的稳定性。
3.可靠性差：某个地方出现bug，例如死循环、内存用完等等，都可能会导致整个系统瘫痪掉。
服务化架构
SOA 面向服务的架构（Service-Oriented Architecture）
SOA是在单体应用中将模块组件从单一进程进一步拆分，形成独立的对外提供服务的网络化组件，每个网络化组件通过某种网络协议对外提供服务（不局限于某种网络协议，可以是底层的TCP/IP，可以是应用层的HTTP，也可以是消息队列协议），最终将多个业务服务通过组件化模块方式打包在一个War包里，然后统一部署在一个应用服务器上。
所以可以这么理解，SOA是单体架构的内部升级。
SOA有两个主流的实现方式：
1.Web Service，它的每个服务都要依赖中心化目录来发现现存的服务，服务提供者通过UDDI协议将服务注册到目录，服务消费者通过UDDI协议从目录中查询服务并获得服务的WSDL描述文件。
2.ESB，它没有中心化的服务节点，每个服务提供者都是通过服务总线的模式插入系统，总线根据流程编排负责将服务的输出进行转换并发送给流程要求的下一个服务进行处理。
要做SOA架构，就要做系统拆分，以服务化的思想为指导，实现面向服务的架构，做服务化拆分。
首先要解决的是如何去拆解我们的系统，一般需要从整体上梳理公司的业务，包括过去、现在以及未来几年内的业务进展，将业务模块化，分解出各个业务模块之间的依赖以及业务模块之间的边界，按照业务边界以及业务之间的依赖顺序进行系统拆分，这是系统拆分的常见做法。
从单体应用到SOA架构的转变如图：
SOA架构的缺陷：
1.升级风险高：因为是所有的功能都部署在一个发布包里，如果要升级，就要更换整个发布包，那么在升级的过程中，会导致整个应用停掉，致使所有的功能不可用。
2.项目交付周期变长：由于单体架构必须要等到最后一个功能测试没有问题了，才能整体上线，这就是水桶理论，只要有一个功能存在短板，整个系统的交付就会被拖累。
3.可伸缩性差：由于应用的所有功能代码都运行在同一个服务器上，如果你想扩展某一个单一功能，但你不得不将整个应用水平进行了扩容，这就导致了其他不需要扩容的功能浪费。
4.监控困难：不同的功能都杂合在一个进程中，这让监控这个进程中的功能变得困难。
微服务架构
将单体应用拆分成多个服务，每个服务独立部署，这样的架构就叫做微服务架构。
微服务架构如图：
微服务架构的优点：
1.易于开发和维护：微服务把一个单一的业务功能放在一个独立的服务中，所以它业务清晰，代码量较少，开发和维护单个微服务相对简单。
2.启动较快：单个微服务代码量较少，所以启动会比较快。
3.局部修改容易部署：对某个服务进行修改，只需要重新部署这个服务即可。
4.每个服务拥有单独的进程，单个服务出现故障不会影响到其他服务的运行。
5.技术栈不受限：在微服务架构中，可以结合实际合理选择技术栈，例如这个服务可以使用MySQL，那个服务可以使用MongoDB。
微服务架构与SOA服务化的对比
1.目的不同
SOA强调不同的异构服务之间的写作和契约，并强调有效集成、业务流程编排、历史应用集成等，典型代表为Web Service和ESB。
微服务使用一系列微小的服务来实现整体的业务流程，目的是有效的拆分应用，实现敏捷开发和部署，缩小变更和迭代影响的范围，并达到单一微服务更容易水平扩展的目的。
2.部署方式不同
SOA服务化通常将多个业务通过组件化模块方式大伯啊在一个war包里，然后统一部署在一个应用服务器上。
微服务将完整的应用拆分成多个微小的服务，每个微服务运行在单一的进程内，微服务中的部署互相独立，互不影响。
3.服务粒度不同
SOA对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。
微服务倡导将服务拆分成更细的粒度，拆分到职责单一，最终通过多个微小服务组合来实现整个架构。