基于 48.3 自定义管理服务器端口
使用默认 HTTP 端口公开管理终结点是一个 基于云的部署的明智选择。但是，如果 应用程序在您自己的数据中心内运行，您可能更愿意公开 使用不同 HTTP 端口的终结点。
为执行器运行状况终结点运行不同的端口的价值是多少？ 在什么样的情况下？
通常，一个端口用于所有服务终结点是否足够好？ 在不同的标准实现上实现安装程序运行状况终结点吗？
您可能希望在不同端口上公开执行器端点的原因与应用程序前面的负载均衡器/防火墙有关。
假设您在端口 8080 上有 API。您的防火墙将采用端口 80 并将流量定向到端口 8080。
为什么我们不直接在 Spring 应用程序上公开端口 80？ 在Linux中，打开端口1024或更低需要root帐户，这是因为下面的端口是敏感端口。因此，一个原因是您不想以root身份运行应用程序。
但是为什么执行器在不同的端口上，那么如果你有执行器，比如说8081，那么你只能从网络内部访问那些，在防火墙后面(因为防火墙只打开端口80用于外部连接(，没有其他人可以检查你的服务的健康状态，内存等。
可能有不同的原因，有些是技术性的，有些不是：
-
您的安全部门有一个策略，即任何"管理"内容(执行器当然属于此类别(都不能共享应用程序的默认端口。所以你只是忍受着这种:)我在一家相当大的公司里看到过这种情况，所以这不是开玩笑。
-
如果您密集使用执行器(例如通过执行器进行一些集成( - 在 tomcat 连接器的同一线程池上将存在请求，作为应用程序必须服务的常规休息请求，在这种情况下，您可能更愿意分开。
-
您有一些网络设备可以路由您的请求，它可以轻松禁止最终用户对某个端口的请求，但它不能在 URL 部分上运行：
http://host:port/api/v1/business-stuff
http://host:port/health
--> Hard / impossible to configure routing
as opposed to:
http://host:port1/api/v1/business-stuff
http://host:port2/health
--> easy - open port1 for end users, don't open port2 to the out world
毕竟弹簧启动提供了许多选择，您应该决定最适合您的选择