Azure应用服务环境是否适合微服务体系结构

时间:2020-05-13 14:52:45

标签: azure azure-app-service-envrmnt

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

我不确定应该为每个服务创建单独的应用程序服务环境还是为所有服务创建一个应用程序服务环境?除了成本,是否有任何技术原因将它们全部保留在相同的应用程序服务环境中?我的第一个想法是为每个服务创建一个应用程序服务环境,因为这将提供最大程度的隔离,但是许多在线示例使人们似乎在同一应用程序服务环境中部署多个应用程序/服务。

谢谢

1 个答案:

答案 0 :(得分:2)

微服务是其中每个人都有自己定义的一个词,但我知道您希望在域级别对功能进行分组,因此避免了需要长期维护的庞大服务群。我会尽量简化事情。

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

想象一下像托管虚拟机这样的App Service Plan,其中一切都已为您准备就绪。您可以向上扩展(提供更多资源)或向外扩展(使用自动为您设置的负载均衡器创建多个实例)。最低生产水平计划P1V2带有3.5GB RAM和210 acus。对于一般的微服务而言,它可以为某些调用提供服务并将数据持久存储在db中,这非常强大。

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

我建议你这样做。您可能会说成本并不重要,但是实际上这将随着公司的成长而变得重要,并且您将有100个服务在每个计划上运行。如果一一部署,也要考虑不必要的资源花费(您可能会使用开发/测试计划来部署应用,以减少资源获取,但功能也有限)。

那么如何分组?有很多方法可以做到,我只列举其中一些我认为效果很好的方法。

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

  2. 通过外部约束。如果您的某些服务是由第三方调用或打给第三方的,那么将它们组合到一个计划中并将它们放置在api网关后面是个好方法,这样无论您是否使用,都可以使它们的公共IP保持静态想要删除服务并重新创建它。一些第三方还将IP列入白名单,因此最好将您的出站IP地址保持静态。

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

在其中一项评论中提出了建议,Service Fabric并不是微服务的未来。它得到维护,但不会继续发展。 Microsoft正在将其客户转移到AKS或Web应用程序。但是以我的口味,即使是托管版本,AKS也很难维护。

最后,我认为应用服务和Web / api应用是在Azure中部署微服务的不错选择。将它们放在相同的区域,并进行多孔分割。设置和维护非常容易。

我希望它能对您有所帮助。如果您需要更多具体信息,请随时与我联系。