多个数据中心中的 ASP.NET 应用程序 - 最佳架构？

Question

对于我从事的大多数 ASP.NET/SQL Server 应用程序，我一直遵循“一个应用程序，一个服务器”架构。我的意思是松散地使用多个带有负载平衡器的服务器等。但它们都在同一个数据中心。

但是，最近出现了一项要求，要求确定将支持美国、中国和俄罗斯用户的应用程序范围。性能将是相当关键的，那么构建这样一个应用程序以使其在所有这些领域都表现良好的最明智的方法是什么？

我想出的选项是：

• 使用一个数据中心（即：不要在世界各地的多个地方托管）。通过 CDN 交付静态内容，但数据库和 ASP.NET 站点将托管在一个地方（例如：美国）。不过，这似乎仍然是一个问题。
• 使用多个数据中心，并拥有多个版本的应用程序。例如：ru.myapp.com、us.myapp.com、ch.myapp.com 以及他们自己的代码/数据库/等。这可行，但需要在每个应用程序中完成报告、管理等工作，这似乎是效率最低的方法。
• 使用不同的架构 - 但我不熟悉替代方案。是否有可能以这样一种方式进行架构，即您拥有一个跨多个数据中心工作的单一应用程序和数据库（类似于负载平衡环境，但规模更大）。

有没有人有任何处理这个问题的最佳方式的经验？

Answer 1

您的前端服务器可以像在单个数据中心内工作一样跨数据中心工作。但是有一些区别 - 负载均衡器通常不能跨颜色工作。您是否必须使用地理 DNS 将人员路由到最近的数据中心，然后在该数据中心内使用负载均衡器。

出现的主要问题是共享资源的使用，例如 DB 或 Web 服务（例如身份验证 Web 服务）。如果你真的需要一个 DB，那么一种架构是有一个主，但多个读取从属分布在不同的数据中心。然后，读取不会因交叉结肠而受到任何惩罚。写入确实必须跨域进行，因此需要支付延迟损失。这适用于大多数写入次数远少于读取次数且写入性能可能比读取慢 1-2 秒且仍被视为可接受的站点。例如拿一个电影票预订网站。读取压倒性地超过写入。

可以通过以下选择显着提高跨色性能 1. 尽量减少往返次数。例如在单个事务上进行所有写入，而不是通过多次调用 DB 进行多次写入。即使用批量查询、存储过程、批量远程调用等。 2. 如果可能，使用乐观写入/最终一致性。例如假设您正在记录用户登录的时间。您可以很好地使其异步，最终记录时间。尽管在某些情况下最终的一致性是不可接受的。