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

Question

我在考虑将一系列REST服务部署到Azure上，这些服务将支持移动应用和Web前端。我希望它们可以独立部署和扩展，需要相互通信以及与其他团队或第三方开发/维护的Web服务、API等进行通信。虽然不确定它们是否是纯微服务，但每个服务都负责一个“领域”，但有时可能需要从另一个服务中获取信息。例如，一个服务负责获取/更新客户地址，另一个服务则负责处理偏好设置。

我不确定是否为每个服务创建单独的应用服务环境，还是为所有服务创建一个应用服务环境？忽略成本因素，是否有任何技术原因要将它们全部放在同一个应用服务环境中？我的第一反应是为每个服务创建一个应用服务环境，因为这样会提供最大程度的隔离，但在线上很多示例中似乎人们都在同一个应用服务环境中部署了多个应用/服务。

谢谢！

- devo

---

在所有的架构参考中，你会发现 AKS 或 Service Fabric。我建议选择其中一个。 - Thiago Custodio

没错，但是你不想为仅由两个组件组成的微服务维护一个AKS集群（即使是托管的）。 - Matthias Güntert

这是一个非常好的问题。我一直对全球对Docker容器和编排器的痴迷感到沮丧。在我看来，只有当需要对计算资源分配和调度进行细粒度控制（即开发非平凡应用程序）或在云中托管服务不是一个选项时，您才需要运行微服务。否则，Azure App Service 要容易得多，并提供您需要的大多数功能。 （但很乐意听听其他人的观点） - sich

Answer 1

微服务是一个被每个人都有自己定义的词汇，但我理解您想要在领域级别上对功能进行分组，以避免长期需要维护的大量服务集合。我会尽可能简化事情。

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

将应用服务计划视为已设置了所有内容的托管虚拟机。您可以进行横向扩展（创建多个实例，并自动为您设置负载平衡器）或纵向扩展（提供更多资源）。生产级别最低的P1V2计划配备3.5GB RAM和210个acus。对于平均微服务来说，这非常强大，可以服务一些调用并在数据库中保留数据。

2）将微服务分组到一个计划中

我建议您这样做。您可能会表示成本不重要，但当您的公司发展壮大并且您将有100个服务运行在每个独立的计划上时，实际上成本就很重要了。还要考虑逐个部署的不必要资源开销（您可能可以使用dev/test计划来部署应用程序，以获得较少的资源，但这也会带来有限的功能）。

那么如何分组呢？有很多方法可以做到这一点，我只想提出一些我看到过很好的方法。

1. 按领域分类。如果您有两个或更多与彼此密切相关的服务，则可能需要将它们放在同一个计划中，因此如果要扩展规模并提高性能，则只需扩展一个计划。

2. 按外部依赖项分类。如果您的某些服务正在被第三方调用或给第三方调用，则将它们分组到一个计划中，并将它们放在API网关后面可能是一个好方法，这样它们就能保持公共IP地址静态，不管您是否想删除并重新创建服务。有些第三方还会将IP地址列入白名单，因此将出站IP地址保持静态可能是个好主意。

3. 性能。由于服务将共享资源，因此很重要的一点是对某些非常关键的服务进行隔离。同样的情况也适用于可能在短时间内产生大量工作负载的服务，这可能会耗尽机器资源，延迟所有其他服务的托管。

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

总之，我认为在Azure中部署微服务时，应用程序服务和Web/API应用程序是相当不错的选择。将它们保持在同一地区并适当分割它们。设置和维护它们非常容易。

希望这有所帮助。如果您需要更具体的信息，请随时联系我。

- Stelios Giakoumidis

---

是的，我也在考虑建立一种“元”组。将几个相关的服务分组到一个 ASE 中。我已经看过 AKS，但我认为它需要更多的工作来构建/维护，而 ASE 则可以为您提供“免费”的服务（免费指不需要付出努力）。到目前为止，我唯一看到的缺点是听说 ASE 需要更长时间才能扩展。我必须使用隔离的 ASE。 - devo