3 层 BizTalk 架构可能吗？答案

【问题标题】：3-Tier BizTalk Architecture Possible?3 层 BizTalk 架构可能吗？
【发布时间】：2018-04-27 17:55:16
【问题描述】：

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

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

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

【问题讨论】：

您为什么认为这是个问题？层背后的整个想法是你独立的层。您当然不希望将 BizTalk 用作您的演示文稿或数据层。但是您可以有一个网站（表示层）调用由 BizTalk（应用层）公开的连接到数据库（数据层）的 Web 服务。除了我不会在 BizTalk 中放太多的业务逻辑，所以你甚至可以让 BizTalk 调用另一个应用层。
问题是微软的建议是将所有HTTP流量转发到中间层，我敢肯定这有内在的安全风险，也与你的建议不同。我认为您的解决方案可能是要走的路，但我希望有一个开箱即用的解决方案。我宁愿不必在将请求委托给中间层的 BizTalk 的 Web 层上创建自定义解决方案。我在 HTTP 接收适配器上看到的所有文档似乎都假设该服务将直接从 Internet/公共资源调用。
您链接到的那篇文章绝不会提及中间层、层或类似概念。它确实提到了外围网络 (DMZ)、数据域和处理域 (FW3)，但这些是防火墙术语，而不是 3 层术语。它只是告诉您将 BizTalk/IIS 从您的 DMZ 放回一层，并将反向代理到您想要向外部世界公开的 IIS 服务。
感谢您的回复。好的，所以我的条件让你失望了。查看this 图表时，似乎建议让来自互联网的流量直接（红线）流向处理网络上的 BizTalk 服务器（我认为它是“应用程序层”）。我在这里的主要问题只是仔细检查这是否是常见做法，或者像您建议的那样（让网站暴露在调用处理网络中的 BizTalk 服务器的外围网络上）是否是更好的选择。
如今，通过 Azure 服务总线中继或 Azure 中的 API 公开 Web 服务变得越来越普遍。但是，是的，通过具有适当安全性的反向代理公开 BizTalk Web 服务是很常见的。如果将 BizTalk 服务器放在 DMZ 中，则必须从 BizTalk 到内部系统中戳出很多漏洞。

标签： proxy biztalk reverse-proxy 3-tier biztalk-2016

【解决方案1】：

我相信您将application tiers 与network architecture 混淆了。

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

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

【讨论】：

【解决方案2】：

请记住，“n 层”是毫无意义的。一个应用可以有任意多的层级。

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

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

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

【讨论】：

【解决方案3】：

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

【讨论】：