Azure上的多个应用程序 - 一个app-per-service或all-in-one？

Question

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

我的项目是：

• 面向公众的网站 - 低负荷
• 私人信息中心 - 适度负载
• 追踪展示次数，点击次数等的跟踪（分析）应用 - 高负载 - 每月500万次点击
• API - 跟踪应用程序依赖它时的高负载
• Quartz.net调度程序（辅助角色）

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

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

我一直在寻找最佳答案，但还没有找到足够的结论。

我主要关心的是原始性能和可伸缩性。价格不是我们的决定因素。

谢谢

Answer 1

这取决于......

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

• 部署和版本控制 - 您是否希望能够单独对系统的某些部分进行版本和部署？维护单独部署会增加成本，但其好处是可以提高灵活性并单独部署更改。这是您决定的最重要方面。
• 团队结构 - 您是否有多个团队在使用该系统？我强烈建议在团队线上分离部署和版本控制。
• 可扩展性 - 从性能角度来看，这两个选项都具有相同的可扩展性。
• UI性能 - 这不应该是部署设计的主要问题。

我们如何解决这个问题：

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

Answer 2

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

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

但是，如果您希望API除了跟踪之外有很大的负担，考虑到您的API可能有一些外部客户端，那么最好将其放在单独的Web角色上。

关于其他2个网络应用，因为它们没有太多负载，您实际上可以将它们与您的跟踪或api角色结合起来。另外，如果您真的不关心定价，那么第三个角色就是主持您的公共站点和仪表板。