微服务入门指南(一)——走进微服务的世界

本文是微服务入门系列的第三篇文章，本系列一共有以下内容：
1.《走进微服务的世界》
2.《微服务架构下的分布式事务基础入门》
3.《微服务架构下的分布式事务解决方案》
4.《数据库的服务化切分》
5.《服务部署》

1. 什么是微服务？

咱们首先给出微服务的定义，而后再对该定义给出详细的解释。

微服务就是一些可独立运行、可协同工做的小的服务。

从概念中咱们能够提取三个关键词：可独立运行、可协同工做、小。这三个词高度归纳了微服务的核心特性。下面咱们就对这三个词做详细解释。

1. 可独立运行

   微服务是一个个能够独立开发、独立部署、独立运行的系统或者进程。

2. 可协同工做

   采用了微服务架构后，整个系统被拆分红多个微服务，这些服务之间每每不是彻底独立的，在业务上存在必定的耦合，即一个服务可能须要使用另外一个服务所提供的功能。这就是所谓的“可协同工做”。与单服务应用不一样的是，多个微服务之间的调用时经过RPC通讯来实现，而非单服务的本地调用，因此通讯的成本相对要高一些，但带来的好处也是可观的。

3. 小而美

   微服务的思想是，将一个拥有复杂功能的庞大系统，按照业务功能，拆分红多个相互独立的子系统，这些子系统则被称为“微服务”。每一个微服务只承担某一项职责，从而相对于单服务应用来讲，微服务的体积是“小”的。小也就意味着每一个服务承担的职责变少，根据单一职责原则，咱们在系统设计时，要尽可能使得每一项服务只承担一项职责，从而实现系统的“高内聚”。

2. 微服务的优势

1. 易于扩展

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

2. 部署简单

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

3. 技术异构性

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

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