单体应用
微服务是在单体应用的缺陷上产生的。那么来说一下单体应用的缺陷：
1、代码臃肿，应用启动时间长；（代码超过1G的项目都有！）回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
2、应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
3、伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
4、开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。
微服务
我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。
微服务架构简单来说就是将单体应用进一步拆分，拆分成更小的服务，每个服务都是一个独立运行的项目。
撇开架构先不说，什么样的服务才算微服务呢？
1、单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
2.面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。
我觉得满足以上两点就可以认为典型的微服务。
微服务框架
目前国内企业使用的微服务框架主要是Spring Cloud。Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：
文章来源: blog.csdn.net，作者：西瓜味的月亮亮�，版权归原作者所有，如需转载，请联系作者。
原文链接：blog.csdn.net/Mr_Dracy/article/details/115059107