微服务实际上就是一些可独立运行、可协同工作的小的服务。微服务的思想是，将一个拥有复杂功能的庞大系统，按照业务功能，拆分成多个相互独立的子系统，这些子系统则被称为“微服务”。每个微服务只承担某一项职责，从而相对于单服务应用来说，微服务的体积是“小”的。这也是微服务自身的优点的来源，下面我们就来介绍微服务的3个优点。

1. 易于扩展

在单服务应用中，如果目前性能到达瓶颈，无法支撑目前的业务量，此时一般采用集群模式，即增加服务器集群的节点，并将这个单服务应用“复制”到所有的节点上，从而提升整体性能。然而这种扩展的粒度是比较粗糙的。如果只是系统中某一小部分存在性能问题，在单服务应用中，也要将整个应用进行扩展，这种方式简单粗暴，无法对症下药。而当我们使用了微服务架构后，如果某一项服务的性能到达瓶颈，那么我们只需要增加该服务的节点数即可，其他服务无需变化。这种扩展更加具有针对性，能够充分利用计算机硬件/软件资源。而且只扩展单个服务影响的范围较小，从而系统出错的概率也就越低。

2. 部署简单

对于单服务应用而言，所有代码均在一个项目中，从而导致任何微小的改变都需要将整个项目打包、发布、部署，而这一系列操作的代价是高昂的。长此以往，团队为了降低发布的频率，会使得每次发布都伴随着大量的修改，修改越多也就意味着出错的概率也越大。 当我们采用微服务架构以后，每个服务只承担少数职责，从而每次只需要发布发生修改的系统，其他系统依然能够正常运行，波及范围较小。此外，相对于单服务应用而言，每个微服务系统修改的代码相对较少，从而部署后出现错误的概率也相对较低。

3. 技术异构性

对于单服务应用而言，一个系统的所有模块均整合在一个项目中，所以这些模块只能选择相同的技术。但有些时候，单一技术没办法满足不同的业务需求。如对于项目的算法团队而言，函数试编程语言可能更适合算法的开发，而对于业务开发团队而言，类似于Java的强类型语言具有更高的稳定性。然而在单服务应用中只能互相权衡，选择同一种语言，而当我们使用微服务结构后，这个问题就能够引刃而解。我们将一个完整的系统拆分成了多个独立的服务，从而每个服务都可以根据各自不同的特点，选择最为合适的技术体系。

当然，并不是所有的微服务系统都具备技术异构性，要实现技术异构性，必须保证所有服务都提供通用接口。我们知道，在微服务系统中，服务之间采用RPC接口通信，而实现RPC通信的方式有很多。有一些RPC通信方式与语言强耦合，如Java的RMI技术，它就要求通信的双方都必须采用Java语言开发。当然，也有一些RPC通信方式与语言无关，如基于HTTP协议的REST。这种通信方式对通信双方所采用的语言没有做任何限制，只要通信过程中传输的数据遵循REST规范即可。当然，与语言无关也就意味着通信双方没有类型检查，从而会提高出错的概率。所以，究竟选择与语言无关的RPC通信方式，还是选择与语言强耦合的RPC通信方式，需要我们根据实际的业务场景合理地分析。