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

在http中，我们可以实现多个URL来执行不同的操作。我们如何使用Netty服务器实现同样的目标？

---

更明确地说，我必须根据请求从netty服务器输出四种类型的google protobuf（也有四种类型）。我应该为每种请求类型创建单独的Netty服务器，还是在同一管道中有不同的处理程序？在后一种情况下，我必须有至少4*3=12个处理程序（对于每个请求类型，一个入站protobuf处理程序、一个出站protobuf处理程序和一个业务逻辑处理程序）。这是一个好的设计吗？

< P>有几种不同的设计方案，考虑不同的权衡。

每个请求/响应类型的服务器。每个具有不同请求/响应类型的调用都由其自己的专用Netty服务器处理。像这样的细粒度服务器将适合一个新的体系结构，一般来说，您可能会继承该体系结构的优点和缺点。良好的构建和部署自动化是成功的先决条件。否则，您将需要额外的工作来构建、部署和配置多个服务器

每个请求/响应类型的处理程序。运行单个Netty服务器，每个请求/响应类型具有不同的处理程序。多个处理程序彼此分离，这使得长期维护更加容易。如果您希望在所有处理程序中都需要一些公共逻辑，比如常见错误处理，可以考虑设置自己的抽象基类。然后，所有特定的处理程序都会将其子类化。正如您所注意到的，它有一个潜在的缺点，即它会导致许多类的激增，这可能会损害不熟悉代码库的人的可读性

多个请求/响应类型的单个处理程序。您可以为所有请求/响应类型编写一个Netty处理程序。在内部，它需要对请求类型进行内省（使用请求对象中的

instanceof

或某种类型的类型描述符字段），然后为该请求分配适当的逻辑。这正符合这种模式。与多个处理程序相比，这避免了多个类的扩散。潜在的缺点是，分派逻辑可能会变成一个单片嵌套的

if-else

或

开关盒

结构，每次添加新的请求/响应类型时都必须小心维护

根据我的经验，我已经成功地使用了选项2和3，这取决于API中不同请求/响应类型的数量。对于相对较小的数量，单个处理程序可以很好地工作，并且分派逻辑不会变得太麻烦而无法维护。对于广泛的API封装，将其组织成不同的处理程序开始变得很有帮助。也可以有仍然使用多个处理程序的混合方法，但每个处理程序都包含一组多个相关的请求/响应类型

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