18

我在实践中没有使用过 Finagle 或 Akka,但我已经阅读了很多关于它们的内容。

Finagle 是一个 RPC 系统,而 Akka 是一个用于高并发应用程序的工具包,为什么所有人都将它们作为两种可能的解决方案进行比较,不能一起使用?我所做的所有搜索都建议使用其中一种,没有人建议将它们一起使用。

例如,Finagle 有一种非常有趣的方式来通过 thrift 及其 IDL 定义端点。使用这个 IDL,我们可以定义一个自定义端点,并通过 scooge 或任何代码生成工具,可以毫不费力地获得服务。此外,还创建了一个连接到此服务的客户端,并自动解决了许多常见的客户端问题(重新连接、超时、重试、负载平衡、连接池……)。

相反,Akka 解决了很多并发问题,并且它的扩展性非常好,没有手动控制线程的所有复杂性。

总而言之,为什么不一起使用它们呢?:

  • Finagle + Thrift(及其 IDL):它促进了服务设计和开发以及部署(包括易于横向扩展)。
  • Akka:它通过其 Actor 系统使用所有服务器功能,并且如果我更改服务器属性(例如,如果它部署在 EC2 上并且我将我的节点从 m1.small 转换为 m1.large),它的扩展性非常好。

你怎么看?

注意:假设映射 Futures 和 Promises 的问题已经解决,以及 FuturePools 和 ExecutionContexts 之间的不匹配问题。该模式是将 Finagle 转换为使用 Futures 的 scala 方式。

4

1 回答 1

13

You are right in that service discovery and service implementation are orthogonal concerns, and I can follow your argument about using Finagle for the former and Akka for the latter. You could in principle use the two together without seeking a grand unification of futures, since you only need to send the service’s reply back to the requesting Actor in a message, i.e. you would need to add your own little “<a href="https://github.com/akka/akka/blob/v2.2.3/akka-actor/src/main/scala/akka/pattern/PipeToSupport.scala" rel="noreferrer">pipeTo” pattern on top of Twitter futures.

于 2013-12-02T06:50:36.010 回答