【问题标题】:API Gateway Micro Service Lookup MethodAPI网关微服务查找方法
【发布时间】:2018-12-02 15:36:14
【问题描述】:

我已经构建了一个 API,其中包含一个 API 网关和两个微服务。 这两个微服务是产品和类别。

API 调用可以执行以下操作:

/v1/account/getAccount          // gets all accounts
/v1/account/getAccount/44       // gets account 44
/v1/categories/getCategory      // gets all categories
/v1/categories/getCategory/24   // gets category 24

帐户可以分类。获取具有相应类别的所有帐户的最佳方法是什么。

  1. 账户微服务调用类别微服务
  2. 网关同步调用账号微服务,然后循环这些账号调用分类微服务获取每个对应的分类
  3. 将第 2 点放入新的聚合微服务中
  4. 其他方式?

谢谢

【问题讨论】:

    标签: aggregate microservices api-design api-gateway


    【解决方案1】:

    简答:4 - 其他方式。

    您遇到的问题是您如何设计微服务的直接后果。通常(这当然取决于用例),让服务成为不同实体的“CRUD”服务,没有任何业务逻辑是一个坏主意

    为什么这是个坏主意?出于同样的原因,在单体应用中做同样的事情是个坏主意。它创建了依赖关系,使微服务相互依赖,最终产生了一个两全其美的解决方案(微服务和单体)。

    您要求获得所有类别的所有客户,这进一步强化了这一点。如果您以正确的方式设计服务,则无需从中提取完整的数据集。

    正确的做法:围绕业务功能而不是数据设计您的服务。如果客户和类别都需要一个功能,那么它们实际上应该在一起并形成具有适当功能的“微服务”(您实际上没有提到任何功能)。

    尽量将数据的不同方面分开,形成不同的功能,即使这意味着某些数据可能是多余的。

    【讨论】:

    • 有趣。所以我有一个类别浏览器和一个产品浏览器。产品浏览器可以显示它所在的类别,但类别浏览器不会显示产品。所以你是说这应该是两个不同的微服务,产品浏览器也会使用查找从数据库中获取类别?
    • 好吧,如果你“只是”想展示东西,为什么需要 HTTP API?为什么不直接渲染 HTML?我的意思是,做事是有原因的。如果没有理由分开事物,那就不要。如果没有理由拥有 HTTP API,那就不要。据我所知,如果您将两者放在一起,您的问题就会消失。
    猜你喜欢
    • 2019-04-06
    • 2020-07-24
    • 1970-01-01
    • 2018-01-25
    • 2019-10-27
    • 2019-10-01
    • 2018-01-06
    • 2016-01-14
    • 2020-11-23
    相关资源
    最近更新 更多