c# - WebApi 中的微服务设计部分

标签 c# design-patterns architecture microservices cqrs

您好我正在尝试创建一个项目骨架使用 CQRS模式和一些外部服务。下面是解决方案的结构。

  • WebAPI
  • 查询处理程序
  • 命令处理程序
  • 仓库
  • ApiGateways(这里是微服务调用的接口(interface)和实现)

  • 我们希望 Controller 保持纤薄。所以我们使用查询处理程序和命令处理程序来处理各自的操作。

    enter image description here
    但是,我们使用外部微服务来获取我们从查询处理程序调用它们的数据。
    所有的 http clinet 构建和调用都将在其中抽象出来。响应将转换为 View 模型并将其传递回 Query 处理程序。

    我们将其命名为 ApiGateways .但它不是由多个服务组成的。
    我们如何在我们的解决方案中调用这部分?代理什么的?瘦 Controller 和微服务架构的任何好例子

    最佳答案

    We name it as API Gateways. But it is not composed from multiple services. How do we call this part in our solution? Proxy or something? Any good example for thin controllers and microservice architecture



    假设:

    从您附加的图像中,我看到命令处理程序和查询处理程序正在调用“外部/微服务”。我猜这个“外部/微服务”是指您正在从当前的微服务处理程序(命令和查询)调用另一个微服务。这些“外部/微服务”是您架构的一部分,并部署在同一个集群上,而不是一些仅公开公共(public) API 的外部系统。 ?
    如果这是正确的,我将尝试根据这个假设来回答。
    API Gateway在这种情况下,API Gateway 的概念可能会产生误导。与您在这里尝试做的事情不同。

    API Gateway根据定义:

    引自 here :

    An API Gateway is a server that is the single entry point into the system. It is similar to the Facade pattern from object-oriented design. The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client. It might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling.



    您实际上正在尝试做的是从您的一个微服务 A 另一个微服务 B 从您的命令或查询处理程序调用。这是一个内部微服务通信,不应该通过 API Gateway 完成。因为这将是外部调用的方法。例如,“外部调用”是指前端应用程序 API或公开API试图调用你的微服务的调用。在这种情况下,您将使用 API Gateway s。

    该组件的更好名称是“CrossMicroServiceGateway”或“InterMicroServiceGateway”;如果你想拥有完整的CQRS你可以像直接调用其他命令或查询一样拥有它,然后你可以使用类似“QueryGate”或“CommandGate”或类似的东西。

    其他建议:

    WebApi

    Query Handlers

    Command Handlers

    Repository

    API Gateways ( here is the interfaces and implementation of microservice calls)



    这听起来很合理,除了 API Gateway我上面描述的。当然,根据我对您项目的有限信息,我很难判断。为了给你一个更准确的建议,我需要知道你是否使用 DDD或不?您如何使用CQRS和其他信息?

    However, we use an external microservices to get the data we are calling them from Query handlers. All the HTTP client construction and calls will be abstracted in them. The response will be converted to a view model and pass it back to Query handler.



    您可以提取所有这些通过 HTTP 处理跨微服务通信的代码/逻辑或其他协议(protocol),处理一般响应,类似于某些核心库,并将其作为一个包包含到您的每个微服务中。这样,您将为所有微服务重用该解决方案。您可以扩展它并将所有与域无关的核心内容(如数据访问或存储库基类、围绕 HTTP 的包装器、单元测试基础架构设置等)添加到该共享库或其他共享库。这样,您的微服务将只关注它应该做的域部分。

    关于c# - WebApi 中的微服务设计部分,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/61456105/

    相关文章:

    c# - 如何读取扫描支票的支票号码和银行路由号码

    c# - 哪里是开始在网格上编写随机路径的好地方?

    design-patterns - 复制对象有哪些好的设计模式?

    android - 项目由几个项目组成

    java - 对于所提供的用例,微服务和单一方法有什么区别

    c# - 具有空值 C# 的 String.Format

    c# - 如何使用 Roslyn 在 C# 中获取 lambda 类型?

    c# - MVC5 + EF + UOW + 服务层在哪里调用 SaveChanges() 并避免多次访问 DB?

    python - python中不同参数类型的方法重载

    c# - 将业务层的通用查询转换为数据访问层