Azure 上的多个应用 - 每个服务一个应用或一体式应用
本文关键字：应用 一个 一体式 Azure 服务 | 更新日期: 2023-09-27 18:33:11
我们正在开发一个大型应用程序，它由多个Web应用程序(在不同的域下(以及一个后台调度程序(使用 Quartz.net(组成，它将在辅助角色上运行(目前它是一个Windows服务，但在Azure上没有意义(。我试图找出最适合我们的方法：为每个应用程序单独托管服务或在单个托管服务/角色下运行所有应用程序。我想还有第三种选择在单个托管服务下运行多个 Web 角色，但随后我需要利用 ARR(应用程序请求路由(，我不确定它会给我带来什么好处(如果有的话(。对我来说听起来像是更多的开销，但我很可能错了？
我的项目是：
- 面向公众的网站 - 低负载
- 私人仪表板 - 中等负载 跟踪
- (分析(应用程序，可跟踪展示次数，点击次数等 - 高负载 - 5+百万次点击/月
- API - 负载也很高，因为跟踪应用程序依赖于它
- Quartz.net 计划程序(辅助角色(
公共网站和仪表板可能应该位于单个 Web 角色上，但我不确定跟踪和 API 项目是否应该使用自己的云服务，以便它们可以独立扩展，或者我是否应该使用主机标头在单个 Web 角色上运行所有内容(当然，调度程序除外(并一次缩放所有内容。所有托管服务都将运行多个实例，因此我不担心部署期间出现问题(因为 Azure 一次转换一个实例(。
此外，在单个角色上运行是否会在客户端应用(Web、仪表板、跟踪(和 API 之间给我带来更好的延迟，或者地缘组和虚拟网络是否使这一点无关紧要？
我一直在寻找最佳答案一段时间，但还没有找到任何足够确凿的东西。
我主要关心的是原始性能和可扩展性。价格不是我们的决定性因素。
谢谢
这取决于...
您的问题有几个方面需要考虑。
- 部署和版本控制 - 您是否希望能够单独对系统的各个部分进行版本控制和部署？ 维护单独的部署会增加成本，但好处是提高了灵活性和单独部署更改的能力。 这是您决定中最重要的方面。
- 团队结构 - 您是否有多个团队在系统上工作？ 我强烈建议按照团队线分离部署和版本控制。
- 可伸缩性 - 从性能角度来看，这两个选项同样可伸缩。
- UI 性能 - 这不应是部署设计的主要关注点。
我们如何处理这个问题：
- 每个系统/子系统都有自己的部署和自己的存储帐户。 这允许轻松进行版本控制和操作管理。
- 我们的系统/子系统旨在履行许多高度凝聚力的职责。
- 系统间通信是基于消息的(例如 Azure 队列(。
- 每个后端辅助角色的职责(我们称为"角色服务"(都可以根据所需的性能特征，通过配置在不同的 Azure 部署角色之间轻松移动。
- 所有后端工作都应是辅助角色的性能。 IIS 是后台进程的糟糕主机。
- UI 性能是通过将所有视图具体化(到 Blob 存储或内存中(来实现的。 也可以使用缓存。
你的问题永远不可能有一个单一的答案。
由于您的跟踪应用程序基本上基于您的 API，因此我假设没有直接的外部流量进入您的 API，并且仅由您的跟踪应用程序使用。因此，在这种情况下，我将将它们都放在一个 Web 角色中。
但是，如果您预计 API 上除了跟踪之外还会有巨大的负载，考虑到您的 API 可能有一些外部客户端，那么最好将其放在单独的 Web 角色上。
关于其他 2 个 Web 应用程序，由于它们没有太多负载，您实际上可以将它们与您的跟踪或 api 角色组合在一起。否则，如果您真的不关心定价，那么还有第三个角色来托管您的公共网站和仪表板。