单体架构
在传统IT行业的软件系统设计大多都是各种独立子系统的堆砌，这也就是所说的单体架构，其本身扩展性差，可靠性低，维护成本高。单体架构在初期系统规模比较小的情况下尚且能够较好的支撑，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：
复杂性逐渐变高，问题修复和新功能开发难度和成本高，引入新问题的可能性变大。同时，任意模块的缺陷都可能会影响整个系统，可靠性低。
随着人员流动，加之复杂性高，新的问题很难被发现和解决，久而久之，问题逐渐变多，变难、变大，技术债务逐渐上升。
随着模块不断集成，部署速度逐渐变慢
想进行整体的技术创新基本不可能，阻碍技术创新
垂直和水平的可扩展性差
SOA架构
随后，引入了SOA服务化（面向服务的架构，它将应用程序的不同功能单元（服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来)。但是，由于 SOA 早期均使用了ESB总线模式，这种总线模式与某种技术栈是强绑定的，如，J2EE。这又使得很多企业的遗留系统很难对接，切换时间太长，对接成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。
SOA服务化思想下的微服务架构
微服务是在 SOA 上做的升华，微服务最早由Martin Fowler与James Lewis于共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP Rest API的方式（告别ESB服务总线），这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
简单讲，微服务不再强调传统SOA架构里面比较重的ESB服务总线，同时将SOA的思想延伸到单个业务系统内部实现真正的组件化。微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”。
从微服务的概念可以看出它有如下好处：
每个服务可以独立开发，易于开发，提高开发人员的生产效率
局部修改容易部署
技术栈不受限
单个服务支持独立部署和发布，可以进行快速迭代部署，更快的交付时间
更有利于业务的扩展，可伸缩性强
转自@软件测试开发技术栈 ，希望对您有所帮助。
如果觉得《软件产品架构中什么是单体架构 SOA架构 微服务架构？》对你有帮助，请点赞、收藏，并留下你的观点哦！
