Расскажу как разрабатывать сервисы для сервисной архитектуры, грамотно деплоить сервис на несколько серверов и знать когда что-то отвалилось.

Unitemp – это офф-лайн стартап с IT составляющей.

Мы большое HR-агенство и наша цель – закрывать позиции синих воротничков в больших компаниях. В крупные таксопарки Москвы мы направляем таксистов, а таким гигантам как Ашан, X5 Retail Group и ВкусВилл мы направляем кассиров, а для Delivery Club мы ищем курьеров.

Рынок новый и неизвестный, поэтому каждый месяц бизнес проверяет новые гипотезы и делает пивоты.

Нам всего 8 месяцев, но за это время мы уже успели обрасти большой кодовой базой. И та функциональность, которую мы реализовали 4 месяца назад, уже неактуальна для текущих бизнес процессов. Бизнес изменил вектор развития и нашему IT-отделу нужно автоматизировать что-то новое.

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

Цель данного доклада рассказать о том, как мы в Unitemp строим наш бэкэнд, используя сервисную архитектуру.


Разработка.

Мы используем Docker для dev-окружения. Каждый сервис имеет Rest Api и документацию на RAML. При разработке одного сервиса, запросы к другим сервисам мокаются.

Каждый сервис имеет 3 API:
- client, для мобильного приложения;
- admin, для админ-панели;
- server, для server-server коммуникации между сервисами.


Эксплуатирование.

Каждый сервис деплоится на два типа серверов:
- web, обслуживает Rest Api;
- bot, на нём выполнятся cron-скрипты и запущены демоны.

Каждый сервис имеет как минимум по два web и bot сервера для high availability.

Для деплоинга мы разработали свой собственный инструмент – Catapulta. В корень сервиса разработчик кладёт файлы deploy.yml, в котором описывает:
- nginx locations
- cron tasks
- daemons

Для демонов указываются веса и количество инстансов.

При деплое, Catapult видит список серверов для сервиса, расчитывает балансировку и для каждого сервиса выдаёт свои конфиги для crontab и supervisord. One-time команды и миграции она отдельно проигрывает на maintain-сервере.

После деплоя шлёт уведомления в telegram и slack – отдел маркетинга счастлив, когда быстро получает уведомления о деплое новых версий лендингов.

Все запросы проходят через Api Gateway на Nginx, который через upstream'ы проксирует запросы на web-сервера сервисов.

Для Api Gateway написан SDK, которым пользуются все сервисы, чтобы делать запросы друг к другу.


Мониторинг.

Для мониторинга Redis, Postgres, Rabbit и самих железок используется Prometheus. Графики смотрим в Grafana.

Каждый инстанс сервиса имеет health-check url, который опрашивается Prometheus. Помимо доступности Redis, Postgres, Rabbit, health-check выдаёт внутреннюю статистику своей работы. Так, если это сервис нотификаций, то он показывает количество sms, email и push-нотификаций, которые через него сегодня прошли, что позволяет показывать красивые графики для бизнеса.

Логи со всех сервисов уходят в Logstash и выводятся в Kibana.