Блог

В прошлом мы создавали нашу систему с использованием инфраструктуры обслуживания без состояния, где, поскольку у нас есть интерфейс API, который помещает элементы в очередь Azure, тогда были рабочие роли, обрабатывающие эти очереди. На бумаге это выглядело великолепно, как и то, как должно работать облако. По мере роста нашей очереди будет запускаться все больше экземпляров нашего приложения, которое является однопоточным, и каждый из них обрабатывает пакет из 30 элементов. По мере сокращения очереди они будут сокращаться.

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

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

Из-за всех ограничений, с которыми мы столкнулись при работе с облачными сервисами, мы в конечном итоге вернулись к единому приложению, которое может обрабатывать добавление более 150 отдельных потоков, и каждый отчет о ходе выполнения возвращается к основному пользовательскому интерфейсу. За небольшую часть затрат и практически без использования системных ресурсов мы перешли от 40 экземпляров, постоянно работающих в облачных сервисах, к 150 потокам, работающим в любое время, с автоматическим масштабированием вверх и вниз по мере необходимости. Мы просто смотрим на то, что произойдет в ближайшие 3 минуты, и масштабируем наши потоки на основе этого.

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

Теперь очевидным недостатком является то, что мы в основном возвращаемся к старому образу мышления, а используемая нами облачная инфраструктура — это не что иное, как виртуальная машина. Что, если это одно приложение выйдет из строя или компьютер перезагрузится? Что происходит, когда нам требуется больше вычислительной мощности? Как нам легко развернуть одно запущенное приложение WinForm? (Мы используем развертывание octopus, и оно выполняет только службы Windows) Как мы справляемся с 8 различными EXE-файлами, запущенными на рабочем столе?

Мы знаем, что должен быть лучший способ, при котором мы можем автоматически масштабировать один поток на основе нашей текущей рабочей нагрузки. Также, когда это выполняется в облаке, поэтому мы не ограничены управлением виртуальными машинами.

Я потратил добрых 6 часов на чтение service fabric, и это кажется отличным шагом в правильном направлении, однако я все еще не могу найти ни одного документа, который описывает наш вариант использования и лучший способ его настройки.

Как мне создать систему, которая автоматически масштабирует экземпляры одной задачи (потока) по мере необходимости, и когда каждая задача выполнена, решает, следует ли ее сворачивать, поскольку она больше не нужна? Я знаю, что мне понадобится родительский работник, который запускает эти экземпляры и сообщает каждому, нужно ли ему завершать работу по завершении. Однако я не могу найти никаких примеров кодирования / документов подобного проекта, который использует Azure.

Отличным вариантом использования был бы отправитель электронной почты:
— У нас есть приложение, которое помещает электронные письма в очередь с расписанием выхода.
— У нас есть второе однопоточное приложение, которое извлекает следующие 30 готовых к работе элементов из очереди и отправляет их.
— Что происходит, когда кто-то добавляет 25 000 элементов в очередь прямо сейчас? Мы хотим, чтобы электронные письма отправлялись, когда они должны, но как нам масштабировать это единственное приложение с 1 потоком, чтобы иметь несколько экземпляров. Как нам затем уменьшить количество потоков, которые больше не нужны после завершения?

Спасибо

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

Затем просто переместите элементы из очереди ожидания в «активную» очередь, когда вы хотите, чтобы они были использованы. На этом этапе вы можете рассчитывать на масштабирование экземпляра для использования рабочей нагрузки из активной очереди. Платформа, которую вы используете для выполнения рабочей нагрузки, является вашим выбором — функции, веб-задания, пакет и т.д.; Однако вы могли бы использовать приложения logic, чтобы помочь координировать часть рабочего потока и перемещать сообщения между очередями.