scala - Finagle 和 Akka，为什么不一起使用呢？

Question

我在实践中没有使用过 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 方式。

Answer 1

你是对的，服务发现和服务实现是正交的问题，我可以按照你关于前者使用 Finagle 和后者使用 Akka 的论点。原则上，您可以将两者一起使用，而无需寻求 future 的大统一，因为您只需将服务的回复在消息中发送回请求的 Actor，即您需要添加自己的小“pipeTo ” 在 Twitter future 之上的模式。