首页 / 51CTO / 正文

拜拜 HTTP,哈喽 Reactive:解决云端的大问题

51CTO 2019-10-17 17:30:05

作者:Mahendra Ramsinghani 是总部位于硅谷的网络安全种子基金 Secure Octane 的创始人。

拜拜 HTTP,哈喽 Reactive:解决云端的大问题

阿里巴巴、Pivotal 和 Lightbend 加持,Reactive 大秀其在微服务界的投资回报!

Linux 基金会最近宣布设立 Reactive 基金会。该基金会的创始成员有阿里巴巴、Lightbend、Pivotal 和 Netifi。那么,这个 Reactive Kool-Aid 到底是什么?为什么所有这些公司都纷纷追捧它?

如果你认可开发人员置身于云原生微服务世界这个前提,你就明白大多数应用程序是分布式、有弹性的。计算分布在集群上,所有数据也是如此。可能是几个用户,峰值状态也可能是成千上万个用户。设计的系统其架构需要应对这种峰值情况。不过,微服务的秘密在于复杂性——资源、成本、性能和延迟的管理仍是个挑战。

如果我们将任何应用程序分解成数百个基本模块(比如容器和微服务),那么最好有一种优雅的方法来管理这些基本模块。这些服务需要始终彼此联系、交互数据并确保总体性能很可靠。说起来容易做起来难。

“云端未解决的大问题”

据 IBM 云的杰出工程师 Daniel Berg 声称:“网络是云端未解决的问题……我们需要网络成为云系统的一等公民。”为什么网络仍是个问题?是因为我们需要重新思考新事物时,沿用旧方法吗?我们曾经设计的汽车装有四轮单马轻便马车那又大又笨拙的轮子。从概念上来讲,这听起来不错,但坐起来很不舒服。

在网络协议的分层体系中,中间层是传输(传输控制协议/互联网协议即 TCP/IP),而最顶层是应用程序层。我们使用一种名为超文本传输?6?7?6?7 协议(或 HTTP)的协议来确保 Web 应用程序可以彼此联系。TCP 诞生于 1974 年,被称为“繁琐的协议”(chatty protocol)——就为了做一些基本的事情它要来回往返多次。一则坊间盛传的 TCP 笑话证明了这一点。

拜拜 HTTP,哈喽 Reactive:解决云端的大问题


HTTP 笑话

HTTP 诞生于 15 年后的 1989 年,用于在客户端/服务器时代提供文档。那个年代,我们所有人都用旋转风扇给台式机散热。我们会使用 Netscape 浏览器来打开网页(超文本),Web 服务器会说:“等一下,让我为你获取该内容。”

三十年后,计算层呈爆炸之势,我们试图用 HTTP 来应对。在机器对机器通信大行其道、交互瞬间达数百万次的时代,HTTP 是否适用?我们的移动设备、物联网设备和边缘设备并没有频繁请求大段大段的文本。而且,客户端/服务器交互不如对点对交互来得多。但是网络层一直困扰着我们,我们在努力确保:使用某些过时的方法,这些微服务可以留在原处。Pivotal 的首席软件工程师 Stéphane Maldini 说:“多达 89% 的微服务架构都基于 HTTP。”Pivotal 是 Reactive 基金会的创始成员之一。在此过程中,我们在效率方面做出很大的妥协。我们应使用下一代 iPhone,却仍使用两个罐子和一根绳子进行通信。

HTTP 不适合微服务

如果我们在微服务时代使用 HTTP,会面临根本性的挑战。首先,没有流量控制——“这意味着数据如同从消防水带喷涌出来,”Netifi 的联合创始人 Robert Roeser 说。由于可以迅速传输数据、打开多个线程,我们最终构建了控制功能,以确保应用程序不会崩溃。

反应式编程是架构层面的根本性改变。它注重速度和性能。

需要有效地管理诸多方面,比如断路器、重试逻辑和线程惊群(thundering herd,指大量进程被唤醒,但只有一个进程享有资源,常常导致系统冻结)。在 HTTP 中,一切都是请求/响应,但是如果我们看一下应用程序的简单通知,我们不需要一直保持轮询状态。请求好比刚上路,急不可耐的孩子坐在后座上嚷个不停“我们到了吗?”

如果我们使用错误的协议,这种低效的机制会导致计算资源严重浪费。IBM 记录下了微服务的低效率:

拜拜 HTTP,哈喽 Reactive:解决云端的大问题

得出这个结论:微服务的性能比传统的整体式模型低 79% 左右。研究人员总结道:“我们发现,用于处理 HTTP 通信的 Node.js 和 Java EE 运行时库在微服务模型中消耗的 CPU 周期比在整体式模型中多很多。”

拜拜 HTTP,哈喽 Reactive

Reactive 基金会隶属 Linux 基金会,旨在加速下一代网络技术。它采纳反应式编程框架(Reactive Programming Frameworks)的优点,建立了社区。Reactive 基金会主席兼 Netifi 联合创始人 Ryland Degnan 还是 Netflix 边缘平台会员的时候对 HTTP 带来的痛苦深有体会。

Ryland 比大多数人更了解规模、延迟和用户体验。Netflix 平台会收到来自数亿会员的数十亿个请求。他说:“我们生活在多维世界中,用户体验至关重要。开发人员必须处理以下三个方面:(a)部署(b)框架和(c)协议。时断时续的连接不可接受。为什么我们不能从上次停止的地方继续下去呢?如果我们单单做到这一点,可以减少我们基础设施 90% 的部分。”

的确,Facebook 已采用 RSocket 来减少移动网络中继段(hop)上的断开连接,并大大精简边缘基础设施。Facebook 的软件工程师 Steve Gury 在 SpringOne Platform 上发言时称:“未来是R-Socket 的天下。”

反应式编程(Reactive programming)是架构层面的根本性改变。它注重速度和性能。Reactive 的主要优势之一是异步I/O,这可以将边缘基础设施精简几个数量级。

阿里云的开发倡导者 Andy Shi 是 Reactive 基金会的创始成员之一。他说:“阿里巴巴有数千名开发人员,我们是世界上最大的电子商务平台之一。我们采用微服务时看到计算的使用率只有 10% 左右,因此往服务网格投入更多的基础设施不是解决之道。pod 使用 REST API 彼此联系,这不是出路。”

REST API 需要多个端点和多趟往返才能获取数据。十多年来,Reactive 基金会的另一位创始成员、Lightbend 的代理首席技术官 Viktor Klang 一直在大力宣传 Reactive,他感觉现在时机终于到来。他说:“我们的系统需要在所需的时间段内获得结果。试想一下,如果你可以计算出重大问题(比如生命意义)的答案,但如果答案在你死后才获得,系统就是失败的。”

比较服务网格和使用场景

如果说 Istio 是最适合平移的 18 轮重型卡车,RSocket 就是法拉利,注重速度与优雅。专家们预示将来两者可能会共存。不过在一些应用领域(比如物联网使用场景),RSocket 显然有优势。Istio 提供负载均衡、服务发现、日志记录和流量管理等功能,不过开销很大。

在研究中,Netifi 相比之下能够处理数量多 16 倍的请求,吞吐量提高 4 倍,同时延迟只有三分之一——也就是说,吞吐量提高了 372%,延迟缩短了 300%。戴尔科技资本公司的投资者 Creighton Hicks 说:“Netifi 有可能如同思科——微服务界的路由器。”

Istio 由谷歌、IBM 和 Lyft 发起,因此它是强大的老牌技术,品牌知名度很高。但是当阿里巴巴和 Facebook 之类的公司开始展示 RSocket 的投资回报时,好戏刚刚开始上演。在伦敦最近的一次演讲中,支持 Ractive 的阵营一派兴奋表情。Facebook 的软件工程师 Ondrej Lehecka 和 Andy Shi 谈到了 RSocket 如何应对现实世界的架构挑战。Shi 说:“RSocket 旨在在微服务和物联网设备当道的时代大放异彩。基于 RSocket 协议和 Reactive Streams 构建的项目将颠覆微服务架构生态圈。Reactive 基金会是这些令人兴奋的项目的核心组织。”

【责任编辑:张燕妮 TEL:(010)68476606】

时讯快报

5.5亿用户的选择

立即打开