16+
Воспроизвести
Видео

Преимущества и недостатки микросервисной архитектуры в HeadHunter

Антон Иванов
Тим лид команды SRE в Headhunter
  • Видео
  • Тезисы
  • Видео
РИТ++ 2017
5 июня 2017, Сколково, Россия
РИТ++ 2017
Запросить Q&A
Видеозапись
Преимущества и недостатки микросервисной архитектуры в HeadHunter
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
В избранное
52,44 K
Мне понравилось 0
Мне не понравилось 0
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
  • Описание
  • Расшифровка
  • Обсуждение

О спикере

Антон Иванов
Тим лид команды SRE в Headhunter

О докладе

Тематика: ИТ и технологии
Секция: Микросервисы

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

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

Поделиться

Я работаю в хантри с этим видом перед тем как я закончил рассказывать Кто есть там Я хочу немножко спойлеров про свой доклад чтобы понимали о чём я буду рассказывать И чего от него ждать первый тезис это что микросервисы упростят вам жизнь в одном Серьёзно усложняться вам жизнь в чём-то другом причём микросервисы затронут всю компанию не только отдел разработки на отдел тестирования отдел эксплуатации и тут Важно смотреть на эффект для компании в целом а я в своем докладе попытаюсь рассказать о том с какими проблемами столкнулись решение будет не очень много Хотя они тоже

будут мне интересно о том чтобы вы понимали с какими болячками С какими трудностями вам придется сталкиваться для того чтобы приходить на микросервисная архитектура Может быть вы Подумайте над тем Стоит ли вам это делается это сделать потом не делать вовсе Ну вот обо мне Я 2 года в хантри работал простым разработчикам и в течение этого времени был в общем ярым сторонником микросервисной архитектуры мне хотелось разделить абсолютно всё сказал что наступит светлое будущее потом я перешел работать в команду которая занимается

отказоустойчивости сайта и тут мое представление о том насколько классный microservices они стали более взвешенным я не говорю о том что это плохая архитектура Я говорю что у неё есть Вполне себе ограничения и вы можете извлечь преимущества и недостатки у меня Clicker плохо работает с этим можно что-то сделать О'кей чтобы представляли у нас был Монолит Вполне себе в 2006 году который был написан на Java на таких фреймворках как строят сгсп торг которым его

и половина этих технологий мы уже поменяли Монолит до сих пор у нас в каком ты виде остаётся он тогда ходил в мкр 3 база данных тогда мы использовали еще моя цель я говорю то мы использовали то по словам мне тогда ещё в центре не было но тем не менее Вот и потом мы стали от него отпиливать куски выделили отдельный сервис которые занимаются идентификации пользователя HD имя фамилия логина и пароля авторизации в соцсетях и так далее Всё сохранилось там и у него была отдельная база мы выделили отдельный сервис поиска собственно

отвечал за то что по поисковому запросу вернуть список Edition резюме или вакансии мы выделили сервис баннера в которых даже своя база была сейчас он разрабатывает вообще отдельная команда не просто отдельные команды отдельном разработчикам которые мне что-то контора находится это секс история это было здорово сейчас мы пришли к архитектуре у нас появилась ac3 фронтонных сервиса они написаны на питоне с использованием Торнадо это сервис который отвечает за то чтобы представлять опасность нашего сайта мобильным приложением

Инстаграм задача интегрировались нашим сайтом это собственно сервис который отрисовывает Основной сайт kp.ru и сервис который мобильный сайт у него он отвечает за мобильный сайт отдельная команда Хотя все они примерно одних и тех же технологий написан питон Торнадо плюс нас в Оренбург frantic у нас выделилось много микросервисов гораздо больше чем помещается на этот слайд среди них стомсервис откликов приглашений ат-сервис машинного обучения рекомендации это подобное я тут попытался какие-то стрелки нарисовать на самом деле это далеко не

все стрелки взаимодействия между сервисами какой-то момент мы поняли что у нас появляется очень много интеграционные логики Ну то есть простой пример надо отправить страничку результатов поиска вакансии надо сходить в сервис поиска поискать Одесская потом сходить в сервис вакансии и наложить на это всё данные название описание зарплаты и так далее и нас появляется сервис интеграционную логики в которые могут ходить фронтовые сервиса фронтовую сервиса могут ходить и напрямую в аккаунт если не интеграционная Лагунова там крутится такая трехуровневая архитектура

получилось Я этот слайд потом покажу ещё раз в конце мы с вами на него посмотрим то в этом сайте есть хорошего что в нём есть плохого Какие решения были хорошо приняты Какие решения были приняты не очень здорово Давайте с вами начали посмотрим Да посмотрим много всего написано есть много докладов о преимуществах микросервисной архитектуры Я хочу рассказать о том что мы чувствуем от микросервисной архитектуре что она мне нравится первая конечно декомпозиция Монолита понятно что там простые сервисы повнимательнее чем

один большой Монстр Монолит в котором непонятно всё как взаимодействуют А тут по крайней мере есть API и понятные связи между сервисами микросервисы Прочитай стирать то есть разработчику достаточно там установить какие-то бы внешних походов и вот тестировала он такой маленький в отличие от Монолита который там ещё куча тексту надо развернуть для того чтобы всё протестировать И не сфокусировать просто на на своем коде Независимый Лиза это кстати очень интересная история Особенно для нас

актуально была независимость релизов Когда у нас наши монолитное приложение religious раз в неделю Анатольевна каждый день получала допуск Елизавета монолитном раз в неделю эти времена уже давно в прошлом и людям каждый день но до сих пор команда отвечает что когда он есть собственный сервер за которой я могу вас посреди дня там собрать релиз протестировать его и там выложить в Протасово монолитом Я до конца дня придётся ждать Вот Ну вот до сих пор наша команда отмечает такое преимущество что ещё круто независимая деградация Ну понятно Если лежит сервиса и он не ошибся Там ведь стоит

обижаться только небольшого функциональность то пользователь это может даже не заметит независимая масштабирование У нас есть например сервис поиска которому требуется много много оперативной памяти естественно мы закупаем подниму специфическое оборудование под базы данных специфично оборудование А подруги сервису можно закупать другое оборудование Независимый масштабировать усиленные сервис возможность пробовать новые технологии угарать просто не возьмешь и не переписываюсь Монолит на новую технологию А тут удобно переписал сервисную технологию понравилось не понравилось раз

дальше этот успех или выпиливаем переписываем обратно и наконец есть такая мерзкая преимущества Я его называю что у сервис есть команда владелец есть кому обратиться кого попроси Вот и справились более того они сами даже заинтересованы в развитии этого сервиса в поддержке разборе инцидентов так далее Это хорошая история чего не круто с чем пришлось сталкиваться Ну первое это когда у вас Монолит у вас в принципе контекст запроса понятен вы смотрите в блоге гриппую там каком фильме фикатор получаете Блок Когда у вас много

сервисов вы будете крепость смотреть и не понимает что происходит с тоже происходило с пользовательским запросам этом придется разбираться это проблема решаема присваивается каждому пользователю запросу идентификатор какое-то вы поэтому идентификатору Ищите индексируются в теологии и щетина примерно пробовали внедрять горелок он там elasticsearch построен и тут надо понимать что у нас достаточно много блоков относительно Конечно вот там больше терабайта в и на тех машинах которые были выделены под брелок от меня были какие-то там тёлки

непонятные были железные мощные машины но них было 100% цепью на успевал индексировать просто филология и я шутила что он скорее иногда находят правило не находят Никаких никаких данных по запросам мы могли потратить время для того чтобы там его настроить это мы решили что мы перепишем сделаем сот О сейчас заработал которая основана на том что мы просто иди запросов при своем не абы какой А засовывал туда там стенд начала выполнения запроса Дальше можно увидеть что все

блоги упорядоченное и в общем-то алгоритм поиска он просто ты каемся в любой место Логу смотрим таймстамп этой строчке больше или меньше и так далее очень быстро находим нужное окно которое нужно просканировать для того чтобы все враги собрать Ну и так покажу могут и что интересно ну на страной сервис сервер на котором человек который сливается всеология Вот И там просто стоит несколько Вот таких простых демонов которые собственно и делают вот эту систему она не требует Никаких особенных ресурсов аксиология запросы показывает но опять же мы вложились написали

и над ней там трудились пара человек слайд который я долго думал вставлять камни вставлять потому что здесь есть Benchmark забить марку Сюда можно покритиковать да что он устроен неправильно вот но тем не менее я сначала разработчик который в общем считают что удаленный вызов это очень просто почти ничем не отличается от локального вызова И вам по этому поводу Очень классно доклад прочитал Очень советую его пересмотреть я от себя лишь добавлю что Ну какой путь проходит запрос он там пишется в буфер сокета стерилизованные

данные запросы пишется в буфер сок это в бустерах сетевой карты сетевых устройств продаются на может быть выделенное железной балансировщики может быть нет там раскрываются запрос крутится на конкретный сервер и дальше и так далее и тому подобное и это мы только достали запрос удалённый стороны дорожный сторона ещё сделать полезную работу какую-то дальше начнет обратный стилизовать ответы передачу и обратно по сети вот интуитивно кажется что если сервис выполняет очень мало Работаю но там сложение двух чисел например наверное не стоит этот удаленный поход делать

почти до 2:00 гораздо проще сложить локально Вот и поэтому вот я сейчас приду график того насколько быстрее медленные удалённые локальный вызов метода они там на самом деле делать какую-то работу по горизонтально расположенной работу которую он делает обмана а2010а график синяя линия этого-то сколько мы запросов в секунду умудряешься делать вызываемые прямую красная линия сколько запросов умудряешься делать типа делаю удаленный вызов на самом деле не совсем удаленный вызов я просто

КПП прослойку на локальный компьютер поставил Вот но собственно показывает наш overhead Ну видно что это играет конечно Чем дольше вас запрос тем тем он меньше относительно собственно полезную работу которая делается Вот Но всё равно на там когда у вас А2 А3 миллисекунды занимают этот euroheat будет достигать по камере там 20% Вот идут Интересно что многие разработчики опять в Ханты очень часто думаешь наши запросы занимают там 50 100 миллисекунд В общем сетевой вверх Атаман никакой вот на самом деле я там много раз смотрю вижу перцентили скорее мы ближе к началу этого график

1/3 1/3 секунды нас многие вот поэтому надо же есть там много выделенных серверов которые только занимаются тем что работу балансируют запрос давно столько настолько много на свете вызов и тут мне возражают на Антона это все лирика железо дешёвая надо дешевая в обслуживании то есть над этим же работает там служба закупок железо нужно что-то его закупил чтобы железо поставили настроили продолжали обслуживать это всё уже люди а люди стоят они не так дёшево Да вот поэтому вот есть такой баланс Ну интуитивно кажется опять же что если у вас малость походу стал как

бы Можно ли график не смотреть Ещё о чём хочется сказать это что РПЦ в принципе сложнее вызова метода что вот для того чтобы сделать удаленный вызов У нас есть целое семейство абстракции например там поисковый клиенток сервисы поиска Он построен на базе нашего хищного хттп клиента который в свою очередь базируется на базе клиентов Зато открытая открытая этапа Client Running который в свою очередь между прочим Не все знают используют найти под собой и так далее и тому подобное и всё это достаточно много не простого кода и хорошо когда

разработчик этого всего может удалить смотреть но у нас например команды сразу туда заглядывает периодически находит там много нового всякие будут соединения и улыбаюсь буферов ивент луп хотите ли вы об этом не хотите да Вопрос к вам и второе О чём здесь тоже надо сказать это то что РПЦ удаленный вызов он сложнее В том смысле что вам придется думать над тем А чего когда сервис не ответил и как он мне ответил реагировали на 500 Q также как реагировать на Ритейл Да вопрос иногда открытый у нас всякие баги в прозе случались связаны с тем что разработчики на вот так Что

считает что севернее ответил или ответил пустым ответом это одно и тоже нет это не одно и то же там разные бизнес-логика зависимость от этого должно было быть распределено я так просто скажу что вот когда вы гуляете сервисы вы тут же попадаешься на все проблемы распределенных систем отказы таймауты Retro дубли и так далее Будьте к этому готовы я приду Просто простой пример того как мы vsr-eu поругаемся по стройке все его цепочки вызовов сервисов очень простой пример смотрите у нас есть балансировщик которая звучит запрос на ну на 11 апреле на другой

сервер под сервисом aeserver б при котором тоже есть балансировщик там из сервиса и так далее Ну вот запросто для того чтобы быть обслужен он проходит вот такую цепочку и допустим вы хотите уложиться в твоём 2 секунды Ну там пользователю сказать через две секунды Извини не смог и дальше не хотите напрягать ваши инфраструктуру этим запросом Ну и кажется что вообще-то тайм-аут 1 балансировщика до сервиса должен быть меньше чем 2 секунды правильно Ну потому что мы обнаружим что сервис недоступен нам ещё надо время переправиться для того чтобы его обслужил ну и так недолго думая

выставляем одну секунду тут Конечно можно порассуждать на тему Что это может быть где-то в районе от 1 секунды до 2 секунд Да потому что мы долго ждём крассервис не понимаем что он лёг а потом быстро миримся и собственно ответ получаем но там предположим одну секунду дальше это одну секунду мы разбиваем на полсекунды перед сервисом был там 250 миллисекунд перед сервисом C дальше начинаются интересные вопросы все запросы сервисы укладывается в 250 мл причём это не должно быть там Катя 999 представителю вас учитывать углы которые просто тяжёлые есть у вас запас Вы же не хотите

запускать в вашей системе лавину retrieve только потому что у вас чего ты там притупилась цели недельный тайм-аут для тяжёлых запросов вы хотите прописывать отдельно в конфиге ли вы что вы с ним будете делать как не завалить себя retrywhen вовремя проблем с базой eservices вас в базу сервисер тупит у вас там первый сервер не ответил послала Генри трейлер и вторую сервис тоже не ответил потому что пить то базу подниму Вот и ваша система всё завалено литрами А тут опять же необходимо настраивать цепочку retrieve так чтобы вы понимали что произошло 333333 уже не нужно в это вкладываться что

делать если сервиса хочет ходить в лице напрямую как там тайм-аут отстроить Что делать если мне 13 а там неотам 23 больше такое тоже бывает необходимо Ну вот просто вот весь этот Круг вопросов вам придется продумывать даже заходить использовать какое-то решение вы должны будете понимать что она работает именно так как вам нужно есть некоторые церемонии связанные с новым сервисом Да я как считал что я сейчас выберу фреймворк я буду писать Допиши его под себя всё и он будет вроде Ага упаковываем тебе не делаем да Перезимуем настраиваем процедуру выкладки настроем ротацию

заливку логов настроем мониторинг 3G включаем систему мониторинга низкочастотных ошибок потому что на мониторинге увидите высокочастотное ошибки А у вас что случается Новокаин торгсиб жена и выход за пределы массива Вы тоже Сходить посмотреть на вашем коде и так далее и нет каждый из этих проблем она очень там никакого рокицани требует для решения и там например Насти система которая автоматизирует сборки любого приложения просто вопрос добавление сервисный запрос добавление конфиг в эту систему вот так далее но тем не менее решите для себя хотите ли вы в это

ввязываться или нет поддержка в актуальном состоянии я опять же на примерах вот мы всё решили за мониторить походу в мкэш нам мониторинга то у которой сама можешь представляет мы хотели посмотреть А что же с этим происходит на стороне клиента на самом деле очень важной частью любой системы распределенной Это именно клиента вот Ну что мы выделяем библиотеку хнмк Идём по 100 500 сервис самообновляемых так чтобы в общем там за используют в библиотеку дальше Мы решили отпевать запросу Если через перегрузом перегружен опять же там зажимаем очереди от порога срабатывания

и все запросы которые приходят на сервис если он понимает что он перегружен он просто отдает сотку или вообще рвет соединение таким образом не заваливают себя еще больше О'кей выделяем хотят опасен вирус проходим всё по 100 500 сервисом обновляем здесь нет никакого Рокет сайнс опять же ничего в этом сложно это даже можно автоматизировать потом просто ещё придётся пройти по 100 500 сервис под настроить таймаут которые были неправильно настроены в самом начале и в общем мы конечно так никогда не делаем мы выбираем 35 главных сервис от которых реально у нас болит а всё остальное даём

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

и тут когда у тебя вот на про солдата и боли с которым мы столкнулись очень интересно посмотреть на те преимущества которые мы извлекли ли мы их точно или не всегда зависят например вот у нас был Монолит и мы хотели его декомпозировать и вот он устроен как-то непонятно есть пакет в котором Давай лежит закон всегда в режиме Tower которые занимались Пакет сервис в котором лежит тоже самое только там встреча с вакансии резюме юзер пакет ресурсов которая контролирует на автомат нюансов походов стерилизуют так далее Ну естественно Вот в этой структуре он совершенно не видна некая

структура приложения То есть каждый из этих папок на самом деле автосвалка из классов Да ничего более вот можно выделить папки которые будут соответствовать не технологическим слоям А бизнес причем конечно в предыдущем докладе Сергей правильно говорил что вообще вот эти барьера не тяжело то есть инкапсулирует в том смысле что придёт какой-нибудь город поставить паблик у того методом того класса который вы хотели инкапсулировать И всё И ваша ваша встроенная система инкапсуляции разрушена Вот но иногда бывают другие контраргументы против этого

аргумента говорят но я тоже хочу написать папе потом Нет ничего хуже чем разработчик с хорошей трудоспособностью он вам и переписок ты перепишет Вполне себе быстро вот а модуля Вы можете в воду льда коллекцию класса с чёрными зависимость между тоже по камере на какое-то время вам структурирует ваш Монолит Вот то есть есть способы декомпозировать Монолит Будет ли он работать не зависит от вам решать Ну да потом если вы хотя бы по папкам Разложите потом хоть проще сервис выделять Да они с каждой там пакета дёргать отдельный класс

Прочитай стирать Ну да заставил протестировать свои microservice выложил против вперед но иногда хочется протестировать всю систему в целом есть конечно подхода когда мы не тестируемые выкладываем сразу в продакшн Это нормальный подход между прочим Вот Но есть и всё-таки есть адепта более там консервативные которые читаются систему нужно протестировать целом и дальше Вы нарвались на сложные страны в которых нужно развернуть все откорректировать настройки у нас потом припрется кусок продакшена копируется его с помощью тех же

PlayBook авто с помощью там ансамбля на тестовый стенд просто корректируется Какие настройки для того чтобы структура тестового стенда она была абсолютно такая же как в пройденный за исключением того что в прозе там пятюню стоп Сервис Одесса 10 это всё на самом деле это достать работа чтобы чтобы создать такой стенд И поддерживать Независимый Лиза выше я упоминал Что отлично У нас каждый сервис Можно ли жить отдельно из-за этого каждая команда которая поддерживает работает быстрее чем если бы мы выпускали Монолит но Представьте себе что вы хотите изменить

а ты сердце кто он для этого нужно сделать Ну Завезите Services совместимости и там будет старый новый какое-то время будет работать и со старым с новым iservice бы тоже потом взгляд сервиса переключив его на использование нового API потом подальше дальше идем по сервисам боюсь функции выпиливаем старая и вроде как были независимы Лизун вот в этом случае Независимый тут вопрос Насколько часто колбасит в Ватсаппе А сколько Вам приходится реализации бизнес переписывать API Хорошо ли оно написано Или она может быть написано хорошо просто там свечу вас такие что

меняют вашу систему достаточно часто и там сервис тестирование много бета тестирование проводится и так далее это всё открытые вопросы тут нету прямо каких-то рецептов независимая деградация Да очень круто когда лежит какое-то сервис и пользователи этого не замечают но Представьте себе что ваш сервис поиска А так по поиску работы поиск сотрудников в него лежит сервис поиска что этот сайт но с сайта читайте лежит вот серый сорокопут приглашение Да работодателя могут пригласить соискателя работа соискатели может откликнуться читаем Что такое сайт

работает нет А если у вас лежит в сервисе который собственно отвечает за то чтобы узнать пользователя Да его там информацию имя фамилия емаил так далее передать вообще бы когда-то мы считаем что вообще оставить не работает никто с ним работать может ты что-то вопрос К тому насколько насколько важна Ваша национальность который вы хотите деградировать если она настолько важна что ватсап перестанет работать то как бы польза от того что вас Независимо деградации вы особо не излечивать отказоустойчивость Многие считают что монолиты ужасно падучая

там происходит затрагивает сразу весь монолиты всё падает на практике я видел что скорее проблема вызывает вызывает сетевые походы они падают с большей вероятностью чем что-то происходит внутри Монолита более того вот у нас в хантри до сих пор Монолит сохраняется и Честно говоря я на практике очень редко видел чтобы реально там какая-то проблема в одном месте затронула всё вот нас бывали downtime из-за того что же там жульен Плохо работал из-за этого болит но это не были проблемы там скажем какой-то бизнес функциональностью это были чисто технологические

проблемы и задачи вопроса Богдан база данных вашего microservice отдельная об этом говорили тут я хочу подчеркнуть что ты должна быть отдельная железка потому что вот ну там до Башни чтобы сэкономить на обслуживании то мы вообще на инфраструктуре Вполне себе установить вашу базу данных на одну и ту железку и вот нас в хантри периодически происходит маленький Dawn тайники противная когда 1server завалил жёсткие диски базы И в общем это падение других сервисов про масштабирование да у вас есть возможность независимо от масштабировать ваши

микросервиса или макро сервис и неважно что происходило в случае с монолитом вы брали просто оставили ещё один серебристой листвой жирное приложение туда правда очень простая масштабирование неправда интересное когда прогнала тут доклад мне возразили ну подожди твоё монолитное приложение может разрастись до таких размеров что она просто не влезет на север и показалось то что это рассказывал на команду которая разработала тестовые стенды на которых стоит свечка vkontakte.com мини копия всего хандра совсем микросервисами что даже туда же всё влезает в какой момент

Монолит станет настолько монолитом что он не влезет на современное железо Я не представляю что вы делаете микросервисами Ну да вы берёте микросерой оставить его на железку желательно в 3 для того чтобы обеспечить отказоустойчивость 0 2 4 автомат вашей компании зависит Но всё равно загружены Да поэтому вы добавляете туда ещё приложением описываете и ввязывается историю с виртуальными докером кастрации так далее у нас раньше были виртуалки у нас от них болела большой overhead мы переводим сейчас продакшена docker у нас многие сервисы в продакшене вдоль и мне кажется что недалек не так

вот тут-то светлое будущее когда нас будет оркестрация кубернетес или что-нибудь в этом роде вот на самом деле польза от независимого масштабирование вы извлекайте тогда когда вам действительно нужно независимо от масштабироваться а всё остальное напиши меня вот сервисов в железке это всё там скорее независимое масштабирование правого дозагрузка оборудования возможность пробовать новые технологии Очень классно когда у вас за каждым сервисом закреплено команда некоторые бизнес в хантри требует того чтобы изменить в сервисах что-то из-за этого

нас обычно отвечает То есть у нас выделяются команда под бизнес фичу Они под сервис иногда из-за этого болит команда приходит отправить сервис в чужой там Spring меня случился или двумя спринга им приходится с этим разбираться в этом нет ничего страшного на самом деле Потому что если понимать подходит а в общем конкретный фреймворк не так важен там начинается зоопарк подходов одна команда написала в одном сервисе так нет с другой по-другому Если у вас нету чёткого разделения команд по бизнесу сущностью и соответствую выделение микросервиса под бизнес сущность это вы попали

потому что вам будет ходить команды по сервисам и прописывать с помощью сервиса свою бизнес свечу гибка но не единообразно команда владелец в некоторые сервисы пишут все обычно это указывает на то что сервис Apple мы-то понимаем вот есть другая штука что если я например у нас отдельно есть команда которая занимается до отказа устойчивостью реагируют на проблемы быстрее чем бизнес команды владельца этого потому что у них свои проблемы у них там деноминация в Беларуси надо срочно переписать Весь billing вот а

там то что вам там у вас там стоит падает это уже там как-нибудь сами разберитесь вот и всё просто чисто больше технологических знаний и нам физически просто работать с монолитом потому что мы там что-то что-то что-то там исправимый сразу всё работает вот а пройтись по всем кому ещё донести до них те знания которые мы получили от непростая Задачка мы регулярно в канаву проводим митапы Димки Там и так далее и тому подобное вообще-то все проблемы микросервисов не требуют Рокет сайнс для решения и зависит от вас Хотите в это ввязываться или нет как раз На мой взгляд находится Вот такая

у нас очень много адептов микросервисной архитектуры которые говорят да Антон давай уже да пилим всё вот а есть люди которые говорят да ладно Поживём ещё у нас там скорость роста просто технологических хэдхантер не такая большая чтобы там вкладываться в микросервиса настолько чтобы мы стали из этого пользу извлекать вот и тут интересно посмотреть на то что я рассказывал и большую часть вывели что я рассказывал мне про преимущества продам скажем недостатки на самом деле недостатки очень легко нивелировать если плит микросервисы правильно правильно вот вас есть монолитов которые приходят

запросы у нас обслуживают отдает обратно ответы и вы можете поделить на слои появляются условий фронтенда как у нас есть Ханка который там занимаются обход там походом по командам наложение на всё это дело там шаблонизация и так далее и у вас есть свой бэндов который собственно отвечает за взаимодействие с базой данных слоев может быть много Да у нас ещё интеграционной в этом в этом пироге вот что здесь плохо с каждый слой это ну он с точки зрения бизнеса нет самодостаточен в том смысле чтобы не выпустить бизнес в одном сервисе Вам приходится пропивать вашу бизнес свечу сразу

через ногу слоёв у вас достаточно много этих походов он на каждый запрос наверняка будет один или несколько походов 102 надо больше у вас появляется максимум болеет всё ит-архитектуры потому что у вас походу много сервис ни за кем не закреплен независимые разработки независимых елизов вы не получаете пробовать новые технологии не можете А зато у вас походов многое систем распределенные Вот и в общем профита что если вы распилить его смотреть таким образом чтобы там были достаточно хорошо выделенная вертикальные

составляющие бизнес сущности не надо чтобы вас какую-то функциональность на сайте можно было просто сходи в 1С сервис предельно да тогда вы получаете в общем вот сервис самодостаточен его зарабатывает команда у вас мало сетевых подходов Желательно чтобы было мало конечно совсем их не станет Вызови каюте Maximum profit именем более это, конечно, предельные случаи Hunter гибрид. и вот например у нас есть секс история когда выдан Service API у него есть отдельная команда на его поддерживает да Это нет самодостаточной устройство командировке необходимо ходить в

иногда там что-то править но в принципе очень хорошо историю что он выделен как и с сервисом мобильной версии сайта интеграционную стоят на мой взгляд нашу боль потому что через него пропивает вся функциональность это практически ещё один Монолит или может быть просто отпускал общаюсь а там от изначального Монолита еще один сервис который там микросервисам ни в коем случае не является просто там инкапсулирует интеграционные логику Должна ли она быть отдельно или её можно было вставить в монолите это ещё там большой вопрос У нас вот я рассказывал если разборки сервис поиска который тоже

выделена Да они там баннер к обществу достаточно А через поиск не самодостаточна в том смысле что надо этой диски кому нужна и диски хочется посмотреть на вакансию в целом Да но тем не менее это там у нас который занимается танцами или машинным обучением процессом который этот сервис пишет А мы на ИЗО студия приходи мы говорим Ребят вы натравили потому что у вас там технологически неправильно Всё сделано Ну вот кажется я сказал почти всё что хотел если какой-то делать вывод из моей презентации наверное будет таким-то сервисная архитектура и архитектура должна

должна соответствовать прежде всего бизнес причем они представлениям О красиво архитектуре у меня это всё спасибо сейчас нас будут вопросы мне сразу в маленькой техническое замечание У нас есть у всех точнее у вас У нас у всех есть приложение мобильное и всем докладчикам будет очень приятно если в мобильном приложении будете там ставить пять звёздочек совсем конечно из-за четыре звёздочки будет хорошо и сотри можно котики да и все котики об осени в мобильном приложении будете тоже можно оценить

докладчиков я забыл вам сказать ногти были Кто был на предыдущих докладах пожалуйста оцениваете докладчиков Спасибо за доклад за такой практической изложение проблемы достоинств у меня такой вопрос Вот вот как раз последний слайды были Значит мы нарезаем приложение горизонтально и вертикально у меня Clicker перестал работать я не могу его показать хорошо там необязательно Вот в общем нас есть монолитный сервис у него есть монолитная вот которая имеет авторизацию как ну как обычно монолитных приложениях Ну один раз логин

пароль и весь функционал причём все админ как построена на базе фреймворка то есть построена средствами фреймворк то есть backend формируется и HTML CSS выбрасывает то есть кнопочки крут Всё сделано Да вот и когда мы будем в это дело на микросервисы Как быть админкой то есть если для бизнес ВИЧем Европе можно выбросить только 510 бизнес методов которые необязательно Круто Только е ты там ничего больше Да тут админ как правило требует много большего функционала Я крут по полной надо там параметр атрибуты и вот как быть

оставлять это написано на горках чудо всё да Или же через API этим управлять но там front-end писать Frontera A backend Ну и как там это взаимодействие как это устроено у вас и там соответственно Если какие если разность админки проблемы с авторизацией вот такой длинный вопрос Да у нас на самом деле итак итак Дело в том что у нас есть сервисы которые находятся под одной админкой есть команды которые пишутся все свои сервисы они решили свой собственно админку замутить Вот

и им это нравится У нас есть сервис который занимается узнаванием пользователя прям когда фронтовой запрос приходит нашу систему пользователь узнается и дальше все сведения об этом пользовать его правах так далее пробрасывается прямо заголовки http2 всё backend в этом смысле она стоит в ваканде Вот И поэтому это вполне себе можно посмотреть она что мне пришло вот такие-то права может сделать это не может сделать это И всё И те кто пишут сервис они в принципе не думают об админки думай только о правах которые предоставили предоставлена такая проблема что одному человеку

нужно сходить и туда и туда и туда и как это с сон то есть чтобы не надо было ему авторизироваться много раз и как Ну ответь единый сервис авторизации вы сможете сейчас быстро скатерть на основании чего сделан технологический стек наших абонентов нет вот это вот на чём это всё сделали руками на колени написанная хороший кот Понятно спасибо. Здравствуй Антон у нас интимный вопрос такой тоже про авторизация Вот вы поняли вопрос Независимый деградации Но вот Меня он тоже очень сильно Выходи мы некрасиво с авторизацией сделать Как обойти вот проблемы с кем-то что нас авторизация ложиться и

больше ничего сделать не может потому что ну как бы проблему Понятно проблемы принципе достаточно очевидны но какие-то готовых властных решений Я до сих пор не слышал про неё я не буду говорить как сделать вам я расскажу как сделано у нас да я думал что мы друг друга поймём Когда у нас лежит сервис авторизации то мы отдаем анонимную сессию Просто она меню анонимного пользователя и пользователь который приходит на сайт имеет возможность работать с сайтом но сайт Не узнают То есть это вот такая контролируемое деградация она в этом заключается естественно всё это есть

триггеры естественно мы читаем дома если мы отдаем много анонимных сессий Но вот мы поступили так А вопрос А что-нибудь знаете вот не знаю кто-то так делал может быть сами думали а Закажи Руслана все права и для старых сессии сохранить вот эти заголовки опрокидывается дальше на бнд но и надеяться то что этого хватит хотя бы какую-то процент пользователей Ну такой проблема стояла честно говоря там сервис узнавай у нас падает достаточно редко чтобы мы думали о том чтобы дальше как-то прокидывать права пользователю на frontend isopan фронтоном свои права присылал

Да можно думать эффективностью чтобы он там их не подделал Но и так далее ну просто такой задачи не стояло мы с этими проблемами они столкнулись хорошо спасибо Так мы задаем вопросы у нас есть рука рука поднимаем руки раньше тогда мы сможем задавать вопросы более оперативно Мне скучно Я хотел бы узнать по поводу для каждого сервиса своя база данных вот насколько это распространяется То есть докладом я понял то что там может быть базы данных именно совершенно различные То есть например кто-то Собирает ли аналитическая база данных Да и работать именно подарить Кто там Ну бизнес-логики вот и

меня такой вопрос то есть именно насколько оно распространяется на сколько у вас там на базу данных разные то есть есть же ну обычно всегда есть какая-то большая база данных Ну да в котором нужно всё и например через какой-то какой-то этой частью Как у вас этот вопрос решен то есть вариант делаете именно слепок этот банк и обновляет его там или какая-то её репликация Насколько этот вопрос отдельно базы данных для каждого сервиса насколько как он вообще выглядит как она выглядит флотации или в тестировании

эксплуатация То есть как какие-нибудь примеры очень просто у нас есть основная база данных в которой лежат основные бизнес сущности вакансию резюме от пользователя и так далее и тому подобное и она высоконагруженные у неё есть мастер реплику несколько реплик с которых можно только читать данные для которых данные долетают и надо устроен таким образом что стараются брать данные из реплик которые легко от масштабировать Да просто доставив нового железа или стараются как можно меньше ходить именно в Мастер для изменения запросов основная база

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

у вас есть даже два кластера Кассандры один отвечает опять же из-за критической функционал без которого мужик не можем 2 за какую-то Да на помойку Yamaha немного данных тогда Но обычно всё-таки сервисы каждый из сервиса свой собственный кластер Краснодоне разворачивают вот используют обычно общий кластер какой-то Ясно спасибо. спасибо спасибо за доклад А у меня вопрос как раз по поводу баз данных и реагирования на скажем так инциденты то есть как происходит система Ну вот что-то пошло не так где-то что-то коротнуло как у вас идёт система ролл Backup

восстановление после какой-то тёплая неудачный фичи если таковой бывает на моей памяти высотой работают Хантера карта Донбасса нас ещё не было мы выкопали регулярно делаем И даже службы эксплуатации регулярно проводит учения по восстановлению СБК но честно говоря инциденты связанные с кратностью данных У нас не было поэтому вот так и можно ещё один вопрос а распределённых то есть Ну наверняка же вас сам контент который ну-ка файлы какие-то ещё как-то То есть даже распределенное хранилище ночного Света работает СЭВ

а что именно Ну контент распределены но не знаю там картинки видела что у вас там ещё есть вы где-то хранить распределённое то Ну да у нас там есть какая-то система из вообще у нас эксплуатацию в своё время написала кассандру энциклопедически Вот они сделали что несколько серверов на каждом установленном МПС который отдает статику и определенным образом определенные скриптами между этими инстанциями данной реплицируется когда приходит запрос У меня есть этот Sharp нету шарата поем пойду От себя и возьму пойду с друга возьму

Эта система работает до сих пор Единственное что есть каширование предметы на уровне прифронтовых серверов Ну вот как-то так вот работает довольно прикольно ну да ну как там написано это мы сами не так много кода индекса дает данные какой-то скрытых реплицируется статику отдавать прямо актуальную общем никакого резона не нужно то есть Да какая разница когда Наталья Ну вот и всё. Здравствуйте Большое спасибо за доклад вопрос он такой объёмный Ну постараюсь разбить чтобы было понятно И

мне может быть кому-то кто тоже задался таким вопросом Всегда ли под микросервисами стоит понимать какую-то одну большую железку на которой разложены либо Такер контейнеры либо виртуальной машины то есть или же нужно держать для каждого сервиса какую-то одну единицу там ну сервер железной там или тут вопрос чего вы хотите да то есть если вы хотите железобетонно отказоустойчивость и так далее наверное вас будут микросервиса просто сервисы каждый будет стоять на своей железки с другой стороны если вы понимаете что это неэффективно зачем Под каждый час

развивает железку которая ещё не загружены требует обслуживания Ты наверное пожертвуйте отказоустойчивость там и так далее в пользу чего ты ещё вообще ну там вся архитектура это про систему балансов Да вот можно выиграть в одном поиграть в другом микросервисы это про это же спасибо очень даже понятно я собственно вопрос который вытекает из вот этого у вас на свадьбе было видно что вас как раз-таки вот на одном сервере виртуалки контейнеры Что вы делаете в случае отказа железного гипервизора

хвост машины они как-то мигрируют его просто за дублированном в другом сервере там нет мы проблемы решаем тем что у нас есть запас по мощности примерно 30% мы закладываем на то чтобы запас по мощности был мы регулярно нагружаемый сайт прям нагрузочному тестом прямо сайт по-живому чтобы убедиться что он возросших нагрузках нагрузках работает вот и пока варю живём без мигрирование Я просто упала какая-то docker железка Ну и черт бы с ней Большое спасибо Так

ещё вопросы Здравствуйте спасибо за доклад хотел бы задать вопросы по вашей мини копия так называемого продакшена то есть вы туда в сервисы которые сконфигурирован прямо для продакшена или вы как сделать отдельный сборку для вот этой теста схемы и выкладывайте туда использовать все те же скрипты Но это обычно Они забыли скрипты которые есть в эксплуатации для того чтобы повернуть сервис мы его разворачиваем в докер контейнере Используйте скрипты но Конфи откладываем собственные даже не столько собственной конфиги но в

некоторых участках конфигов прописываем плейсхолдера что вот здесь используя значение для продал здесь используя значения для структура вот как-то так получается Ну это те же сервис абсолютно история тряпки даже ну то есть docker Image он один и тот же и там и там замены там там я наверное точно не расскажу об этом гораздо лучше расскажет наш Quo вот мы Дело в том что мы сейчас в процессе перехода на Докера да то есть какие-то все уже в продакшене крутится в докере вот какие-то сервисы до сих пор Debian пакетами раскладываются вот

не хочу Не знаю не хочу не отвечу хорошо спасибо за этот образ Здравствуйте спасибо за доклад вот у меня такой вопрос Вот я например надо у вас было диаграмма там были указаны сервиса там ABC и вот с таймингами которые пробрасываются Как вы вот вот эти тайминги пробрасывать если у вас появились новые серии вот что вы делаете Какая стратегия мы ничего не можем продолжать там делить тайминги и игнорировать Приду конечно это я провёл предельный случай Мы конечно так не поругаемся более того у нас в некоторых сервисах не намерена отключили ретро мы сказали от них больше более

чем от чем пользы потому что этом во всём заваливают в других очередная настроили сервисы которые не очень критичны для продам и особенно там выставили какие-то дефолтный таймауты соображения того что Ну не должен запрос больше 2 секунд Да там в этом автосервисы которые гораздо более критичных ко времени ответ мы там действительно проанализировали выставили другие таймаута То есть всё зависит от того какую выгоду Мы хотим извлечь на в сети таймаута вот и всё А ещё один вопрос по поводу сервис-интегратор вот вы говорили Он там большая боль с ним

Вот хотелось бы поподробнее Что именно вот-вот МТС сервис у нас там есть какие-то скрипты ну или что-то или что что это такое вот которые знают о других сервисов которые Ну как-то видел вы наказываете ну вы имеете в виду Service Discovery какое-то Нет ну Service Discovery Понятно Я имею в виду вот у вас есть сервис Он интеграционный вы не можете его просто переплывать или в чём в чём его проблема сервисы интеграционного ну проблемы операционного устройства вытекают

из того не делает не какую полезную сущности именно для бизнеса да то есть он с одной стороны принимает запросы которые впитывают фронтенда Особенно с ним ничего не делаю кроме боксирует на ПНД и в зависимости от разных абонентов идёт на другие и так далее да Вот то есть он автоматически получился никогда такое монолитное приложение которое сетевого вверх и добавляет Амирхана сигнализацию сигнализацию но при этом а то есть там бизнес логики никакой нету что-ли там где есть она просто минимально просто нужно ли для этой бизнес-логики выделять

именно отдельное тепло июня или может быть небольшой кусок бизнес-логики сходить туда когда он ответит Возьмите данные сходи туда да держать вместе с другой бизнес это открытый вопрос на самом деле у нас опять же есть сторонники оставление этого интеграционного условия дантона всё-таки он как-то декомпозировать Монолит сторонники которые говорят Нет давайте обратно интеграционной слой куда-нибудь в сервис который отвечает за корку национальность Даллас Я как-то построил просто диаграмму сетевого взаимодействия оказалось 30% запросов у нас всех все вопросы то 30% это будет между

интеграционном слоем и слоем скоро функциональностью вопрос Вы хотите да-да-да грациозной слой отдельно или может его засунуть в слове скоро функциональности кальяне такси связанная вот а ну а если у нас есть вот это последовательность 10 нераскрытых сначала этот сервис BC а потом нужно их сторнировать Ну если что-то пошло не так нам всё равно нужен этот интеграционный слой Почему нельзя написать в любом другом месте То есть почему для этого нужно выделять отдельные типологию нет отдельной репозитории и так далее там подобное ташлык можно

написать в любом сервисе хорошо спасибо Здравствуйте Меня зовут Дмитрий Я только вопрос по поводу было Было ли у вас практика прямо в продакшене например прицел СВД изменить её структуру Я просто опишу проблему которую на своё время возникла есть например над магазин и есть некоторые карты лояльности которые привязываются к клею и в качестве там прямо реки мы используем как раз номер карты Но вдруг через полгода через год возникает потребность ввести новую

вендора и получается что мы не можем первичный ключ и нам Production таким хирургическим путём приходилось привязывать первичные вторичные ключи от Было ли у вас такая практика проблема когда мы говорим о репрессированных в ДНТ ещё проблематично всё сделать схему базы данных мы регулярно меняем в том числе заменяем 1 другие так далее это бывает необходимо иногда это приводит когда он там в том смысле что эти данные прилетают на реплику там лучше таблицу Там и так далее я

честно говоря не большой специалист в области все сидим Вот тебе и гораздо лучше об этом рассказывать такое бывало Вот ну как бы с этим живём Ну я просто немножко как-будто когда просто добавить одно поле это легко когда надо отвязать перепривязать с десяток таблицы вот эти вот первичный больничный ключи Но это легче застрелиться нам приходилось все время скрипит просто писать на питоне который автоматически это делают перед этим 10 раз локально протестировать развернуть кластер там протестировать на For Key Production и уже

после вот этого что ничего там не валяться вот мы стараемся делать всё инкрементально В смысле что выпустить какой-то скрип на пруд посмотреть работает выпустить другой на просмотреть работает И постепенно шишками приходим Кто и схемы можно давать для этого требуется несколько релизов возникают такие Добрый день а у меня простой вопрос Чем сервисных ситуации микросервисной тут как-то вообще в гости Ты хоть какая-то сейчас есть или она потерялась окончательно отличный вопрос я например считаю что

не прощаюсь наркотик это там предельный случай сервис на архитектура как Монолит тоже предельный случай сервис архитектуры в котором всего один сервис Да вот я не знаю мне честно говоря никогда не приходило в голову выделять четкие критерии просто их в бизнесе особенно не использую назовёшь ты своим сервисом микросервисам или просто взяли смотрю что-то изменится но паспорт я понимаю разницу не знаю в том же амазоне между Amazon lambda чёткий microservices new-service уже не сделать и там нормально каким-нибудь с двоичным сервером который какой-то сервис реализует вот об этом так

понимаю почти всё что у нас происходит в нашем энтерпрайз В общем это нормальный сервис архитектура никто не пишет я в этих строчек отдельных микро и реально это всё-таки нормальный хороший полноценный большие тяжелые Всё Давайте ещё раз поблагодарим докладчика

Комментарии для сайта Cackle

Купить этот доклад

Доступ к видеозаписи доклада «Преимущества и недостатки микросервисной архитектуры в HeadHunter»
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно

Доступ ко всем записям докладов мероприятия

Доступ к записям всех докладов «РИТ++ 2017»
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Билет

Интересуетесь тематикой «ИТ и технологии»?

Возможно, вас заинтересуют видеозаписи с этого мероприятия

29 августа 2019
Москва
7
50
геймдев, игры, киберспорт, медиа, разрвлечения

Похожие доклады

Сергей Орлов
Архитектор, лидер юнита Архитектура в Avito
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Николай Балакирев
Ведущий разработчик в Avito
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Александр Сербул
Менеджер контроля качества интеграции и внедрений в 1С-Битрикс
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно

Купить это видео

Видеозапись

Доступ к видеозаписи доклада «Преимущества и недостатки микросервисной архитектуры в HeadHunter»
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно

Conference Cast

ConferenceCast.tv — архив видеозаписей докладов и конференций.
С этим сервисом вы можете найти интересные лекции специально для вас!

Conference Cast
1153 конференции
32338 докладчиков
14311 часов контента