本文是微服务入门系列的第三篇文章，本系列一共有如下内容：
1.《走进微服务的世界》
2.《微服务架构下的分布式事务基础入门》
3.《微服务架构下的分布式事务解决方案》
4.《数据库的服务化切分》
5.《服务部署》
1. 什么是微服务？
我们首先给出微服务的定义，然后再对该定义给出详细的解释。
微服务就是一些可独立运行、可协同工作的小的服务。
从概念中我们可以提取三个关键词：可独立运行、可协同工作、小。这三个词高度概括了微服务的核心特性。下面我们就对这三个词作详细解释。
- 可独立运行
微服务是一个个可以独立开发、独立部署、独立运行的系统或者进程。
- 可协同工作
采用了微服务架构后，整个系统被拆分成多个微服务，这些服务之间往往不是完全独立的，在业务上存在一定的耦合，即一个服务可能需要使用另一个服务所提供的功能。这就是所谓的“可协同工作”。与单服务应用不同的是，多个微服务之间的调用时通过RPC通信来实现，而非单服务的本地调用，所以通信的成本相对要高一些，但带来的好处也是可观的。
- 小而美
微服务的思想是，将一个拥有复杂功能的庞大系统，按照业务功能，拆分成多个相互独立的子系统，这些子系统则被称为“微服务”。每个微服务只承担某一项职责，从而相对于单服务应用来说，微服务的体积是“小”的。小也就意味着每个服务承担的职责变少，根据单一职责原则，我们在系统设计时，要尽量使得每一项服务只承担一项职责，从而实现系统的“高内聚”。
2. 微服务的优点
1. 易于扩展
在单服务应用中，如果目前性能到达瓶颈，无法支撑目前的业务量，此时一般采用集群模式，即增加服务器集群的节点，并将这个单服务应用“复制”到所有的节点上，从而提升整体性能。然而这种扩展的粒度是比较粗糙的。如果只是系统中某一小部分存在性能问题，在单服务应用中，也要将整个应用进行扩展，这种方式简单粗暴，无法对症下药。而当我们使用了微服务架构后，如果某一项服务的性能到达瓶颈，那么我们只需要增加该服务的节点数即可，其他服务无需变化。这种扩展更加具有针对性，能够充分利用计算机硬件/软件资源。而且只扩展单个服务影响的范围较小，从而系统出错的概率也就越低。
2. 部署简单
对于单服务应用而言，所有代码均在一个项目中，从而导致任何微小的改变都需要将整个项目打包、发布、部署，而这一系列操作的代价是高昂的。长此以往，团队为了降低发布的频率，会使得每次发布都伴随着大量的修改，修改越多也就意味着出错的概率也越大。
当我们采用微服务架构以后，每个服务只承担少数职责，从而每次只需要发布发生修改的系统，其他系统依然能够正常运行，波及范围较小。此外，相对于单服务应用而言，每个微服务系统修改的代码相对较少，从而部署后出现错误的概率也相对较低。
3. 技术异构性
对于单服务应用而言，一个系统的所有模块均整合在一个项目中，所以这些模块只能选择相同的技术。但有些时候，单一技术没办法满足不同的业务需求。如对于项目的算法团队而言，函数试编程语言可能更适合算法的开发，而对于业务开发团队而言，类似于Java的强类型语言具有更高的稳定性。然而在单服务应用中只能互相权衡，选择同一种语言，而当我们使用微服务结构后，这个问题就能够引刃而解。我们将一个完整的系统拆分成了多个独立的服务，从而每个服务都可以根据各自不同的特点，选择最为合适的技术体系。
当然，并不是所有的微服务系统都具备技术异构性，要实现技术异构性，必须保证所有服务都提供通用接口。我们知道，在微服务系统中，服务之间采用RPC接口通信，而实现RPC通信的方式有很多。有一些RPC通信方式与语言强耦合，如Java的RMI技术，它就要求通信的双方都必须采用Java语言开发。当然，也有一些RPC通信方式与语言无关，如基于HTTP协议的REST。这种通信方式对通信双方所采用的语言没有做任何限制，只要通信过程中传输的数据遵循REST规范即可。当然，与语言无关也就意味着通信双方没有类型检查，从而会提高出错的概率。所以，究竟选择与语言无关的RPC通信方式，还是选择与语言强耦合的RPC通信方式，需要我们根据实际的业务场景合理地分析。
