AWS ALB 背后的微服务（ish）设置中的健康检查路由组织
Health check route organisation in microservice(ish) setup behind AWS ALB
ALB背后的多个服务之间如何命名健康检查路由？
我正在将我的 API 和数据库迁移到 AWS。在移动之前，我将单体式 REST API 拆分为四个服务：
- public API（连接到哪些应用程序和网站）
- admin API（用于管理网站）
- 消息API（用于与应用程序实时通信的网络套接字服务器）
- workers（基于队列的任务处理器）
我现在正在尝试找出一个好的路线组织方式。首先创建了两个子域，api.mydomain.com 和 www.mydomain.com.
我将 api 子域定向到我的 ALB，它仅根据路径路由流量，如下所示：
- "/sockets" -> 消息传递-api
- "/admin" -> admin-api
- "/" -> public-api
现在我正在尝试实施健康检查路线。我想将它们命名为“/health”。但健康检查需要针对每个目标群体。由于 ALB 仅根据路径进行路由，因此我不能在一台以上的服务器上拥有 /health。
可能的解决方案：
1。通过子域分隔服务
我可以为每个服务创建一个子域，例如：
- api.mydomain.com
- sockets.mydomain.com
- admin.mydomain.com
通过此设置，我可以在每个服务中都有一个 /health 而不会发生冲突。
2。通过命名分隔健康检查路由
我可以为每项服务命名不同的健康检查路径，例如：
- api.mydomain.com/health-public-api
- api.mydomain.com/health-messaging-api
- api.mydomain.com/health-admin-api
建议？
以上两种解决方案似乎都可行，但我想知道其中一种解决方案是否会在以后出现问题，例如添加更多服务时，或者我何时添加 graphQL API 稍后。
edit:
I just bumped into one drawback with solution #1. My local
dev-enviromnemt is setup with a docker image for each service and
nginx for routing the requests. On top of this I use ngrok to be able
to reach the dev environment from the Internet.
I think it would be hard to solve the service separation in based on
subdomains, but I really don't need the /health routes in the dev
enviromnent, so I guess I could just pretend they are not there.
回答我自己的问题作为文档，并可能对其他人提供一些意见。
tl;博士：
我选择了第三种选择，通过路径中的第一级分离所有服务。与我以前的结构的主要区别是我的主 api（又名 public-api）已从根目录移动到名为 /app[=60= 的子路径].我也把它重命名为 app-api.
- api.mydomain.com/app/..
- api.mydomain.com/admin/..
- api.mydomain.com/套接字/..
- api.mydomain.com/auth/..
- www.mydomain.com/..
这个解决方案给了我几个优点，没有缺点（我认为）。
优点：
- 通过 nginx 在 ALB 和本地开发环境中轻松路由请求，无需 SNI 所需的额外工作
- 子域 api 与网站非常清楚地分开
- /health 路由默认获得唯一的名称，因为它们位于不同的路径下。
- 应用程序（网络和智能手机）可以使用通用的 api url (api.mydomain.com/) 并且仍然可以访问所有服务，即它们不需要以不同的方式存储多个初始化 Axios 连接。没什么大不了的，但仍然..
我还选择使 /health 更符合未来需求，并在每个服务中对以下结构进行标准化。
- api.mydomain.com/servicename/health
- api.mydomain.com/servicename/health/上架
- api.mydomain.com/servicename/health/准备就绪
up = 响应请求，ready = 所有依赖项都已连接（即数据库等）
/health returns 状态 200 以及描述准备情况的 json 对象。
/health/is-up 响应 200 或无响应（即根本无法访问）
/health/is-ready 如果所有依赖项都准备好，则返回 200，否则返回 500。
AWS 中的目标群体将使用 /is-ready 进行健康检查，但目前它与 /is-up 是一样的，因为我还没有实施准备测试。
ALB背后的多个服务之间如何命名健康检查路由？
我正在将我的 API 和数据库迁移到 AWS。在移动之前，我将单体式 REST API 拆分为四个服务：
- public API（连接到哪些应用程序和网站）
- admin API（用于管理网站）
- 消息API（用于与应用程序实时通信的网络套接字服务器）
- workers（基于队列的任务处理器）
我现在正在尝试找出一个好的路线组织方式。首先创建了两个子域，api.mydomain.com 和 www.mydomain.com.
我将 api 子域定向到我的 ALB，它仅根据路径路由流量，如下所示：
- "/sockets" -> 消息传递-api
- "/admin" -> admin-api
- "/" -> public-api
现在我正在尝试实施健康检查路线。我想将它们命名为“/health”。但健康检查需要针对每个目标群体。由于 ALB 仅根据路径进行路由，因此我不能在一台以上的服务器上拥有 /health。
可能的解决方案：
1。通过子域分隔服务
我可以为每个服务创建一个子域，例如： - api.mydomain.com - sockets.mydomain.com - admin.mydomain.com
通过此设置，我可以在每个服务中都有一个 /health 而不会发生冲突。
2。通过命名分隔健康检查路由
我可以为每项服务命名不同的健康检查路径，例如：
- api.mydomain.com/health-public-api
- api.mydomain.com/health-messaging-api
- api.mydomain.com/health-admin-api
建议？
以上两种解决方案似乎都可行，但我想知道其中一种解决方案是否会在以后出现问题，例如添加更多服务时，或者我何时添加 graphQL API 稍后。
edit:
I just bumped into one drawback with solution #1. My local dev-enviromnemt is setup with a docker image for each service and nginx for routing the requests. On top of this I use ngrok to be able to reach the dev environment from the Internet.
I think it would be hard to solve the service separation in based on subdomains, but I really don't need the /health routes in the dev enviromnent, so I guess I could just pretend they are not there.
回答我自己的问题作为文档，并可能对其他人提供一些意见。
tl;博士： 我选择了第三种选择，通过路径中的第一级分离所有服务。与我以前的结构的主要区别是我的主 api（又名 public-api）已从根目录移动到名为 /app[=60= 的子路径].我也把它重命名为 app-api.
- api.mydomain.com/app/..
- api.mydomain.com/admin/..
- api.mydomain.com/套接字/..
- api.mydomain.com/auth/..
- www.mydomain.com/..
这个解决方案给了我几个优点，没有缺点（我认为）。
优点：
- 通过 nginx 在 ALB 和本地开发环境中轻松路由请求，无需 SNI 所需的额外工作
- 子域 api 与网站非常清楚地分开
- /health 路由默认获得唯一的名称，因为它们位于不同的路径下。
- 应用程序（网络和智能手机）可以使用通用的 api url (api.mydomain.com/) 并且仍然可以访问所有服务，即它们不需要以不同的方式存储多个初始化 Axios 连接。没什么大不了的，但仍然..
我还选择使 /health 更符合未来需求，并在每个服务中对以下结构进行标准化。
- api.mydomain.com/servicename/health
- api.mydomain.com/servicename/health/上架
- api.mydomain.com/servicename/health/准备就绪
up = 响应请求，ready = 所有依赖项都已连接（即数据库等）
/health returns 状态 200 以及描述准备情况的 json 对象。
/health/is-up 响应 200 或无响应（即根本无法访问）
/health/is-ready 如果所有依赖项都准备好，则返回 200，否则返回 500。
AWS 中的目标群体将使用 /is-ready 进行健康检查，但目前它与 /is-up 是一样的，因为我还没有实施准备测试。