Каковы ограничения / недостатки использования одной службы приложений azure для размещения нескольких приложений / микросервисов?

Question

Может ли кто-нибудь сказать мне или объяснить, каковы ограничения / недостатки развертывания нескольких микросервисов (скажем, 2-3) на одном сервере Azure AppService?

Для достижения следующих целей мы используем микросервисы

• Служить одной цели или нести единоличную ответственность
• Иметь понятный интерфейс для коммуникации
• Меньше взаимозависимостей
• Может развертываться независимо без влияния на остальную экосистему
• Может масштабироваться независимо
• Может давать сбой
• Разрешить вашим командам работать независимо, не полагаясь на поддержку и услуги других команд
• Допускаются небольшие и частые изменения
• Меньше технических долгов
• Более быстрое восстановление после сбоя

Но как работает служба приложения Azure, когда мы пытаемся развернуть один из микросервисов? повлияет ли это на другие микросервисы? можем ли мы использовать это в производственных средах?

Я наткнулся на несколько ссылок, по которым размещаются несколько приложений в одном сервисе приложений, определяя виртуальный путь для windows и для linux, добавляя azure хранилище, но это лучше / хорошая практика?

Answer 1

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

Вы можете размещать множество приложений по одному и тому же плану, если этот план предусматривает достаточно памяти / ЦП / сетевых ресурсов для удовлетворения совокупных потребностей этих приложений. Для нескольких небольших приложений при небольшом размере плана не должно возникнуть проблем с обработкой всех из них в производственной среде. Основным преимуществом комбинации является экономия затрат, поскольку тарифный план - это единица оплаты, а не приложения.

Microsoft документирует некоторые причины изолировать приложения по отдельным планам:

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

Исходя из моего опыта, я бы добавил несколько соображений:

• Развертывание и перезапуск приложений могут вызвать скачки ЦП для плана (что является сервер). Если ваши приложения чувствительны к производительности и вы часто развертываете их, вам может потребоваться большее разделение
• Azure для обслуживания требуется перезапуск серверов не реже одного раза в месяц или чаще. Если все ваши приложения используют общий план, перезагрузка патча может означать, что вся система не работает и все приложения конкурируют за ресурсы при одновременном запуске
• Я обычно использую отдельные планы в качестве границ среды, поэтому производственный план отдельно от плана тестирования. «Тестовые» приложения go в плане тестирования, «Профессиональные» приложения в производственной среде, чтобы тестирование не повлияло на пользователей.
• Azure Функции могут лучше подходить для размещения множества микросервисов

Answer 2

Нет, это не так. Они будут соревноваться за вычислительные ресурсы, и в случае отказа оборудования все они go отключатся.