如何为多种输出类型设计 Netty Server

Question

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

Answer 1

有几个不同的设计选项需要考虑不同的权衡。

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

根据我的经验，我在选项 2 和 3 上都取得了成功，具体取决于 API 中不同请求/响应类型的数量。对于相对较小的数量，单个处理程序可以很好地工作，并且调度逻辑不会变得过于繁琐而无法维护。对于广泛的 API 足迹，将其组织成不同的处理程序开始变得有帮助。也可能存在仍然使用多个处理程序的混合方法，但每个处理程序涵盖一组多个相关的请求/响应类型。

如果您能够获得构建和部署工具的复杂性，那么类似于选项 1 的微服务架构可能会很有吸引力。但是，如果您不能在该工具上进行投资，那么它可能只会产生大量额外的工作。