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

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

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

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

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

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

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 回复
  • 就是说 网关 需要知道 后面的微服务 在干啥.
    然而这事是不合理的.
    网关应该是业务无关的.

推荐标签 标签

  • 阿里巴巴

    阿里巴巴网络技术有限公司(简称:阿里巴巴集团)是以曾担任英语教师的马云为首的 18 人,于 1999 年在中国杭州创立,他们相信互联网能够创造公平的竞争环境,让小企业通过创新与科技扩展业务,并在参与国内或全球市场竞争时处于更有利的位置。

    43 引用 • 221 回帖 • 129 关注
  • GitLab

    GitLab 是利用 Ruby 一个开源的版本管理系统,实现一个自托管的 Git 项目仓库,可通过 Web 界面操作公开或私有项目。

    46 引用 • 72 回帖
  • 锤子科技

    锤子科技(Smartisan)成立于 2012 年 5 月,是一家制造移动互联网终端设备的公司,公司的使命是用完美主义的工匠精神,打造用户体验一流的数码消费类产品(智能手机为主),改善人们的生活质量。

    4 引用 • 31 回帖
  • iOS

    iOS 是由苹果公司开发的移动操作系统,最早于 2007 年 1 月 9 日的 Macworld 大会上公布这个系统,最初是设计给 iPhone 使用的,后来陆续套用到 iPod touch、iPad 以及 Apple TV 等产品上。iOS 与苹果的 Mac OS X 操作系统一样,属于类 Unix 的商业操作系统。

    84 引用 • 139 回帖 • 1 关注
  • WebClipper

    Web Clipper 是一款浏览器剪藏扩展,它可以帮助你把网页内容剪藏到本地。

    3 引用 • 9 回帖 • 2 关注
  • Netty

    Netty 是一个基于 NIO 的客户端-服务器编程框架,使用 Netty 可以让你快速、简单地开发出一个可维护、高性能的网络应用,例如实现了某种协议的客户、服务端应用。

    49 引用 • 33 回帖 • 18 关注
  • abitmean

    有点意思就行了

    30 关注
  • 面试

    面试造航母,上班拧螺丝。多面试,少加班。

    325 引用 • 1395 回帖
  • Sphinx

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

    1 引用 • 209 关注
  • Ant-Design

    Ant Design 是服务于企业级产品的设计体系,基于确定和自然的设计价值观上的模块化解决方案,让设计者和开发者专注于更好的用户体验。

    17 引用 • 23 回帖
  • wolai

    我来 wolai:不仅仅是未来的云端笔记!

    2 引用 • 14 回帖
  • Docker

    Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的操作系统上。容器完全使用沙箱机制,几乎没有性能开销,可以很容易地在机器和数据中心中运行。

    490 引用 • 916 回帖 • 2 关注
  • 架构

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

    142 引用 • 442 回帖
  • 倾城之链
    23 引用 • 66 回帖 • 139 关注
  • 笔记

    好记性不如烂笔头。

    308 引用 • 793 回帖
  • 设计模式

    设计模式(Design pattern)代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

    200 引用 • 120 回帖 • 1 关注
  • HHKB

    HHKB 是富士通的 Happy Hacking 系列电容键盘。电容键盘即无接点静电电容式键盘(Capacitive Keyboard)。

    5 引用 • 74 回帖 • 465 关注
  • SQLite

    SQLite 是一个进程内的库,实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。SQLite 是全世界使用最为广泛的数据库引擎。

    5 引用 • 7 回帖
  • Spark

    Spark 是 UC Berkeley AMP lab 所开源的类 Hadoop MapReduce 的通用并行框架。Spark 拥有 Hadoop MapReduce 所具有的优点;但不同于 MapReduce 的是 Job 中间输出结果可以保存在内存中,从而不再需要读写 HDFS,因此 Spark 能更好地适用于数据挖掘与机器学习等需要迭代的 MapReduce 的算法。

    74 引用 • 46 回帖 • 561 关注
  • SpaceVim

    SpaceVim 是一个社区驱动的模块化 vim/neovim 配置集合,以模块的方式组织管理插件以
    及相关配置,为不同的语言开发量身定制了相关的开发模块,该模块提供代码自动补全,
    语法检查、格式化、调试、REPL 等特性。用户仅需载入相关语言的模块即可得到一个开箱
    即用的 Vim-IDE。

    3 引用 • 31 回帖 • 101 关注
  • Postman

    Postman 是一款简单好用的 HTTP API 调试工具。

    4 引用 • 3 回帖 • 3 关注
  • Shell

    Shell 脚本与 Windows/Dos 下的批处理相似,也就是用各类命令预先放入到一个文件中,方便一次性执行的一个程序文件,主要是方便管理员进行设置或者管理用的。但是它比 Windows 下的批处理更强大,比用其他编程程序编辑的程序效率更高,因为它使用了 Linux/Unix 下的命令。

    122 引用 • 73 回帖
  • 国际化

    i18n(其来源是英文单词 internationalization 的首末字符 i 和 n,18 为中间的字符数)是“国际化”的简称。对程序来说,国际化是指在不修改代码的情况下,能根据不同语言及地区显示相应的界面。

    8 引用 • 26 回帖
  • WebSocket

    WebSocket 是 HTML5 中定义的一种新协议,它实现了浏览器与服务器之间的全双工通信(full-duplex)。

    48 引用 • 206 回帖 • 347 关注
  • 星云链

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

    3 引用 • 16 回帖 • 2 关注
  • MySQL

    MySQL 是一个关系型数据库管理系统,由瑞典 MySQL AB 公司开发,目前属于 Oracle 公司。MySQL 是最流行的关系型数据库管理系统之一。

    677 引用 • 535 回帖
  • PHP

    PHP(Hypertext Preprocessor)是一种开源脚本语言。语法吸收了 C 语言、 Java 和 Perl 的特点,主要适用于 Web 开发领域,据说是世界上最好的编程语言。

    179 引用 • 407 回帖 • 489 关注