Вступление
Я работаю с большими НПО, чтобы архитектировать их многогранные системы. Эти системы отвечают за распространение информации, сбор данных, анализ и источники и погружения в другие системы. Нашей ближайшей целью было создание информационной платформы (IP). MDP был сужен до следующего набора функций.
Целевая персона
IP был предназначен для 3 основных персонажей.
- Жители деревни
- Прямые потребители
- Низкие технологические возможности
- Языковые барьеры
- Различные устройства — размеры и возможности
- Нерегулярная полоса пропускания
- OPS Team
- Отвечает за обучение с использованием контента
- Отправка отзывов для контента от пользователей
- Обновления контента (ограниченное)
- Контент -команда
- В первую очередь ответственность за содержание
- Регулярные обновления контента
Требования
СМИ поддержка
Портал должен поддерживать различные типы носителей, которые включают, но не ограничиваются; Видео, цифровые книги, изображения, аудио (подкаст). Контент генерируется командой по маркетингу и образованию, которая затем загружается в общественный репозиторий для загрузки. Весь контент находится в открытом доступе.
Многоязычная и региональная поддержка
Сам контент универсален. Информация и инструкции изменяются на основе местного языка, диеты и доступности ресурсов. Портал должен поддерживать повторное использование контента, а также конкретный контент для конкретного региона. Простота управления данными портала со стороны контента была первостепенной.
Обновления на основе интервала
Контент -команда обновляет данные несколько раз в день. Однако не было необходимости делать обновления в реальном времени. Новый контент может отображаться в течение часа.
Аналитика
Измерение является основным для любого успешного развертывания, особенно для крупных и разнообразных. Мы учитывали необходимость гранулированного измерения для кликов, отскок, воспроизведения, пропускает сразу с первого дня.
3 -я сторона API
Контент для портала должен быть доступен для сторонних приложений для их внутреннего потребления. Интересная часть здесь заключается в том, что содержание по API совпадает с веб -сайтом, однако сторонние заявки должны быть задушены, чтобы избежать прокси или чрезмерного использования нашей конечной точки.
Окончательная архитектура
Помимо приведенных выше требований, нам также было поручено обеспечить экономическую эффективность наряду со скоростью доставки. Очевидным выбором была типичная трехуровневая архитектура, которая достигла бы большинства целей. У команды также был правильный опыт. Однако я решил пойти по другому маршруту. В недавнем прошлом я развернул архитектуру на базе JSON, которая хорошо сократилась с до 20 миллионов посетителей, но нигде не близко к сложности.
Я внес несколько изменений и раздал решение свободно по схеме сегрегации CQRS — Командного запроса. Все данные, которые необходимо было отображать (путь чтения), были основаны на файлах JSON, которые постоянно обновлялись через флот функций Lambda. С другой стороны, путь записи был проведен API Gateway (HTTP).
База данных происхождения
Это основные источники информации. Это может быть Google Sheet, Airtable, RDBMS -источники данных. Они обеспечивают фактические метаданные содержания и правила трансформации.
Потяните флот Lambda
PLF запустите либо на основе реактивного или расписания. Они извлекают данные из источников данных и объединяют их на основе правил. Вывод разделен на основе языка, региона, содержания и использования. Они генерируют файлы JSON в конце процесса и загружают их в ведро S3, используя соглашение, которое может понять веб -приложение.
Информационный портал (IP)
Построенный на CSS React и Tailld CSS, IP доставляет контент пользователям. Это легкий, отзывчивый PWA. Может работать с ограниченной полосой пропускной способности и работает по всем размерам дисплея устройства. Как только он загружается, он вытаскивает соответствующий JSON с сервера через CloudFront, в зависимости от региона и настройки языка. Все действия пользовательского интерфейса, такие как фильтрация и поиск, выполняются на стороне клиента. Размер каждого JSON управляется и использует агрессивное сжатие для быстрого доставки данных. Механизм автоматического перезагрузки в React (ReactsWr) гарантирует, что клиент переигрывает JSON каждые 15 минут или при перезагрузке страницы.
Клиенты API
Для 3 -го API контента мы используем основной шлюз API (APIGW). Используя метод APIGW, мы можем напрямую подключить метод GET к ресурсу S3. Это не требует клейкого кода или обработки. Это легко обрабатывается Apigw.
Используя планы API Keys & Plans, мы обеспечили доступ только аутентифицированных клиентов, а также оценили свои вызовы API.
Аналитика и читать
Все пути записи используют основные функции API -шлюза (APIGW) и Lambda для записи в DynamoDB. Мы захватываем все детальные события, такие как воспроизведение, загрузка, посещение и оценка их на сервер. Частичная потеря данных в порядке с ожидаемым объемом.
Мы создали внутренний портал для создания обратной связи с использованием, который был основан на данных в DynamoDB. В веб -приложении использовались конечные точки HTTP API в одном и том же APIGW, чтобы получить данные из DynamoDB.
Агрегатор ЛАБДА
Чтобы отслеживать и проанализировать изменения контента, мы развернули функции Lambda на основе Cron, которые вытащили текущий JSON в ведре данных и создали его снимок. Снимки были агрегированы в течение некоторого интервала времени и загружались в ведра S3. WebApp забрала последние совокупные данные и наметил их для просмотра администратора.
Результаты и заключение
Вся настройка заняла около 1,5 месяцев, чтобы построить. После развертывания мы никогда не нарушали бесплатный уровень многих услуг для обработки. Нашим самым большим центром затрат была передача данных. Мы также включили все краевые узлы для CloudFront, что стоило нам немного больше. Проблемы задержки были не существуют. Наш DR был довольно самостоятельно решен из -за того, что S3 стал нашим основным хранилищем данных, а DynamoDB был очень доступен, но не в критическом пути.
Окончательные примечания
У нас был конкретный вариант использования, который был подан довольно хорошо с нашим выбором дизайна. Это не может быть самой оптимальной архитектурой для более требовательных и в реальном времени приложений.
Оригинал: «https://dev.to/arifamirani/a-json-based-serverless-quasi-static-platform-ha5»