- PVSM.RU - https://www.pvsm.ru -
На днях мы порелизили новую фичу — Дорожные события в навигаторе. Теперь пользователи мобильных приложений могут не только посмотреть на дорожные пробки и места расположения скоростных камер, но и участвовать в обмене информацией на дорогах: указать места ДТП, дорожных работ, перекрытий, а также просто пообщаться. Помимо указанных мест сориентироваться в ситуации помогут добавленные фотографии.
В статье расскажу, как мы разработали сервис, способный хранить миллионы фотографий и обслуживать тысячи запросов в секунду.
В 2ГИС очень много внимания уделяется контенту и его качеству. Один из типов контента — изображения. Перед нами часто возникают задачи:
Сервисов у нас прилично. И каждый раз всё делать заново и наступать на одни и те же грабли нам не хочется.
В один прекрасный солнечный день во время планирования к нам поступила очередная задача: в приложениях скоро появятся дорожные события. Помимо того, что их смогут создавать пользователи, к ним можно будет прикреплять фотографии, чтобы предоставить пользователям больше информации о ситуации на дорогах.
На тот момент ситуация с добавлением пользовательских фоточек в продукт подразумевала два варианта:
Выбор дался нам довольно тяжело: интеграция с сервисом Photo добавляла дополнительных неудобств всем участникам взаимодействия, а путь прямой интеграция с хранилищем — ещё один велосипед в рамках каждого сервиса. Кроме того, потребность в поддержке работы с изображениями была не только у Дорожных событий, но и ещё у нескольких фич.
Поэтому мы пошли другим путём — выделили специализированный сервис FileKeeper, который помимо базовых операций над изображениями:
Нужно отметить, что большую часть всех требований и решений удалось довольно быстро сформулировать благодаря опыту, полученному в ходе эксплуатации сервиса Photo.
Концептуальная схема нового сервиса, а точнее — группы сервисов:
На схеме изображены следующие элементы:
Архитектура понятна. Теперь стоит рассказать о том, как сервис можно использовать. Интеграция основана на следующих правилах:
Соблюдение таких правил упрощает реализацию, а также позволяет гибко управлять подключением новых провайдеров, предоставляя возможности задавать ограничения на свои данные и даже выбирать способ хранения.
Может показаться несколько странным, что загрузка файлов проходит через провайдер — дополнительное лишнее звено.
Причины такого решения:
Рассматривать все сценарии взаимодействия между провайдером и API довольно скучно. Наиболее интересный для разбора — загрузка изображений. Именно на нём и остановимся подробнее.
На входе имеем: ключ, выданный провайдеру для взаимодействия с FileKeeper API, набор изображений для загрузки и знание спейса, в который хотим положить все изображения.
Позитивный сценарий:
И всё было было бы хорошо, если бы все сценарии были позитивными, но…
Что-то может пойти не так?
Любая интеграция между разными приложениями приводит к большому количеству нюансов и мест для удара головой: недоступность сервиса, сетевые задержки, разрывы соединений, заканчивающееся место на диске, приход OOM-киллера.
Большую часть всех проблем можно разбить на группы, которые как раз соответствуют каналу взаимодействия совместно с «сервисом-приёмником». Рассмотрим их по порядку.
Отказ FileKeeper API (1) может возникнуть вследствие недоступности сервиса, таймаута подключения или ошибки при разборке и проверке корректности запроса.
Отказ может быть чреват только тем, что запрос будет отвергнут на старте обработки и провайдеру придётся его обработать.
Отказ PG HA (2) может возникнуть из-за некорректного sql-запроса, нарушения ограничений целостности, установленных на уровне БД, разрыва или сетевых проблем.
В данном случае обработать ошибку должен не только провайдер, но и сервис FileKeeper API.
Отказ Ceph (3) может возникнуть как из-за сетевых проблем, аналогично предыдущим вариантам отказов, так и из-за отказа в обслуживании по причине некорректности ключей доступа, отсутствия доступного места, недостаточности прав для записи.
Отказ более проблемный, нежели предыдущие два, так как в PG HA уже есть запись о файле, а привести её в активное состояние не получилось — так появился «зомбированный» файл. Это как раз тот случай, когда нужно и ошибку обработать, и данные почистить. Чистка мусора после таких проблем — одна из задач Recycler.
Причины отказа PG HA (4) аналогичны (2), последствия и их разрешение подобны (3).
Существует ещё один вид — отказ провайдера принимать ответ (5). Произойти он может по причине срабатывания таймаута на обработку запроса на стороне провайдера.
Такие отказы тяжело системно обрабатывать, так как разрыв соединения находится вне контроля сервиса. Ликвидация корректно обработанных запросов, которые не дошли до инициатора, может осуществляться через мониторинг, а также путём периодической сверки хранимых файлов и файлов, о которых знает провайдер.
Релиз Дорожных событий прошёл успешно. Теперь самое время подумать о том, чего удалось достигнуть и куда двигаться дальше.
Помимо очевидного, реализовав FileKeeper мы:
Автор: shnellpavel
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/278733
Ссылки в тексте:
[1] Ceph: https://ceph.com/
[2] Источник: https://habr.com/post/354248/?utm_campaign=354248
Нажмите здесь для печати.