【问题标题】：What are the limitations/drawbacks of using single azure app service to host multiple applications/microservices?使用单个 Azure 应用服务托管多个应用程序/微服务有哪些限制/缺点？
【发布时间】：2020-10-31 04:25:03
【问题描述】：
谁能告诉我或解释一下在单个 Azure AppService 服务器上部署多个微服务（比如 2-3 个）有哪些限制/缺点？
为了实现以下我们使用微服务
- 服务于单一目的或承担单一责任
- 拥有清晰的沟通界面
- 相互依赖较少
- 可以独立部署而不影响生态系统的其他部分
- 可以独立扩展
- 可以独立失败
- 让您的团队独立工作，无需依赖其他团队提供支持和服务
- 允许小而频繁的更改
- 减少技术债务
- 更快地从故障中恢复
但是当我们尝试部署其中一项微服务时，Azure 应用服务如何工作？它会影响其他微服务吗？我们可以在生产环境中使用它吗？
我通过添加 azure 存储为 windows 和 linux 定义虚拟路径，在单个 appservice 上托管多个应用程序的链接很少，但这是最佳/好的做法吗？
【问题讨论】：
标签：
azure
microservices
azure-storage
azure-web-app-service
azure-appservice
【解决方案1】：
不，不是。它们会争夺计算资源，如果硬件出现故障，它们就会全部宕机。
【解决方案2】：
听起来您指的是在共享应用服务计划中托管多个应用服务应用。这在概念上（和物理上）与在服务器上运行多个应用程序相同，我会沿着这些思路考虑利弊。
您可以在同一个计划中托管多个应用，只要该计划提供足够的内存/CPU/网络资源来满足这些应用的综合需求。对于一些小型应用程序，适度的计划大小在生产中处理所有这些应用程序应该没有问题。组合的主要好处是节省成本，因为计划是收费单位，而不是应用程序。
Microsoft documents some reasons 将应用隔离在单独的计划中：
- 该应用占用大量资源。
- 您希望独立于现有计划中的其他应用扩展应用。
- 应用需要不同地理区域的资源。
根据我的经验，我想补充一些注意事项：
- 部署和重新启动应用程序可能会导致计划（即服务器）的 CPU 峰值。如果您的应用对性能很敏感并且您经常部署，您可能需要更多的分离
- Azure 维护要求服务器至少每月重新启动一次或更多次。如果您的所有应用都在共享计划中，则补丁重启可能意味着整个系统已关闭，并且所有应用在同时启动时会争夺资源
- 我通常使用单独的计划作为环境边界，因此生产计划与测试计划分开。 “测试”应用在测试计划中进行，“产品”应用在生产中，以防止测试影响用户。
-
Azure Functions 可能更适合托管许多微服务