Опыт использования NoSQL решений на реальном проекте с микросервисной архитектурой (MSA)

• > 15 000 RPS IO each
• Десятки миллионов активных задач

• Гарантированность выполнения

• Отказоустойчивость

• Масштабируемость горизонтально

• Модульность

• Высокая производительность
• 3 x 4 CPU 1 GB RAM

Легко!

• Автоматически дописываем задачу в crontab с нужным временем и запросом
• cron будет сам дергать какой-то наш скрипт с указанными параметрами, а скрипт будет отправлять запрос на камеру

0 5 * * * node ~/script.js -request {"method": "GET", url: "http://google.com"}

Возможные варианты:

• Переписать на

• Найти блокеры и bottlenecks и устранить

Database

1. Для задач нужно persistent хранилище с удобным доступом
   • Это хранилище должно быть быстрым
   • Нужны репликация и шардирование
   • В текущей схеме в общем-то нет реляций, нам нужна лишь коллекция задач
   • Запрос может быть разный, в зависимости от интерфейсов того, кто создает задачу, отправляет непосредственно запрос и т.д., то есть нам бы очень хотелось schemaless
   • У нас нет особых требований по аналитике - в основном это поиск и фильтрация по статусам/датам

Database

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

• Репликация и шардирование из коробки
• Достаточно высокая скорость вставки и выборки
• Нормально справляется с миллионами документов
• Схема коллекции может быть очень гибкой
• Агрегирование данных
• MapReduce

Services

2. Мы должны гарантировать выполнение задач, и иметь возможность горизонтально масштабироваться

Наше приложение можно разбить на следующие сервисы:

- Relay Service. Предоставляет REST-API (endpoint) для работы с нашим сервисом.

- Scheduler Service. Отвечает за непосредственно планирование выполнения задач.

- Request Performer. Умеет отправлять HTTP-запросы

- Watcher. Следит за тем, чтобы все задачи действительно выполнялись.

Services

Сервисная шина спешит на помощь.

- Все сервисы общаются только через нее. Это дает нам независимость сервисов друг от друга

- У каждого сервиса есть свой канал. Если мы хотим что-то сказать сервису, то нам достаточно "послать сообщение" в этот канал.

- Каждый сервис предоставляет из себя кластер из воркеров. Это дает

• горизонтальную масштабируемость - расширяем кластер, добавляем новый воркер

• отказоустойчивость. если кто-то упал, остальные продолжают работать и забирать сообщения

• производительность. кто-то сильно занят - работу сделают другие

Service Bus

В свою очередь, шина должна быть

• Персистентной
• С высокой пропускной способностью
• Поддерживать Pub/Sub, MQ
• Быть весьма быстрой
• Уметь масштабироваться

По сути, шина становится самой критичной точкой отказа и "боттлнеком" сервиса (не считая БД).

И очень бы хотелось спокойно спать по ночам :)

Service Bus

В качестве шины будем использовать еще одно NoSQL решение:

• Умеет Pub/Sub
• Пропускная способность инстанса - 80 000 rps
• Может быть персистентным
• В качестве MQ будем использовать List (lpush/brpop), он же и выступит в качестве балансировщика нагрузки
• Есть redis-cluster (хотя пока еще не очень)
• Есть время жизни ключей (TTL)
• И умеет еще очень много чего полезного :)

const waitForNewTask = () => redis
  .brpop([redisChannel.newTasks, workerId], 0)
  .then(([, message]) => {
    handleTask(message);
    waitForNewTask();
  });

Ожидание задач от шины

export function send(command) {
  if (getConnectionsTotal() < connectionsLimit) {
    sendRequest(command);
  } else {
    redisPusher.lpush(
      redisChannel.workerRequests, 
      JSON.stringify(command)
    );
  }
}

Отправка события в шину

Что же в итоге вышло?

Итоги

• Выбирать инструменты нужно исходя из задач и проблем
• NoSQL решения также могут себя проявить в совершенно неожиданных ролях, казалось бы, не слишком связанными непосредственно с базами данных (спасибо термину за это)
• Есть некоторые клевые архитектурные паттерны, которые здорово покрывают класс задач, связанных с микросервисами, масштабируемостью и т.д., но надо помнить про п.1
• А еще наш пилотный запуск (перевод парка из 20 тысяч камер в исходное положение в 24:00) произошел как-то так: