重新理解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两位大师对微服务的定义依旧具有蓬勃的生命力。因此，许多正在或者计划实践微服务的架构师们，还需要深入理解这一定义，结合实践找到符合自己企业和团队的微服务演进之路。