Uber 实时推送平台实践：gRPC 推动基础设施的发展( 四 ) ：Uber实时推送平台实践：gRP

HelixControllers：顾名思义，这是一个由五个节点组成的独立服务，只负责运行ApacheHelixController进程，是进行拓扑管理的“大脑” 。无论何时启动或停止任何Streamgate节点，它都会检测到更改并重新分配分片分区。
近几年来，我们一直在使用这种架构，并能够在服务器端实现99.99%的基础架构可靠性。这种推送基础设施的应用越来越多，支持iOS、Android和Web平台上的十几种不同类型的应用。在150万以上并发连接的情况下，我们已经在运行这个系统，每秒推送超过25万条消息。
gRPC推动基础设施的未来
这种服务器端基础设施一直保持稳定。在网络条件日益改善、应用范围日益扩大的新城市里，我们将致力于不断提高向移动设备发送消息的长尾可靠性。为了填补空白，我们已经尝试了新的协议和开发方法。经过检验，以下几点是导致可靠性下降的主要原因。
丢失确认
上文定义的RAMEN协议是为减少数据传输而优化的，因此只有每30秒或在客户端重新连接时才会报告确认。这样会导致确认被延迟，在某些情况下，确认消息传输失败。这样很难区分消息的真实丢失与确认请求的失败。
连接稳定性差
保持服务器和客户端之间的健康连接是至关重要的。在处理错误、超时、后退或应用程序生命周期事件（打开或关闭）、网络状态变化、主机名和数据中心故障切换方面，不同平台的客户端实现之间存在许多细微的差别。这样会在不同版本中产生性能差异。
传输限制
因为协议是在SSE上实现的，所以数据传输是单向的。有些新的应用经验需要我们实现双向信息传输。在没有实时测量往返时间的情况下，无法确定网络状况、传输速度和减少线路阻塞。在没有base64这样的文本编码的情况下， SSE也是一种基于文本的协议，这限制了我们传输二进制负载的能力，导致负载变大。
2019年底，我们开始开发下一代的RAMEN协议，以克服上述缺点。经过大量的考虑，我们选择了在gRPC上构建它。 gRPC是一种被广泛采用的RPC协议栈，具有跨多种语言的客户机和服务器的标准化实现。对于许多不同的RPC方法，它提供了一流的支持，并且可以与QUIC传输层协议进行互操作。
新的基于GRPC的RAMEN协议扩展了以前的基于SSE的协议，但其中存在一些重要区别：
当前将立即发送反向流的确认。这样就提高了确认的可靠性，但数据传输量却略微增加。实时确认使我们能够实时测量RTT ，了解网络状态。可将消息的真实损失与网络损失区分开来。其提供了协议之上的抽象层来支持流复用等功能。同时也使我们可以尝试采用网络优先级和流控制算法来提高数据使用和通信延迟的效率。这个协议抽象了消息负载，以支持不同类型的序列化。将来我们可以研究其他的序列化，但gRPC保留在传输层。强大的不同语言客户端实现还允许我们快速支持不同类型的应用和设备。这项工作目前正处于测试发布阶段，目前对其未来看好。
最后
在Uber的出行体验中，推送平台是一个不可或缺的部分。现在这个平台已经提供了上百种不同的功能，以下是该平台在获得巨大成功的几个主要原因。
关注点分离
随着业务需求的变化，消息触发、创建和交付系统之间的明确职责划分使我们能够将焦点转移到平台的不同部分。在ApacheHelix中，将交付组件与拓扑逻辑、流媒体的核心业务逻辑高度分离，这使得gRPC在完全相同的架构上得到支持，但是使用不同的线协议。
行业标准技术
以行业标准技术为基础，使实施更稳健且长远，成本更低。上面的系统维护开销已经很小了。作为一个平台，我们可以在团队规模上提供极高的效率。以我们的经验来看， Helix和Zookeeper非常稳定。
更简单的设计
通过这个协议，我们可以在不同的网络环境下扩展到数百万用户、数百种功能和数十种应用，这个协议的简单性使得它容易扩展，发展迅速。
作者简介：
UdayKiranMedisetty ， Uber高级工程师；NileshMahajan ， Uber工程师；AnirudhRaja ， Uber二级软件工程师；MadanThangavelu ， Uber高级工程经理。
原文链接：
https://eng.uber.com/real-time-push-platform/
答应我，从今以后这样打开InfoQ
2021年前端开发的下一步发展预测
被接连封杀后，出海的“TikTok们”还在坚持什么？
InfoQ读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加InfoQ小助手，回复关键字“进群”申请入群。回复“资料” ，获取资料包传送门，注册InfoQ网站后，可以任意领取一门极客时间课程，免费滴！大家可以和InfoQ读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！