何为微服务？

说到微服务，那么就要回答关于它的三个问题？

1. 微服务是什么？

2. 微服务怎么来的？

3. 微服务在什么时候使用？

   它的出现得从软件发展史说起，在微服务出现之前得软件应用时代我们可以先称之为单体应用时代。
   单体应用就是以往最常见得软件架构方式，一个web应用打成一个war包发布到生成环境，一个应用作为一个war包作为一个整体且只有一个模块就是单体应用。随着需求和技术得演变推进，一个单体应用在无数程序员的多年加工下变得庞大、复杂、难以理解和维护、可用性低。
   这个时候，庞大且复杂的应用救星微服务就出现了，它是一种概念，把一个单体应用拆分为多个模块变成分布式应用。
   比如一个销售系统有两个业务模块，某天你想要修改它其中的售后模块，这个时候你就需要重新部署并启动这一整个系统才能完成你的更新。
   
   但若是分成两个服务的话你只需要修改并更新你想要变动的那一快，在此同时其它模块还能正常的提供服务，服务重启的时间简短了，可用性得到了提高，系统应用的架构也变得更容易理解。一个服务成为一个独立模块，相互隔离，使用特定的通信方式协作完成业务。它们独立部署、独立拓展，从某种意义上来说，微服务是一种解耦。
   
   这时候也许你会说：那我本来只用开发一个应用的，现在要开发两个甚至更多的应用了，甚至还要去处理分布式会遇到的数据同步，分布式事务等等问题，岂不是更麻烦了？
   你说的没错，微服务的使用确实会增加系统架构的复杂性，所以在面对一些体积小、架构简单系统是不该采用微服务的。

总结下来：

1. 微服务是一个思想，是一个庞大复杂应用架构的解决方案。
2. 因为一些单体应用在无限膨胀下走向了灭亡，急需一种新的应用架构方式来保证应用的可用性、可维护性、高可用性等。
3. 在应用复杂庞大到它的体积和复杂程度带来的麻烦要大于采用微服务的分布式架构带来
   问题和麻烦之时，就该采用微服务。否则没有必要强行使用微服务让应用架构变得更加复杂。

还要人会问，微是什么概念，是像国外开发者常说的一个函数一个服务的这种粒度才叫微服务吗？很显然不是的，按什么样的粒度来拆分服务是看应用的实际情况和业务需求而来的。