概念:微服务就是一些可独立运行、可协同工作的小的服务。微服务是现在特别流行的服务,微服务的字面意思是大家都很好理解,就是将系统拆分成很多小的独立系统,每个系统我们看成一个服务,从存储,缓存,部署相对独立。通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。

从概念中我们可以提取三个关键词:可独立运行、可协同工作、小。这三个词高度概括了微服务的核心特性。下面我们就对这三个词作详细解释。

可独立运行

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

可协同工作

采用了微服务架构后,整个系统被拆分成多个微服务,这些服务之间往往不是完全独立的,在业务上存在一定的耦合,即一个服务可能需要使用另一个服务所提供的功能。这就是所谓的“可协同工作”。与单服务应用不同的是,多个微服务之间的调用时通过RPC通信来实现,而非单服务的本地调用,所以通信的成本相对要高一些,但带来的好处也是可观的。

小而美

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

1. 微服务的优点

1. 易于扩展

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

2. 部署简单

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

3. 技术异构性

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

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

2. 数据库的服务化