如何设计多输出类型的Netty服务器
问题描述:
正如在http中我们可以实现多个url来执行不同的操作。我们如何用Netty Server实现同样的功能? 更明确地说,我必须根据请求(也是4种类型)从netty服务器输出四种类型的google protobuf。我应该为每个请求类型创建单独的Netty服务器,还是应该在同一个管道中使用不同的处理程序?在后面的情况下,我将不得不拥有至少4 * 3 = 12个处理程序(对于每个请求类型,一个入站protobuf处理程序,一个出站protobuf处理程序和一个业务逻辑处理程序)。这是一个好的设计吗?如何设计多输出类型的Netty服务器
答
有几种不同的设计方案需要考虑不同的权衡。
- 服务器每个请求/响应类型。具有不同请求/响应类型的每个调用都由其专用的Netty服务器处理。像这样的细粒度服务器将适合microservices architecture,并且一般来说,您可能会继承该架构的优点和缺点。良好的构建和部署自动化是取得成功的先决条件。否则,您将最终需要额外的工作,部署和配置多台服务器。
-
每个请求/响应类型的处理程序。为每个请求/响应类型运行带有不同处理程序的单个Netty服务器。多个处理程序彼此分离,这可以使长期维护更容易。如果您希望在所有处理程序中使用一些通用逻辑(例如常见错误处理),则可以考虑设置自己的抽象基类实现
ChannelHandler
。然后,所有特定的处理程序都将继承该类。正如你所指出的,它有一个潜在的缺点,它导致许多类的泛滥,这可能会损害不熟悉代码库的人的可读性。 -
多个请求/响应类型的单个处理程序。您可以为所有请求/响应类型编写单个Netty处理程序。在内部,它需要对请求类型进行内省(使用
instanceof
或请求对象中的某种类型的描述符字段),然后分派给该请求的适当逻辑。这符合front controller模式。与多个处理程序相比,这避免了多个类的扩散。潜在的缺点是调度逻辑可以变成嵌套的嵌套结构,每次添加新的请求/响应类型时都必须仔细维护。
根据我的经验,根据API中不同请求/响应类型的数量,我已经成功使用了选项2和3。对于一个相对较小的数量,单个处理程序运行良好,并且调度逻辑不会变得太麻烦以至于无法维护。对于广泛的API脚本,它将变得非常有用,可以将它组织到不同的处理程序中。还有一些混合方法仍然使用多个处理程序,但每个处理程序都覆盖一组多个相关的请求/响应类型。
如果您可以获得构建和部署工具的复杂性,像选项1这样的微服务体系结构可能会很有吸引力。如果你不能在这个工具上投资,那么它可能会产生很多额外的工作。