微服务自从Fred George提出，后续逐渐由不同的大师如Martin Fowler，Neal Ford等人接力推广演进后，已经在业界如火如荼的流行了好些年，它的目的是有效的拆分应用，实现敏捷开发和部署 。
借用Martin Fowler的话说：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。
每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
从这里面我们可以看出，这里面的关键字是“小”，“独立”，“轻量级”，从中我们可以总结为：服务之间是松耦合的，不相互影响的。但“小”绝对不是字面上理解的小，我们下面将介绍一个服务的小的维度是什么。
单体服务提到微服务，就不能不提到单体应用了，我们通常所说的单体应用，即将所有功能都打包成在一个独立单元的应用程序。
一个典型的单体应用就是将所有业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。
在微服务或者SOA架构没提出来之前，业界应该基本都是单体应用，分布式系统架构在业界内已经有较长的历史了，但单体应用还是占据着大半壁江山。
存在即合理的
所以存在的东西都具备自己的优点，我们来看一下单体应用的优点。
优点开发方便：集中式管理，只需要在一个解决方案中编程和构建
测试相对简单：只需要写一些端到端的测试用例，启动即可整体联调查找问题
部署手段简易：只需要把一份构建好的文件丢上服务器
容易横向扩展：可以部署多个实例，由负载均衡器调度即可
没有分布式的管理/调用开销
这些优点是显著的，它们能给人带来明确的掌控感觉，而不是不可控的飘渺虚无感。
然而，它的缺点也是非常明显的，想想我们现在大部分的项目，伴随着越来越快的互联网信息时代，业务要的就是灵活变动和快速上线，针对于灵活和快速，单体应用是无法提供的。
缺点开发效率低：系统庞大复杂，没人能理解全部，且所有的开发在一个项目改代码，代码冲突不断
代码维护难：代码功能耦合在一起，牵一发动全身
部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个周期往往很长
稳定性不高：系统缺乏故障隔离，一个微不足道的小问题，可以导致整个应用挂掉
可以肯定的是，一旦你的应用变成一个又大又复杂的怪物，那开发团队肯定很痛苦。敏捷开发和部署举步维艰，每次的开发都会引出其他问题，因为它们的耦合性太强了。
其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。
另外，团队士气也会走下坡路。如果代码难于理解，就不可能被正确的修改，最终会走向巨大的、不可理解的泥潭。
所以在这时，很多人把目光投向了微服务。
微服务 由来首先任何的技术不会平白无故的出现，它们的出现，是某些痛点一直在困扰着大多数人，所以这些技术的出现，都是有特定背景的。
从上面来看，有诉求才会有发展，没有单体式应用的痛点折磨，没有分布式系统的铺垫，没有自动化工具的应用，是不可能出现所谓的微服务的，所以我们可以说，微服务架构是演进过来的。
微服务是一种架构风格微服务在Chris口中，是一种架构设计风格，而在国内，更多的开发者视之为具体的某个服务，所以我们通常的说法是“一个微服务”，按照Chris自己的说法，系统是采用了微服务架构设计风格，由若干个服务构成，这才是一个完整的微服务。
“微”服务微服务这个术语让我们很多人错误的将关注点聚焦在“微”上，它暗示着我们服务的颗粒度是应该非常小的。
实际上，大小不是一个重要的考虑因素。