1、什么是微服务
上一篇文章说了SpringBoot简化了基于Spring的开发，这只是最直观的一方面，事实上SpringBoot的诞生，有它所处的大时代背景的原因在里面，那就是微服务，这也是谈 SpringBoot必谈微服务的原因。
2014年一个叫Martin Fowler （同时也是经典著作《重构：改善既有代码的设计》一书的作者）发表了一篇关于微服务的博客，比较形象生动地介绍了什么是微服务，然后微服务才慢慢被人所熟知。他说微服务其实是一种架构风格，我们在开发一个应用的时候，这个应用应该是由一组小型服务组成的，每个小型服务都运行在自己的进程内，小服务之间通过HTTP的方式进行互联互通。
2、单体应用架构
和微服务相对应的就是我们之前的单体应用，就是大名鼎鼎的all in one的风格。这种风格把所有的东西都写在一个应用里面，比如我们熟悉的OA，CRM，ERP系统，所有的页面，所有的代码都放在一起，打成打成一个war包，然后把war包放在Tomcat容器中运行。
单体应用架构图如下：
这种传统web开发架构模式当然也有它的优势，比如它测试部署比较简单，因为不涉及到多个服务的互联互调，只需要把应用打成一个war包上传到服务器就行了，可以说是一人吃饱全家不饿。同样也不会给运维带来麻烦，方便水平扩展，只需要又把相同的应用复制多份放在不同的服务器中就达到了扩展的目的。
单体应用的的缺点也显而易见，容易牵一发而动全身，比如要更改一个小小的功能，就可能需要重新部署整个应用。当然，更大的挑战就是日益增长的用户需求。
3、微服务架构
现在我们任何一个应用都有可能成为一个大型的应用，而大型应用不可能一个应用就解决的了的，如如何维护，如何分工合作，都不能很好的解决这些问题。所以我们需要使用微服务架构，来应大型的复杂的项目中所遇到的日常开发和维护中遇到的问题和痛点。
我们下面来介绍微服务架构
所谓的微服务，就是打破以前的传统方式，以前我们将应用中所有的功能单元都放在一个项目中，然后把整个应用部署到服务器上，如果负载能力不行了，就通过应用的水平复制来进行扩展，如下图左边所示。
而微服务提倡的是，把每一个功能元素独立创建一个项目，可以通过功能元素的动态组合，如一个功能元素需要多一点服务来提高负载能力，就在服务器中多部署一些，如果一个功能元素的负载要求不是很大，就可以在服务器中少部署一些该功能服务，或者说有一些功能只在有需要的时候才用到，平时就可以不部署。换句话说就是功能元素级别的复制，如下图右边所示。
这样好处就是节省了项目所使用的资源，还有一个就是我们把服务微化以后，每一个服务都是一个可替换的，可独立升级的软件单元（功能元素），各个微服务之间通过http方式进行轻量级通信。
服务微化以后，给我们带来的问题就是，项目的部署和运维是相当不容易的。
提示：关于Martin Fowler写的微服务博客，一定要好好的阅读，点击这里的链接是中文版的博客内容。
网友评论