c# - 在 azure 上托管 WCF 服务时有哪些限制(如果有)

Question

我编写了一个 WCF 服务，我想将其托管在 azure 中。当我编写该服务时，我并没有想到要在 azure 中托管它。

每个应用程序，甚至 WCF 服务，都在使用平台资源。当我说资源时，我指的是任何东西:

1. 内存
2. CPU
3. 文件句柄
4. 低级 API (pinvoke)
5. Com 对象。
6. 套接字
7. .Net BCL API(是的，我什至将其视为一种资源)
8. 数据库
9. 等等..等等..(任何不是我自己编写的代码的内容)

假设示例:例如，如果服务登录到驱动器“H”，它可能在我的计算机上运行(因为我有驱动器“H”)，但它可能无法在云上运行。对于驱动器“C”或任何驱动器号也是如此，我什至不知道从服务角度如何看待文件系统。 这只是一个例子。

另一个假设的例子:我可以从服务中调用 nt.dll 中的某些 winapi 方法，它将在我的计算机上运行。但我想它在云上不起作用。

我的问题是: 如何知道云端可以使用哪些资源以及写入云端时如何使用资源？需要遵循哪些“规则”？还有是否有任何“智能”编译器可以确保我的服务与云平台兼容

我很高兴获得有关此主题的任何详细解释或引用\书籍。我试图通过谷歌搜索找到一些信息，但没有找到任何足够好的内容。

一旦我获得详细信息，我将能够将必要的内容移植到我的服务(如果需要的话)。

Answer 1

这些限制取决于您托管 WCF 服务的方式:

1. Windows Azure 网站:这是一种共享托管模型。如果您在网站中部署 WCF 服务，则需要考虑到这一点。这意味着您对磁盘的访问权限有限，对低级 API 的访问权限有限，无法使用 native 库，...
2. Windows Azure Web/Worker Roles (PAAS):您的应用程序将部署在 Windows Server 2008/2012 VM 中。因此，如果您愿意，您可以利用在普通虚拟机上使用的所有功能(您在问题中提到的所有“资源”)。唯一需要记住的是，这些虚拟机不是持久性的(这意味着您存储在虚拟机上的所有数据都可能会丢失)，并且负载均衡器不具有粘性(如果您使用 WCF session ，这可能会成为问题)。事实上，这些机器不是持久性的，也意味着您无法以可靠的方式在它们上安装数据库服务器，但您可以使用外部数据库，例如 SQL Azure。此解决方案的优点是机器由 Fabric Controller 维护，因此您可以将服务包(应用程序)推送到 Windows Azure，其余的部署工作将为您完成。
3. Windows Azure 虚拟机 (IAAS):您将获得一台类似于 Web/Worker Roles 中的机器，它允许您使用所有“资源”，但具有更多控制权。计算机是持久性的，这意味着您存储在其上的所有内容都将保留在 Blob 存储中(如果计算机崩溃，您不会丢失存储在操作系统驱动器和数据磁盘上的数据)。这是最接近本地部署的替代方案，但这也增加了额外的工作。您将负责管理所有服务器上的部署、处理安全更新……但在这种情况下，您可以在计算机上安装自己的数据库。请记住，这里的负载均衡器也不具有粘性，这可能会影响 WCF session 等功能。