使为 azure（也）开发的项目能够在云之外部署（例如在 Windows Server 计算机上）需要哪些步骤？我的项目有 2 个工人角色。一个基本上是数据挖掘器，另一个托管（自托管）WCF 服务。它使用 Azure 表服务、队列和 Blob 服务。这些元素将如何从云端转换？SQL 数据库或 NoSql 方法？我将如何添加一个抽象级别以允许它使用实际可用的任何资源，而无需修改底层实现（即我的 DataServiceContext 类保持大部分不变）？
编辑1：
工作者角色 <=> Windows 服务
Azure 表服务 <=> EntityFramework + WCF 数据服务？
不幸的是，如果不进行大量返工，您将无法完成它。尽管您的 Web/工作者角色可能更容易移动，但您的大问题是使用 Azure 存储。虽然您可以（或可能已经）抽象出您的存储并注入到任何适当的存储中，但您很可能（无论是否明确）做出了特定于 Azure 存储的设计注意事项。这意味着您实施的内容可能在 Azure 上运行良好，但在本地运行不佳。例如，您使用的 blob 存储的许多功能（例如页 blob 或冗余）在传统的基于磁盘的存储中是不可用的。
不久前，我给 Scott Gu 发了一封电子邮件，专门询问缺少与 Azure 存储 API 兼容的本地存储产品该怎么办。他回答说 API 兼容性是他们正在努力的事情，并将在今年晚些时候（去年 2012 年）出现。我假设这指的是在本地运行的 Azure 网站（和其他 IaaS）——他们去年在预览版中宣布了这一点。就存储和计算而言，目前还没有。
我建议您避免尝试使用相同的代码和基础结构为 Azure 和本地构建应用程序。既然您已经开始使用 Azure，请质疑对内部部署的需求，并尝试发现潜在的需求。是安全恐惧吗？归属感？成本？也许您可以了解真正需要什么，并在您的 Azure 应用程序中解决这些问题。也许有点推销在 Azure 上运行的好处会比重写更容易。毕竟，应用程序必须在本地运行的用例并不多——否则我们根本不会做这个云计算。
我曾从事过一个需要在云端和本地部署的项目，具有相同的代码库。也许我可以从我身边分享一些想法。
我们在设计的时候需要关注很多方面，主要关注云和本地的不同环境，在我们的系统中构建一些虚拟化层。这样我们就可以通过配置进行切换。
文件系统：我们有一个虚拟文件操作界面，里面包含了文件保存、删除和获取的方法。然后我们有两个本地和 blob 的实现类。
数据库：这可以通过支持 SQL Server 和 SQL Azure 的简单 SQL 帮助程序类轻松完成。只需要更改连接字符串。但是在使用 SQL Server 时，我们也遵循 SQL Azure 的限制，例如不能跨数据库查询。
配置：我们将一些配置移到了从 web.config 启用缓存的数据库中，特别是对于那些可能在运行时更改的配置元素。这是因为在云上部署时，除非推送新包，否则我们无法更改 web.config。
托管：由于我们的项目是 WCF 服务，因此我们为底层服务实现创建了多个托管项目。其中一些用于本地部署，例如 Windows 服务托管、控制台应用程序托管和 IIS 托管。我们还有一个 Web 角色和工作人员角色，可用于在云上托管我们的服务。托管项目非常简单，它们都使用相同的服务实现类。
日志：我们利用我们的文件系统层，以便日志可以保存在本地文件（本地部署）或表服务（云部署）中。
缓存：我们从 ServiceStack 学习了代码，并为 Windows Server AppFabric Cache 和 Windows Azure Shared Cahce 构建了一个缓存接口和一些实现。它可以通过配置进行切换。对于下一个版本，我们将为云服务缓存实现另一个实现类。
无状态：我们确保我们的应用程序，特别是服务实现是无状态的。这不仅对云部署很重要，对本地部署也很重要。
希望这可以帮助。