拜拜 HTTP，哈喽 Reactive：解决云端的大问题

作者：Mahendra Ramsinghani 2019-10-17 09:19:24

新闻

云计算 如果你认可开发人员置身于云原生微服务世界这个前提，你就明白大多数应用程序是分布式、有弹性的。计算分布在集群上，所有数据也是如此。

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

[[279424]]

　　阿里巴巴、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 笑话

　　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 记录下了微服务的低效率：

　　得出这个结论：微服务的性能比传统的整体式模型低 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 基金会是这些令人兴奋的项目的核心组织。”