Azure 应用服务环境是否适合微服务架构

Question

我正在考虑将一组 REST 服务部署到 azure 中。这些服务将支持移动应用程序前端和基于 Web 的前端。我希望它们可以独立部署和扩展。他们需要与其他团队或第三方开发/维护的其他一些 Web 服务、API 等进行通信。不确定它们是否是纯微服务，但想法是每个服务都负责一个“域”，但是它可能需要从其他服务之一获取信息。例如，一个负责获取/更新客户的地址，另一个负责偏好。

我不确定是否应该为每个服务创建一个单独的应用服务环境，还是为所有服务创建一个应用服务环境？撇开成本不谈，是否有任何技术理由让它们都保持在同一个应用服务环境中？我的第一个想法是为每个服务创建一个应用服务环境，因为这样可以提供最大程度的隔离，但是网上的很多示例看起来好像人们在同一个应用服务环境中部署了多个应用/服务。

谢谢

Answer 1

微服务是每个人在他/她的脑海中都有自己定义的词之一，但我理解您希望在域级别对功能进行分组，以便从长远来看避免需要维护的庞大服务群。我会尽量简化事情。

1) 应用服务计划 -> 托管虚拟机

想象一个应用服务计划就像一个托管虚拟机，一切都为你准备好了。您可以向上扩展（提供更多资源）或向外扩展（创建多个实例并自动为您设置负载均衡器）。最低生产级别计划 P1V2 带有 3.5GB 的 RAM 和 210 acus。对于可以为某些调用提供服务并将数据保存在数据库中的普通微服务来说，它非常强大。

2) 将微服务分组在一个计划中

我建议你这样做。您可能会说成本无关紧要，但当您的公司成长并且您将有 100 项服务在每个自己的计划中运行时，这实际上很重要。如果您一一部署，还要考虑不必要的资源消耗（您可能会使用开发/测试计划来部署您的应用程序以获得更少的资源，但这也带来了有限的功能）。

那么如何分组呢？有很多方法可以做到，我只会列举一些我认为效果很好的方法。

1. 按域。如果您有两个或更多彼此密切相关的服务，您可能需要在同一个计划中使用它们，因此如果您想横向扩展并提高性能，您只需横向扩展一个计划。

2. 通过外部依赖。如果您的某些服务被第三方调用或向第三方发出呼叫，那么将它们组合在一个计划中并将它们放置在 api 网关之后可能是一种很好的方法，以便它们保持其公共 ip 静态，无论您是否想要删除服务并重新创建它。一些第三方还将 IP 列入白名单，因此保持出站 IP 地址静态可能是个好主意。

3. 表现。由于服务将共享资源，因此隔离一些非常重要的服务非常重要。同样的事情适用于可能在短时间内选择大量工作负载的服务，这可能会耗尽机器资源，从而延迟托管在一起的所有其他服务。

在其中一条评论中回答建议，Service Fabric 不是 Azure 中微服务的未来。它得到维护，但不会再进化了。微软正在将他们的客户转向 AKS 或 Web 应用程序。但在我看来，AKS 有点难以维护，即使是托管版本。

最后，我认为应用服务和 web/api 应用是在 azure 中部署微服务的不错选择。将它们保持在同一区域并错误地拆分它们。设置和维护非常容易。

我希望它能帮助你。如果您想要更具体的信息，请随时与我联系。