我一直在忙着将一个单片服务层分成大约30个小块＆＃39;可以独立部署（C＃，Web API）。
与此同时，我们正在转向Azure。 这些微服务应该如何部署？
我们需要4个环境（devint，QA，UA和Prod），因此我们将为每个PaaS使用4个插槽，并为每个微服务使用新的Paas。 但这会让经理变得昂贵和困难。
有更好的方法吗？ （我对Azure知之甚少，所以感谢任何帮助。）
由于
答案 0 :(得分：3)
Azure Service Fabric是为微服务而构建的，可能是最好的选择。特别是在Azure平台上运行时的前瞻性思维。但是，根据您的时间线，Service Fabric仍在预览中的事实可能是一个问题。预览中的Azure功能没有完整的SLA保证，它们将在制作时可用（GA）。
Azure App Service中用于微服务的最简单的托管解决方案是将不同的服务部署为 Web Apps ，可能使用Web Jobs进行任何后台处理。 Web Apps和Web Jos非常适合构建微服务，我过去曾在项目中使用过这种方法。
关于你关于＆＃34; 4个插槽＆＃34;的评论。如果您指的是 Web App部署插槽，那么您将需要重新考虑使用同一Web App的4个部署插槽来托管您的不同环境。特别是在Production中，应该有一个用于Live Production实例的Deployment Slot，以及一个用于Staging区域的插槽，用于在交换它们之前测试部署。当谈到Dev / Int，QA和UAT时，您将希望拥有一个或多个Web应用程序以及必要的部署插槽以满足您的需求。您要做的最后一件事是混合您的Dev / Int，QA，UAT和Production环境。了解单个Web应用程序的所有部署插槽都在完全相同的虚拟机上运行也非常重要;这意味着如果您将所有4个环境都设置为部署插槽，那么您的Dev和QA环境可能会影响生产的性能;这将是可怕的。
答案 1 :(得分：0)
您应该考虑使用Azure Web Apps来托管您的块，因为它不需要对您编码的API或网站进行任何自定义（与具有其打包和部署格式的云服务不同）。相同的WebDeploy机制可以在任何IIS服务器上运行（在您自己的服务器上，AWS或Azure上）
查看Azure Resource Manager (ARM)以定义底层资源，例如托管App服务计划（相当于Web服务器），Web应用程序和数据库。您很可能在每个环境和不同配置（例如不同的API URL）或次要调整（例如高级SQL计划或更大/更多Web应用程序实例）中具有相同的资源集。因此，ARM模板可以在4个环境中共享，每个环境都有自己的ARM参数文件。