Лучшие практики для реализации базовых веб-интерфейсов dotnet с возможностью горизонтального масштабирования в облаке

Question

Мы создали базовый веб-интерфейс API dotnet, использующий базу данных SQL Server. Теперь мы планируем развернуть этот проект в Microsoft Azure.

Во время развертывания этого приложения мы также рассматриваем возможность включения опции автоматического масштабирования (горизонтальное масштабирование).

Прежде чем мы это сделаем,Нам нужны вопросы, которые мы хотим прояснить.

Нужно ли нам добавлять в наше приложение дополнительный код, который позволяет правильно работать с автоматическим масштабированием?

Правильно, в некотором смысле, как можнобыть более одного экземпляра приложения, работающего из-за горизонтального масштабирования. Мы используем базу данных, и будет запущено более одного экземпляра в случае гонки (т. Е. Два ресурса одновременно обращаются к одним и тем же данным). Я имею в виду, что мы можем добавить транзакцию (или использовать блокировку) в нашем коде, чтобы избежать подобных сценариев?

Я хочу знать, есть ли рекомендации, которым следует следовать при реализации такого рода приложений?

Спасибо и ждем ваших ответов!

Answer 1

При разработке стратегии автомасштабирования учитывайте следующие моменты:

• Система должна быть рассчитана на горизонтальное масштабирование. Избегайте предположений о сходстве экземпляров;не проектируйте решения, которые требуют, чтобы код всегда выполнялся в определенном экземпляре процесса. При горизонтальном масштабировании облачной службы или веб-сайта не следует предполагать, что серия запросов из одного и того же источника всегда будет направляться в один и тот же экземпляр. По той же причине проектные службы должны быть без сохранения состояния, чтобы избежать необходимости всегда направлять серию запросов от приложения на один и тот же экземпляр службы. При разработке службы, которая считывает сообщения из очереди и обрабатывает их, не делайте предположений о том, какой экземпляр службы обрабатывает конкретное сообщение, поскольку автоматическое масштабирование может запустить дополнительные экземпляры службы по мере увеличения длины очереди. Шаблон Конкурирующие потребители описывает, как обрабатывать этот сценарий.

• Если решение реализует долгосрочную задачу, разработайте эту задачу для поддержки как масштабирования, так и масштабирования вБез должной осторожности такая задача может помешать чистому завершению экземпляра процесса при масштабировании системы или может привести к потере данных в случае принудительного завершения процесса. В идеале, нужно выполнить рефакторинг долго выполняемой задачи и разбить выполняемую обработку на более мелкие, отдельные фрагменты. Шаблон Pipes and Filters предоставляет пример того, как этого можно добиться. В качестве альтернативы вы можете реализовать механизм контрольных точек, который регулярно записывает информацию о состоянии задачи и сохранять это состояние в долговременном хранилище, к которому может обращаться любой экземпляр процесса, выполняющего задачу. Таким образом, если процесс остановлен, выполняемая им работа может быть возобновлена ​​с последней контрольной точки с использованием другого экземпляра.

Для получения дополнительной информации следуйте документу: https://github.com/Huachao/azure-content/blob/master/articles/best-practices-auto-scaling.md

Answer 2

Относительно этого:

Правильно, в некотором смысле, поскольку может быть несколько запущенных приложений из-за горизонтального масштабирования. Мы используем базу данных, и будет запущено более одного экземпляра в случае гонки (т. Е. Два ресурса одновременно обращаются к одним и тем же данным). Я имею в виду, что мы можем добавить транзакцию (или использовать блокировку) в наш код, чтобы избежать подобных сценариев?

Имейте в виду, что даже если приложение работает на одной машине, запросы будутпо-прежнему обрабатываться одновременно. Это означает, что даже на одном компьютере 2 запроса могут привести к обновлению одной и той же записи в базе данных. Таким образом, приведенные выше вопросы об условиях гонки применимы и к веб-приложениям с одним экземпляром.

Старайтесь избегать блокировок: весь смысл (горизонтального) масштабирования заключается в повышении производительности. Используя блокировки, вы фактически удаляете эти преимущества, поскольку только один процесс может одновременно использовать заблокированный ресурс.

Другие соображения:

• Если вы используете оперативную памятькеш, вы можете заменить его на распределенный кеш .
• Руководство по MS docs