从接触IT行业以来，微服务一词便一直环绕耳边，借此文章，来挖一挖微服务到底是个啥.
微服务(MicroServices): 为什么叫做微服务呢？我的理解将其划分为了“微”以及“服务”:
“微”：便是细微，细小，粒度细.
“服务”：能提供某种服务的功能.
我们为什么需要微服务？
存在即合理。在我们以往的传统项目，大多数都是单体应用。
什么是单体应用呢？
举个老套的例子。老板现在要我做一个网上购物系统，那我的系统肯定提供了商品浏览模块，购物车模块，支付模块等等...
这么多的模块我也不在怕的，在感觉良好的分出MVC层后，我把所有的模块实现在了同个application里面。那么，我实现的这个系统便是一个单体应用（一个application嵌套了所有的模块）。
单体应用的弊端：
我把网上购物系统部署上生产环境后，等待着老板的夸奖。
可是...
DAY 1: 老板的需求实在是太多了，隔三差五要我加新功能。我每次进行改动后，又得把我整个系统停掉后重新部署。每一次部署都好慢好慢啊，跑测试都能跑一小时了，启动APP又好久。
DAY 2: 今天支付模块出了点问题，没法付钱，我又得重新部署整个系统，所有模块都会暂停使用。老板指头大骂：付不了钱和我浏览商品有啥关系？
DAY 3:今天在Fix支付功能的BUG的时候，影响到了购物车功能的模块，唉，部署上去又有问题了.
DAY 4:有个同事加入我系统的开发，我让他去负责开发新的模块，可是他的技术栈和我系统使用的技术栈不一样啊，还得让他去学习.更气的是，他还嫌弃我用的技术过时...
.....
综上可见，对于单体应用：
1.单一应用部署，对于某一改动，所有的功能都将暂停服务。
2.系统功能耦合性强，无法做到分而治之，牵一发而动全身。
3.系统功能的隔离性差，任何一个模块都可能导致系统瘫痪。
4.对于开发人员技术栈要求要求高度统一。
在受尽折磨后，我决定将购物系统的各个功能进行“微服务化”，把购物车模块，支付模块等模块进行了拆分。果不其然，效果显著。
现在，我修bug的时候，丝毫不会影响到其它功能，并且再也不用担心改动到其它模块的逻辑啦。
同事也可以愉快的用他自己技术栈去实现他负责的模块，反正我只需要他最后实现的功能是一致的。
那么，对于上述系统功能的拆分，体现出了微服务的应用，以及它的优势。
