Границы между службами, фильтрами и кодеками в Finagle

Finagle и Netty устроены совершенно по-разному.

Сервисы, фильтры и кодеки на самом деле являются совершенно ортогональными понятиями. Позвольте мне попробовать и объяснить. Как пользователь -- т.е. не разработчик кодека - вам нужно знать только о службах и фильтрах.

Во-первых, кодек отвечает за преобразование потока байтов в дискретные запросы или ответы. Например, кодек HTTP считывает поток байтов и создает объекты HttpRequest или HttpResponse.

Service — это объект, который на запрос выдает Future ответа — это простая функция (и она действительно расширяет Function). Что интересно в сервисах, так это то, что они симметричны. Клиент использует службу, сервер предоставляет ее. Важная особенность служб заключается в том, что (1) они работают с отдельными запросами и ответами и (2) они сопоставляют запросы с ответами — все это подразумевается их типом. Вот почему мы называем finagle системой «RPC» — пары запрос/ответ являются определяющей характеристикой RPC.

Итак, у нас есть Службы, но полезно и важно изменять поведение Службы независимо от самой службы. Например, мы можем захотеть предоставить функцию тайм-аута или повторных попыток. Это то, что делают Filter. Они предоставляют независимый от службы метод изменения поведения Службы. Это расширенная модульность и повторное использование. Например, тайм-ауты в finagle реализованы как фильтр и могут применяться к любому сервису.

Подробнее о сервисах и фильтрах можно узнать в школе Scala.

*

Итак, давайте сравним это с обработчиками Netty. Это общие обработчики событий, которые также могут быть объединены в стек. Вы можете делать с ними много похожих вещей, но базовая модель представляет собой поток событий, присоединенных к соединению. Это усложняет написание универсальных модулей (например, для реализации повторных попыток, тайм-аутов, накопления сбоев, трассировки, отчетов об исключениях и т. д.), потому что вы не можете делать много предположений о конвейере, с которым работаете.

Конвейеры Netty также объединяют реализацию протокола с обработчиками приложений. Finagle четко разделяет их, и благодаря этому улучшается модульность.

Netty — прекрасный набор абстракций, но для RPC-серверов finagle предлагает большую модульность и компонуемость.

*

Подводя грубый итог, можно сказать, что Netty «ориентирована на поток», а finagle — «ориентирована на сервис». Это важное отличие, которое позволяет нам реализовывать надежные сервисы RPC по модульному принципу. Например, пул соединений и балансировка нагрузки — крайне важные для RPC-клиентов — естественным образом выпадают из сервисной модели, но не вписываются в потоковую модель.

Я не думаю, что это должно быть решение между кодеком или фильтром. Кодеки скорее будут завернуты в фильтры.

Что касается логики принятия решений, то, где ее разместить, будет зависеть от решений, которые необходимо принять. Бизнес-решения должны согласовываться с вашей бизнес-логикой, в то время как некоторые решения, такие как маршрутизация, балансировка нагрузки, определенные типы контроля доступа и т. д., могут хорошо подойти в качестве фильтра.

Услуги обычно находятся в конце очереди, и Finagle со своими фильтрами доставит вас туда.

Не знаю, есть ли в этом смысл?

Просто отойдите на мгновение от технических деталей и посмотрите на логику. Что за что должно отвечать, а потом получить технологию под свой дизайн. Не сгибайте свой дизайн слишком сильно, чтобы он соответствовал технологии.

Кстати, я реализовал шлюзовой сервер поверх Finagle, и должен сказать: с этой библиотекой приятно работать.

Я не знаю, что вы пытаетесь создать, но взгляните также на возможные альтернативы: Spray, Blueeyes, Unfiltered, Play-Mini и т. д. Это может помочь вам лучше понять, что куда идет.