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

Микросервисная Архитектура: проблемы и решения

Сергей Орлов
Архитектор, лидер юнита Архитектура в Avito
  • Видео
  • Тезисы
  • Видео
РИТ++ 2017
5 июня 2017, Сколково, Россия
РИТ++ 2017
Запросить Q&A
Видеозапись
Микросервисная Архитектура: проблемы и решения
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
В избранное
9,05 K
Мне понравилось 0
Мне не понравилось 0
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
  • Описание
  • Расшифровка
  • Обсуждение

О спикере

Сергей Орлов
Архитектор, лидер юнита Архитектура в Avito

О докладе

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

Большое количество современных веб-проектов переходит на микросервисную архитектуру.

Она решает большое количество проблем, присущих монолитным системам, однако накладывает 
качественно новые требования на разработку, эксплуатацию и тестирование. Многие классические задачи предстают в новом свете.

В докладе я коротко расскажу об основных паттернах микросервисной архитектуры, опишу присущую ей проблематику, а также дам обзор подходов, помогающих в решении проблем.

Поделиться

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

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

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

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

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

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

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

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

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

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

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

достаточно известный принцип Single responsibility Что значит здесь здесь значит опять же вещи опять же всё связано с законом каналы то есть принцип единой ответственности кода некоторой системы которая делает Ровно одну вещь которая не ожидается и при этом четко расписано если мы видим что сервис начинает на самом деле выполнять различные функции есть целый набор функциональности которая не относится к другой функционал сервиса то мы можем вынести в

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

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

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

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

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

заходит у нас уже есть база которая Скорее всего тоже монолитные и скорее всего очень большая и и при этом на с мигрировать тебя просто так затруднительно но при этом даже в такой ситуации Да когда мы идём с ней Из точки 0 точка A и точки 100 из 12 V3 хотим попасть куда-то в 10:00 где у нас прекрасная микросервисной архитектурой все сервисы независимые общаются друг с другом по понятно протоколом даже таком случае мы можем применить несколько приёмов Чтобы достичь подобного уровня

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

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

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

для различных сервисов То есть например где-то делать крут банально там jangi условных синхронных фреймворках что просто больше поддержка библиотек больше разработчиков знает Быстрее Всё происходит разработка Gateway часто делают асинхронными используют для их разработки асинхронные фреймворки Даже если мы используем один язык для всей компании то этому разные формулировки случае питона там синхронное торнадо и синхронный Django rest Ноги твои удобнее делать синхронно Потому что когда так там как правило немного и поэтому

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

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

есть доступная версия сайта там с джаваскрипт фронтендом вот При таком подходе часто бывает полезно делать разные pyae разных клиентов и такой подход называется backend frontend когда Таких вот Great Wave делается несколько поклеить на платформу плюс бывают варианты Когда удобно держать даже не одно мобильное папа мобильный мобильный примерно каждые мобильное приложение потому что здесь опять же вступает в силу Закон конвея что приложение очерчена также команда если нас например отдельная команда разработки мобильного оператора для iOS отдельная то логично сделать отдельный гейтвей

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

каждому из сервисов возникает задача найти инстанса там где запущена и запросить такие данные отсутствует такое понятие как сервис-реестр это некоторая централизованное хранилище которое хранит в себе весь список сервисов актуальная информация где кто и ответственность за поддержание информации в актуальном состоянии при этом Service Discovery можно условно разделить на два варианта два подхода так называемой клиентская когда сервис клиент сам занимается тем что находятся конечно endpoint и некоторое сервис Северное когда он находит

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

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

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

в случае микросервисов Вот такая история не прокатит Вам нужен некоторый всякий вам чтобы автоматизировать deployment вам нужно собственно само средство deployment вам нужны некоторые артефакты которые будут которые будут диплоид сада в нашем случае Ну распространенный подход сейчас это docker контейнеры Но это может быть и доп пакета rpm пакет то есть некоторый слой абстракция на тему технология минако на которых вы разрабатываете потому что в нашем случае например 24 за КБК ЕНВД отработки но при этом вся

и должен быть Един он как бы помимо этого все эти процессы и все эти сервисы даже если у вас всё это не нагружена но у вас уже 10 сервисов для отказоустойчивости вы подняли по 3 штуки по русскому обычаю ситуациях уже 30 и все эти 30% надо как-то менеджменте надо их запускать причём запускать так как мы стремимся Да уменьшить time-to-market можно быстрее то ещё и перезапускать как-то выкатывается следить что они там всё-таки работают и тут возникает вопрос мониторинга путем автоматического мониторинга который не должен

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

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

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

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

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

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

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

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

команд Вот это эту проблему, как бы, чем надо решать их можно раньше ты сразу внедряя, микросервисная архитектура задумал, по крайней мере о том, как бы, как мы будем узнавать о новых сервисах. Как там где греться Happy маме, потому что внедрение новые фичи во многом по времени упирается в изучении в отладку и, если нас нет полноценного Station Как дела, Мы можем сделать запрос к развернутому сервису, то разработка каждой новые фичи сильно замедляется, А в случае микросервисной архитектуры многое фичи и представляет из себя,

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

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

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

как на самом деле Мониторинг это огромное обширные темы, и там он может быть, так очень скучно и очень простое так и бесконечным полем для применения знаний опыта таланта желание что-то делать будет доклад про так называемый Винкс рейтинг то есть случае микросервисная архитектура У нас есть такой как бы есть разные паттерны как сервис общаются между собой есть асинхронными либо синхронными то есть есть асинхронный вариант page степени который бегает Амбре соляр PC когда мы просто

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

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

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

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

подтверждает опять же в сохранении в контексте Service Discovery там возникает еще ряд вопросов связанных с Discovery конфигурация датой сохранением конфигурации сестра там factors учит нас вообще здравый смысл учит нас о том что конфигурацию нужно отделять от приложение приложение конфигурация должна инжектится injection принцип опять же достаточно старый Вот с таким подходом помимо инжектор конфигурации Да есть что инжектор называемых секретов то есть некоторый информации Нельзя просто хранить системе управления систем контроля версий в бите

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

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

Прости меня зовут Виктор Благодарю вас за доклад после упомянули в начале доклада о таком принципе Database Database for Service вопрос Ну из этого вытекает что у нас под каждый раз получится это свобода а в общем в приложении Она будет очень фрагментировано А не лучше ли делать отдельные сервис под базу данных остальные сервисы интегрировать в эту базу которые будут к этому сервису обращаться А ты лучше просто не всегда мы начинаем с того что делаем новые сервисы поэтому есть вариант когда базу уже есть она монолитная и так далее Тогда нужно постепенно выносить функциональность

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

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

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

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

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

по крайней мере вы не можете синхронно поменять версию библиотеки во всех сервисах так чтобы это всё несла Поэтому если зависимость требует некоторого единого дипломата Это скорее всего сервис если кот может существовать Почём не рамках там 30 секунд а в рамках долгого времени существовать в виде разных версий Да точно свечку интерес клиента например да Он может быть в одном сервисе версия 1 в другом server2 это в принципе ничего не ломает вот если так то может работать то это можно вынести в библиотеку если меняться

должно синхронно в одном месте она меняется часто и требует обновление клиентов Тойота сервис и даже в этом случае вам нужно будет если обновление несовместимые мигрировать Это всё через параллельные и потом выключения старого пожалуйста Здравствуйте дорогой вопрос Когда у нас результатом работы одного микросервиса является большой набор данных скажем гигабайт и он является входными данными для другого микросервиса Хорошо ли объединять эти два микросервиса в рамках скажем одного сервера и передавать эти данные

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

бы всё-таки оставил на действительно потом оставил бы всё это видео файлы на диске но при этом всё-таки подумал как бы это можно было распараллелить плюс не все инфраструктуры поддерживают в принципе файл на диске да то есть если это kubernetes docker Росатом файловую систему в принципе она эфемерно то есть там перезапуск контейнера но просто Всё стирается нужно будет всё равно есть какие-то другие подходы сетевые файловые системы как минимум до 7 работаем с дисками значит это всё равно сеть значит может быть этот гигабайт всё такие стоят

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

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

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

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

то есть хотелось бы добиться вот легкого старта сервиса то есть там заходишь в файл и пошёл там начать скачать так репозиторий команда установки база команда там дистанцирование там зависимых библиотека так да Вот хотелось бы узнать конкретно решение Какое Вы применяете у себя вот чтобы дать нам бы хотелось таких задач легко поднять продукт как восстанавливать группу microservices если что-то вот Backup какие-то слетели и права то есть разные например в версии базы данных например там какие-нибудь интимные данные в базе чтобы не сливать сторонним разработчикам где-то там далеко

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

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

Какие данные вы хотите дернуть из реальной базы что Вас могут быть некоторые внешние сущности говоря компьютер на него там завязан Выпишите некоторые такой конфликт взять юзера там Зайди в 8 или с определенным влмк тестовый пользователь вытаскивать по нему некоторую структуру дополнять объектов в Фокстроте что важно Вот о чём мы говорили про всякие приватные данные и так далее И вот на основе этих данных собирается уже docker образ и этот docker образ используется разработчиками для Daewoo то есть они работают на не всех данных и

таким образом базар заворачиваются быстрее она Занимает место и так далее плюс эти данные фиксируются в Советском мы не нарушаем личные данные пользователей приватную информацию там транзакция свернул такой подход а docker образ базы данных то есть слово рядом базы прямо хранится Бинар ником в настоящее время в России когда он стартует он просто делает - Говорит - импорт Ну более того это уже база с бинарными бинарными ну с записями в самой базе Toyota Town которые образ который содержит в себя внутри уже и базу тоже

IV периодически Нася и перестраивается то есть мы имеем каждый день минимум каждый день Да некоторые новой слепок с обновленными данными конкретными миграции а можно мне просто есть какая-то конкретная реализация которая придумал к вам подойти попозже и Обсудите её насколько это велосипед на там и в нашем случае ну docker очевидно Не велосипедна имеет свою сидели я сейчас просто не могу долго долго рассказывать я понял да конечно я буду здесь Большое спасибо Пожалуйста Здравствуйте спасибо зарплата пост

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

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

описании связи но при этом описании связи скорее всего нужно будет делать руками Я видел аналогичное решение Но они требуют kubernetes и работают на уровне кластера и отслеживать трафик соседа практически проксирование то есть на данный момент у вас нет форматов приходится пока идея да Ну представь скажем так представление как это делать там в чём ещё удобства что там часто такая звездчатая система структура когда есть monolith.in.ua сервис ИЗО сервисом к твоим по сути да еще большая пачка сервису

то есть связи не все со всеми а всё-таки более централизованное Это несколько упрощает подходит то есть связь там точка а точка б вот команда может Договориться с команды б и а команда была уже в рамках там своих трёх-четырёх сервисов Пока к сожалению не автоматически разбирается где что ориентирована звездочёта структуру не на сетевую там типа Movano когда он рассчитывает scp-073 поставил на самом деле когда всё совсем скорее всего что-то не так с логикой приложение ценность виноватым Я не я не отрицаю что нас такого не будет но пока всё

сводится к таким схемам скорее Спасибо пожалуйста сворачиваться Здравствуй Спасибо за доклад А вы сказали что дешевле сделать приблизительно так команде iOS разрабатывает свою Apes q-service команде допустим Android приложение взрывными большой жирный есть такой подход О'кей А бизнес логика это отдельная получается microservice или они обе команды дублируют реклама продуктовых вот есть варианты что они не дублируются многие фичи часто не реализуется одновременно на йоте Андроиде как минимум там

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

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

тестировать разные команды Просто непонятно почему она сломалась потому что поменяли разработчик другой команды практика показала что дешевле повторять два раза бизнес-логика нежели иметь некую третью который заставляет Это не у нас как раз одно мобильная ты нашу Спасибо пожалуйста Здравствуйте спасибо за доклад подскажите пожалуйста вы используете себя на проекте А бета-тестирования и Если да то как вы распределяете запросы между разными версиями сервисов на уровне инфраструктуры кубернет или всё-таки тестируйте внутри компонентов внутри

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

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

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

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

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

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

между Веркой ip-адресом всё равно welcomes ногти самые события которых Антон будет рассказывать потом А по поводу границ microservices по поводу границы есть некоторые Ну на самом деле если много логики скорее всего её можно разбить То есть как хороший пример вот сервис который занимается платежами 1server Нет на самом деле его можно разбить там можно сделать действительно много сервисов при этом там не будет проблем с наклонностью потому что с транзакцию мен просто пояснил транзакциями будет заниматься сервис который будет заниматься учётом Да

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

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

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

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

Доступ к видеозаписи доклада «Микросервисная Архитектура: проблемы и решения»
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно

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

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

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

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

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

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

Антон Иванов
Тим лид команды SRE в Headhunter
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Николай Балакирев
Ведущий разработчик в Avito
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Николай Рыжиков
Разработчик в HealthSamurai
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно

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

Видеозапись

Доступ к видеозаписи доклада «Микросервисная Архитектура: проблемы и решения»
Доступно
В корзине
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно
Бесплатно

Conference Cast

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

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