Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Преимущества и недостатки
микросервисной архитектуры
в HeadHunter
Иванов Антон
SRE team lead
СПОЙЛЕРЫ
● Микросервисы упростят жизнь в одном, но усложнят в другом
● Важно смотреть на эффект для компании в целом
● Дал...
ОБО МНЕ
● ~ 2 года — просто разработчик в HeadHunter
● ~ 2 года — тимлид команды SRE (Site Reliability Engineering)
3
НАША АРХИТЕКТУРА
2006
Монолит
DB
Java
Struts
JSP
Torque
Memcached
5
ПЕРЕХОД К СЕРВИСАМ
Монолит
DB
Search
Banners
DB
HHID
DB
6
КАК СЕЙЧАС
hh.ru m.hh.ruAPI
Correktor
Recommen
dations
MLHHID ...
Монолит SearchBannersSession Responses
Integration
7
ЧТО КРУТО?
ЧТО КРУТО?
● Декомпозиция монолита
(несколько простых сервисов с явным API проще монстра-монолита)
● Проще тестировать
(за...
ЧТО ЕЩЕ КРУТО?
● Независимая деградация
(когда лежит сервис А, сервис Б продолжает работать)
● Независимое масштабирование...
ЧТО НЕКРУТО?
ВЕСЬ КОНТЕКСТ ЗАПРОСА
Сервис А:
● сделал то
● сделал се
● сходил туда
● сходил сюда
● ошибка
Сервис Б:
● сделал то
● сдела...
ВЕСЬ КОНТЕКСТ ЗАПРОСА
● Присваиваем каждому пользовательскому запросу идентификатор
● Ищем все логи по идентификатору с по...
RPC ТЯЖЕЛЕЕ ВЫЗОВА МЕТОДА
Железо дешевое,
а его обслуживание?
https://github.com/AntonIvanov87/java-benchmarks/tree/master...
RPC СЛОЖНЕЕ ВЫЗОВА МЕТОДА
● Пулы соединений, пулы байт-буферов, эвент-лупы…
Все это — много непростого кода с множеством н...
РАСПРЕДЕЛЕННОСТЬ
Выделяя сервисы, вы сразу попадаете на сложности распределенных
систем: отказы, таймауты, ретраи, дубли и...
таймаут 2 сек
balancer
service A service A
balancer
service B service B
balancer
service C service C
● Все запросы на serv...
ЦЕРЕМОНИЯ: НОВЫЙ СЕРВИС
● Выбираем на чем писать, дописываем под себя
● Упаковываем (деабинизируем / докеризируем / ...)
●...
ПОДДЕРЖКА В АКТУАЛЬНОМ СОСТОЯНИИ
● Решили замониторить походы в memcached
○ Выделяем библиотеку hh-memcached-client
○ Прох...
ТРАНЗАКЦИИ
Иногда хочется межсервисных транзакций...
20
ТАК ЛИ КРУТО, КАК КАЖЕТСЯ?
21
ЕСТЬ ЛИ ЕЩЕ СПОСОБЫ ДЕКОМПОЗИРОВАТЬ?
● ru.hh.dao
○ public VacancyDAO
○ public ResumeDAO
○ public UserDAO
○ ...
● ru.hh.ser...
“ПРОЩЕ” ТЕСТИРОВАТЬ
Протестировать сервис — хорошо, а как протестировать всю систему?
Сложные стенды, в которых нужно разв...
“НЕЗАВИСИМЫЕ” РЕЛИЗЫ
Предположим, вам нужно изменить API одного из вызовов сервиса C:
● релиз C с совместимым API
● релиз ...
“НЕЗАВИСИМАЯ” ДЕГРАДАЦИЯ
● Лежит сервис поиска
○ лежит половина сайта
● Лежит сервис откликов и приглашений
○ лежит полови...
“ОТКАЗОУСТОЙЧИВОСТЬ”
● Сетевой вызов упадет с бОльшей вероятностью, чем внутрипроцессный.
● База данных каждого сервиса то...
СЛОЖНОСТИ МАСШТАБИРОВАНИЯ
● Виртуалки, docker, оркестрация…
● “Независимое” масштабирование круто,
когда требуется специфи...
ВОЗМОЖНОСТЬ ПРОБОВАТЬ ТЕХНОЛОГИИ
● Зоопарк технологий
(где-то Spring, где-то Guice, надо знать оба)
● Зоопарк подходов
(гд...
КОМАНДА-ВЛАДЕЛЕЦ
● В некоторые сервисы пишут все
● SRE быстрее реагирует на проблемы, чем бизнес-команда-владелец,
у них —...
Все проблемы микросервисов решаются,
для этого не требуется rocket science,
хотите ли вы их решать?
30
КАК ПИЛИТЬ?
31
ГОРИЗОНТАЛЬНО VS. ВЕРТИКАЛЬНО
● Слой не самодостаточен
● Много сетевых походов
● Максимум боли
● Минимум профита
● Сервис ...
hh.ru m.hh.ruAPI
Монолит SearchBannersSession Responses
Integration
33
Сервисная архитектура должна соответствовать
бизнес-фичам.
34
Спасибо.
Вопросы?
an.ivanov@hh.ru
Upcoming SlideShare
Loading in …5
×

Преимущества и недостатки микросервисной архитектуры в HeadHunter / Антон Иванов (HeadHunter)

759 views

Published on

РИТ++ 2017
Зал Конгресс-холл, 5 июня, 12:00

Тезисы:
http://ritfest.ru/2017/abstracts/2749.html

Раньше HeadHunter был большим монолитным приложением. Несколько лет назад мы приняли решение выделять из него микросервисы. За несколько лет мы поняли, что микросервисы - это не серебряная пуля и при неправильном "распиле" создают существенные проблемы: сложность разработки, деплоя, эксплуатации и др. Иногда эти проблемы сводят на нет преимущества от использования микросервисов.

В докладе хочу взвесить преимущества и недостатки микросервисов при вертикальном и горизонтальном делении на микросервисы.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Преимущества и недостатки микросервисной архитектуры в HeadHunter / Антон Иванов (HeadHunter)

  1. 1. Преимущества и недостатки микросервисной архитектуры в HeadHunter Иванов Антон SRE team lead
  2. 2. СПОЙЛЕРЫ ● Микросервисы упростят жизнь в одном, но усложнят в другом ● Важно смотреть на эффект для компании в целом ● Далее опыт и мнение 2
  3. 3. ОБО МНЕ ● ~ 2 года — просто разработчик в HeadHunter ● ~ 2 года — тимлид команды SRE (Site Reliability Engineering) 3
  4. 4. НАША АРХИТЕКТУРА
  5. 5. 2006 Монолит DB Java Struts JSP Torque Memcached 5
  6. 6. ПЕРЕХОД К СЕРВИСАМ Монолит DB Search Banners DB HHID DB 6
  7. 7. КАК СЕЙЧАС hh.ru m.hh.ruAPI Correktor Recommen dations MLHHID ... Монолит SearchBannersSession Responses Integration 7
  8. 8. ЧТО КРУТО?
  9. 9. ЧТО КРУТО? ● Декомпозиция монолита (несколько простых сервисов с явным API проще монстра-монолита) ● Проще тестировать (застабил внешние походы и вперед) ● Независимые релизы (когда хочу, тогда тестирую и выпускаю свой сервис) 9
  10. 10. ЧТО ЕЩЕ КРУТО? ● Независимая деградация (когда лежит сервис А, сервис Б продолжает работать) ● Независимое масштабирование (закупаем серверы только под те сервисы, которые нужно отмасштабировать) ● Возможность пробовать новые технологии (небольшой сервис переписать проще) ● Команда-владелец (отвечает за сервис, заинтересована в поддержке и развитии) 10
  11. 11. ЧТО НЕКРУТО?
  12. 12. ВЕСЬ КОНТЕКСТ ЗАПРОСА Сервис А: ● сделал то ● сделал се ● сходил туда ● сходил сюда ● ошибка Сервис Б: ● сделал то ● сделал се ● сходил туда ● сходил сюда ● сделал тото ● вернул тото Сервис В: ● сделал что ● сделал то ● сходил ли ● вернул ли Сервис Г: ● сделал то ● сделал се ● сделал тото ● сделал сето Сервис Ж: ● сделал то ● сходил туда ● сделал се ● упал 12
  13. 13. ВЕСЬ КОНТЕКСТ ЗАПРОСА ● Присваиваем каждому пользовательскому запросу идентификатор ● Ищем все логи по идентификатору с помощью Graylog: ○ Много логов (1.3 TB / день) ○ 100% CPU на машинах Graylog ○ Много потерь ● Вложились в собственное решение (timestamped request id + бинарный поиск в логах) 13
  14. 14. RPC ТЯЖЕЛЕЕ ВЫЗОВА МЕТОДА Железо дешевое, а его обслуживание? https://github.com/AntonIvanov87/java-benchmarks/tree/master/rpc-benchmarks 14
  15. 15. RPC СЛОЖНЕЕ ВЫЗОВА МЕТОДА ● Пулы соединений, пулы байт-буферов, эвент-лупы… Все это — много непростого кода с множеством настроек ● Требуется думать, что будет при ошибках RPC Search client HH http client Async http client Netty 15
  16. 16. РАСПРЕДЕЛЕННОСТЬ Выделяя сервисы, вы сразу попадаете на сложности распределенных систем: отказы, таймауты, ретраи, дубли и т. д. 16
  17. 17. таймаут 2 сек balancer service A service A balancer service B service B balancer service C service C ● Все запросы на service C укладываются в 0.25 сек? ● Есть запас? ● Отдельные таймауты для “тяжелых” запросов? ● Как не завалить себя ретраями во время проблем с базой сервиса C? ● Что делать, если service A хочет ходить в service C напрямую? ● Что делать, если хотим не один ретрай, а больше? 1 сек 1 сек 0.5 сек 0.5 сек 0.25 сек 17
  18. 18. ЦЕРЕМОНИЯ: НОВЫЙ СЕРВИС ● Выбираем на чем писать, дописываем под себя ● Упаковываем (деабинизируем / докеризируем / ...) ● Настраиваем процедуру выкладки ● Настраиваем ротацию и заливку логов ● Настраиваем мониторинг и триггеры ● Подключаем систему мониторинга низкочастотных ошибок ● ... 18
  19. 19. ПОДДЕРЖКА В АКТУАЛЬНОМ СОСТОЯНИИ ● Решили замониторить походы в memcached ○ Выделяем библиотеку hh-memcached-client ○ Проходимся по 100500 сервисов и обновляем ● Решили отпинывать запросы, если сервис перегружен ○ Выделяем библиотеку hh-http-server-utils ○ Проходимся по 100500 сервисов и обновляем ○ Опять проходимся по 100500 сервисов и донастраиваем пороги срабатывания ● Часто выбираем 3-5 главных сервиса, на остальные забиваем ((( ○ Потом таки надо обновить и долго обновляем, перепрыгивая несколько версий 19
  20. 20. ТРАНЗАКЦИИ Иногда хочется межсервисных транзакций... 20
  21. 21. ТАК ЛИ КРУТО, КАК КАЖЕТСЯ? 21
  22. 22. ЕСТЬ ЛИ ЕЩЕ СПОСОБЫ ДЕКОМПОЗИРОВАТЬ? ● ru.hh.dao ○ public VacancyDAO ○ public ResumeDAO ○ public UserDAO ○ ... ● ru.hh.service ○ public VacancyService ○ public ResumeService ○ public UserService ○ ... ● ru.hh.resource ○ public VacancyResource ○ public ResumeResource ○ public UserResource ○ … 22 ● Пакеты (“папки”) классов по бизнес- фичам, а не по слоям ● Модули - коллекция пакетов - с явными зависимости от других модулей ● Потом проще выделять сервис
  23. 23. “ПРОЩЕ” ТЕСТИРОВАТЬ Протестировать сервис — хорошо, а как протестировать всю систему? Сложные стенды, в которых нужно развернуть все сервисы, откорректировать настройки (таймауты, например), а потом поддерживать. 23
  24. 24. “НЕЗАВИСИМЫЕ” РЕЛИЗЫ Предположим, вам нужно изменить API одного из вызовов сервиса C: ● релиз C с совместимым API ● релиз B с совместимым API ● переключение A на использование нового API ● выпиливание старого API из B ● выпиливание старого API из C service A service B service C 24
  25. 25. “НЕЗАВИСИМАЯ” ДЕГРАДАЦИЯ ● Лежит сервис поиска ○ лежит половина сайта ● Лежит сервис откликов и приглашений ○ лежит половина сайта ● Лежит сервис сессии ○ лежит весь сайт 25
  26. 26. “ОТКАЗОУСТОЙЧИВОСТЬ” ● Сетевой вызов упадет с бОльшей вероятностью, чем внутрипроцессный. ● База данных каждого сервиса тоже отдельная? 26
  27. 27. СЛОЖНОСТИ МАСШТАБИРОВАНИЯ ● Виртуалки, docker, оркестрация… ● “Независимое” масштабирование круто, когда требуется специфичное оборудование. Server App Server App Server App Server App Server App Server AppApp App App App App AppApp App App 27
  28. 28. ВОЗМОЖНОСТЬ ПРОБОВАТЬ ТЕХНОЛОГИИ ● Зоопарк технологий (где-то Spring, где-то Guice, надо знать оба) ● Зоопарк подходов (где-то юнит-тесты пишутся так, где-то — иначе) ● Гибко, но не единообразно. 28
  29. 29. КОМАНДА-ВЛАДЕЛЕЦ ● В некоторые сервисы пишут все ● SRE быстрее реагирует на проблемы, чем бизнес-команда-владелец, у них — свои задачи ● В SRE больше технологических знаний 29
  30. 30. Все проблемы микросервисов решаются, для этого не требуется rocket science, хотите ли вы их решать? 30
  31. 31. КАК ПИЛИТЬ? 31
  32. 32. ГОРИЗОНТАЛЬНО VS. ВЕРТИКАЛЬНО ● Слой не самодостаточен ● Много сетевых походов ● Максимум боли ● Минимум профита ● Сервис самодостаточен ● Мало сетевых походов ● Максимум профита ● Минимум боли 32 МОНОЛИТ Слой 1 Слой 2 Сервис 1 Сервис n
  33. 33. hh.ru m.hh.ruAPI Монолит SearchBannersSession Responses Integration 33
  34. 34. Сервисная архитектура должна соответствовать бизнес-фичам. 34
  35. 35. Спасибо. Вопросы? an.ivanov@hh.ru

×