处理微服务请求的设计模式答案

【问题标题】：Design Pattern for handling Microservices requests处理微服务请求的设计模式
【发布时间】：2017-11-23 03:19:17
【问题描述】：

我有一个基于微服务的应用程序。我有一个接收 HTTP 请求的代理/网关 API。然后我有另外两个服务服务 A 和服务 B。当 Broker API 接收到消息时，它使用 RabbitMQ 将其发送到服务。然后在每个人中，我应该根据消息处理它并以不同的方式处理它（执行不同的操作）。

这是我目前处理消息的方式：

服务A

    public string ProcessAsync(Message message)
    {

        switch (message.EventCode)
        {
            case "context 1":
                return action1();
            case "context 2":
                return action2();
            case "context 3":
                return action3();
            case "context 4":
                return action4();
            case "context 5":
                return action5();
            default:
                throw new Exception("Unknown message event code!");
        }
    }

如果我有不超过 5 到 10 种不同的消息类型，则使用 switch 语句是有意义的。但在我的应用程序中，我有 30 个。编写这么大的条件语句很难看，而且维护起来也不同。我正在寻找一种能够从应用程序中消除此问题的设计模式。你有什么想法？您如何看待状态模式？

【问题讨论】：

sourcemaking.com/refactoring/…

标签： design-patterns asp.net-core rabbitmq microservices

【解决方案1】：

是“网关路由模式” 当它收到请求时，API 网关会查询一个路由映射，该映射指定将请求路由到哪个服务。例如，路由映射可能会将 HTTP 方法和路径映射到服务的 HTTP URL。该功能与 NGINX 等 Web 服务器提供的反向代理功能相同。

[1]https://medium.com/@madhukaudantha/microservice-architecture-and-design-patterns-for-microservices-e0e5013fd58a

【讨论】：

【解决方案2】：

您可以尝试CQRS 架构。

在 CQRS 中，每个命令都只有一个处理程序；作为组件，您需要有一个CommandDispatcher，它使用CommandSubscriber 将每个命令分派给正确的处理程序。每条命令执行后，都会产生一个或多个事件；每个事件也被分派给一个或多个事件处理程序。

如果每条消息都具有相同的类Message，那么您的CommandSubscriber 应该基于message.EventCode 注册命令处理程序。如果每条消息都有不同的类（即Message 是interface），那么CommandSubscriber 应该根据消息类注册命令处理程序。这种架构风格尊重Open-close principle，而您的基于开关的风格却没有。

【讨论】：