Límites entre servicios, filtros y códecs en Finagle

Question

Netty, que se usa dentro de Finagle, utiliza una cartera de "manejadores" para procesar secuencialmente dentro y fuera de datos encuadernados. Los ejemplos de Netty, y las bibliotecas incluidas, muestran varios manejadores usados ​​para cosas tales como autenticación, códecs de protocolo y la lógica comercial real del servicio.

Parece que Finagle adopta el concepto de controlador y, en su lugar, ofrece directamente codecs, filtros y servicios a usuarios de API. Si bien estos tienen distintas firmas, los nuevos usuarios de Finagle se quedan con la tarea de decidir qué usar para implementar cada parte de su servidor global. En lugar de simplemente decidir dónde dividir la cadena en varios manipuladores Netty, ahora necesitan decidir qué parte debe ser parte de un códec, frente a cualquier filtro, frente al servicio singular al final de la cadena. En resumen, aunque Finagle es una biblioteca de nivel superior a Netty, y debería facilitar la tarea de crear el servicio, el usuario de la API puede tener más opciones para hacer.

¿Cuáles son los puntos clave de decisión, y ventajas y desventajas, para colocar una porción particular de la secuencia de procesamiento en un códec frente a un filtro frente al servicio singular? Si existe la posibilidad de que la tubería pueda extenderse más, ¿la lógica del servicio debe colocarse en un filtro, con un servicio "noop" al final de la tubería? Dada la flexibilidad en el pedido de filtros (como controladores en la línea de producción), frente al códec singular en un extremo y el servicio en el otro extremo, ¿por qué no debería ser "todo" un filtro?

Answer 1

Finagle y Netty están estructurados de manera bastante diferente.

Los servicios, filtros y códecs en realidad son conceptos bastante ortogonales. Déjame intentar & explicar. Como usuario, es decir. no es un implementador de un códec; solo debe conocer los servicios y filtros.

En primer lugar, un códec es responsable de convertir una secuencia de bytes en solicitudes o respuestas discretas. Por ejemplo, el códec HTTP lee el bytestream y produce objetos HttpRequest o HttpResponse.

A Service es un objeto que, dada una petición, produce una Future de respuesta - que es una función simple (y de hecho se extiende Function).Lo interesante de los servicios es que son simétricos. Un cliente usa un servicio, un servidor proporciona uno. Lo importante de los servicios es que (1) operan sobre solicitudes y respuestas discretas, y (2) hacen coincidir las solicitudes con las respuestas, todo lo cual está implícito en su tipo. Es por eso que llamamos a finagle un sistema "RPC": los pares de solicitud/respuesta son la característica que define a los RPC.

Entonces, tenemos Servicios, pero es útil e importante modificar el comportamiento del Servicio independientemente del servicio en sí. Por ejemplo, es posible que deseemos proporcionar funcionalidad de tiempo de espera o reintentos. Esto es lo que Filter s hacen. Proporcionan un servicio independiente del método para modificar el comportamiento del Servicio. Esta modularidad y reutilización mejoradas. Por ejemplo, los tiempos de espera en finagle se implementan como un filtro y se pueden aplicar a cualquier servicio.

Puede encontrar más detalles sobre los servicios & filtros en el Scala School.

*

Por lo tanto, quiero contrastar a los manipuladores de Netty. Estos son manejadores de eventos genéricos, que también son apilables. Puede hacer muchas cosas similares con ellos, pero el modelo subyacente es un flujo de eventos que están conectados a una conexión. Esto hace que sea más difícil escribir módulos genéricos (por ejemplo, para implementar reintentos, tiempos de espera, acumulación de errores, rastreo, informes de excepción, etc.) porque no puede hacer muchas suposiciones sobre la tubería con la que está operando.

Las tuberías de Netty también combinan la implementación del protocolo con los manejadores de aplicaciones. Finagle separa limpiamente los dos, y la modularidad se ve reforzada por eso.

Netty es un maravilloso conjunto de abstracciones, pero para los servidores RPC, finagle ofrece una mayor modularidad y capacidad de compilación.

*

Resumiendo crudamente se podría decir que es Netty “corriente orientada”, mientras que finagle está “orientado al servicio”. Esta es una distinción importante, y es lo que nos permite implementar servicios de RPC robustos de manera modular. Por ejemplo, la agrupación de conexiones y el equilibrio de carga, que son crucialmente importantes para los clientes de RPC, caen naturalmente del modelo de servicio, pero no se ajustan al modelo de flujo.

Answer 2

No creo que deba ser una decisión entre el códec o el filtro. Los códecs prefieren envolverse en filtros.

En cuanto a la lógica de decisión, dónde ubicarla, dependería de las decisiones que se tengan que tomar. Las decisiones empresariales deben ir con la lógica de su negocio, mientras que algunas decisiones como el enrutamiento, el equilibrio de carga, ciertos tipos de control de acceso, etc., podrían encajar bien como un filtro.

Los servicios suelen estar al final de la fila, y Finagle con sus filtros te llevará hasta allí.

¿No sabes si esto tiene sentido?

Solo aléjese de los detalles técnicos por un momento y observe la lógica. Lo que debería ser responsable de qué, y luego conseguir que la tecnología se ajuste a su diseño. No doble demasiado su diseño para adaptarse a la tecnología.

Por cierto, he implementado un servidor de puerta de enlace en la parte superior de Finagle, y debo decir: es una buena biblioteca para trabajar.

No sé lo que está intentando construir, pero eche un vistazo a posibles alternativas también: Spray, Blueeyes, Sin filtro, Play-Mini, etc. Puede ayudarlo a obtener una mejor comprensión de lo que ocurre.