火热报名中 | 洞察 AI 领域前沿动态,尽在11月30日 深圳 WAVE SUMMIT! 了解详情
写点什么

微服务的历史与陷阱

  • 2020-05-06
  • 本文字数:4485 字

    阅读完需:约 15 分钟

微服务的历史与陷阱

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


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


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

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

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

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

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


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


微服务与 SOA 的关系

对于了解过 SOA 的人来说,第一次看到微服务这个概念肯定会有所疑惑:为何有了 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 和微服务本质上是两种不同的架构设计理念,只是在“服务”这个点上有交集而已,因此两者的关系应该是第三种模式。


其实,Martin Flower 在他的微服务文章中,已经做了很好的提炼:


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 一无是处而微服务无所不能,这也导致了很多团队在实践时不加思考地采用微服务—既不考虑团队的规模,也不考虑业务的发展,也没有考虑基础技术的支撑,只是觉得微服务很牛就赶紧来实施,以为实施了微服务后就什么问题都解决了,而一旦真正实施后才发现掉到微服务的坑里面去了。


我们看一下微服务具体有哪些坑。


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

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


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



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


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

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


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


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

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

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

  • 调用链太长,性能下降

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

  • 调用链太长,问题定位困难

  • 系统拆分为微服务后,一次用户请求需要多个微服务协同处理,任意微服务的故障都将导致整个业务失败。然而由于微服务数量较多,且故障存在扩散现象,快速定位到底是哪个微服务故障是一件复杂的事情。样例如下图所示。



Service C 的数据库出现慢查询,导致 Service C 给 Service B 的响应错误,Service B 给 Service A 的响应错误,Service A 给用户的响应错误。我们在实际定位时是不会有图例中这么清晰的,最开始是用户报错,这时我们首先会去查 Service A。导致 Service A 故障的原因有很多,我们可能要花半个小时甚至 1 个小时才能发现是 ServiceB 返回错误导致的。于是我们又去查 Service B,这相当于重复 Service A 故障定位的步骤……如此循环下去,最后可能花费了几个小时才能定位到是 Service C 的数据库慢查询导致了错误。


如果多个微服务同时发生不同类型的故障,则定位故障更加复杂,如下图所示。



Service C 的数据库发生慢查询故障,同时 Service C 到 Service D 的网络出现故障,此时到底是哪个原因导致了 Service C 返回 Error 给 Service B,需要大量的信息和人力去排查。


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

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

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

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

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

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

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

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

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

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


如果以上场景都依赖人工去管理,整个系统将陷入一片混乱,最终的解决方案必须依赖自动化的服务管理系统,这时我们就会发现,微服务所推崇的“lightweight”,最终也发展成和 ESB 几乎一样的复杂程度。


本文转载自技术锁话公众号。


原文链接:https://mp.weixin.qq.com/s/ASAyc7rhyJXBSx_d7geinA


2020-05-06 17:24634

评论

发布
暂无评论
  • SOA 的未解之谜

    eBIZQ的Joe McKendrick在他最新的一篇博文中谈到了SOA周围的一些未解之谜:SOA与云计算的区别,在人们还没有完全实施SOA之前何来SOA的失败,如何度量SOA的成功等。

  • Service Mesh 的请求路由流程分析

    本文主要分析 WeiboMesh 在运行阶段请求路由的实现,对比现有的通用 Service Mesh (比如 Istio )在这方面的不同。

    2018-03-21

  • 书摘与采访:SOA 100 问 - 问与答

    Kerrie Holly和Ali Arsanjani编著的《SOA 100问:问与答》一书深入解析了SOA,它涵盖了很多SOA相关的话题,包括SOA基础知识,它对业务及组织的影响,SOA方法与架构以及SOA的未来。InfoQ就这本书采访了作者Kerrie Holley和Ali Arsanjani。

  • 遗留系统要想加入 SOA 需要服务么?

    Joe McKendrick在对Oracle印度公司Oracle Fusion Middleware副经理Shailender Kumar的一次采访中问到SOA能否用在无服务的应用中。

  • 初探微服务架构

    我想你一定很好奇微服务架构到底是什么样子的,接下来我们一起走进微服务架构,来看看它的各个组成部分。

    2018-08-28

  • 关于 ESB 实施的几点建议

    谈及企业服务总线(ESB),在有面向服务的架构(SOA)实施经验的开发者眼中一定不会陌生。这些年,人们一直在谈论它,以至有些人认为“实施SOA一定需要ESB”,或“只要将ESB架起来了,我们就SOA了”。这些说法有可取之处,也存在片面之嫌,由于业界对于ESB没有统一、标准的定义,所以一千个人眼中有一千个“ESB”也就成了情理中的事情了。然而,怎么才能将ESB用好?我们需要清楚地认识ESB在SOA中所扮演的角色,理解哪些工作是ESB的职责之内,哪些却不是。只有正确地认识了ESB的职能,并委以恰当的任务,才能将它用在刀刃上、发挥其巨大的能量。

  • 观点:在设计你的 SOA 时——品味至上

    Dan Creswell声称,在把各种组件拼装成一个优秀SOA的过程中,“品味至上(taste is everything)”。Dan说,与某些人所声称的只需对SOA采取千篇一律的方法就可以相对的是,如何挑选分布式服务的技术栈、如何对服务“单元”分层等等,在考虑考虑一组指导方针的同时,完全是个品味问题。

  • 解析微服务架构(二)微服务架构综述

    随着市场的快速发展,业务的不断扩大,单块架构应用面临着越来越多的挑战,其改造与重构势在必行。而微服务架构的诞生,是互联网高速发展,虚拟化技术应用以及持续交付、DevOPS深入人心的综合产物。随着用户需求个性化、产品生命周期变短,微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。同时,以Docker为代表的容器虚拟化技术的盛行,将大大降低微服务实施的成本,为微服务落地以及大规模使用提供了坚实的基础和保障。

  • 深入理解微服务架构:银弹 or 焦油坑?

    微服务与SOA究竟有什么关系?

    2018-07-14

  • 后端 BaaS 化(上):NoOps 的微服务

    微服务的概念其实和FaaS高度相似,也有不少公司用FaaS实现了微服务架构。

    2020-04-27

  • SOA 与微服务的比较和对比

    微服务与SOA这两种架构风格经常被人们拿来进行比较与对比,有些人认为这两者互不相干,而另一些人则相信他们具有密切的血缘关系。Matt Braiser最近在一篇文章中也对这一话题展开了讨论,他的观点倾向于后者,即两种架构具有很高的密切度。他相信,微服务的出现应当归功于SOA原则的成功,并在文章中给出了他的理由。

  • 服务端开发的宏观视角

    今天我们从服务端的发展历程、服务端开发的需求谈起,以此方便你理解服务端开发的生态会怎么演化,技术迭代会走向何方。

    2019-08-20

  • Stefan Tilkov:跳过单体应用,从微服务开始

    在过去的几个月中,许多人都宣称微服务架构应该总是从单体应用开始,其中包括Martin Fowler和Sam Newman,但Stefan Tilkov认为,那经常是错误的,构建一个模块边界清楚、结构良好的单体应用然后再迁移到微服务在大多数情况下都非常困难,几乎不可能。

  • 企业架构中的坑:你是否搞混了“服务”?

    本文就讲一个词——服务。

  • 基于经验的 SOA 成功原则

    在SOA领域工作多年之后, Jean-Jacques Dubray写下了他所信奉的四条促进实现成功SOA的原则。

  • 说点题外话 01|好耦和与坏耦和

    学习的目的,是改变我们的行为和思维。

    2021-07-20

  • 微服务设计介绍

    近日,Russ Miles在介绍微服务的设计与构建时谈到,在向微服务转变时,设计简单的组件与系统是关键所在。我们要聚焦在组件的演化上,以及如何构建系统才能支持演化与改变。

  • 微服务的优缺点

    最近一段时间以来,社区中围绕着微服务产生了很多争论,也充斥着大量的宣传。过去的10年间,我们已经实现了很多笨重的SOA解决方案,微服务是业界期待已久的解决方案么?或者说微服务要比整体解决方案更加简单?

  • 内聚对 SOA 是否重要?

    Jim Webber重新点燃了关于SOA里是否需要内聚的服务(Cohesive Services)的一些讨论。一篇本无冒犯之意的文章,却引起了激烈的争论。

发现更多内容

博睿数据入选首批欧拉技术测评方案,为欧拉生态开发者应用体验保驾护航

博睿数据

14年软件开发经历IT:低代码已成为企业管理的核心引擎

钉钉宜搭低代码

钉钉 低代码 IT 数字化 钉钉宜搭

大转盘抽奖

Rubble

4月日更 4月月更

Docker技术三大要点:cgroup, namespace 和 unionFS, 从理论到实践

Jerry Wang

Docker 容器 虚拟化 容器镜像 4月月更

内网渗透(蚁剑+MSF)

喀拉峻

网络安全 WEB安全 内网渗透

百度文心大模型「技术天团」首次亮相!首场技术开放日、AI创意派决赛来啦~

百度大脑

梳理数仓FI manager节点健康检查逻辑

华为云开发者联盟

运维 GaussDB(DWS) Manager 健康检查 FI manager

Linux驱动开发-编写超声波测距模块的驱动

DS小龙哥

4月月更

智慧零售产业应用实战,30分钟上手的高精度商品识别

百度大脑

16 张图 | Nacos 架构原理①:一条注册请求会经历什么?

悟空聊架构

nacos 注册中心 4月日更 悟空聊架构 4月月更

读《Software Engineering at Google》(06)

术子米德

架构师成长笔记

存储成本降低80%,“大智慧”的选择

华为云开发者联盟

数据分析 存储 GaussDB(for Redis) 降本增效

数据分析之前知道这 7 件事,少花 80% 时间

龙国富

数据分析 数据采集

【深度分享】阿里云架构师解读四大主流游戏架构

阿里云弹性计算

游戏

ERNIE-GeoL:“地理位置-语言”预训练模型

百度大脑

2022年全新FFmpeg/WebRTC/RTMP/RTSP/HLS/RTP播放器-音视频流媒体高级开发学习大纲

赖猫

音视频开发 音视频技术

实例解析山路十八弯的Flutter 2.0路由

岛上码农

flutter ios 安卓开发 4月月更 跨平台开发

自研消息队列之消息队列数据库表设计

晨亮

「架构实战营」

高精度PP-YOLOE、轻量化PP-PicoDet SOTA模型重磅开源

百度大脑

JVM虚拟机,基础原理总结

知了一笑

Java JVM 虚拟机

[Day16]-[链表]反转链表

方勇(gopher)

LeetCode 数据结构和算法

一次简单易懂的多态重构实践,让你理解条件逻辑

华为云开发者联盟

多态 条件逻辑 多态重构 基础逻辑

检测、跟踪、行为识别All-In-One!产业级行人分析系统重磅开源!

百度大脑

Tiger DAO VC:将你的风险投资变成DAO组织协同

BlockChain先知

审核和审批的区别

秋去冬来春未远

mac浏览器密码获取难?教你两种方法,轻松搞定

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

数据结构之链表中的快慢指针

乌龟哥哥

4月月更

三问三答,解传统企业敏捷转型担忧

华为云开发者联盟

DevSecOps 华为云 敏捷转型 Scrum团队 敏捷团队

飞桨EasyDL助力资讯网站实现信息自动分类

百度大脑

coreldraw2022订阅版本最新版本简介

茶色酒

cdr2022

深入解析 Apache BookKeeper 系列:第二篇 — 写操作原理

Apache Pulsar

开源 架构 云原生 中间件 Apache Pulsar

微服务的历史与陷阱_文化 & 方法_技术琐话_InfoQ精选文章