1

我们正在开发一个大型应用程序，该应用程序由几个 Web 应用程序（在不同的域下）以及一个后台调度程序（使用 Quartz.net）组成，它将在 Worker 角色上运行（目前它是一个 Windows 服务，但这没有意义在 Azure 上）。我试图找出最适合我们的方法：为每个应用程序单独托管服务或在单个托管服务/角色下运行所有​​应用程序。我想有第三种选择在单个托管服务下运行多个 Web 角色，但是我需要使用 ARR（应用程序请求路由），我不确定它会给我带来什么好处（如果有的话）。对我来说听起来像是更多的开销，但我很可能是错的？

我的项目是：

  • 面向公众的网站 - 低负载
  • 私人仪表板 - 中等负载
  • 跟踪展示次数、点击次数等的跟踪（分析）应用程序 - 高负载 - 5+ 百万次点击/月
  • API - 也是高负载，因为跟踪应用程序依赖它
  • Quartz.net 调度器（工作者角色）

公共网站和仪表板可能应该在单个 Web 角色上，但我不确定跟踪和 API 项目是否应该使用自己的云服务，以便它们可以独立扩展，或者我是否应该使用主机标头在单个 Web 角色上运行所有内容（当然除了调度程序）并立即扩展所有内容。所有托管服务都将运行多个实例，因此我不担心在部署过程中出现问题（因为 Azure 一次转换一个实例）。

此外，在单一角色上运行是否会给我在客户端应用程序（Web、仪表板、跟踪）和 API 之间提供更好的延迟，或者关联组和虚拟网络是否使这一点无关紧要？

我一直在寻找最佳答案，但还没有找到任何足够确凿的答案。

我主要关心的是原始性能和可扩展性。价格对我们来说不是决定性因素。

谢谢

4

2 回答 2

1

这取决于...

您的问题有几个方面需要考虑。

  • 部署和版本控制 - 您是否希望能够分别对系统的各个部分进行版本控制和部署？维护单独的部署会增加成本，但好处是增加了灵活性和单独部署更改的能力。这是您的决定中最重要的方面。
  • 团队结构 - 您是否有多个团队在系统上工作？我强烈建议按照团队划分部署和版本控制。
  • 可扩展性——从性能的角度来看，这两个选项都具有同等的可扩展性。
  • UI 性能 - 这不应该是您的部署设计的主要关注点。

我们是如何解决这个问题的：

  • 每个系统/子系统都有自己的部署和自己的存储帐户。这允许简单的版本控制和操作管理。
  • 我们的系统/子系统旨在执行许多高度凝聚力的职责。
  • 系统间通信是基于消息的（例如 Azure 队列）。
  • 每个后端工作者角色的职责（我们称之为“角色服务”）可以通过配置在不同的 Azure 部署角色之间轻松移动，具体取决于所需的性能特征。
  • 所有后端工作都应该是工人角色的表现。IIS 是后台进程的糟糕主机。
  • UI 性能是通过具体化所有视图（进入 blob 存储或内存）来实现的。也可以使用缓存。
于 2013-09-29T13:14:58.083 回答
0

你的问题永远不可能只有一个答案。

由于您的跟踪应用程序基本上基于您的 API，因此我假设没有直接的外部流量进入您的 API，并且仅由您的跟踪应用程序使用。所以在这种情况下，我将把它们都放在一个网络角色中。

但是，如果您预计 API 上的负载不是来自您的跟踪，考虑到您的 API 可能有一些外部客户端，那么最好将其放在单独的 Web 角色上。

关于您的其他 2 个 Web 应用程序，由于它们没有太多负载，您实际上可以将它们与您的跟踪或 api 角色结合使用。否则，如果您真的不关心定价，则可以使用第三个角色来托管您的公共站点和仪表板。

于 2013-09-29T07:52:17.260 回答