从今天开始，记录和分享我学习微服务的过程。
一、什么是微服务
每当这个时候，台下的同学便蠢蠢欲动，意欲施展才华，释放自己的洪荒之力。
老师曾经说过，人类在起名字的时候 -- 特别是在给事物起名的时候，大概会有这几番考虑：(1) 能够尽量的概括事物的性质，作用。 (2) 名字得优雅好听又装逼。
于是小明同学就记住了这两个规则想要表现一番，小明同学胸有成竹给解释道：“微，当然有细小，微小的意思；而服务呢，当然最容易联想到的就是大宝剑服务了。因此，微服务就代表了快捷、便利的大宝剑的意思”。老师听完后，拍着小明的肩说道：“你实在是太过优秀，我小学三年纪的课堂已经满足不了你求知若渴的心，你去六年级报道吧...”
好的，希望这个尴尬的开场白没有吓跑三年级以下的同学们，我们言归正传。
维基百科上给出的定义是：微服务（Microservices）是一种软件开发技术，是面向服务的架构（Service-Oriented Architecture，SOA）的变体，微服务架构将应用程序组成一系列松散耦合的服务集合。在微服务体系结构中，服务是细粒度的，协议是轻量级的。
二、微服务的优点
将应用程序分解为不同的更小的服务的好处是，它改进了模块化，使应用程序更容易理解、开发、测试，并且更能抵御体系结构的侵蚀。它还通过允许小型自治团队开发、部署和部署来并行化开发。
简单来说，微服务架构基本符合我们拆解问题的方式 -- 把一个复杂问题拆成多个简单的问题，这个复杂问题就是在开发软件过程中的复杂度问题，但微服务的拆解是基于业务模块的。
总结一下：
独立性
这里的独立性指的是各个服务的开发、测试、部署都相互独立。比如：我们的用户服务就可以拆分作为一个单独的服务，而它的开发也不用依赖于其他服务。如果我们的用户量大，我们可以很容易的对其进行负载敏捷性
当一个新需求出现时，特别是在一个庞大的项目系统中，你得去考虑各方的问题，兼容性，影响度等等，而使用微服务则可以省掉很多这些废时又烧脑的环节。实现更灵活
在以前的项目开发中，基本上一个大的项目都基于同一语言的技术架构来开发，这样的限制很大 。而使用微服务拆分后的各服务之间没有这个限制，你只需要保证对外提供的接口是正常可用的就行。至于你是使用什么语言、什么框架通通不用关心。
三、微服务的问题及不足
上面的优点看完，我发现似乎微服务没什么缺点啊，这一部分是不是可以省了。
不，历史上那些著名的杠精告诉我们，任何事物都有它的两面性。好吧，请看：
拆解难度
上面我们提到微服务的拆分是基于业务的，不是我们随心所欲，想怎么拆就怎么拆的（你以为你是...吗），那么问题来了，由谁来拆，怎么拆？沟通成本
由于服务拆分，当服务调用方需要使用某服务的接口时，首先需要找到该服务的负责方，通常在一个大公司中，这种场景是跨部门的，沟通成本可想而知。而如果服务的负责方想要改变某一个接口，那么也得和各个服务调用方沟通...数据一致性
由于我们服务的相互独立，它们的数据也当然独立，但这也是一个问题，当调用多个服务接口来进行操作时，如何保证各服务间的数据都是一致的，这既是问题，也是难点
总结：现在看来，杠精们总结的没错，确实事物都有两面性。因此，在选择微服务架构时，可根据自己的场景在优劣性之间来进行一个平衡。没有最好的架构，只有最合适的架构。
四、微服务架构图示例
如下是一个简单的微服务架构图示意
五、总结
文中的资料也信息均来自于网络，正所谓分享是美好品德的表现 -- 鲁迅。
结合上述，如果是业务相对明确、简单，而又要求敏捷的交付、快速地迭代产品，更方便的运维。那么选择微服务架构是一个不错的选择。
