Появилась задача написать веб-сервис/API, который бы отдавал предварительно агрегированные данные (собранные из внешних источников) пользователям. Упрощенно, должно быть что-то вроде такого набора компонентов:
1. Сервис-сборщик, который просыпается по расписанию, собирает данные и кладет их в БД(например, 3 раза в день).
2. БД/хранилище.
3. Сервис/API для внешних пользователей, который бы просто забирал из БД.
4. Какой-то API для управления, чтобы, например, очистить БД, поменять расписание сборщика, еще какая-то настройка.
Из-за обилия функционала и неопытности, нужна помощь понять какой функционал Azure использовать для каждого компонента. Любой совет или ссылки на литературу подойдут. Возможно есть какая-то типичная архитектура для таких типов приложений.
Хотелось бы добавить, что есть опыт работы с AppServices, поэтому первое желанию было - все сделать на аппсервисах:
1. Аппсервис для сборки данных с некоторым набором АПИ (который бы просто засыпал и просыпался несколько раз в день)
2. Аппсервис-обертка для маленькой БД (sqlite)
3. Аппсервис для внешних пользователей.
4. Аппсервис с апи-оберткой для управления.
Но насколько это хорошая практика? (подозреваю, что плохая) Возможно есть инструменты, чтобы сделать это проще и правильнее.
Вариантов очень много, и очень хорошо что вы упомянули что знакомы с AppServices.
С учетом этого советую использовать AppServices, плюс managed database на ваш выбор - MySQL, Postgres, или, если очень любите - MSSQL.
Насчет 1 - я не очень знаю Azure, возможно в AppServices есть возможность сделать активацию по расписанию. Если нет, для молодых есть serverless, для консерваторов - постоянно бегущий AppServices или VM.
По хранилищу можно брать Azure Blob Storage. Оно выглядит как файловая система но имеет API несколько отличный от традиционного.
По поводу БД - можно брать Azure CosmosDb который вроде как совместим с API SQL, Mongo, Cassandra.
По другим сервисам не скажу. Там наверное много вариантов как что делать. Но ввиду отсутствия каких-то архитектурных мыслей - вы можете брать какую угодно набор сервисов и просто наблюдать производительность и смотреть на биллинг. Если где-то станет плохо - вот тогда уже и будет повод порассуждать. А так - недостаточно информации чтобы придумать что-то типичное.
Сложный
