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

Question

我传统上遵循我所使用的大多数ASP.NET / SQL Server应用程序的“一个应用程序，一个服务器”架构。我的意思是，松散地使用了多台服务器和负载均衡器等，但它们都在同一个数据中心。

然而，最近，一项要求的范围已经到位，该应用程序将支持美国，中国和俄罗斯的用户。性能将是非常关键的，那么构建这样一个应用程序的最明智的方法是什么，以便它在所有这些领域表现良好？

我提出的选项是：

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

有没有人有最佳处理方法的经验？

Answer 1

您的前端服务器可以跨数据中心工作，就像在单个数据中心内工作一样。虽然存在一些差异 - 负载均衡器通常不会交叉结果。您是否必须使用地理DNS将人员路由到最近的数据中心，然后在该数据中心内使用负载均衡器。

出现的主要问题是使用共享资源，例如DB或身份验证Web服务等Web服务。如果您确实需要单个数据库，那么一个体系结构就是拥有一个主服务器，但是多个读取从服务器分布在不同的数据中心。然后读取不会因为跨越colo而受到任何惩罚。写入必须跨越colo，从而支付延迟惩罚。这适用于大多数站点，其中写入比读取数量少得多，并且写入性能比读取慢1-2秒，并且仍被视为可接受。例如拍电影票预订网站。读取绝不仅仅是写入。

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