Question

我们正在尝试设计特权用户可以创建业务的用例（特权使用是企业主）。每个企业可以拥有多个用户。为了满足此要求，我们正在考虑创建三个服务UserAPI，BusinessAPI和SubscriptionAPI。 UserAPI负责用户创建，删除，更新和查找同样的业务和订阅api将执行类似的操作。

/ API / V1 /用户/
/ api / v1 / business /
/ API / V1 /订阅/

对于我们想要为业务创建新用户的场景，我们考虑使用SubscriptionAPI

步骤如下：

是否存在业务“Business API客户端”将用于检查。
用户是否已存在给定的手机号码“用户API客户端”将用于检查。
如果上述条件通过，将调用“用户API客户端”进行用户创建。
上述步骤将提供用户ID
订阅表Subscription_id，business_id，user_id

请求

POST / api / v1 / subscription / business / {id}
Request Body UserVO

在SubscriptionAPI中重复UserVO - 这是正确的吗？

另请分享所描述的服务设计观点，可以做些什么改进。

Answer 1

如果您尝试使用3种不同的微服务，则可以使用Zuul代理。

为您的服务提供 Zuul作为API网关。它可以作为您所有服务的守门人。您可以定义自定义zuul过滤器，如前置，后置等。

我建议根据您的规范使用zuul预过滤器，然后在将请求路由到Subscription服务之前，请求其他两项服务获取所需的输入。

以下是供参考的链接：
https://spring.io/guides/gs/routing-and-filtering/

使用此配置路由请求：

zuul:
 prefix: /api/v1
 stripPrefix: false
proxy:
 stripMapping: false
 mapping: /api/v1
 addProxyHeaders: true
routes:
Business-API:
 path: /business/**
 url: http://localhost:8213
 stripPrefix: false
user-service:
path: /user/**
url: http://localhost:8212
stripPrefix: false

关于请求有效负载，您可以拥有所需的任何有效负载。请记住，所有服务必须可以独立部署。这意味着如果您要删除您的商家，则需要决定您的订阅操作。层叠可能会让你陷入困境。最好花更多的时间和思考整个领域。如果您的服务对彼此的依赖性太大，那么最好将它们集中为一个域。

我在这里解释了如何定义您的域名：
DB design for microservice architecture

微服务设计业务和用户RestAPI

1 个答案: