译者|布加迪
审稿人|孙淑娟
数据正在快速增长。三年内，全球每天产生的数据量将达到 463 艾字节。相比之下，迄今为止人类产生的单词总数估计仅为 5 艾字节。
为了在当今的数字经济中取得成功，许多企业正在实施策略来使用和分析所有这些数据，以实时做出正确的业务决策。预计到 2025 年，每个互联人的平均每日数字交互次数将达到 5,000 次。企业需要能够满足对实时数据、流程和用户体验不断增长的需求。
一种策略是使用事件驱动架构。事件驱动架构是一种软件设计模式，允许企业实时操作客户交易等业务事件。事件驱动架构并不是一个新概念，自 20 世纪 70 年代以来就已存在。直到最近，这项技术还没有真正为企业和消费者提供实时服务。
事件驱动架构现在成为解决现代业务问题和提供卓越消费者体验的焦点。
事件驱动架构以事件为基础，向相关方发送业务系统状态变化的信号。例如，事件可以是在线购买、产品正在运输或产品正在运送到客户家门口。各行各业都不断发生事故。
事件驱动架构中有生产者和消费者。生产者触发事件，事件作为消息通过事件通道发送给感兴趣的消费者，其中事件被异步处理。生产者和消费者不必等待对方开始下一个任务，因为生产者与接收者是松散耦合或完全解耦的。
由于通信和业务逻辑的分离，解耦还提高了可扩展性。如果订阅者离线或消费减慢，发布者可以避免瓶颈并且不受影响。如果订阅者在跟上事件时遇到困难，事件流会记录事件以供将来检索。发布者可以继续发送通知而不受吞吐量限制，并且对故障具有高度弹性。发布/订阅（pub/sub）是事件驱动架构中常见的设计模式，它提供了发布者和订阅者之间交换消息的框架。消息代理接收来自发布者的所有事件，并将实时发生的事件路由到订阅者，即那些已注册接收事件的订阅者。代理还记录事件。消费者可以随时访问事件流，并且可以读取最新的消息，或者处理自上次检查事件流以来收到的一系列消息。
如果使用消息代理，发布者不知道订阅者，即使感兴趣的人数增加也不会受到影响。发布到经纪人使生产者有机会跨不同设备和平台向一系列消费者传递通知。
将功能构建到应用程序中以提供大规模实时体验是有风险、复杂、昂贵且耗时的。组织最初可能会花费数月时间使用现成的组件构建自定义解决方案。随着团队努力应对规模和可靠性要求的复杂性，所需的时间可能会长达数年。
许多应用程序依赖于一系列相互依赖的消息。但是，如果这些消息丢失或顺序混乱，用户体验将受到影响，并且在此过程中客户数据可能会受到损害或丢失。提供具有数据完整性的实时数字体验所需的技术非常复杂，并且通常会导致不可接受的权衡，例如公司为了数据完整性而大规模牺牲性能。
还存在性能问题。不良或不可预测的延迟以及高带宽消耗的问题可能会给应用程序开发人员在设计、构建和扩展实时功能时带来不确定性。除了最大限度地减少延迟和带宽要求之外，组织还必须尽量避免这些措施中的差异，以便为开发人员提供可预测性并确保提供的体验具有竞争力。对于组织来说，设计、构建和运营自己的全球分布式容错实时基础设施也很困难。为了实现容错，组织需要在多个数据中心拥有多个冗余组件，以便在其他组件丢失时保持系统运行。
当组织开始扩展时，它要么从构建基础设施的方式中获益，要么承受后果。未到位的基础设施无法扩展或提供满足实时客户需求所需的弹性。此外，对于大多数组织来说，为事件驱动架构构建自己的基础设施只会分散开发真正使其产品脱颖而出的实时体验的注意力。要达到可以依靠基础设施来提供有竞争力的体验的程度，需要团队雇用许多人员并开发可能与业务核心无关的技能。
为了克服这些挑战，Ablly 边缘消息平台提供了相应的 API，允许开发人员构建用于实时通信的应用程序和基础设施，而组织无需管理规模、延迟、消息完整性，或网络中断。
任意数量的订阅设备都将实时接收从设备发布到 Ably 的消息。为此，Ablly 将消息流量组织到命名通道中。连接到 Ably 后，客户端可以是发布者（将消息推送到 Ably）、订阅者（等待从 Ably 推送消息），或两者兼而有之。虽然 Ably 可以传送数十亿条消息，但订阅者只能在他们订阅的频道上接收消息。
通道提供了一种实现发布/订阅模式的方法，允许发布者快速有效地将数据推送给订阅者。新数据被推送给订阅者，这样他们就不必轮询服务器来检查新数据。
Ably 的在线状态功能允许客户在频道上宣布他们的在线状态。在线状态功能使开发人员能够构建协作应用程序，例如聊天室、多人游戏或协作工具，因为 Ably 会自动实时跟踪任何设备上的在线人员。频道上的每个成员都有一个唯一的客户端标识符和一个可选的负载来描述成员的状态，例如进入频道、更新状态或离开频道。其他设备或服务实时订阅这些存在事件。
Ably 是一个全球分布式系统，其中通道可以在多个区域独立活动，因此不存在单点故障或拥塞。
下图说明了 Ably 如何解决高效全球路由的挑战：
