proxy - 3 层 BizTalk 架构可能吗？

Question

根据此BizTalk 文档，HTTP 接收适配器必须位于应用程序（中间）层。这意味着 BizTalk 仅限于 2 层架构，这对于现代企业来说是一个很大的限制。

微软推荐的反向代理建议（在上面的链接上）是这个问题的常见解决方案吗？是否有人使用任何其他配置来使用 Web/外围层中的 HTTP 接收适配器并能够通过应用程序层协商消息？

如果使用反向代理方法，是使用企业中现有的代理还是为解决方案配置了专用代理？

Answer 1

我相信您将应用程序层与网络架构混淆了。

BizTalk 几乎按照定义是中间层，意味着至少有 3 层解决方案。会有调用 BizTalk 服务的客户端、BizTalk 应用程序本身，以及一些包含大部分业务逻辑的业务线应用程序（然后是系统用来存储其记录的任何数据库/存储库）。BizTalk 可能会与多个业务应用程序进行交互以处理客户端请求。

您引用的图表和文章仅描述了如何使用反向代理授予外部客户端访问您的内部网络上托管的 BizTalk HTTP(S) 终结点的权限。

Answer 2

请记住，“n 层”的东西几乎没有意义。一个应用程序可以有任意多的层级。

但是，在 99.9% 的情况下，没有理由将 BizTalk HTTP 主机或任何其他终结点放在外围网络上。

根据当地政策，商店将进行端口转发或入站代理（反向代理也不是真正的事情；）。

在 BizTalk 中，实现这一点的方式绝对没有限制。如何完全取决于您的网络团队允许或喜欢什么。

Answer 3

如今，通过 Azure 服务总线中继或 Azure 中的 API 公开 Web 服务变得越来越普遍。但是，是的，通过具有适当安全性的反向代理公开 BizTalk Web 服务是很常见的。如果您将 Bi​​zTalk 服务器放置在 DMZ 中，您必须从 BizTalk 到您的内部系统戳出很多漏洞，这是您想要避免的。