一.微服务的来源和它要实现的目的
微服务的概念源于 Martin Fowler 于 2014 年 3 月 25 日写的一篇文章 Microservices（中文版翻译点击查看）
微服务架构模式的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。 Micro 这个词意味着每个服务都应该足够小，但是，这里的小不能用代码量来比较，而应该是从业务逻辑上比较——符合 SRP 原则的才叫微服务。
关于微服务的一个形象表达：
X 轴：水平扩展，即在负载均衡服务器后增加多个运行实例
Z 轴：数据库的扩展，即分库分表
Y 轴：功能分解，即将不同职能的模块分成不同的服务
二.微服务与与单体应用的区别
在了解微服务之前，我们先看看微服务（microservice）和单体应用（monolithic application）的区别。
一个完整的单体应用一般为三个主要部分构成，客户端界面，服务端应用，数据库。服务端处理接收到的HTTP请求，执行业务逻辑，查询修改数据库里的数据，再将html视图输出给浏览器。他们三个部分构成一个独立的单元，所有处理请求的业务逻辑都在一个进程中。它可以进行横向扩展，通过负载均衡将多个应用部署到多台服务器上。单体应用是一种很自然很成功的架构，但是他也有让人感到有不方便的地方，将他部署到云上的时候需要整体部署，每当你变更程序的一小部分逻辑需要整体的构建和部署，这样就很难保持一个好的模块化结构，很难让一个模块的变更不影响到别的模块，扩展应用程序只能整体的扩展，而不能进行部分扩展。
这为微服务的出现奠定了基础，应用程序构建为一整套服务，每个服务可以独立部署和扩展，每个服务之间有明确的边界，每个服务可以使用不同的编程语言，不同的数据库，甚至于不同的团队去管理维护。
三.微服务架构的优点
1.复杂度可控
在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
2. 独立部署
由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
3.技术选型灵活：
微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。
4.容错：
当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
5.扩展：
每个服务可以各自进行 x 扩展和 z 扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
参考博客:Wind Mt Spring Cloud（零）：微服务的那些事儿
