从历史看未来,大规模微服务系统的困境 ---- 基于消息的架构的回归

本贴最后更新于 2355 天前,其中的信息可能已经时移俗易

在大规模分布式系统的架构上,微服务系统是现在很多大型互联网公司的架构方向。

这是一个务实的很好的方向,相对于旧的宏服务来说。

然而,像淘宝这种规模的系统,微服务很容易陷入一个困境,就是 聚合层的扇入扇出过大带来的接口过多复杂爆炸的问题,以及聚合层过小,导致客户端请求域名过多复杂度爆炸的矛盾。

先看下淘宝现在的服务架构图:

jpg

由此图我们可以看出每一个微服务的聚合层都有非常高的扇入,处于中间的聚合层还有很高的扇出。

这就是基于 RPC 的微服务架构的根本缺陷所在。

下面我从几个方面来分析下原因:

RPC 的流行,源于 HTTP/AJAX 在互联网应用中流行,在此之前,更多更大的 IT 系统,诸如电信、银行、军事都是基于消息的。以标准最全规模最大的电信系统为例,全球的电话系统都是基于几套信令标准来互通的。所谓信令也就是控制消息。电信系统的优点是,学院派,一开始就是把问题想清楚,缺点是复杂。所以,在以个人网站起家的诸多互联网巨头带起来的风气里,自然看不到电信系统的影子。而互联网应用,包括电商、O2O、社区等都是采用的 AJAX/RPC 为基础的 SaaS、微服务架构。本质的根源是,互联网应用出身草莽,创业开始头半年,快速上线比架构可演进要重要一千倍。

但是有两个例外,一个是腾讯的 QQ,一个是诸多 PC 客户端网游。由于腾讯 QQ 的创始团队有浓厚的电信背景。而网游追求单服务器高负载能力以降低成本。在互联网初期,服务器能力低下的时代,用 HTTP/AJAX 的网页单服务器带不了多少人在线,不适合低成本高在线人数为追求的 MMORPG 类客户端网游。

从历史我们可以看出,选择什么架构,取决于:速度和成本的折中。

因此,我们应该看到虽然 RPC/微服务似乎成为了互联网的唯一选择,并不是经过深思熟虑的长远考虑,更多的是基于惯性,而这个惯性的起点基于快速上线一个简单 Web 站点的需求。

说了这么多,到底 RPC/微服务 和 消息/信令 系统的架构层面的区别是什么呢?

区别是:有没有在系统每一层固定下所有通过该层的 通讯协议 的细节。

假设,我们有一个 系统 负责提供 算术 功能。

在基于 RPC/微服务的系统中,可能设计是,分两层,对外网关层 叫 算术 Gateway,包装内部 加法 Service、减法 Service、乘法 Service、除法 Service 的所有的接口,对外提供服务。这样设计的结果是,算术 Gateway 的对外的接口非常多,而且要重复下层服务的 Schema。**这就导致了 Gateway 需要知道底层的业务逻辑。**对接口的依赖也是一种依赖,对于网关来说,即便是和微服务云内部的接口构成了依赖关系,也是一个巨大的负担.

在基于消息/信令的系统中,可能涉及是,也有一个算术 Gateway,可以接受 一种类别叫 算术运算的消息。每个消息还有子类别,可能是 加、减、乘、除。 这样的好处是,Gateway 无需理解到子类别的处理逻辑和接口细节,只要知道两点:1. 自己能处理的主消息类型  2. 下层所能处理的子消息类型。如此 Gateway 可以方便的路由消息给下层的消息处理器。这也是电信系统的通用设计方式,每一层信令系统都只针对自己的业务域,信令包含子信令,信令的处理器只要知道能处理对应子信令的消息处理器并不需要了解子信令的 Schema。

在国内的网游,以及交通银行的手机银行系统中,广泛的使用 Erlang/OTP 平台。该平台来自于世界最大的电信设备制造商爱立信。在 Erlang/OTP 中,每个 Process 都是一个 Actor 负责处理自己邮箱的消息。而亚马逊最新的 ServerLess 架构却和二十年前的 Erlang/OTP 架构有异曲同工之妙。

由此可见,ServerLess/Actor/消息/信令,其实有很深的设计渊源,是同一种思想的不同领域实现。本质上就是把消息 Schema 的固化和消息的处理解耦。在 RPC/微服务的架构中,每一层,都必须用某种语言/IDL 唯一缺点的描述自己能处理的消息的全部 Schema。而消息/信令架构天然没这个约束。

以上是从 Schema 的层面分析的区别,从同步和异步的暗示上来说,RPC/微服务架构诱骗开发人员用户同步的思想来设计接口,无端制造出了超时重试导致雪崩、同步阻塞浪费线程等问题。任何一个大型系统天然是异步,任何同步的系统的努力都会随着系统的增大而成本越来越高。异步、非阻塞是大部分消息系统设计背景。这点更加重了 RPC/微服务架构的使用成本。

更糟糕的是,随着系统规模的扩大,很多 RPC/微服务系统发现自己必须存在很多环路调用,但是环路又是 RPC/微服务架构的大敌。为此不得不引入诸如 Kafka 等消息队列来引入异步性,解除环路。于是系统的复杂度 Double。 

为何系统复杂了,就会出现环路,这是因为任何复杂系统必然是一个 图计算 系统,而且 必然是一个 有向有环图。为了把一个有向有环图适配到一个树状的 RPC/微服务架构中,架构师们花费了不少脑力。显然,这是一种巨大的浪费。

以上是从 架构抽象层面 的分析。

另一个角度来说,RPC 的易用性并不比消息高,否则,我们用的终端命令行就应该是函数调用的样式操作,而不是现在的交互会话的样式了。人类更喜欢会话方式。更不用说,在每个『消息』的末尾加上 『&』就可以异步化处理消息的简便表达方式,好理解好使用。

综上所述,人类徘徊了 20 多年的以后,大规模分布式系统的架构来设计又慢慢的回到了 消息/信令 架构。

  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    142 引用 • 442 回帖
  • 消息系统
    1 引用 • 2 回帖
  • 分布式
    80 引用 • 149 回帖 • 4 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • demoj

    "Gateway 需要知道底层的业务逻辑"这一句不是很理解,微服务也是把各个模块给封装了的吧

    1 回复
  • 就是说 网关 需要知道 后面的微服务 在干啥.
    然而这事是不合理的.
    网关应该是业务无关的.

推荐标签 标签

  • Bootstrap

    Bootstrap 是 Twitter 推出的一个用于前端开发的开源工具包。它由 Twitter 的设计师 Mark Otto 和 Jacob Thornton 合作开发,是一个 CSS / HTML 框架。

    18 引用 • 33 回帖 • 659 关注
  • LeetCode

    LeetCode(力扣)是一个全球极客挚爱的高质量技术成长平台,想要学习和提升专业能力从这里开始,充足技术干货等你来啃,轻松拿下 Dream Offer!

    209 引用 • 72 回帖
  • Solidity

    Solidity 是一种智能合约高级语言,运行在 [以太坊] 虚拟机(EVM)之上。它的语法接近于 JavaScript,是一种面向对象的语言。

    3 引用 • 18 回帖 • 399 关注
  • SQLServer

    SQL Server 是由 [微软] 开发和推广的关系数据库管理系统(DBMS),它最初是由 微软、Sybase 和 Ashton-Tate 三家公司共同开发的,并于 1988 年推出了第一个 OS/2 版本。

    21 引用 • 31 回帖 • 1 关注
  • React

    React 是 Facebook 开源的一个用于构建 UI 的 JavaScript 库。

    192 引用 • 291 回帖 • 385 关注
  • ngrok

    ngrok 是一个反向代理,通过在公共的端点和本地运行的 Web 服务器之间建立一个安全的通道。

    7 引用 • 63 回帖 • 624 关注
  • ZeroNet

    ZeroNet 是一个基于比特币加密技术和 BT 网络技术的去中心化的、开放开源的网络和交流系统。

    1 引用 • 21 回帖 • 638 关注
  • 星云链

    星云链是一个开源公链,业内简单的将其称为区块链上的谷歌。其实它不仅仅是区块链搜索引擎,一个公链的所有功能,它基本都有,比如你可以用它来开发部署你的去中心化的 APP,你可以在上面编写智能合约,发送交易等等。3 分钟快速接入星云链 (NAS) 测试网

    3 引用 • 16 回帖
  • 游戏

    沉迷游戏伤身,强撸灰飞烟灭。

    176 引用 • 815 回帖
  • Android

    Android 是一种以 Linux 为基础的开放源码操作系统,主要使用于便携设备。2005 年由 Google 收购注资,并拉拢多家制造商组成开放手机联盟开发改良,逐渐扩展到到平板电脑及其他领域上。

    334 引用 • 323 回帖 • 2 关注
  • Sphinx

    Sphinx 是一个基于 SQL 的全文检索引擎,可以结合 MySQL、PostgreSQL 做全文搜索,它可以提供比数据库本身更专业的搜索功能,使得应用程序更容易实现专业化的全文检索。

    1 引用 • 211 关注
  • 人工智能

    人工智能(Artificial Intelligence)是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门技术科学。

    133 引用 • 189 回帖
  • Telegram

    Telegram 是一个非盈利性、基于云端的即时消息服务。它提供了支持各大操作系统平台的开源的客户端,也提供了很多强大的 APIs 给开发者创建自己的客户端和机器人。

    5 引用 • 35 回帖 • 2 关注
  • Mac

    Mac 是苹果公司自 1984 年起以“Macintosh”开始开发的个人消费型计算机,如:iMac、Mac mini、Macbook Air、Macbook Pro、Macbook、Mac Pro 等计算机。

    166 引用 • 595 回帖 • 1 关注
  • SendCloud

    SendCloud 由搜狐武汉研发中心孵化的项目,是致力于为开发者提供高质量的触发邮件服务的云端邮件发送平台,为开发者提供便利的 API 接口来调用服务,让邮件准确迅速到达用户收件箱并获得强大的追踪数据。

    2 引用 • 8 回帖 • 483 关注
  • 安全

    安全永远都不是一个小问题。

    199 引用 • 816 回帖
  • Rust

    Rust 是一门赋予每个人构建可靠且高效软件能力的语言。Rust 由 Mozilla 开发,最早发布于 2014 年 9 月。

    58 引用 • 22 回帖
  • Python

    Python 是一种面向对象、直译式电脑编程语言,具有近二十年的发展历史,成熟且稳定。它包含了一组完善而且容易理解的标准库,能够轻松完成很多常见的任务。它的语法简捷和清晰,尽量使用无异义的英语单词,与其它大多数程序设计语言使用大括号不一样,它使用缩进来定义语句块。

    543 引用 • 672 回帖
  • 反馈

    Communication channel for makers and users.

    123 引用 • 911 回帖 • 245 关注
  • BookxNote

    BookxNote 是一款全新的电子书学习工具,助力您的学习与思考,让您的大脑更高效的记忆。

    笔记整理交给我,一心只读圣贤书。

    1 引用 • 1 回帖
  • IPFS

    IPFS(InterPlanetary File System,星际文件系统)是永久的、去中心化保存和共享文件的方法,这是一种内容可寻址、版本化、点对点超媒体的分布式协议。请浏览 IPFS 入门笔记了解更多细节。

    21 引用 • 245 回帖 • 240 关注
  • BND

    BND(Baidu Netdisk Downloader)是一款图形界面的百度网盘不限速下载器,支持 Windows、Linux 和 Mac,详细介绍请看这里

    107 引用 • 1281 回帖 • 27 关注
  • API

    应用程序编程接口(Application Programming Interface)是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。

    77 引用 • 430 回帖
  • 强迫症

    强迫症(OCD)属于焦虑障碍的一种类型,是一组以强迫思维和强迫行为为主要临床表现的神经精神疾病,其特点为有意识的强迫和反强迫并存,一些毫无意义、甚至违背自己意愿的想法或冲动反反复复侵入患者的日常生活。

    15 引用 • 161 回帖
  • 持续集成

    持续集成(Continuous Integration)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

    15 引用 • 7 回帖 • 1 关注
  • C++

    C++ 是在 C 语言的基础上开发的一种通用编程语言,应用广泛。C++ 支持多种编程范式,面向对象编程、泛型编程和过程化编程。

    107 引用 • 153 回帖 • 3 关注
  • 服务器

    服务器,也称伺服器,是提供计算服务的设备。由于服务器需要响应服务请求,并进行处理,因此一般来说服务器应具备承担服务并且保障服务的能力。

    125 引用 • 588 回帖