通过ESB公开API的最佳方式是什么？

目前，我们有许多组件在REST和SOAP上公开它们的API，还有许多web应用程序也存在。下面是一些端点的高级视图，使用示例域example.com模拟一些端点

restsvc.example.com/v2--ELB-->| svr1.example.com/v2 |

soapsvc.example.com/v3--ELB-->svr2.example.com/v3|

corpwebapp.example.com--ELB-->|svr1.example.com/someapp/index.html|

ncorpwebapp.example.com--ELB-->svr2.example.com/anotherapp/index.html|

为了解决各种使用场景，我们引入了ESB，现在所有这些API甚至Web应用程序都是通过ESB代理的

restsvc.example.com/v2-ELB-->esb.example.com:8280/service/v2-->svr1.example.com/v2

soapsvc.example.com/v2-ELB-->esb.example.com:8280/service/v3-->svr2.example.com/v3|

corpwebapp.example.com-ELB-->|esb.example.com:8380/someapp/index.html |-->| svr1.example.com/someapp/index.html|

nonwebapp.example.com-ELB-->|esb.example.com:8480/someapp/index.html |-->| svr2.example.com/anotherapp/index.html|

所有这些公共API都指向ESB，但现在ESB已经在不同的端口和端点公开了这些API和web应用。例如：现在v2应用程序使用path/service/v2在端口8280上侦听

由于端点已更改，为了支持具有默认端口的现有端点，ELB必须满足这些要求。但这似乎与ELB紧密耦合，因为需要在端口和路径之间进行一些转换

我有几个问题

这是通过ESB公开API的正确方法吗

在ELB级别处理端口和路径是否正常且正确

AWS ELB是否能够支持此要求

如果问题1回答“否”，那么使用中介级逻辑根据子域URL模式等路由到不同的服务器好吗

---

在分析了一些信息和专家反馈后，我们介绍了这些策略并在我们的基础设施中实施

理想情况下，ESB应该侦听公共端口（80或443）。然后，它应该查看请求的详细信息，并将请求路由到各种应用程序。它可以根据内容类型、请求url等进行路由

---

当需要在ELBs和ESB之间映射变化数量时，ELBs将请求转发给一个或多个ESB。配置更改应该是最低限度的。问题中介绍的实现在ELB端有一些核心映射逻辑。ESB中的内部路由逻辑可以更改以适应这些需求。

听起来您需要适当的SOA治理吗？你有正式的治理文件吗？这些问题应该由您的SOA策略来回答。@Namphibian，谢谢您的评论。最初我们没有SOA治理，后来我们启动了SOA治理，包括SOA策略和许多设计规则