设计 Rio 的一些想法

on technology

这几天在写一个叫做 Rio 的项目。 它是一个服务端的程序，使用 Python 编写，基于 Flask+Celery 开发。 现在它处于早期开发阶段，还有很多我期待中的特性尚未实现。 但是它现在可以跑通简单的流程(大概)。

它期望解决的问题是异构系统的事件驱动编程。 这个问题有很多解决方案，我的解决方案也绝非就是最终或最好的。 但我希望它能比别的方案少一些些使用上的不愉快(笑)。

貌似事件驱动编程是件挺简单的事情。也确实也有很多现成的解决方案。

考虑过直接基于 Message Queue 来传递消息，通过 Fanout 将消息传递到各个队列去，服务通过消费者进程消费队列中的消息。

这确实是一个效率很高的做法，但就体验上来说，不易调试是很大的问题。 消费者的监听逻辑散落于各个服务中，缺失一份服务间的消息分发全局拓扑图。 在架构变得复杂后，后续的运维工作也需要跟上：队列监控，追踪系统等等。 总之，这个方案适合消息体量很大或者运维设施很完善的 Team。

我期望中的易于调试是可以通过 REPL 或者 Curl 就能完成的操作。 我期望中的简单架构是一个项目起尽可能少的进程来完成尽可能多的事情。 顺便能很快查到任意一个事件都会触发了哪些异步操作。

问题和功能大概就是酱紫。为了达到我期望中的结果，对整个系统做了一些约束：

  • 预先向 Rio 注册事件与关联的 Webhook。
  • 消费者在服务中以 HTTP Webhook 的形式提供。
  • 生产者向 Rio 发送事件。

在托管监听和转发这些事情后，生产者和消费者的实现变得简单, 它们都只需要发送或处理 HTTP 请求。

当然，会有潜在的单点问题和性能问题。Rio 加大了这两个问题的风险。 未来，Rio 主要会在易用性和优化性能上花精力去开发。