2.2 微服务

2.2.1 从SOA到微服务

从十多年前的面向服务架构(Service Oriented Architecture, SOA)转型开始,业界一直在寻找更灵活的软件架构,以便于更迅速地响应业务的变化。传统的应用倾向于在一个应用中囊括多个不同的功能模块。SOA时代提倡的是应用系统对外暴露功能并提供服务,通过服务的组合形成新的应用。在SOA架构下,应用通过服务暴露功能,实现了彼此信息的交换和集成,使得通过服务的组合和编排形成新的应用系统成为可能。但是多个模块和功能仍然被包含在同一个应用中、同一个交付件中,这使得各个模块的功能相互交缠,彼此制约。

为了解决SOA没有解决的问题,业界出现了微服务架构(Microservice Architecture, MSA)这一思想。微服务架构提倡将应用化整为零,减小颗粒度。如图2-4所示,大型的应用(Monolithic Application)按照一定的规则被拆分成若干个颗粒度更小的应用。这些细小的应用称为微服务(Microservice)。

图2-4 微服务架构示意图

2.2.2 微服务的价值与挑战

微服务的出现,突破了传统单体应用架构的制约,增加了应用架构的灵活度,为应用的开发和交付带来了价值。

❑ 更清晰的权责。在微服务架构下,应用的颗粒度变小,每一个微服务尽可能只做一件事情,并将这件事情做好。各个微服务之间的职能边界变得更清晰。

❑ 更快速的开发和交付节奏。每一个微服务都可以独立地被开发,可以有自己的开发和交付节奏。每一个微服务都可以被独立地部署,可以有独立的上线和更新节奏。应用系统的更新不再牵一发而动全身,应用更新的节奏将更快。

❑ 更灵活的资源扩展。每一个微服务可以独立地部署和运行,因此可以独立地为每个服务进行扩容和缩容,而不影响其他服务。

微服务架构在带来价值的同时也带来了一些新的挑战,在落地实践微服务架构时,用户必须思考如何解决这些挑战。

❑ 团队组织变化。微服务架构的引入使得应用架构化整为零。应用架构的改变也将导致开发应用的开发团队结构发生变化。用户必须克服和适应组织变化带来的影响。

❑ 运维复杂度。单体应用化整为零,意味着需要运维管理的应用实例数将大大增加。原本只需要部署管理一个应用实例的单体应用,在微服务架构下工作量呈指数级增长。用户需要通过有效的手段降低运维的复杂度,容器是一个好的解决方案。

❑ 微服务治理。微服务之间的通信、调用链的跟踪管理、状态监控、错误跟踪排查等都需要相应的解决方案。

关于微服务的更详细介绍,推荐参考ThoughtWorks的Martin Fowler的文章《Micro-services Guide》,地址为https://martinfowler.com/microservices/

2.2.3 Serverless与微服务

与Serverless相似,微服务也是云计算发展的产物。云计算平台解决了基础架构利用的效率瓶颈,为应用提供更方便的基础服务(如构建、更新、扩容、高可用、错误自恢复等)。微服务架构从应用架构的层面入手,为未来的应用从架构层面上更契合云计算平台提供了各种服务和资源,进一步提高了应用开发和交付的效率。

Serverless和微服务两种架构都强调功能的解构。两者都强调最小的成员单位专注于做一件事情,做好一件事情。但是微服务架构中的最小成员单位是微服务,而Serverless架构中的最小成员单位是函数。Serverless和微服务的目的是一致的,那就是提高应用开发、交付上线的效率。但是两者侧重点不同。微服务强调化整为零,提高应用架构灵活度。Serverless强调的是“减负”,即将服务器移出用户的管理职责范围,从而降低管理复杂度和成本。

在微服务架构下,系统化整为零,架构上带来灵活性的同时,也增加了开发、部署和运维的复杂度。虽然通过容器等技术可以降低相关的复杂度,但是对比而言,Serverless应用的开发和运维的效率更高,管理成本更低。

Serverless是一种具有前瞻性的技术,那么现在许多组织和企业在推进的微服务架构是不是都是徒劳的呢?答案是否定的。Serverless架构的实现有一个很重要的前提,那就是需要一个强大的智能云计算平台,无论是公有云还是私有云。目前而言,并不是每一家企业或组织都具备这个条件。再者,没有一个架构是完美的,Serverless也有它的限制,不是每一个场景都适合引入Serverless架构。