Rest AWS ALB后面的微服务（ish）设置中的健康检查路线组织 如何在ALB背后的多个服务中命名健康检查路径？

我正在将我的API和数据库移动到AWS。在移动之前，我将我的monolith REST API分为四个服务：

公共API（应用程序和网站连接到的API）

管理API（用于管理网站）

消息传递API（用于与应用程序实时通信的web套接字服务器）

工人（基于队列的任务处理器）

我现在正试图找出一个好的路线组织。最初创建了两个子域，api.mydomain.com和www.mydomain.com

我将api子域定向到我的ALB，该ALB仅基于路径路由流量，如下所示：

• “/sockets”->消息传递api
• “/admin”->管理api
• “/”->公共api

现在我正在尝试实施健康检查路线。我想把它们命名为“/健康”。但健康检查需要针对每个目标群体。由于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

建议？ 上述两种解决方案似乎都是可行的，但我想知道其中一种解决方案是否会影响我，例如，当添加更多服务时，或者当我稍后添加GraphQLAPI时

编辑：

我只是在解决方案1中遇到了一个缺点。我的本地 dev enviromnemt为每个服务和 用于路由请求的nginx。除此之外，我使用ngrok能够 从Internet访问开发环境

我认为基于服务的分离很难解决 子域，但我真的不需要dev中的/health路由 环境，所以我想我可以假装他们不在那里

---

以文档的形式回答我自己的问题，并可能向其他人提供一些信息

tl；博士： 我选择了第三个选项，通过路径中的第一级分离所有服务。与以前的结构的主要区别在于，我的主api（也称为公共api）已从根路径移动到名为/app的子路径。我还将其重命名为appapi

• api.mydomain.com/应用程序
• api.mydomain.com/管理员
• api.mydomain.com/套接字
• api.mydomain.com/auth/
• www.mydomain.com/

这个解决方案给了我一些优点，但没有缺点（我认为）

优点：

• 通过nginx在ALB和本地开发环境中轻松路由请求，而无需SNI的额外工作
• 子域非常清楚地将api与网站分开
• /健康路由在默认情况下获得唯一的名称，因为它们位于不同的路径下
• 这些应用程序（web和智能手机）可以使用一个通用的api url（api.mydomain.com/），并且仍然可以访问所有服务，也就是说，它们不需要存储几个不同初始化的Axios连接。没什么大不了的，不过

我还选择了使/health更具前瞻性，并在每个服务中对以下结构进行标准化

• api.mydomain.com/servicename/health
• api.mydomain.com/servicename/health/is-up
• api.mydomain.com/servicename/health/is-ready

up=响应请求，ready=连接所有依赖项（即数据库等）

• /运行状况返回状态200以及描述就绪状态的json对象

• /运行状况/正常响应为200或无响应（即根本无法访问）

• /如果所有依赖项都已就绪，则health/is ready响应200，否则响应500

AWS中的目标群体将使用/is ready进行健康检查，但目前它与/is相同，因为我还没有实施就绪测试