Finagle 中使用的 Netty 使用“处理程序”管道来顺序处理输入和输出数据。Netty 示例和包含的库显示了用于身份验证、协议编解码器和服务的实际业务逻辑等各种处理程序。
Finagle 似乎采用了处理程序的概念，而是直接为 API 用户提供编解码器、过滤器和服务。虽然这些具有不同的签名，但 Finagle 的新用户需要决定使用哪个来实现其整个服务器的每个部分。他们现在需要决定哪个部分应该是编解码器的一部分，而不是任何过滤器，还是链末端的单一服务，而不是仅仅决定在哪里将链分解为各种 Netty 处理程序。总而言之，虽然 Finagle 是一个比 Netty 更高级别的库，并且应该使构建服务的任务更容易，但 API 用户可能有更多的选择。
将处理流的特定部分放入编解码器与过滤器与单一服务的关键决策点和优点/缺点是什么？如果管道有可能进一步扩展，是否应该将服务逻辑放入过滤器中，在管道末端使用“noop”服务？鉴于排序过滤器（作为管道中的处理程序）的灵活性，而不是一端的单一编解码器和另一端的服务，为什么“一切”不应该是一个过滤器？
Finagle 和 Netty 的结构完全不同。
服务、过滤器和编解码器实际上是非常正交的概念。让我试着解释一下。作为用户——即。不是编解码器的实现者——您应该只需要了解服务和过滤器。
首先，编解码器负责将字节流转换为离散的请求或响应。例如，HTTP 编解码器读取字节流，并生成HttpRequest或HttpResponse对象。
AService是一个对象，给定一个请求，它会产生Future一个回复——它是一个简单的函数（实际上它是 extends Function）。服务的有趣之处在于它们是对称的。客户端使用服务，服务器提供服务。服务的重要之处在于（1）它们对离散的请求和响应进行操作，以及（2）它们将请求与响应相匹配——所有这些都隐含在其类型中。这就是我们将 finagle 称为“RPC”系统的原因——请求/响应对是 RPC 的定义特征。
所以，我们有服务，但独立于服务本身修改服务行为是有用且重要的。例如，我们可能想要提供超时功能或重试。这就是我们Filter要做的。它们提供了一种独立于服务的方法来修改服务行为。这增强了模块化和重用性。例如，finagle 中的超时被实现为过滤器，并且可以应用于任何服务。
您可以在Scala School中找到有关服务和过滤器的更多详细信息。
*
因此，让我们将其与 Netty 的处理程序进行对比。这些是通用事件处理程序，也是可堆叠的。您可以用它们做许多类似的事情，但底层模型是附加到连接的事件流。这使得编写通用模块变得更加困难（例如，实现重试、超时、故障累积、跟踪、异常报告等），因为您无法对正在使用的管道做出很多假设。
Netty 管道还将协议实现与应用程序处理程序混为一谈。Finagle 将两者完全分开，并因此增强了模块化。
Netty 是一组很棒的抽象，但是对于 RPC 服务器，finagle 提供了更大的模块化和可组合性。
*
粗略地总结一下，你可以说 Netty 是“面向流的”，而 finagle 是“面向服务的”。这是一个重要的区别，它使我们能够以模块化的方式实现健壮的 RPC 服务。例如，连接池和负载平衡（对 RPC 客户端至关重要）自然会从服务模型中分离出来，但不适合流模型。
我认为这不应该是编解码器或过滤器之间的决定。编解码器宁愿被包裹在过滤器中。
至于决策逻辑，放置它的位置将取决于必须做出的决策。业务决策应该符合您的业务逻辑，而路由、负载平衡、某些类型的访问控制等某些决策可以很好地适应过滤器。
服务通常位于线路的末端，Finagle 及其过滤器将带您到达那里。
不知道这是否有意义？
暂时离开技术细节，看看逻辑。什么应该负责什么，然后让技术适合你的设计。不要过度弯曲您的设计以适应技术。
顺便说一句，我在 Finagle 上实现了一个网关服务器，我必须说：这是一个很好的库。
我不知道您要构建什么，但也可以看看可能的替代方案：Spray、Blueeyes、Unfiltered、Play-Mini 等。它可能会帮助您更好地了解什么去哪里。