vlambda博客
学习文章列表

微服务是近几年非常火热的架构设计理念，大部分人认为是 Martin Fowler提出了微服务概念，但事实上微服务概念的历史要早得多，也不是 Martin Fowler创造出来的， Martin Fowler只是将微服务进行了系统的阐述。不过不能否认 Martin Fowler在推动微服务火热起来的作用，微服务能火， Martin Fowler功不可没。

参考维基百科英文版，我们简单梳理一下微服务的历史：

• 2005年：Dr. PeterRodgers在Web ServicesEdge大会上提出了“Micro-Web-Services”的概念。

• 2011年：一个软件架构工作组使用了“microservice”一词来描述一种架构模式。

• 2012年：同样是这个架构工作组，正式确定用“microservice”来代表这种架构。

• 2012年：ThoughtWorks的James Lewis针对微服务概念在QCon San Francisco 2012发表了演讲。

• 2014年：James Lewis和 Martin Fowler合写了关于微服务的一篇学术性的文章，详细阐述了微服务。

由于微服务的理念中也包含了“服务”的概念，而SOA中也有“服务”的概念，我们自然而言地会提出疑问：微服务与SOA是什么关系，有什么区别，为何有了SOA还要提微服务？这几个问题是理解微服务的关键，否则如果只是跟风拿来就用，既不会用，也用不好，用了不但没有效果，反而还可能有副作用。

SOA为什么被提出？

对于了解过SOA的人来说，第一次看到微服务这个概念肯定会有所疑惑：为何有了SOA还要提微服务呢？等到简单看完微服务的介绍后，很多人可能就有一个疑惑：这不就是SOA吗？

我们看一下，什么是SOA？

OASIS给予出的SOA定义：SOA是一个范式，用于组织和利用可能处于不同所有权范围控制下的分布式系统。 维基百科给出的SOA定义：“面向服务的体系结构（Service-oriented   architecture）是构造分布式系统的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。它采用开放标准、与软件资源进行交互并采用表示的标准方式。”。 百度百科：面向服务的体系结构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 看了这些规范定义，小编只想说一句，说人话！说人话，说人话！ 幸好，有人还搞了一个SOA标准模型。

以笔者了解的电信行业为例，大量的系统由第三方厂商提供或者是外包厂商维护，形成若干的数据孤岛和服务离散。A系统要访问B系统，需要B提供接口；C需要访问B系统，也需要B提供接口。由于异地系统的复杂性，大量竖井式应用无法响应日益变化和复杂的业务流程。

在这种背景下，IBM 等公司提出了 SOA理念，将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。

SOA 提出了一系列构建分布式系统的原则，这些思考直到今天也依然适用：

服务具备明确定义的标准化的接口

服务应该是松耦合的

服务应该是无状态的

服务是可以组合

服务的发现、注册机制

微服务与SOA的关系

关于SOA和微服务的关系和区别，大概分为几个典型的观点。

• 微服务是SOA的实现方式

如下图所示，这种观点认为SOA是一种架构理念，而微服务是SOA理念的一种具体实现方法。例如，“微服务就是使用HTTP RESTful协议来实现ESB的SOA”，“使用SOA来构建单个系统就是微服务”“微服务就是更细粒度的SOA”。

                            

• 微服务是去掉ESB后的SOA

如下图所示，这种观点认为传统SOA架构最广为人诟病的就是庞大、复杂、低效的ESB，因此将ESB去掉，改为轻量级的HTTP实现，就是微服务。

• 微服务是一种和SOA相似，但本质上不同的架构理念

如下图所示，这种观点认为微服务和SOA只是有点类似，但本质上是不同的架构设计理念。相似点在于下图中交叉的地方，就是两者都关注“服务”，都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有ESB、服务的粒度、架构设计的目标等。

以上观点看似都有一定的道理，但都有点差别，到底哪个才是准确的呢？单纯从概念上是难以分辨的，我们对比一下SOA和微服务的一些具体做法，再来看看到底哪一种观点更加符合实际情况。

• 服务粒度

整体上来说，SOA的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，“员工管理系统”就是一个SOA架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”“员工福利管理”等更多服务。

• 服务通信

SOA采用了ESB作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful协议、RPC协议，无须ESB这样的重量级实现。Martin Flower将微服务架构的服务通信理念称为“Smart endpoints anddumb pipes”，简单翻译为“聪明的终端，愚蠢的管道”。之所以用“愚蠢”二字，其实就是与ESB对比的，因为ESB太强大了，既知道每个服务的协议类型（例如，是RMI还是HTTP），又知道每个服务的数据类型（例如，是XML还是JSON），还知道每个数据的格式（例如，是2017-01-01还是01/01/2017），而微服务的“dumb pipes”仅仅做消息传递，对消息格式和内容一无所知。

• 服务交付

SOA对服务的交付并没有特殊要求，因为SOA更多考虑的是兼容已有的系统；微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。如果没有这些基础能力支撑，微服务规模一旦变大（例如，超过20个微服务），整体就难以达到快速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的坑，就是系统拆分为微服务后，部署的成本呈指数上升。

• 应用场景

SOA更加适合于庞大、复杂、异构的企业级系统，这也是SOA诞生的背景。这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来或进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是ESB。

微服务更加适合于快速、轻量级、基于Web的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于Web，虽然开发技术可能差异很大（例如，Java、C++、.NET等），但对外接口基本都是提供HTTP RESTful风格的接口，无须考虑在接口层进行类似SOA的ESB那样的处理。

综合上述分析，我们将SOA和微服务对比如下表所示。 

对 比 维 度	SOA	微  服  务
服务粒度	粗	细
服务通信	重量级，ESB	轻量级，例如HTTP/ RESTful
服务交付	慢	快
应用场景	企业级	互联网

 

因此，我们可以看到，SOA和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已，因此两者的关系应该是第三种模式。

其实，Martin Fowler在他的微服务文章中，已经做了很好的提炼：

 

In short, the  microservice architectural style is an approach to  developing asingle  application as a suite of small services,  each running in its own process and  communicating with  lightweight mechanisms, often an HTTP resource API. These  services are built around business capabilities and independently deployable   by fully automated deployment machinery.

 

上述英文的三个关键词分别是：small、lightweight、automated，基本上浓缩了微服务的精华，也是微服务与SOA的本质区别所在。

通过前面的详细分析和比较，似乎微服务本质上就是一种比SOA要优秀很多的架构模式，那是否意味着我们都应该把架构重构为微服务呢？

其实不然，SOA和微服务是两种不同理念的架构模式，并不存在孰优孰劣，而只是应用场景不同而已。我们介绍SOA时候提到其产生历史背景是因为企业的IT服务系统庞大而又复杂，改造成本很高，但业务上又要求其互通，因此才会提出SOA这种解决方案。如果我们将微服务的架构模式生搬硬套到企业级IT服务系统中，这些IT服务系统的改造成本可能远远超出实施SOA的成本。

曾经SOA架构下迷途

在技术上，ESB 架构虽然实现了业务逻辑与服务集成的解耦，可以更好地进行中央化的服务治理，也暴露出一些问题：

由于过度强调业务系统的可复用性，而不是对企业 IT 架构的治理和重构。大量服务集成的实现逻辑被下沉到 ESB 内部；而微服务/服务化架构下的注册中心是单纯的注册机制。

ESB 基于一个中心化的消息处理系统，集中式EAI的模式，本身会成为一个单点，可扩展性和性能的挑战。

• 

  上图from 百度百科

另，EAI模式下的SOA，实施过程中服务的定义往往没有站在全局架构下思考，宏观未有企业信息架构指导、微观未有类似DDD的指引，协议翻译和集成终于服务的合理抽取。

微服务架构下迷途

大略是老马提出 微服务有以下几个特征：

1.   通过服务实现组件化；

2.   按业务能力来划分服务与组织团队；

3.   服务即产品；

4. 智能终端与哑管道；

5. 去中心统一化；

6. 基础设施自动化；

7. Design   for   failure；

8. 进化设计

还有人说微服务是RESTful协议；微服务技术栈可以变。我想说，这些未必是微服务的必要条件。

迷信微服务不可取，我们看一下微服务具体有哪些坑。

• 服务划分过细，服务间关系复杂

服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。

从理论的角度来计算，n个服务的复杂度是n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的。下图形象了说明了整体复杂度。

粗粒度划分服务时，系统被划分为3个服务，虽然单个服务较大，但服务间的关系很简单；细粒度划分服务时，虽然单个服务小了一些，但服务间的关系却复杂了很多。

• 服务数量太多，团队效率急剧下降

微服务的“微”字，本身就是一个陷阱，很多团队看到“微”字后，就想到必须将服务拆分得很细，有的团队人员规模是5~6个人，然而却拆分出30多个微服务，平均每个人要维护5个以上的微服务。

这样做给工作效率带来了明显的影响，一个简单的需求开发就需要涉及多个微服务，光是微服务之间的接口就有6~7个，无论设计、开发，还是测试、部署，都需要工程师不停地在不同的服务间切换。

• 开发工程师要设计多个接口，打开多个工程，调试时要部署多个程序，提测时打多个包。

• 测试工程师要部署多个环境，准备多个微服务的数据，测试多个接口。

• 运维工程师每次上线都要操作多个微服务，并且微服务之间可能还有依赖关系。

• 调用链太长，性能下降

由于微服务之间都是通过HTTP或RPC调用的，每次调用必须经过网络。一般线上的业务接口之间的调用，平均响应时间大约为50ms，如果用户的一起请求需要经过6次微服务调用，则性能消耗就是300ms，这在很多高性能业务场景下是难以满足需求的。为了支撑业务请求，可能需要大幅增加硬件，这就导致了硬件成本的大幅上升。

• 调用链太长，问题定位困难（略）

• 没有自动化支撑，无法快速交付

如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。例如：

• 没有自动化测试支撑，每次测试时需要测试大量接口。

• 没有自动化部署支撑，每次部署6~7个服务，几十台机器，运维人员敲shell命令逐台部署，手都要敲麻。

• 没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件。

• 没有服务治理，微服务数量多了后管理混乱

信奉微服务理念的设计人员总是强调微服务的lightweight特性，并举出ESB的反例来证明微服务的优越之处。但具体实践后就会发现，随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的lightweight就会变成问题。主要问题如下。

• 服务路由：假设某个微服务有60个节点，部署在20台机器上，那么其他依赖的微服务如何知道这个部署情况呢？

• 服务故障隔离：假设上述例子中的60个节点有5个节点发生故障了，依赖的微服务如何处理这种情况呢？

• 服务注册和发现：同样是上述的例子，现在我们决定从60个节点扩容到80个节点，或者将60个节点缩减为40个节点，新增或减少的节点如何让依赖的服务知道呢？

• 微服务引入的技术复杂度，如分布式事务

信奉微服务理念的设计人员总是强调微服务的lightweight特性，并举出ESB的反例来证明微服务的优越之处。但具体实践后就会发现，随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的lightweight就会变成问题。

     末了，总结一下。不要照搬微服务，如同当年的SOA一样，获得对应的收益必然要付出相应的成本。如果对于自己团队的业务阶段、技术水平、业务特性识别不清楚，可能南辕北辙。

注：本文2/3篇幅节选自《从零开始学架构：照着做，你也能成为架构师》一书，获电子工业出版社授权发布，当当有售。

再次推荐华哥在《极客时间》的专栏：

微服务架构谈系列预告

之三：思辨SOA和微服务

之四：服务化对于研发利好是过程，对于业务反应效率才是结果

之五：服务化架构承受之重：增加了哪些复杂度

之六：分布式事务

之七：服务治理和监控

往期推荐：

• 
  

• 
  

• 
  

      ……

      

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。