Приложение ASP.NET в нескольких центрах обработки данных - лучшая архитектура?

Question

Я традиционно придерживался архитектуры «одного приложения, одного сервера» для большинства приложений ASP.NET/SQL Server, над которыми я работал. Я имею в виду это свободно, используя несколько серверов с балансировщиком нагрузки и т. Д. Но они все были в одном центре данных.

Однако в последнее время появилось требование о применении приложения, которое будет поддерживать пользователей в США, Китае и России. Производительность будет достаточно критической, так что самый разумный способ архитектовать такое приложение, чтобы он хорошо работал во всех этих областях?

варианты я придумываю является:

• Используйте один единый центр обработки данных (т.е. не пройдет в нескольких мест по всему миру). Предоставляйте статический контент через CDN, но база данных и сайт ASP.NET будут размещаться в одном месте (например: США). Похоже, что производительность все равно может быть проблемой.
• Использование нескольких центров обработки данных и наличие нескольких версий приложения. Например: ru.myapp.com, us.myapp.com, ch.myapp.com со своим собственным кодом/базами данных и т. Д. Это будет работать, но такие вещи, как отчетность, управление и т. Д., Должны выполняться в каждом приложении, что представляется наименее эффективным.
• Используйте другую архитектуру, но я не знаком с альтернативами. Возможно ли, чтобы у вас было одно приложение и база данных, работающие в нескольких центрах обработки данных (например, в среде с балансировкой нагрузки, но в большем масштабе).

Есть ли у кого-нибудь опыт в лучшем способе справиться с этим?

Answer 1

Ваши интерфейсные серверы могут работать через центры обработки данных так же, как они работают в одном центре обработки данных. Есть некоторые отличия, хотя - балансировка нагрузки обычно не работает с перекрестным цветом. Вам нужно будет использовать гео DNS для маршрутизации людей в ближайший центр обработки данных, а затем использовать балансировщик нагрузки в этом центре обработки данных.

Главной проблемой, которая возникает, является использование общих ресурсов, таких как БД или веб-служба, такая как веб-служба проверки подлинности. Если вам действительно нужна отдельная БД, тогда одна архитектура должна иметь один мастер, но несколько подчиненных устройств чтения распространяются в разных центрах обработки данных. Чтения затем НЕ платят штраф за перекрестный коло. Записи должны пройти кросс-коло и, таким образом, заплатить штраф за латентность. Это работает для большинства сайтов, где записи намного меньше, чем чтения, и где производительность записи может быть на 1-2 секунды медленнее, чем читать, и все же считаться приемлемой. например взять сайт бронирования билетов. Чтения в подавляющем большинстве больше, чем записи.

Эффект перекрестного цвета может быть значительно улучшен с помощью следующих вариантов: 1. Минимизировать количество круговых поездок. например все записи записываются по одной транзакции, а не выполняют многократную запись через несколько вызовов в БД. то есть использовать пакетные запросы, хранимые процедуры, пакетный удаленный вызов и т. д. 2. Используйте оптимистичную запись/возможную согласованность, если это возможно. например скажем, вы записываете время входа пользователя в систему. Вы можете очень хорошо сделать его асинхронным, где время будет записано. Хотя есть сценарии, где возможная согласованность неприемлема.