Grenzen zwischen Diensten, Filtern und Codecs in Finagle

Netty, das in Finagle verwendet wird, verwendet eine Pipeline von "Handlern", um eingehende und ausgehende Daten nacheinander zu verarbeiten. Einige Beispiele und enthaltene Bibliotheken zeigen verschiedene Handler, die für Dinge wie Authentifizierung, Protokollcodecs und die eigentliche Geschäftslogik des Dienstes verwendet werden.

Finagle scheint das Handler-Konzept zu übernehmen und bietet stattdessen API-Benutzern Codecs, Filter und Dienste direkt an. Während diese unterschiedliche Signaturen aufweisen, müssen neue Benutzer von Finagle entscheiden, welche verwendet werden sollen, um jeden Teil ihres gesamten Servers zu implementieren. Anstatt nur zu entscheiden, wo die Kette in verschiedene Netty-Handler aufgeteilt werden soll, müssen sie jetzt entscheiden, welcher Abschnitt Teil eines Codecs sein soll, und zwar im Vergleich zu allen Filtern und dem singulären Dienst am Ende der Kette. Obwohl Finagle eine Bibliothek auf höherer Ebene als Netty ist und die Erstellung des Dienstes erleichtern soll, muss der API-Benutzer möglicherweise eine größere Auswahl treffen.

Was sind die Hauptentscheidungspunkte und Vor- / Nachteile, um einen bestimmten Teil des Verarbeitungsstroms in einen Codec oder Filter oder in einen singulären Dienst zu übertragen? Wenn die Möglichkeit besteht, dass die Pipeline weiter erweitert werden könnte, sollte die Servicelogik stattdessen in einem Filter mit einem "noop" -Dienst am Ende der Pipeline platziert werden? Angesichts der Flexibilität bei der Bestellung von Filtern (als Handler in der Pipeline) im Vergleich zum singulären Codec auf der einen Seite und zum Dienst auf der anderen Seite, warum sollte "alles" nicht ein Filter sein?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage