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 回答