如何为多种输出类型设计 Netty Server
How to design Netty Server for multiple output type
与 http 一样，我们可以实现多个 url 来执行不同的操作。我们如何使用 Netty 服务器实现相同的目的？
更明确地说，我必须根据请求（也是 4 种类型）从 netty 服务器输出四种类型的 google protobuf。我应该为每种请求类型创建单独的 Netty 服务器，还是应该在同一管道中使用不同的处理程序？在后一种情况下，我必须至少有 4*3 = 12 个处理程序（对于每个请求类型，一个入站 protobuf 处理程序、一个出站 protobuf 处理程序和一个业务逻辑处理程序）。设计的好吗？
有几个不同的设计选项需要考虑不同的权衡。
- 每个 request/response 类型的服务器。 每个具有不同 request/response 类型的调用都由其自己的专用 Netty 服务器处理。像这样的细粒度服务器适合 microservices architecture，并且通常，您可能会继承该架构的优点和缺点。良好的构建和部署自动化是实现这一目标的先决条件。否则，您将需要额外的工作来构建、部署和配置多台服务器。
- 每个 request/response 类型的处理程序。 运行 每个 request/response 类型具有不同处理程序的单个 Netty 服务器。多个处理程序彼此解耦，这可以使长期维护更容易。如果您想要跨所有处理程序的一些通用逻辑，例如常见的错误处理，您可以考虑设置自己的抽象基础 class 实现
ChannelHandler。然后，所有特定的处理程序都会 subclass 那个。正如您所指出的，它有一个潜在的缺点，即它会导致许多 classes 的激增，这可能会损害不熟悉代码库的人的可读性。
- 多个 request/response 类型的单个处理程序。 您可以为所有 request/response 类型编写单个 Netty 处理程序。在内部，它需要对请求类型进行内省（使用
instanceof 或请求对象中的某种类型描述符字段），然后分派到该请求的适当逻辑。这符合 front controller 模式。与多个处理程序相比，这避免了多个 classes 的扩散。潜在的缺点是分派逻辑可以变成整体嵌套 if-else 或 switch-case 结构，每次添加新的 request/response 类型时都必须小心维护。
根据我的经验，选项 2 和选项 3 都取得了成功，具体取决于 API 中不同 request/response 类型的数量。对于相对较小的数量，单个处理程序可以很好地工作，并且调度逻辑不会变得太麻烦而无法维护。对于广泛的 API 足迹，将其组织到不同的处理程序中开始变得有帮助。也可以有仍然使用多个处理程序的混合方法，但每个处理程序涵盖一组多个相关的 request/response 类型。
如果您能够熟练掌握构建和部署工具，那么像选项 1 这样的微服务架构可能会很有吸引力。如果您不能投资于该工具，那么它可能只会产生大量额外的工作。
与 http 一样，我们可以实现多个 url 来执行不同的操作。我们如何使用 Netty 服务器实现相同的目的？ 更明确地说，我必须根据请求（也是 4 种类型）从 netty 服务器输出四种类型的 google protobuf。我应该为每种请求类型创建单独的 Netty 服务器，还是应该在同一管道中使用不同的处理程序？在后一种情况下，我必须至少有 4*3 = 12 个处理程序（对于每个请求类型，一个入站 protobuf 处理程序、一个出站 protobuf 处理程序和一个业务逻辑处理程序）。设计的好吗？
有几个不同的设计选项需要考虑不同的权衡。
- 每个 request/response 类型的服务器。 每个具有不同 request/response 类型的调用都由其自己的专用 Netty 服务器处理。像这样的细粒度服务器适合 microservices architecture，并且通常，您可能会继承该架构的优点和缺点。良好的构建和部署自动化是实现这一目标的先决条件。否则，您将需要额外的工作来构建、部署和配置多台服务器。
- 每个 request/response 类型的处理程序。 运行 每个 request/response 类型具有不同处理程序的单个 Netty 服务器。多个处理程序彼此解耦，这可以使长期维护更容易。如果您想要跨所有处理程序的一些通用逻辑，例如常见的错误处理，您可以考虑设置自己的抽象基础 class 实现
ChannelHandler。然后，所有特定的处理程序都会 subclass 那个。正如您所指出的，它有一个潜在的缺点，即它会导致许多 classes 的激增，这可能会损害不熟悉代码库的人的可读性。 - 多个 request/response 类型的单个处理程序。 您可以为所有 request/response 类型编写单个 Netty 处理程序。在内部，它需要对请求类型进行内省（使用
instanceof或请求对象中的某种类型描述符字段），然后分派到该请求的适当逻辑。这符合 front controller 模式。与多个处理程序相比，这避免了多个 classes 的扩散。潜在的缺点是分派逻辑可以变成整体嵌套if-else或switch-case结构，每次添加新的 request/response 类型时都必须小心维护。
根据我的经验，选项 2 和选项 3 都取得了成功，具体取决于 API 中不同 request/response 类型的数量。对于相对较小的数量，单个处理程序可以很好地工作，并且调度逻辑不会变得太麻烦而无法维护。对于广泛的 API 足迹，将其组织到不同的处理程序中开始变得有帮助。也可以有仍然使用多个处理程序的混合方法，但每个处理程序涵盖一组多个相关的 request/response 类型。
如果您能够熟练掌握构建和部署工具，那么像选项 1 这样的微服务架构可能会很有吸引力。如果您不能投资于该工具，那么它可能只会产生大量额外的工作。