一些背景......
我们是第一次涉足 Azure，并正在尝试逐步实现这一目标。目前，我们的第一个应用程序将是监视队列以处理请求(例如发送电子邮件或执行一些屏幕抓取)的辅助角色，我们只需从本地 MVC 应用程序和 WCF 服务插入到队列中。稍后我们会将 MVC 应用和 WCF 服务迁移到 Azure。
我们的开发工作流程基本上是这样的(在不重要的方面进行了一些修改):
- 在本地和一些共享服务器上进行开发。检查源代码管理。
- 每 15 分钟，构建服务器就会构建一次并部署到“开发”环境(如果我们需要访问本地以外的“开发”环境，则兼作 CI 和覆盖)
- 技术测试人员手动触发构建服务器，将最后成功的“Dev”版本部署到测试环境(或者之前部署的测试版本，包括/不包括数据库)。
- 技术测试人员和业务测试人员手动触发构建服务器，将上次成功的“测试”版本(或者之前部署的测试版本，包括/不包括数据库)部署到 QA 环境。
- 有时我们会合并 QA 批准部署的变更集。
- 稍后，我们的生产构建服务器会将此版本部署到临时环境，然后再部署到我们的生产环境(我们在并行/独立环境中托管它 N 次)。
正如您所知，我们有许多内部托管的应用程序版本，供内部支持人员在投入生产之前使用。我希望这些对 Azure 的依赖程度相当低。我不需要完成服务器依赖性，因此我们将继续使用 Azure 队列，也许还有一些其他机制，只是因为它们很容易继续使用，但我们不希望我们的构建服务器必须部署到 Azure对于每一种环境(或者支付所有托管费用)。
那么，我们如何才能以实际测试部署到 Azure 的代码的方式合理地在本地托管我们的辅助角色？
建议的一个选择是，我们将辅助角色创建为包装器/外观，并在类库中完成所有实际工作，这是我们的计划。然而，允许我们“托管”它的后续操作是创建第二个包装器/外观应用程序，它执行与辅助角色相同的工作，只是我们可以将其作为计划任务或窗口运行服务器。最终，我不喜欢这个选项，因为整个项目在进入登台之前从未经过测试。
是否可以执行类似的操作，我们创建第二个包装器/外观应用程序，而不是调用它实际引用的类库并调用工作线程中的 Run() 函数角色？
最佳答案
你认为Azure emulator可能对你有帮助吗？这些是 differences真实的 Azure 提供商和模拟器之间。
为你的 worker 角色设置一个外观似乎是合理的。并使用适配器使任何可能的云(或其他托管)技术适应该外观？只是想提出一些想法。我之前实际上使用过这种方法，但这是一个“个人”项目。
使用PowerShell配置您的角色等等。 配置您的 Azure 模拟器，如 this .
关于c# - 如何在本地/内部托管 Azure 辅助角色？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7111338/