我正在考虑将一组 REST 服务部署到 Azure 中。这些服务用于支持移动应用程序前端和基于 Web 的前端。我希望它们能够独立部署和扩展。他们需要相互通信以及其他团队或第三方开发/维护的其他 Web 服务、API 等。不确定它们是否是纯粹的微服务，但想法是每个服务都负责一个“域”，但它可能需要从其他服务之一获取信息。例如，一个负责获取/更新客户的地址，另一个负责偏好。
我不确定是否应该为每项服务创建一个单独的应用服务环境，还是为所有服务创建一个应用服务环境？抛开成本不谈，是否有任何技术原因可以将它们全部保留在同一个应用服务环境中？我的第一个想法是为每个服务创建一个应用程序服务环境，因为这将提供最大程度的隔离，但网上的许多示例使人们看起来像是在同一个应用程序服务环境中部署多个应用程序/服务。
谢谢
最佳答案
微服务是每个人脑海中都有自己的定义的词之一，但我理解您希望在域级别对功能进行分组，这样您就可以避免从长远来看需要维护的庞大服务群。我会尽量简化事情。
1) 应用服务计划 -> 托管虚拟机
想象一个应用服务计划就像一个托管虚拟机，一切都为您准备就绪。您可以纵向扩展(提供更多资源)或横向扩展(使用自动为您设置的负载均衡器创建多个实例)。最低生产级别计划 P1V2 配备 3.5GB RAM 和 210 acus 。对于一个普通的微服务来说，它非常强大，可以服务一些调用并将数据保存在数据库中。
2) 将微服务分组到一个计划中
我建议你这样做。您可能会说成本并不重要，但当您的公司发展壮大并且您将拥有 100 项服务并在每个自己的计划中运行每项服务时，成本实际上会很重要。如果逐一部署，还要考虑不必要的资源消耗(您可能可以使用开发/测试计划来部署应用程序，以获得更少的资源，但功能也有限)。
那么如何分组呢？有很多方法可以做到这一点，我只列出其中一些我见过的效果很好的方法。
按域。如果您有两项或多项彼此密切相关的服务，则可能需要将它们纳入同一计划中，因此如果您想横向扩展并提高性能，则只需横向扩展一项计划。
通过外部依赖性。如果您的某些服务由第三方调用或向第三方进行调用，那么将它们组合在一个计划中并将它们放置在 api 网关后面可能是一种好方法，这样它们就可以保持其公共(public) ip 静态，无论您是否想要删除服务并重新创建它。一些第三方还将 IP 列入白名单，因此最好保持您的出站 IP 地址静态。
性能。由于服务将共享资源，因此隔离一些非常重要的服务非常重要。同样的情况也适用于那些可能在短时间内承担大量工作负载的服务，这可能会耗尽机器资源，从而延迟托管在一起的所有其他服务。
回答其中一条评论中的建议，Service Fabric 不是 Azure 中微服务的 future 。它得到维护，但不会再进一步发展。 Microsoft 正在将客户转向 AKS 或 Web 应用程序。但在我看来，AKS 有点难以维护，即使是托管版本也是如此。
总之，我认为应用服务和 Web/API 应用是在 Azure 中部署微服务的不错选择。将它们保持在同一区域并适本地分割它们。它非常容易设置和维护。
希望对你有帮助。如果您需要更多具体信息，请随时与我联系。
关于azure - Azure应用服务环境是否适合微服务架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61777811/