如何设计多输出类型的Netty服务器

Question

正如在http中我们可以实现多个url来执行不同的操作。我们如何用Netty Server实现同样的功能？ 更明确地说，我必须根据请求（也是4种类型）从netty服务器输出四种类型的google protobuf。我应该为每个请求类型创建单独的Netty服务器，还是应该在同一个管道中使用不同的处理程序？在后面的情况下，我将不得不拥有至少4 * 3 = 12个处理程序（对于每个请求类型，一个入站protobuf处理程序，一个出站protobuf处理程序和一个业务逻辑处理程序）。这是一个好的设计吗？

Answer 1

有几种不同的设计方案需要考虑不同的权衡。

1. 服务器每个请求/响应类型。具有不同请求/响应类型的每个调用都由其专用的Netty服务器处理。像这样的细粒度服务器将适合microservices architecture，并且一般来说，您可能会继承该架构的优点和缺点。良好的构建和部署自动化是取得成功的先决条件。否则，您将最终需要额外的工作，部署和配置多台服务器。
2. 每个请求/响应类型的处理程序。为每个请求/响应类型运行带有不同处理程序的单个Netty服务器。多个处理程序彼此分离，这可以使长期维护更容易。如果您希望在所有处理程序中使用一些通用逻辑（例如常见错误处理），则可以考虑设置自己的抽象基类实现ChannelHandler。然后，所有特定的处理程序都将继承该类。正如你所指出的，它有一个潜在的缺点，它导致许多类的泛滥，这可能会损害不熟悉代码库的人的可读性。
3. 多个请求/响应类型的单个处理程序。您可以为所有请求/响应类型编写单个Netty处理程序。在内部，它需要对请求类型进行内省（使用instanceof或请求对象中的某种类型的描述符字段），然后分派给该请求的适当逻辑。这符合front controller模式。与多个处理程序相比，这避免了多个类的扩散。潜在的缺点是调度逻辑可以变成嵌套的嵌套结构，每次添加新的请求/响应类型时都必须仔细维护。

根据我的经验，根据API中不同请求/响应类型的数量，我已经成功使用了选项2和3。对于一个相对较小的数量，单个处理程序运行良好，并且调度逻辑不会变得太麻烦以至于无法维护。对于广泛的API脚本，它将变得非常有用，可以将它组织到不同的处理程序中。还有一些混合方法仍然使用多个处理程序，但每个处理程序都覆盖一组多个相关的请求/响应类型。

如果您可以获得构建和部署工具的复杂性，像选项1这样的微服务体系结构可能会很有吸引力。如果你不能在这个工具上投资，那么它可能会产生很多额外的工作。