一直以来，篠原俊一（Shunichi Shinohara）和加藤究（Kiwamu Kato）在致力于将可靠消息传送（Reliable Messaging）引入 Ruby。他们以先前设计基于 Java 的高容量消息传送框架的经验为基础，通过他们自主的 API 和协议的项目，试图将这个努力变为现实。 AP4R 这个项目的名称是 Asynchronous Processing for Ruby 的缩写，意即“Ruby 的异步处理”。该项目是一个异步可靠消息处理的实现，提供消息队列和消息分派的功能。篠原和加藤在日本 Ruby 会议 2007（RubyKaigi 2007）上进行了演讲（PDF 幻灯片），介绍了他们的 API，并强调其核心设计哲学：鲁棒性和轻量级。
这个项目问世仅仅一年，但已经能支持：
- 不管业务逻辑是非同步调用还是同步调用的，都可以以简单的 Web 应用或者 Ruby 代码的形式实现；
- RBMS（MySQL）或者基于文件的消息持久化能力；
- 支持在单个或者多个服务器上跨多个 AP4R 进程的负载平衡；
- 对以下多个协议的支持：XML-RPC、SOAP 和 HTTP POST 等等。
先前，篠原和加藤已经实现过他们自己的基于 Java 的 API 和协议（称为 RtFA），这项成果被用于一个包含 100 台服务器的大型应用中，该应用每天处理超过 1 亿条消息。篠原和加藤声称，他们已经改进了先前在 AP4R 上的工作，并且也在易用性上花了很大工夫。AP4R 所附带的文档非常完整详尽。
要将 AP4R 整合进 Rails，典型流程如下：
- 客户端（如 Web 浏览器）向 Web 服务器（Apache 和 Lighttpd 等）发送请求；（
- Rails 应用通过 mod_proxy 或者其它被同步地在 mongrel 上执行；
- Rails 应用通过 AP4R 的 API 发送消息，并可以在随后立刻响应给客户端；
- AP4R 将消息放入队列，并且异步地将其请求到 Web 服务器；
- 异步的业务逻辑（以常见的 Rails Action 的形式实现）被执行。
0.3.x 关注的是后台服务化（Daemonization）、URL 重写过滤器（URL-rewrite filter）、DLQ / SAF 恢复，以及对将 Stomp 和 HTTP 作为底层协议的支持。今后的版本将包含对监控和管理的支持（如线程状态和 Web 前端）、与 Cacti 和 Nagios 等的协作、多进程、动态可配置性、自动恢复和阻塞队列等等。
暂无签名
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论