Здесь переводится видео в статью Сергея Орлова из Avito "Микросервисная Архитектура проблемы и решения"
Ссылка на видеодоклад https://www.youtube.com/watch?v=GIslwdE2DWY
Текст сделан из субтитров. Буду очень благодарен в форматировании текста, его вычитки. Для этого достаточно знать русский язык. Присылайте свои pull request или присылайте текст на почту patsev.anton[собака]gmail.com
давайте попробуем начать меня зовут орлов сергей я работаю в компании avid занимаюсь вопросами сервис на архитектуры сегодняшний доклад будет содержать следующие части вообще задача нас сейчас на сегодняшний доклад рассказать об общих подходах зачем нужна микро сервисной архитектура в рамках какого контекста на используются какие проблемы решает и как и какие проблемы несет сама микро сервисной архитектура соответственно начнем с короткого обзора что из себя представляет backend современного большого виа проекта далее рассмотрим как микро сервисной архитектура может помочь задачам которые в рамках букин до ставятся перед разработчиками каждый день рассмотрим основные паттерны которые используются при адаптации микро серых и архитектуры к задачам рассмотрим подробно в чем даже не минусы в чем требования которое предъявляет такая архитектура к разработчикам компании к задачам к уровню автоматизации и коротко расскажу про секцию микро сервиса которая будет проходить здесь же сегодня начнется чуть позже так все достаточно просто современный backend большого проекта это огромное количество функциональности даже если мы видим приложение из одной кнопки за ним стоят десятки приложений с терабайта данных целый зоопарк хранилищ бас аналитик события различные технологии языки и есть такие такой вариант как приобретенные компании когда мы не можем сохранить один и тот же стих технологии в одном проекте просто потому что проектов на самом деле много и появляются новые проекты которые написаны на новых языках делаются отдельными командами части распределенными командами далее многофункциональности это в любом случае много кода и много это миллионы строк опять же разные языки если причем это как языки программирования так и языки запросов причем современные во фреймворке помогает нам сделать код более лаконично но качественно эта проблема не решается это все равно миллионы строк причем высокоуровневые функциональность и соответственно это много людей много разработчиков много команд и при этом нам нужно как-то работать надо решать задачи соответственно нам нужно разрабатывать новую функциональность потому что законченный проект это мертвый проект функциональность должна разрабатываться как можно быстро как можно быстро доносится до конечного пользователя до 100 наша цель чтобы тот самый тайм ту марки до время до появления функциональности уже для конечного пользователя снос как можно более низким и при этом мы должны сохранить достаточный уровень качества сразу говорю что говоря о качестве мы сразу должны понимать что есть некоторый нужный уровень которого мы хотим добиться и что тайм ту market и уровень качества находятся по сути в обратной зависимости мы можем делать очень быстро но с качеством будет беда либо мы можем стараться избежать любой проблемы любой ошибке и при этом видеть релизы примерно никогда детстве на две эти две основные метрики да не вступают в противоборство с друг другом и тут важно найти некоторый баланс [музыка] здесь стоит упомянуть в этот момент в такую вещь как закон конли вот есть прямая цитата и очень вольный перевод очень-очень вольный перевод который сделал я то есть подход в том что архитектура программных систем соответствует структуре команд который мы имеем в случае бэг-энда большого проекта это утверждение еще раз доказывает свою истинность потому что просто очень много группы разработки много проектов много продуктов относительно независимой функциональности который разрабатывать разные группы людей которые решают на самом деле часто достаточно разные задачи причем как на основе fun как про функциональность так и про различные бизнес метрики и вот в этот момент стоит начать говорить о микро сервисной архитектуре том какие решения на предлагает для того что с этим всем бороться на мой взгляд микро сервисной архитектура является по сути развитие некоторых принципов подходов паттернов которые описывались достаточно давно в литературе тот же закон кону это 67 год например соответственно то что предлагает микро сервисной архитектура это некоторые классические подходы которые перенесены на из уровня паттернов которые касаются разработки приложения на уровень архитектуры когда мы описываем систему из нескольких компонентов которые взаимодействуют друг с другом и основные принципы можно выделить следующие 1 красивая архитектура дает возможность инкапсуляции почему капсюля ция которую достаточно трудно нарушить в отличие от подхода с монолитом потому что в случае монолита одна строчка написанная там по ошибке может нарушить инкапсуляция которая до этого выстраивалась там долго и упорно специальным образом у нас нет надежных средств защиты вызвать там публичный метод не из того модуля который с которого он задумывался то есть языки программирования дают определенные гарантии отделения публичного интерфейса от приватного но этого недостаточно чтобы четко поддерживать инкапсуляция внутри большого монолитного приложения и решить эту проблему качественно соответственно если мы хотим в принципе иметь решение какой-то проблемы решение должно быть качественным то есть исключать в принципе возможность допустить ошибку вот разработка в монолите даже с применением паттернов проектирования не дает возможности исключить ошибки инкапсуляции качественного отличия от микро сервиса микро сервис в принципе инкапсулирует всю свою бизнес-логику за единым и поэмы появляется некоторой точкой входа которую мимо который нельзя пройти то есть естественно теоретически мы можем найти ту самую базу который использует сервис начать делать не запросы напрямую им такие вещи во-первых решаются административно во вторых все-таки человек идёт по пути наименьшего сопротивления имея некоторые пион вряд ли захочет заменить его на что-то другое далее принципе диной ответственности тоже достаточно достаточно известный принцип сингл responsibility что он значит здесь здесь значит опять же две вещи опять же все связано с законом конная то есть и есть принцип один и ответственности кода некоторые системы которая делает ровно одну вещь которая не ожидается и при этом четко расписано если мы видим что сервис начинает на самом деле выполнять различные функции есть целый набор функциональности которая не относится к другой функциональности сервиса то мы можем вынести еще один сервис использовать его независимо второй второй аспект принципа единой ответственности эта ответственность людей команд а то есть каждого сервиса есть четко очерченный круг лиц который занимается разработкой и поддержкой это может быть один человек для отказоустойчивости этом чаще всего несколько человек минимум два иногда люди болеют выходит в отпуск соответственно под ответственность здесь понимается в том числе ответственность за сам сервис большом проекте это важно важно чтобы любого куска кода у любой задачей был четкий ответственный которому можно обратиться и третий момент это скорость разработки причем сервисный подход дает возможность ускорить разработку несет не только за счет того что приложение получаются меньше и меньше логике меньше логических связей в коде меньше вещей которые нужно поправить чтобы рисовать новый функциональность в чем основная проблема монолита чтобы как правило новая фича упирается в несколько строчек но эти несколько строчек находятся могут находиться в 10 модулях монолита в разных частях затрагивать разные аспекты все это нужно аккуратно поменять и протестировать то есть скорость разработки упирается даже не скорость написания нового кода а зависит от чтение старого и зависит от тестирования потому что площадь затрагиваемых изменений просто больше кроме этого на скорость существенно влияет такая возможность как возможность использовать технологии которые наиболее точно подходит под задачи как пример если вам нужно разработать сервис который использует подходы машинного обучения и ваш проект весь написан на php у вас одна возьму у вас два варианта на самом деле на самом деле один вы можете начать пробовать делать машинное обучение на печке например своими силами и дальше вы умеете то на это уйдет очень много времени либо там какие-то сейшены расширения писает либо вы можете написать независимый сервис который использует питоновский стек и на нем достаточно быстро и качественно решить задачу это на самом деле дает прирост к разработке также значительные помимо того что в микро сервисе прочь проще писать новый год далее чуть больше конкретики как с этими сервисами все-таки быть как выделяется что они должны отвечать снова ясно от предыдущих озвученных принципах основные паттерны расскажу вкратце the bass пир сервис подход следует из названия все достаточно просто на словах при этом на деле это то что часто вызывает затруднения почему потому что как правило микро сервисы особенно если мы говорим большом проекте микро сервис это не не . 0 это не код написанный с нуля который сразу построен по принципу микро сервисной архитектура чаще всего у нас уже есть монолит как правило он достаточно большой то есть это несколько десятков тысяч строчек может быть там сотен может быть и за миллионы заходят нас уже есть база которая скорее всего тоже монолитное скорее всего очень большая и и при этом нагружены из мигрировать ее просто так затруднительным но при этом даже в такой ситуации до когда мы идем с нее с точки 0 в точку а из точки в точку 1 из 1 в два в три хотим попасть куда-то в 10 где у нас прекрасная microserver которые все сервисы независимы и общаются друг с другом по понятно протоколом даже таком случае мы можем применить несколько приемов чтобы достичь подобного уровень уровня изоляции то есть первый подход который мы можем использовать все новое делается уже в виде сервисов получается ситуация когда у нас есть некоторый монолит монолит обращается к сервисам к не которому набор сервисов которые примерно на ну примерно независимо делают некоторые задачи некоторую полноценную логику которая вынесены из монолита на вернее ним еще не внесена туда следующий подход собственно вынесения когда от монолита постепенно остается тонкий слой который задает по сути тот самый api gateway когда есть только вызовы сервисов и сбор данных от них расскажу подробнее про этот подход то есть представим что у нас уже разнесено все все в отдельных базах отдельные сервиса работают с этими базами все реализованных идей пьян при этом ну api внутренних сервисах часто достаточно минималистичные атомарные то есть мы соблюдаем принцип когда один сервис на одну задачу при этом понятно что может быть несколько api хендлеров и максиму о том что это одна функция она не всегда состоятельна потому что ну часто это круто над каким-то данными но при этом у нас есть некоторые 5 внешнего внешне пиаре которые должны быть более сложными которые должны отдавать с данные из разных сервисов причем часто еще дополнительно как-то слитые вместе плюс нам нужно где-то просто проверять авторизацию возможно делать тротлинг логирование сбор событий многие подобные вещи здесь на сцену выходит api gateway подход заключается в том что мы делаем некоторые отдельный сервис который занимается включить на тем что собирает данные с различных брендов соединяет их при этом важно отметить что часто он может делать такие вещи в параллель опять же здесь выходит в плюс то что мы можем использовать различные технологии для различных сервисов то есть например где-то нам удобно делать крут банально там на джанки условно каких-то синхронных проверках что просто больше поддержка библиотек больше разработчиков знают быстрее происходит разработка api gate вы часто делают acer асинхронными используют для их разработки асинхронные фромборке даже если мы используем один язык для всей компании то это могут быть разные формы локи случае питона там асинхронные торнадо и синхронный django соответственно gateway удобнее делать синхронном потому что кода так как там как правило немного и при этом мы можем собирать данные в параллель тем самым уменьшая время ответа нашего сервиса и несколько нивелируя проблема микро сервисов это все-таки системы сетевые вызовы и latency плюс gateway борется с этом все еще и еще и тем что помимо 1-цы сети которая есть внутри дата центра до локальной сети еще есть сеть от клиента от фронтэнда для нашего сервиса либо от мобильного приложения до нашего сервиса соответственно как бы нам не нужно делать большое количество запросов с фронтэнда мы делаем один запрос и получаем почти все данные при этом api gateway позволяет не не перри реализовывает некоторую повторяющуюся логику в разных клиентах ну и соответственно сильно экономит время ответа и сильно упрощает клиент как построению с подходом как если бы мы дергали каждой независимой простенький микро сервис клиента и собирали это все вместе однако здесь возникает еще один вариант когда нам нужны разные 5 для разных клиентов например у нас есть мобильные приложения есть десктопной версии сайта там с джо скриптовых фронтэнда вот при таком подходе часто бывает полезно делать разные 5 для разных клиентов и такой подход называется бы контроль frontend когда таких вот gateway'ев делается несколько полей твой на платформу плюс бывают варианты когда удобно держать даже не одно мобильная пиа по мобильному api например на каждое мобильное приложение потому что здесь опять же вступает силу закон канвы и что приложение очерчена также команды если у нас например отдельная команда разработки мобильного питом для ios и отдельные для android то логично сделать отдельные пикет вы иначе командам придется толкаться в рамках одной к до базы и большое количество времени сил лед на коммуникацию что чревато задержка сроков ошибок ошибками далее когда мы переходим к сервисам здесь начинается переход следующую часть про вопросы про проблемы которые ставят микро сервисной архитектура в обмен на те улучшения возникает ряд целый класс задать же доктора тоже надо решать стоит такая задачка к discovery грубо говоря находить где кто так как сервисов много инстансов еще больше каждому из сервисов возникает задача найти инстанции там где запущенное приложение и запросить такие данные тут водится такое понятие как сервис регистра это некоторое централизованное хранилище которое хранит в себе весь список сервисов актуальную информацию где кто и ответственна за поддержание этой информации в актуальном состоянии при этом сервис discovery можно условно разделить на два варианта два подхода так называемая клиентская когда сервис клиент сам занимается тем что находят конечные поинты и некоторые сервис серверная когда он находит него есть некоторые серверы серверы же занимается discovery то есть может быть некоторый proxy server to jane джинкс например там случае облачных систем как там например используем купер на эту него есть собственные средства собственный пиа и он использует ты сиди для хранения этой информацией где кто находится и отдельный демон эту информацию собирает и обновляет вейпе а я прокси-сервера которые ставят внутри кластера уже могут найти из этого и передать информацию где кто находится и запроектировать запросы уже на конечный point при этом все это прикручена к обычному engine иксу сбоку и гости переписывает его конфи girl аудит их так и далее собственно чего нам стоит микро сервисной архитектура надо понимать что это все нужно для решения определенного класса задач в определенной проблематике проблематика было описано чуть ранее про много кода много людей и много функциональности вот если сейчас не так то наверное думать о подобных вещах может быть немножко рановато почему потому что налагаются некоторые определенные требования на все аспекты разработки в компании 1 klas klas вопросов качественной про структуры то есть если у нас есть один монолит мы можем научиться выкладывать его там за какое-то количество времени какие-нибудь скриптовом которые написали самостоятельно один раз и он как-то работает и всех кто устраивает особенно если у вас релиз все-таки не один раз в день там раз в неделю например есть какой нибудь один разработчик который имеет это волшебное знания и права доступа то чтобы запустить какой-нибудь скриптик и он имеет его чинить если нужно случае микро сервисов такая история не прокатит вам нужен некоторый чай вам чтобы автоматизировать deployment вам нужно собственно само средство deployment в нужно сделать некоторые артефакты которые будут который будет тепло и cd нашем случае распространенный подход сейчас это докер контейнеры но это может быть и d пакет рпн пакет то есть некоторый слой абстракции над теми технологиями на которые вы на которых вы разрабатываете потому что ну в нашем случае при минус 4 за к бэк-энд разработке но при этом вся и должен быть один мы как бы к этому стремимся помимо этого все эти процессы все эти сервисы даже если у вас все это не нагружена но у вас уже 10 сервисов и для отказоустойчивость вы подняли по три штуки по русскому обычаю этого своих уже 30 и все эти 30 процессов надо как-то мы начать надо их запускать при чем запускать так как мы стремимся до уменьшить time to market дпс как можно быстрее то еще и перезапускать как-то выкатываться следить что они там все таки работают и тут возникает вопрос мониторинга почему автоматического мониторинг который не просто должен присутствовать что уже не везде соблюдается плюс он должен опять же поддерживать нужный уровень автоматизации чтобы добавление каждого нового узла как проходила как можно более автоматический и тут возникает вопрос что опять же нужен софт который будет это делать плюс очевидно нужна поддержка с приложение нужные half чайки то есть некоторые специальные пей который добавляет некоторую отдачу некоторой информации для мониторинга том что сервис жив что у него все хорошо соответственно все это ложится все это ложится на плечи я делаю эксплуатации на devops of вас должна быть некоторого такая инфраструктура хоть в каком ну достаточно качественном видение чтобы все это тянуть следующий класс проблем микро сервис архитектура на мой взгляд опять же ну и по моему опыту налагает определенные дополнительные требования на каждого конкретного разработчика почему потому что на самом деле требования двух основных вещей первое разработчик должен стать немножко drums почему потому что если случай монолита разработчик если это не там нет тимлида не ведущий разработчик команды он тепло и условно бесконечный сервер когда-то давно была построена некоторая программная архитектура там были подняты какие-то железки настроены какие-то applications сервера к этому прикручен какой то скрипт который умеет катится к титу то на печке приложение каким-то мышцы целях статора лето и разработчик не думает о том сколько там железо какие там ресурсы что с нагрузкой и все это всех устраивает пока что-то не станет слишком тяжелым и не вызывают проблемы в случае запуска новых нового сервиса [музыка] разработчику нужно сразу рассчитывать нагрузку сразу думать о ней сразу думать о том какое количество железа потребуется на реализацию в новой фичи и в принципе это позитивный подход потому что все эти вопросы в случае монолит неявно также присутствовали но микро в сервисной архитектура ставят эти требования заставляет думать об этих требованиях сразу в самом начале разработки что важно ещё до написания кода и второй вопрос который возникает перед разработчиком который тоже желательно решает до написания кода это собственно проектирование перед то есть случае кода внутри монолита проще рефакторинг кто-то не до передал какой-то параметр функцию не так что то назвал не там разместил какие у нас есть какие-то тесты у нас есть какие-то тестировщики например и есть надежда что если мы переменную функцию то ничего не сломается или по-крайней мере мы это увидим в случае микро сервисов так уже не получится у нас есть тебя это некоторый публичный контракт его нельзя менять максимум его можно дополнить то есть это будет как-то мутировать будут добавляться дополнительные поля но мы не можем просто что-то переименовать и перенести я как мы знаем да и здесь две основные проблемы инвалидов а киша и именование переменных теперь затрудняет переименовать переменные при этом мы можем и нет волшебных там серебряных пуль подходы в подходе к versio нирования до единстве наши варианта то сделать новую api команду имея опять же мониторинг который опять же требуется понять чувства все на нее перешли заставить их на неё перейти как-то административно уговорами по разному если это внешнее заказчики там все все еще интересно это огромное количество коммуникации огромное количество времени сил которые которое заплачены деньги там сотрудников сотрудникам просто чтобы передавать какую-нибудь поле соответственно разработчик сразу становится немного архитектором там слышит он должен проектировать свои паи это дополнительную ответственность дополнительные силы и время и третий класс проблем это документация на самом деле она встает в любом проекте и микро сервис там или нет но здесь она опять же ставит все качественный и на мой взгляд намного раньше смыт чтобы обратиться каком-то сервису мы должны знать что он есть мы должны знать как выглядит его и 5 мы должны знать где он находится тот самый сервис discovery да опять же проблемы нам нужны некоторые средства документирования может быть полуавтоматического документирована тем не менее нам нужны некоторые каталоге сервисов нам нужно хранение этой информации об этих сервисах просто просто банально чтобы там те же средства нахождение кто кто отвечает за конкретный сервис например большой компании просто невозможно знать всех нужны некоторые стандартные механизмы роутинга уже не запросов а роутинга запросов внутри команд вот эту эту проблему как бы чем надо решать их можно раньше то есть сразу эхо из внедряя микро сервисной архитектура задумал по крайней мере задуматься о том как бы как мы будем узнавать о новых сервисах как декорировать хрипами потому что грубо говоря внедрение новой фичи во многом по времени упирается в изучении и 5 отладку и если у нас нет полноценного стретчинга как где мы можем сделать запрос к развернутому сервису то разработка каждую новую фичу сильно замедляется от случай микро сервисной архитектуры много и фичи и представляют из себя интеграцию с этими так что вот нужна некоторая ответственность принятие решений в понимании зачем все это нужно [музыка] лишь в каком 103 далее у нас есть 10 минут расскажу коротко секция на самом деле мы начиная такую инициативу преследовали два основных две основные задачи до рассказать о своем опыте которым с которым мы реально столкнулись адаптируя сервисной архитектуру то есть мы занимаемся подобными вещами наверное уже более двух лет как собственная разработка и софтверной частью так и частью которая связана с devops облаком с инфраструктурой и вторая задача послушать чужой опыт потому что опыт все-таки местами уникален и есть новые интересные приемы которые могли не прийти в голову на которые реально могут сказать время силы и при этом мы можем кому-то сэкономить время и силы что касается затем секция то очень не сказал предметную область на самом деле у многих оно похоже и у веб-проектов и бэг-энда для проектов больше сходства чем различий соответственно я думаю что решение применимы и для пример в одной компании могут быть на погром мере частично явным образом не полностью применимый в рамках другой компании где и когда за мной будет за доклад антон его на выход hunter pro подробности использования микро сервисные архитектуры именно у них и далее приглашаю всех на секцию микро сервисы и сейчас ее до упора зал сан-паулу немножко рассказал расскажу в качестве тизеров о чем там будет будет доклад про мониторинг про мониторинг всегда полезно мониторинг а то о чем вспоминают когда роль уже обо всем вспомнили все сделали и внезапно оказывается что что-то сломалось непонятно почему и как на самом деле мониторинг это огромные обширные темы итан она может быть как очень скучно и очень простой и так и бесконечным полем для применения знаний опыта талант и желание что-то делать будет доклад про так называемый even стрим processing то есть случай микро сервисной архитектуры у нас есть такой как бы есть разные паттерны и как сервис и общаются между собой есть они могут быть асинхронными либо синхронными то есть есть асинхронный вариант почти пить нектар и веба и пятом рестлер писи когда мы просто вызываем метод дожидаемся испанцы и все окей есть до синхронные варианты когда мы используем очереди используем некоторые события что еще важно есть такой подход когда ну мы изолируем ся по данным до в идеале и при этом нам нужно как-то синхронизировать состоянии разных сервисов вот здесь на фоне на сцену выходят события и некоторые шины данных типа очередей когда мы информацию можем прокинуть по очереди и по сути догнать state какого-то при до какого-то сервиса б до состояния сервиса вот будет доклад моего коллеги а нашей системе явин стрим processing это так называемый quick stream то есть некоторый набор событий которые происходят на сайте там пользователь посмотрел объявление пользователь посмотрел рекламу куда то нажал что-то посмотрел все это превращается в события и через специальную систему все эти потоки роутера в различные внешние хранилища для различных внешних сервисов стентон highload кучу данных аналитикой и так далее это тот самый случай когда мы не можем ходить в один и тот же сервис в одну и ту же базу просто потому что база для аналитики и база самих данных они разные нирн заточены под разные паттерны использования под разную нагрузку и здесь нельзя просто так наплевать на принципы там разделение микро сервис вопрос ходить в одну базу база должны быть разные вот здесь-то классический пример почему общение через события может быть полезным также будет ряд докладов про практику использования микро сервисов причем в проектах которые части уже монолиты не такие огромные как основная ли авито но тоже не маленький как люди новую функциональность разрабатывают уже в рамках микро сервисов и какие вопросы встают и как они их решают кроме этого будет доклад про от опять же моего коллеги димы ходакова который занимается машинным обучением рекомендательными системами опять же даже вот так вот в таких областях где казалось бы фокус смещен в сторону от архитектуры там где приложение так далее тоже находят применение подхода микро сервисами когда у нас независимые маленькие сервиса каждый из которых отвечает за свою задачу [музыка] кто нас тут security это то о чем забывают даже когда не забывают о мониторинге мой пример это подтверждает опять же в контексте хранения сервис в контексте сервис discovery там возникает еще ряд вопросов связанные с discovery конфигурации да то есть хранением конфигурации the factors учит нас вообще здравый смысл учат нас о том что конфигурацию нужно отделять от приложения приложения и конфигурации должна инжектит со там depends injection принцип опять же достаточно старый вот с таким подходом помимо inject и конфигурации да еще и он сжег так называемых секретов то есть некоторой информации которая нельзя просто хранить системе управления конфигурацией контроля версии в детей некоторые секретные данные по роли ключи от и пифы многое другая чувствительная информация от наш от ребят из безопасности человек с безопасность которые нас занимаются подобными вещами будет доклад про использование продукта от хэши короб который называется волк служит как разных хранение секретов то есть полноценный kweli сервис опять же слеп и пиарим который может которых шифрованному виде хранить внутри данные из из которого эти данные можно получать стикер нам виде использовать уже внутри приложений я расскажу про конкретный опыт как мы это решение внедрили у себя как мы вас интегрировали с кластером к бернейс у которого из коробки есть свои секреты на не сильно праве проще и хуже как это все выглядит [музыка] ну вот такая секция сейчас дням сан-пауло сейчас за мной будет антон иванов наверно у меня пока все благодарим докладчик с либо у нас вот расстался множко больше времени на вопросы поэтому давайте позже весны вопросы но должно какие призы но превысил мне не дошли до рук моих да за лучший вопрос смерть ньюмана про микро сервисы очень хорошие здравствуйте добрый день раз ты меня зовут виктор благодарю вас за доклад по всему упомянули в начале доклада о таком принципе дата по дата блистер сервис вот вопрос одну из этого вытекает что у нас под каждый сервис получится небольшая какая-то своя база а в общем в приложении она будет очень фрагментирован а а не лучше ли делать отдельные сервис под базу данных остальные сервисы интегрировать в эту базу которые будут к этому сервису обращаться вот именно этой лучше просто не всегда мы начинаем с того что делаем новые сервисы поэтому есть вариант когда базу уже есть она монолитные так далее тогда нужно постепенно выносить функциональность которая ни с чем не связана и действительно делать из этого отдельные сервиса то есть просто накручивать на этот сервис новый функционал для работы с базой ну а бы иметь ввиду сделать один сервис вокруг всей базы до вокруг сие остальные сервисы просто будут идти с который будет уже с базой работать ну такой подход имеет ряд недостатков то есть во первых лаз некоторые единая точка отказа во вторых вы теряете принципы единственные обязанности да то есть база занимается всем соответственно если она занимается всем она не может делать все одинаково хорошо часто это просто разные базы и под базы данных понимается не обязательно sql там или по адресу ли oracle это может быть какой-нибудь кластер кассандра может быть тарантула может быть манга тебе может быть что то еще в зависимости от задачи в нашем случае на практике так и есть плюс даже если это например основная база да там реляционная прогресс то профиль нагрузки очень разные опять же в монолите одна из проблем это то что труднее отлаживается то есть micro сервиса тоже требует некоторой инфраструктура для упрощения отладки но случае базы вы вам трудно понять и за каких запросов все тормозит потому что тормозят как правило то есть нарушают работу база одни запросы а тормозят соседние поэтому вот чем больше у вас с некоторой функциональности внутри базы какой-то семантики запросов и так далее что вам труднее все это отделить сам банально будет труднее администрировать единую базу плюс случай монолитной базы у нас тоже не все в одном хранилище вот плюс тут как бы еще большая нагрузка на эксплуатацию все-таки лучше лучше по возможности разносить либо если вам нужно синхронизироваться между разными базами использовать события благодарю вас спасибо вам простоте голове плачу рука да здравствует спасибо за доклад он такой архитектурный получился вот вопрос эти доказать если у нас разные сервисы используй какой-то общих 1 это естественно . то носить в виде библиотек не обязательно такой правильный путь перри используемый код может ли или должен ли оформляться библиотеками которые потом естественно несут зависимы коду бог есть такой я я я воспользовался просто абсолютно правильный вопрос как бы утверждений не моё наука ты услышал прочитала но мне очень понравилось если вам в этом что-то нужно ну вот эту зависимость до нескольких сервисов нужно что-то поменять синхронно да то скорее всего это не библиотека этот это некоторый еще один сервис что-то вынести в библиотеку можно при условии что эта библиотека должна но может меняться не синхронно по всем сервисам по всем инсам по всем приложениям потому то она по определению распределенного сервисов по определению много ну или несколько по крайней мере вы не можете синхронно поменять версию библиотеки во всех сервисах так чтобы это все не сломалась поэтому если зависимость требует некоторого единого deployment а то это скорее всего сервис если код может существовать причем не в рамках там 30 секунд а в рамках долгого времени существовать в виде разных версий да у нас есть county regis клиент например на он может быть в одном сервисе версии 1 другом сервисе версии 2 этот принципе ничего не ломает вот если так это может работать то это можно вынести библиотеку если меняться должно синхронно в одном месте она меняется часто и требует обязательно объем ли обновление клиентов тот сервис и даже в этом случае вам нужно будет если обновление несовместимый мигрировать это все через параллельные пиаре потом выключи мастером пожалуйста здравствуйте на вопрос когда у нас результатам работы одного microserver со является большой набор данных скажем гигабайт и он является входными данными для другого микро сервиса хорошо ли объединять эти два микро сервис в рамках скажем одного сервера и передавать эти данные через памяти или через диск а не гонять все это посети там архитектор смотреть гонять все через диск если ты именно вот диск физически да тут могут возникнуть вопросы с масштабированием то есть пока она как бы гоняется через диск может быть и ладно если вам нужно много процессов и вы можете как-то распараллелить обработка этих данных то здесь я бы скорее этот гигабайт это некоторое единое блога seo нельзя разделить ну даже в таком ну то есть если задача ровно в этом и она в принципе не параллели зато ну я бы все таки оставил на действительно потом оставил бы все это виде файла на диске но при этом все-таки подумал как бы это можно было раз проверить плюс не все инфраструктуры поддерживают в принципе оставить файл на диске да то есть если такой бернейс докера то там файловая система в принципе но она эфемерна то есть там пири-пири запуске контейнера она просто все стирается то есть тут нужно будет все равно есть какие-то другие подходы сетевые файловые системы как минимум до если мы работаем с диском и значит это все равно сеть и значит может быть этот гигабайт все-таки стоит куда нибудь положить видеоблогов какой-нибудь авторы авторы авторы центры например советуют их было бы класть в рай ок я не пробовал там дерзайте могу нам как вариант вот инфраструктура еще можешь задавать некоторые такие моменты если вы знаете у вас только один сервер одна утилита и задачи все и так работает то почему бы нет нет просто хочется параллели то есть каждый микро сервис он делает свою работу и они не обязательно связаны вот эти два микро сервису друг с другом есть и другие вещи капризнее связанные которые передают скажи мне гигабайта там ну дела байт понятно если работа асинхронная и второй сервис просто ждет можно например отдельно положить файл куда нибудь синхронизацию между сервер сами сделают через очередь да то есть второй сервис просто ожидает на очереди приходы некоторого события некоторые задачи да просто очередь задача получает события что файл готов надо работать и дальше обрабатывает собственно сам файл на самом деле вот я рассказывал про доклад димы ходакова которые занимаются каким-то региональными системами lavita в принципе у них сколько я могу судить их задачи у них похожие схемы когда нужно обучать мат модельки и перекладывать большие файлы как раз там между этапами can эра подготовить данные потом скормить их модели там из модели ну собственно уже получить артефакт виде обученной модели с данными да там виде скалярным ского объекты его уже потом куда-то тепло и там оборачивать сервис и так далее вот в принципе я думаю что вы поймаете можно поподробнее узнать как они это делают насколько я знаю у них как раз вот был рефакторинг сторону конвейера дочерью задачками но при этом где-то может быть еще осталось файловой системы но это все равно если это все хочется параллели масштабировать и так далее потому что сегодня вы stance обрабатывать один блок например до завтра нужно обработать 10 бобов и сама себе этот блок не параллели ца их стало больше то есть тут все равно нужно будет придумывать как его передать между узлами вычислительными спасибо пожалуйста спасибо вам за доклад вопрос такой вот микро сервис на архитектура вот тот что описывали сервис пир база да то есть сервис сервис становится такой независимой ячейкой и вот например чтобы приход пришла новая команда и нужно условная сервис запустить для разработки то есть хотелось бы добиться от легкого старта сервиса то есть там заходишь в ридми файл и пошел там скачает так репозиторий команда установки база команда там дистанцирования там зависимый библиотек и так хотелось бы узнать конкретное решение какое вы принимаете у себя вот чтобы достичь о тут нам бы хотелось таких задач легко поднять продукт как восстанавливать группа микро сервис если что-то вот backup какие цели теле и право то есть разные например версии базы данных например там какие-нибудь интимные данные в базе чтобы и сливать сторонним разработчикам где-то там далеко сделать аккаунт light новую версию базы и как вот это все вот эти вот регистрировать чтобы в проекте это было достаточно по тонкому реализовано не баш скрипта и там мухи который лазит там на ftp перекладывают чет там бэкапы там прям тут же mais quel там как вы с этим справляетесь нашел примерно 4 вопроса это она один вопрос то есть как бы набить сервисы как его восстанавливать но это как бы ограничение есть какие-то чтобы легко было право то есть может быть разные версии то есть нельзя все версии посмотреть бэкапов и как восстановить если централизовано под бэкапом имеется какая-то боевая базу под нагрузкой надо его iv которые много статистики заявок и например тестовый базы где все это не надо чтобы каждый раз backup долго не поднимался чтобы вот легко ну смотрите для нужет разработки мы используем подход когда у нас есть отдельный оффлайновый процесс до который делает так называемый сам болт то есть некоторый набор данных него есть некоторый конфигуратор но все это вся эта история самописный но там ничего особо сложного просто пишите некоторую конфигурацию какие данные вы хотите дернуть из реальной базы что вас могут быть некоторые внешние сущности грубо говоря компьютер на него там завязано кучу всего вы пишете некоторые такой конфиг взять юзера там сойди условно 8 или с определенным емейлом к тестовый пользователь вытаскиваете по нему некоторую дополнена дополнительные объектов в устроить и что важного то о чем вы говорили про всякие приватные данные и так далее и вот на основе этих данных собирается уже докер-образ и этот докер-образ используется разработчиками для divo то есть они работают на не всех данных и таким образом база разворачивается быстрее она занимает меньше места и так далее плюс эти данные опусти руются соответственно мы не нарушаем личные данные пользователей как приватную информацию там транзакции наверно вот такой подход а докер-образ то есть от базы данных то есть слово рядом базы прям хранится бинарник а в настоящее время в россии когда он стартует он просто делает мой сколь nuclear сквозь боль импорт более того это уже база с бинарными бинарными записями в самой базе то есть некоторый образ который содержит тебя внутри уже и базу тоже и все это периодически нося и перестраивается то есть мы имеем каждый день минимум каждый день до некоторые новый слепок с обновлёнными данными с накатанной миграцию спасибо пожалуйста а можно ли просто есть какая-то конкретная реализация которая придумала к вам подойти попозже и обсудить ее носок это велосипед на там в нашем случае ну докер очевидно не велосипед на нее минус воют на сидели щас просто небом долларов долго рассказывать я понял да конечно я буду здесь большое спасибо пожалуйста спасибо раздать здравствуйте спасибо за доклад вот вы рассказали про микро сервисы и там было упоминание что есть micro сервисы которые обслуживаются микро сервисами возникает некая иерархия зависимости вот каким образом вы оформляете или если оформляет те зависимость чтоб провести impact анализ ну предположим какой-то из микро сервисов мы планируем вывести из продакшена на что это повлияет с учетом развесистой sti дерево так ну в данный момент на самом деле готовая система у нас подобной нету но мы над ней работаем то есть это некоторый способ все начинается с но на самом деле все до могу рассказать как я планирую это делать я это буду делать ближайший месяц все начинается со и на самом деле почему потому что и для разработчика это некоторая единая точка входа в продакшен в кластеры так далее то есть нажимаю кнопочку за тепло и сервис мы можем помимо собственно самого тепло и сборки там документации так далее можем еще и в том числе куда-то запушить мета информацию о сервисе то есть мы вот на эти на этом этапе собираем некоторые информацию в том числе описание связи но при этом описании связи скорее всего нужно будет делать руками я видел аналогичные решения но они требуют кубер немцы и работают на уровне кластера и отслеживают трафик то есть это практически проксирование то есть на данный момент у вас нет форматов предстательство пока идея ну представь скажем так представление как это делать плюс там в чем еще удобства что там часто такая звездчатая система структура когда есть монолит . ну сервис и за сервисом который является опеки твоим по сути да еще большая пачка сервисов то есть связи не все со всеми а все-таки более централизованное это несколько упрощает подходы то есть понятно что есть связь там . . b вот команда может говорится команды б и а команда была же в рамках там своих трех четырех сервисов по пока к сожалению не автоматически разбирается где что то есть у вас ориентир на звезды чувствую структуру не на сетевую там типа мама на когда он рассчитывается аренды себе поста на самом деле когда все совсем скорее всего что-то не так с логикой приложения одолжи данность прям портным и снова там я нет я не отрицаю что у нас такого не будет но пока все сводится к вот таким схемам скорее спасибо пожалуйста сворачиваться здравствуй спасибо за доклад вы сказали что дешевле сделать победителем так команде а ios и разрабатывать свою описку сами car service команде допустим android приложение взорван они пришли на если какой подход окей а бизнес-логика это отдельное получается microserver или они обе команды дублируют recommend и продуктов на ну вот есть варианты что они не дублируются многие фичи часто не релизиться одновременно на ios и android как минимум там есть некоторые смещения по срокам и смещение это не ну в случае мобильных приложений это не continuous integration teams три раза в день как как написали это все-таки релизный цикл там 1 месте хотя бы поэтому они не так уж и далеко не всегда они делают одни и те же фичи плюс да если у вас есть некоторые общие функциональности серия там дайте мне вот notification center хороший пример да то есть у вас может быть сервис почты сервис отправки пуша и services мск есть некоторые сервис который разруливать например все модификации по разным каналам проектируя на те астана те остальные сервисы вот это может быть вынести в отдельный сервис а например как к этим сервисом будет пользоваться и 5 android или айос это можно рисовать в каждом конкретном open gate в отдельном то есть может теоретически получится такая ситуация когда в андроиде свой бизнес логика мой бизнес вот если такая ситуация действительно очевидно и она повторяется то вот этот подход с отдельным брендом для каждого фронтэнда он дает как бы преимуществ должен по крайней плюс меньше затрат на синхронизацию на коммуникацию и так далее кто-то что-то добавил у кого что-то сломалось при этом от тестируют разные команды при этом непонятно чем она сломалась потому что поменяли разработчика другой команды с практика показал что дешевле повторять два раза бизнес-логику были иметь некую третью команду которая описывает это doom команд не у нас как раз одно мобильная то есть практика поголовно не ношу спасибо здорово спасибо за доклад подскажите пожалуйста вы используете себя на проекте оба тестирования и если да то как вы распределяете запросы между разными версиями сервисов на уровне инфраструктуры кубер нет или все-таки тестируйте внутри компонентов все даже печальнее скорее чаще всего все таки оба тестирования пока в монолите но уже инструменты ну потому что сервиса собственно что-то делаю там монолит решает кого он вызовет когда и так далее и тут скорее движение в сторону того что из монолита будет вытащи на все останется некоторая пи gateway как который как раз и будет заниматься оба тестированием но оба тестирования удобно все-таки делать в этом самом монолите с отдельным сервисом который например хранит эксперименты самом эту информацию но если вы будете использовать эти gotway то вам нужно и между сервисами его вставить то есть они напрямую могут соединяться запросто отправлять нужно таки через api gotway даже внутридневных итоге может решать каким сервисом сделать запрос и например как пример у нас есть там пачка рекомендательных сервисах да перед ними есть один gateway это как бы уже и сейчас так при этом вы с клиента можете собрать запрос битвы и таким образом чтобы указать какие рекламные бэг-энда выдерните не рекламные организационная вы можете сделать некоторую там выбор куда что каждый сотый запрос мы запрашиваем еще и новый сервис рекомендации вместо старого там или еще какой-то дополнительный то есть логика и рулет в нашем случае сейчас монолит но при этом мы можем с разных сервисов собирать или не собирать какие-то данные там делаем запрос или не делать вот запрашиваете не запрашивают логика остается за вызывающей стороны спасибо к нос последний вопрос после этого нас будет книжка за лучший вопрос если раньше доклад раз спасибо за доклад на самом деле два вопроса ага первый вопрос как вы делаете транзакционный между микро сервисами то есть грубо говоря есть сервис который там не знаю подтверждает счет есть сервис который там совершает покупку продукта или там какой-то резервирование если допустим счет не подтвердился или что-то произошло то другой сервис там должен откатить операцию как вы это разруливаете то первый вопрос второй вопрос насколько должен быть маленьким или большим микро сервис то есть если не учитывать там принципе диной ответственности ну что это как бы понятно просто если так вот сложилось что у сервиса ну там статистика например много данных много кода есть какие-то метрики которые позволяют там понять что вот все как бы микро сервис слишком большой породили там спасибо пожалуйста смотрите по поводу разниц по полу традиционности опять же распределенные системы опять же тут скорее даже задача часто ставятся не обеспечить инновационность иметь возможность восстановления после авария то есть догнать состоянии до какого-то актуального в случае независимых баз в принципе это все делается при помощи опять же событий и некоторого logo этих событий то есть у вас есть база состоянием а некоторая база б вы что-то комитете в локальную базу и отправляйте event принимающей стороне чтобы догнать ее состояние он его получает а догоняет и все как бы консистенции но венчал contestant как то так если вам реально совсем-совсем нужны транзакции что бывает а сам не так часто на мой взгляд то все-таки пусть это будет одна база но чаще всего вот такого и венчур дагона состояния должно быть достаточно то есть грубо говоря у нас есть база для аналитики ибо зовут для обработки онлайн транзакции да и мы в принципе не сделаем традиционность между верте кай и под грифом со мной венчал консистенцию те самые события которых антон будет рассказывать потом а по поводу границ микро сервис на собак поводу границы и но есть некоторые ты жид ну на самом деле если много логики скорее всего ее можно разбить то есть как хороший пример вот сервис который занимается платежами это один сервис или нет на самом деле его можно разбить то можно сделать действительно много сервисов при этом там не будет проблем с традиционностью потому что с транзакцию мне просто пояснил транзакциями будет заниматься сервис который будет заниматься собственно вот учетом да но отдельно у нас платежах есть все и шлюза то платежных систем и тут традиционности в любом случае уже как бы нет плюс плюс могут быть разные шлюзы отдельно функциональность для предоставления отчетности да и она не обязана быть транзакционный с онлайновой базы то есть мы вот эту всю логику которая вроде как про одно и тоже платежи можем побить уже на некоторую пачку совсем ну достаточно самодостаточных компонентов я думаю что в вашем случае но тоже можно хотя попробовать выяснится что не все она там про одно и то же по размеру все очень все варианты которые я слышал это что то что можно относительно быстро переписать но мне кажется логику деление микро сервисов но микро сервис и так далее можно же обсудить в кулуарах сейчас мы выбираем видимо сама вопросника до вопрос на мой взгляд правильно это вот как раз про карту сервисов про да для меня это очень неприятный вопрос потому что это то что я еще не сделал и что я делаю в данный момент на я считаю что правильно так поблагодарим сергея был очень интересный доклад про микро сервиса волита