我正在将我的API和数据库移至AWS。在移动之前，我将我的monolith REST API分成四个服务：
我现在正试图找出一条良好的路线组织。最初创建了两个子域，api.mydomain.com和www.mydomain.com。
我将api子域指向我的ALB，它只基于路径路由流量，如下所示：
现在我正在尝试实施健康检查路线。我想把它们命名为“/ health”。但健康检查需要针对每个目标群体。由于ALB仅基于我不能在多个服务器上具有/ health的路径进行路由。
我可以为每个服务创建一个子域，例如： - api.mydomain.com - sockets.mydomain.com - admin.mydomain.com
通过这种设置，我可以在每项服务中保持健康状态而不会发生冲突。
我可以为每项服务命名健康检查路线，例如：
上述两种解决方案似乎都可行，但我想知道其中一种解决方案是否会在以后引起我的兴趣，例如添加更多服务，或者稍后我会添加graphQL API。
修改
我刚刚在解决方案＃1中遇到了一个缺点。我的当地人 dev-enviromnemt设置了每个服务的 docker 映像 nginx 用于路由请求。除此之外，我还可以使用 ngrok 从互联网到达开发环境。
我认为基于此解决服务分离很难 子域名，但我真的不需要开发中的/ health路由 enviromnent，所以我想我可以假装他们不在那里。
答案 0 :(得分：0)
回答我自己的问题作为文档，可能还有其他人的意见。
TL; DR： 我选择了第三个选项，通过路径中的第一级分隔所有服务。与我之前的结构的主要区别在于我的主api（aka public-api）已从根目录移动到名为 / app 的子路径。我还将其重命名为 app-api 。
这个解决方案给了我一些优点，没有缺点（我认为）。
优点：
我还选择了使/健康更具前瞻性，并在每项服务中对以下结构进行标准化。
up =响应请求，就绪 =所有依赖关系都已连接（即数据库等）
/ health 返回状态200以及描述准备就绪的json对象。
/ health / is-up 以200或无响应（即根本无法访问）回复
/ health / is-ready 以200响应，否则为500.
AWS中的目标群体将使用/准备进行健康检查，但是现在它与/ is-up是一样的，因为我尚未实施准备测试。