Finagle中服务，过滤器和编解码器之间的边界 [英] Boundaries between Services, Filters, and Codecs in Finagle

问题描述

Netty使用处理程序"管道来顺序处理入站和出站数据. Netty示例和包含的库显示了用于身份验证，协议编解码器以及服务的实际业务逻辑等各种处理程序.

Netty, which is used within Finagle, uses a pipeline of "handlers" to sequentially process in and out bound data. Netty examples, and included libraries, show various handlers used for things such as authentication, protocol codecs, and the actual business logic of the service.

Finagle似乎采用了处理程序的概念，而是直接向API用户提供编解码器，过滤器和服务.尽管这些签名具有不同的签名，但是Finagle的新用户要承担决定使用哪些任务来实现其整个服务器的每个部分的任务.现在，他们不仅仅是确定将链分成各种Netty处理程序的位置，还需要确定哪一部分应该是编解码器的一部分，而不是任何过滤器，而应该确定链末尾的单一服务.总而言之，尽管Finagle是比Netty更高级别的库，并且应该使构建服务的任务更加容易，但API用户可能有更多选择.

Finagle appears to take the handler concept, and instead directly offer API users codecs, filters, and services. While these have varying signatures, new users of Finagle are left with the tasks of deciding which to use in order to implement each portion of their overall server. Instead of merely deciding where to break the chain up into various Netty handlers, they now need to decide which portion should be part of a codec, versus any filters, versus the singular service at the end of the chain. In sum, although Finagle is a higher-level library than Netty, and should make the task of building the service easier, the API user may have more choices to make.

将处理流的特定部分放入编解码器，过滤器还是单个服务的关键决策点和优缺点是什么?如果存在进一步扩展管道的可能性，是否应将服务逻辑放入过滤器中，而在管道末端使用空"服务?考虑到排序过滤器(作为管道中的处理程序)的灵活性，而不是一端使用单一的编解码器，而另一端使用单一的编解码器，为什么所有内容"都不是过滤器?

What are the key decision points, and pros/cons, for placing a particular portion of the processing stream into a codec vs. a filter vs. the singular service? If there is a possibility that the pipeline could be extended further, should the service logic be placed into a filter instead, with a "noop" service at the end of the pipeline? Given the flexibility in ordering filters (as handlers in the pipeline), versus the singular codec on one end and service on the other end, why shouldn't "everything" be a filter?

推荐答案

Finagle和Netty的结构完全不同.

Finagle and Netty are structured quite differently.

服务，过滤器和编解码器实际上是非常正交的概念.让我尝试解释.作为用户-即不是编解码器的实现者，您只需要了解服务和过滤器即可.

Services, Filters, and codecs are actually quite orthogonal concepts. Let me try & explain. As a user -- ie. not an implementor of a codec -- you should only need to know about services and filters.

首先，编解码器负责将字节流转换为离散的请求或响应.例如，HTTP编解码器读取字节流，并生成HttpRequest或HttpResponse对象.

First, a codec is responsible for turning a stream of bytes into a discrete requests or responses. For example, the HTTP codec reads the bytestream, and produces HttpRequest or HttpResponse objects.

Service是一个对象，在收到请求后会产生Future答复-这是一个简单的函数(并且确实扩展了Function).服务的有趣之处在于它们是对称的.客户端使用一项服务，服务器提供一项.关于服务的重要一点是(1)它们对离散的请求和响应进行操作，并且(2)它们将请求与响应进行匹配-所有这些都由其类型隐含.这就是为什么我们称finagle为"RPC"系统-请求/响应对是RPC的定义特征.

A Service is an object that, given a request, produces a Future of a reply -- it’s a simple function (and indeed it extends Function). The interesting thing about services is that they are symmetric. A client uses a service, a server provides one. The important thing about services is that (1) they operate over discrete requests and responses, and (2) they match requests to responses - all of which is implied by its type. This is why we call finagle an "RPC" system - request/response pairs are the defining characteristic of RPCs.

因此，我们有服务，但是独立于服务本身修改服务行为 是有用且重要的.例如，我们可能想提供超时功能或重试.这就是Filter的作用.它们提供了一种与服务无关的方法，用于修改服务行为.这增强了模块化和重用性.例如，finagle中的超时被实现为过滤器，并且可以应用于任何服务.

So, we have Services, but it's useful and important to have modify Service behavior independently of the service itself. For example, we might want to provide timeout functionality, or retries. This is what Filters do. They provide a service independent method of modifying Service behavior. This enhanced modularity and reuse. For example, timeouts in finagle are implemented as a filter, and can be applied to any service.

您可以找到有关服务和服务的更多详细信息. Scala School 中的过滤器.

You can find more details about services & filters in the Scala School.

*

因此，我们将其与Netty的处理程序进行对比.这些是通用事件处理程序，也可以堆叠.您可以使用它们执行许多类似的操作，但是基础模型是连接到连接的事件的流.这使编写通用模块(例如，实现重试，超时，失败应计，跟踪，异常报告等)变得更加困难，因为您无法对正在使用的管道做出很多假设.

So, let’s contrast this to Netty’s handlers. These are generic event handlers, that are also stackable. You can do many similar things with them, but the underlying model is a stream of events that are attached to a connection. This makes it more difficult to write generic modules (eg. to implement retries, timeouts, failure accrual, tracing, exception reporting, etc..) because you cannot make many assumptions about the pipeline you’re operating with.

Netty管道还将协议实现与应用程序处理程序合并在一起. Finagle将两者干净利落地分开，因此，模块化得以增强.

Netty pipelines also conflate the protocol implementation with application handlers. Finagle cleanly separates the two, and modularity is enhanced because of it.

Netty是一组很棒的抽象，但是对于RPC服务器，finagle提供了更大的模块化和可组合性.

Netty is a wonderful set of abstractions, but for RPC servers, finagle offers greater modularity and composability.

*

粗略地总结一下，您可以说Netty是面向流的"，而finagle是面向服务的".这是一个重要的区别，这就是使我们能够以模块化方式实现可靠的RPC服务的原因.例如，对于RPC客户端至关重要的连接池和负载平衡，自然会从服务模型中消失，但不适用于流模型.

Summarizing crudely you could say that Netty is "stream oriented" while finagle is "service oriented". This is an important distinction, and it's what allows us to implement robust RPC services in a modular manner. For example, connection pooling and load balancing - crucially important to RPC clients - fall out naturally from the service model, but doesn’t fit in the stream model.

这篇关于Finagle中服务，过滤器和编解码器之间的边界的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！