重新理解Martin Fowler对微服务的定义

2014年,ThoughtWorks的Martin Fowler与James Lewis对一种新的架构风格——微服务(微服务这个术语最早诞生2011年在威尼斯召开的一次软件架构师工作坊)——提供了完整的定义。随着他们的定义,微服务这种架构风格迅速地成为软件行业的热词,并被许多互联网公司采纳,陆续开始迈入微服务的演进过程。如今微服务已经进入所谓的Service Mesh 2.0时代,诸多微服务框架、平台以及设计原则如雨后春笋般出现。在微服务走入成熟的时刻,再来重读Martin Fowler对微服务的定义,或许会另有一番收获。

微服务的完整定义来自Martin Fowler的文章《MicroServices》。作者是James Lewis与Martin Fowler,他们对微服务的定义如下所示:

根据这个定义,我们可以勾勒出微服务的基本构成要素:

  • 每个服务运行在自己的进程中;
  • 微服务之间采用轻量级通信;
  • 微服务应基于业务能力进行构建;
  • 采用自动化部署机制实现微服务的独立部署;
  • 服务的管理应采用最小的中心化管理。

“每个服务运行在自己的进程中”。随着Docker等容器化技术的发展,一个微服务的物理边界不一定等于网络边界,最小的物理边界变成了“进程”。在Java平台下,诸如Spring Boot等框架引入了更加便捷的Web容器部署方式,使得定义、部署与运行一个微服务都变得更加简单。由于微服务粒度比传统的SOA服务更小,它对Web应用服务器的要求也变得更加轻量级。除了Tomcat,还可以使用Jetty等更加轻量级的Web容器。

不仅运行微服务变得轻量,微服务之间的通信也变得更加轻量,如定义中的第二个要素——“微服务之间采用轻量级通信”。什么是轻量级通信?文章认为是基于HTTP协议的资源API,通常指的是RESTful API。不过随着类似Netty、gRPC等RPC框架、PB序列化协议以及Kafka等消息中间件的广泛运用,在生产应用中,微服务之间的通信也不仅限于RESTful。毕竟HTTP协议在传输性能和可靠性方面仍然存在局限性,而JSON的序列化能力也是差强人意。因此,除了基于http协议的REST服务,如Spring Boot/Cloud;还可以是RPC协议,例如使用阿里的Dubbo或新浪的Motan;甚至使用消息中间件传递消息来完成通信。

定义强调了微服务与业务能力(Business Capability)之间的关系。显然,是业务而非技术在驱动微服务的设计。现在,有越来越多的人认识到了这一点,随之开始重视领域驱动设计(DDD),并尝试将领域驱动设计引入到微服务架构设计中。领域驱动设计的潜能还有待挖掘,培养具有领域驱动设计能力的团队成员,可能会成为决定微服务架构演进成败的一个重要因素。此外,采用微服务架构的团队是否遵循康威定律,并在文化上与之吻合则是微服务演进的另一个挑战。

在推动持续集成和持续交付时,自动化部署已经得到了普及,Docker与K8S之类的容器化技术在某种程度上改变了自动化部署的方式。DevOps的理念也成为了运维团队的建设目标。但是,在许多传统企业的微服务化进程中,属于基础设施层面的持续集成、持续交付和DevOps显然还未准备好。技术上,持续集成与持续交付的成熟度还有待提高,许多团队还未能完全做到自动化测试与自动化部署,还需要花费很多精力与成本来偿还这些技术债。在运维文化上,困难更大。开发与运维仍然属于两个“老死不相往来”的团队,开发不操心运维的脏活累活,运维不具备编写自动化脚本的能力。这些现状可能会极大地制约微服务的演进,甚至会导致企业的微服务演进成为一种形式。

定义中提及的“最小中心化管理”是从语言层面讲解的,即采用微服务时,将不再受限于服务实现的技术栈,无论是开发语言还是数据库,都可以自由选择。如果我们仅仅将微服务视为一种简单的服务化,无疑,对服务的调用确实是一种跨平台的通信。从理论上讲,只要规定了服务的通信协议以及服务的接口,就可以自由选择技术栈。然而,当微服务被分解得越来越小,微服务的数量变得越来越多时,微服务架构其实已经衍生为一个庞大的生态圈。从微服务的生命周期看,我们需要考虑微服务的定义、开发、测试、上线、监控以及最后的消亡(降级)。从微服务的系统架构看,我们需要考虑微服务的注册、发现、编排、监控、运维等。这些需求衍生出许多微服务框架,如Spring Cloud、Dubbo。但是,这些框架为了实现这些功能,采用的实现都或多或少导致了代码的侵入,使得微服务对开发语言的选择受到许多限制。若要满足Martin Fowler定义的“最小中心化管理”,服务网格(Service Mesh)才是最佳答案。自2016年9月Linkerd第一次公开使用之后,伴随着Linkerd、Envoy、Istio、NGINX Application Platform、Conduit等新框架的涌现,服务网格和它的边车(Sidecar)模式让多语言的微服务协作变得更加容易。未来几年的微服务发展,应该是服务网格占据主流。

整体来看,微服务的技术实践已经开始向更加成熟迈进。在微服务的实践与运用上,互联网企业走在了前面,它们甚至在诸多方面都成为了微服务技术发展的先行者。然而,对于微服务的设计、技术落地以及相应的文化建设和基础设施搭建,许多团队的能力与意识仍显不足,尤其是针对一些传统企业,要实现企业架构向微服务转型,依旧是“路漫漫其修远兮”。James Lewis与Martin Fowler两位大师对微服务的定义依旧具有蓬勃的生命力。因此,许多正在或者计划实践微服务的架构师们,还需要深入理解这一定义,结合实践找到符合自己企业和团队的微服务演进之路。