API场景中的数据流

Data Streaming in the API Landscape

原文作者：Kin Lane

原文地址：https://dzone.com/articles/data-streaming-in-the-api-landscape

译者微博：@从流域到海域

API场景中的数据流

我正在重新审视my real-time API research(我的实时API研究)作为上周我所进行的一些“数据流”和“事件溯源”对话的一部分。我的研究领域从来都不是完美的，但我认为实时仍然是考虑我们近期在应用场景中看到的一些变化的最佳保护伞。

它们并不是什么新鲜事物，但是已经有了新的活力，关于它们新的而且有趣的对话不断开展，并且有一些我不能忽视的增长趋势。为了支持我的研究，本周我花了一天的时间深入并与我的朋友Alex在TheNewStack.io和WSO2 Tyler Jewell的新首席执行官之间进行了一次对话，讨论正在发生的事情。

我接近我的研究的方式是总是退后一步，看看现在已经发生了什么，我想再看看一些我在这个领域中已经关注的实时API服务提供商：

• Pubnub：为开发人员构建安全的实时移动性，Web和物联网应用程序的API。
• StreamData：将任何API转换为实时数据流，而不需要在服务器上执行任何一条代码。
• Fanout.io：Fanout的反向代理可以帮助您立即将数据推送到连接的设备。
• Firebase：通过我们的NoSQL云数据库存储和同步数据。数据在所有客户端实时同步，并在您的应用下线时仍保持可用状态。
• Pusher：实时技术的领导者。我们授权所有开发人员使用我们的简单托管API为Web和移动应用创建实时功能。

我一直在追踪这些提供商在一段时间内的工作。它们一直在推动流和实时API的界限。我认为值得注意的还有另一个开源解决方案，我相信上面的一些服务已经使用了Netty.io。

• Netty：Netty是一个异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。

我也想确认并将Google的做法纳入到一段时间的技术中：

• Google Cloud Pub / Sub：Google Cloud Pub / Sub是一项全面管理的实时消息服务，允许您在独立应用程序之间发送和接收消息。

接下来，我想重新理解对这个领域的所有Apache的项目。我总是试图控制它们每一个实际所提供的内容，以及它们怎样重叠。所以，像这样放在一起看它们会帮助我思考它们是如何去适配大环境的。

• Apache Kafka：Kafka™用于构建实时数据管道和流应用程序。它具有横向扩展性，容错性，(处理)速度级快，并且可以在数千家公司的生产环境中运行。
• Apache Flink：ApacheFlink®是一款面向分布式、高性能、始终可用并且始终准确无误的数据流应用程序的开源流处理框架。
• Apache Spark：Spark Streaming可以轻松构建可扩展的可容错流应用程序。Spark Streaming是Spark API核心的扩展，它支持实时数据流的可扩展、高吞吐量、可容错流处理。
• Apache Storm Apache Storm是一个免费且开源的分布式实时计算系统。Storm可以轻松可靠地处理无限数据流，从而把Hadoop需要进行批处理的操作实时处理。
• Apache Apollo：ActiveMQ Apollo是一个更快，更可靠，更易于维护从原始ActiveMQ基础构建的消息传递代理。

有一件我认为值得注意的事，当你阅读它们的API时，你会发现它们缺少网络。Apollo有一些重要的REST风格的方法，你可以找到一些其他的网关和插件，但是当你考虑如何将这些技术应用到更广泛的API场景中时，我会说它们没有拥抱网络。

这点需要说明，我认为值得一提的是，Google在gRPC上做出的努力提供了“使用http/2的传输的双向流式传输和完全集成的可插入身份验证”：

• gRPC：高性能的开源通用RPC框架。

另外，我认为最值得注意的是，它们在继续了API拥抱网络并构建在HTTP/2之上的传统。对我而言，这是非常重要的，我的书中总会将一些重要的甚至是王牌的(系统/框架)开源。开放源代码技术越多，公司的服务使用越多，我会感觉到越舒服，我告诉读者它们应该将这些融入到它们的业务中。

在介绍完成这些服务和工具之后，我不想忘记那些提供的很好的协议，这可以帮助我们在实时领域做一些事情。我正在跟踪12个实时协议，这些协议是我在跟踪的公司，组织，机构和政府机构中看到的：

• 简单（或流式）面向文本的消息协议（STOMP）：STOMP是简单（或流式）面向文本的消息传递协议。STOMP提供可互操作的线路格式，以便STOMP客户端可以与任何STOMP消息代理进行通信，以便在多种语言、平台和代理之间提供简单而广泛的消息可互操作性。
• 高级消息队列协议（AMQP）：高级消息队列协议（AMQP）是用于在应用程序或组织之间传递业务消息时的开放标准。它连接系统，为业务流程提供所需的信息，并可靠地传输实现其目标的指令。
• MQTT：MQTT是机器对机器（M2M）/物联网连接协议。它被设计成一个非常轻量级的发布/订阅消息传输(机制)。对于与需要较小代码空间和/或网络带宽较高的远程位置进行连接非常有用。
• OpenWire：OpenWire是跨语言有线协议，允许从多种不同的语言和平台本地访问ActiveMQ。Java OpenWire传输是ActiveMQ 4.x或更高版本中的默认传输。
• Websocket：WebSocket是一种通过单个TCP连接提供全双工通信信道的协议。WebSocket协议在2011年被IETF标准化为RFC 6455，Web IDL中的WebSocket也被APIW3C进行了标准化。
• 可扩展消息和呈现协议（XMPP）：XMPP是可扩展消息和呈现协议，这是一组用于即时消息，状态，多方聊天，语音和视频呼叫，协作，轻量级中间件，内容联合和广义路由的开放式技术的XML数据(协议)。
• SockJS：SockJS是一个浏览器JavaScript库，提供了一个类似WebSocket的对象。SockJS为您提供了一个连贯的，跨浏览器的JavaScript API，可在浏览器和Web服务器之间创建低延迟，全双工，跨域的通信通道。
• PubSubHubbub：PubSubHubbub是Internet上的分布式发布/订阅通信的开放协议。最初设计用于扩展数据馈送的Atom（和RSS）协议，该协议可应用于任何数据类型（即HTML，文本，图片，音频，视频），只要它可通过HTTP访问即可。其主要目的是提供实时改变通知，这改善了客户端以某种任意时间间隔定期轮询反馈服务器的典型情况。通过这种方式，PubSubHubbub提供了推送的HTTP通知，而不需要客户端消耗资源轮询检测更改。
• Real-Time Streaming Protocol (RTSP)：实时流协议（RTSP）是一种网络控制协议，设计用于娱乐和通信系统以控制流媒体服务器。该协议用于建立和控制端点之间的媒体会话。媒体服务器的客户端发出VCR式命令，例如播放和暂停，以便实时控制从服务器播放媒体文件。
• Server-Sent Events：服务器发送事件协议（SSE）是浏览器通过HTTP连接从服务器接收自动更新的技术。The Server-Sent Events EventSource API由W3C标准化为HTML5的一部分。
• HTTP实时流式传输（HLS）：HTTP实时流式传输（也称为HLS）是由Apple Inc.实施的基于HTTP的媒体流式通信协议，作为其QuickTime，Safari，OS X和iOS软件的一部分。
• HTTP长轮询：HTTP长轮询是客户端轮询服务器请求新信息的协议。服务器保持请求打开，直到有新数据可用。一旦可用，服务器响应并发送新的信息。当客户端收到新信息时，它立即发送另一个请求并重复该操作。这有效地模拟了服务器推送功能。

这些协议被我上面列出的大多数服务提供商和工具所使用，但在我的研究中，我总是试图关注服务和工具，而非它们支持的实际开放标准。

在我看来，我还必须提及实时的入门级方面的内容。许多API提供商都支持，而且也是一些公司，组织，机构和代理机构在用其他方法淹没之前需要接触的101级(101-level ，原文如此)方法。

• Webhooks：Web开发中的 Webhook是一种通过自定义回调来增强或改变网页或Web应用程序的行为的方法。这些回调可能由第三方用户和开发人员维护、修改和管理，第三方用户和开发人员可能不一定与发起网站或应用程序有关。

那(Webhooks)是实时API场景。当然，还有其他服务和工具，但这是最重要的。我也在尝试与事件源，架构，消息传递以及API空间的其他层次（等现今用来回于移动位和字节）进行交叉。技术人员并不总是最擅长使用精确的单词或使事情简单易懂，更不用能说得清楚了。这是我对流式API方法所关注的问题之一，它们经常悬在我们头顶(需要解决的意思)，并超出了某些API提供者的需求，并且也可能是API消费者。它们在某些使用案例中占有自己的位置，大型组织有这些资源，但我仍花了很多时间担心这个小家伙。

我认为在Twitter API社区中可以找到一个很好的Web API与对比Streaming API的示例。许多人只需要简单，直观的RESTful端点就可以访问数据和内容，而更小的一部分人需要获得技术，技能和计算能力来大规模处理他们的事情。无论如何，我看到像Apache Kafka这样的技术即将变成即插即用式技术，基础架构变成服务方式，任何人都可以快速部署到Heroku，并通过SaaS模式开展工作。所以，很自然的，我仍然会关注并试图从所有这些中获得一些理解。我不知道它会走向何处，但我会继续调整并讲述实时流API技术如何被使用或未被使用。