коротко: - рантайм для контейнеров (goto cncf); - квоты в рантайма контейнеров (goto cncf); - свой контейнер реджистри; - api gateway (goto cncf); - писать sdk для своих микросервисов; - кодогенерация клиентов для микросервисов; - выбрать протокол (goto cncf); - service proxy (+ envoy контейнер; goto cncf); - jaeger для трейсинга; - service mesh (goto cncf); - свой шаблон сервисов (см. доклад Александра Лукьянченко); - kafka & pulsar для eventual consistency.
@konstantin50212 жыл бұрын
Cncf это что?
@vladimirmakarov6344 Жыл бұрын
@@konstantin5021 cloud native computing foundation
@valk98199 ай бұрын
Чисто по факту брат
@Павел-ю5и8 ай бұрын
Спасибо тебе.
@sodz51447 ай бұрын
Часто забывают, что наверное самой крутой фитчей микросервисов является Version delivery. Это когда ты можешь баллансировщиком указать долю нагрузки поступающую на новую версию сервиса одновременно продолжая эксплуатировать стабильную версию. Этот подход работает и при переходе от монолита к микросервисам, чертим карту-план перенаправления функционала в микросервисы и поехали.
@SergeiCherkai2 жыл бұрын
коротко - несколько раз подумайте, прежде чем идти в микросервисы
@maksimivanov8728 Жыл бұрын
Монолит проверен временем, найти по нему специалиста программиста несложно+недорого по цене, достаточно иметь сис.админа для обслуживания. А вот микросервисы это новый подход требующий высокой квалификации архитектора, которого сложно будет найти+дорого содержать ДевОпса которые тоже на дороге не валяются и тд. Вся эта чехарда с новыми технологиями разработки не оправдана, а лишь усложняет работу программистов и тех-менеджеров.
@vr296459 ай бұрын
это усложняет разработку для двух десятков программистов которые делают платформу, для остальных все элементарно
@WarbeastMr11 ай бұрын
Прикольно звучит. Набрали туеву хучу инженеров и думаем, чем бы их занять? А, точно, микросервисы же!!!
@uralk4347 ай бұрын
могут себе позволить))
@alexeybobr45372 жыл бұрын
Пипец 1К микросервисов в авито. Что там может быть такого на сайте объявлений? Современное программирование превращается в какой-то нелепый аттракцион для усложнения себе жизни с последующим его героическим преодолением.
@PlayGameToday2 жыл бұрын
Просто не научились оптимизировать, и это далеко не "современное программирование", а "программирование в Авито", лол )))
@namesurname35332 жыл бұрын
Дело не в том, что есть на сайте, а в нагрузке. Представь сколько людей, каждую секунду заходит на авито
@timur28872 жыл бұрын
Типичная ситуация для большого количества разработчиков: никто не в состоянии удержать в голове всю систему, она превращена в помойку
@agentdaun5699 Жыл бұрын
@@timur2887 Так для этого микросервисы и нужны. Разработчику рекомендательный системы не нужно знать что там в поиске. 1000 это не микросервисов, а инстансов.
@timur2887 Жыл бұрын
@@agentdaun5699 да какая разница, помойка есть помойка)
@SlavaVy0 Жыл бұрын
Напоминает какое-то сравнение agile vs waterfall да никто никогда не писал монолиты, который запускается единым процессом и все статически линкуется. Точно также раньше в деплое была пачка всевозможных компонент, которые имели свой релизный цикл и все свое, другие команды просто ходили туда по API По авито складывается ощущение, что микросервис = класс(или небольшой набор классов), но потом постоить цепочки вызовов кто в какой сервис ходит становится мегапроблематично.
@-dubok- Жыл бұрын
А не лучше ли использовать DDD подход? При прямых связях между сервисами получается, по-сути, всё тот же монолит, так как вызовы прямые и сервисы обязаны знать друг о друге. Это порождает кучу межсервисных взаимодействий, прокси и прочего барахла. Такое должно быть тяжело поддерживать. Я считаю, что лучше изпользовать событийно-ориентированную архитектуру. Событие - это сообщение без указания адресата. При такой архитектуре каждый сервис связан только с шиной событий и больше ни о чём не знает. Это выглядит куда проще и, на мой взгляд, правильнее.
@AgentFire0 Жыл бұрын
А какая принципиальная разница между микросервисом, являющимся мастер-хранилищем информации о сущности N, и некоей абстрактной доменной моделью (куда можно обратиться), представляющей эту же сущность N, но под капотом реализуемой, скорее всего, таким же одним микросервисом? Допустим такую ситуацию, где сервису нужно сходить за информацией об объекте N. 1. В случае со знанием "куда идти", мы делаем синхронный запрос в целевой микросервис (= имеем знание о нём, как об "ответчике" на такие запросы) 2. В случае с событиями, мы делаем асинхронное событие "хочу инфу по объекту N", и терпеливо ждём событие-ответ с нужными данными. (=имеем знание о том, что событие-запрос обязательно формирует событие-ответ) Имхо, оба варианты примерно эквивалентны.
@-dubok- Жыл бұрын
@@AgentFire0 микросервисы - это разбиение по функциям (службам, сервисам), а DDD - разбиение по предметным областям. Функции могут использоваться разными другими микросервисами для какой-то своей непонятной логики, а предметные области чётко делят приложение на независимые части. Функциональное разбиение делает приложение очень связным, и это прямые связи всегда. Короче, тот же монолит, но разбитый на отдельные, связанные по сети, части. А в предметной области большая часть происходящего (иди даже вся) независима от других предметных областей. В DDD какие-то функции могут повторяться в разных микросервисах, потому что главное - это независимость предметных областей, а не разделение труда по функциям. В DDD проще реализовать событийную архитектуру и именно она там и должна использоваться, а в микросервисах так не получится, потому что они заточены на прямые вызовы и очень зависимы друг от друга.
@millkiway3682 Жыл бұрын
3:17 контейнеры не используются в продакшнне. К чему тогда был весь этот доклад с примерами докер контейнеров
@valk98199 ай бұрын
Может кто-то объяснит мне когда идет autoscale и downscale что происходит с данных из баз данных когда происходит downscale?
@sergeypoprygin26703 жыл бұрын
22:48 не работал с микросервисами, но secure breaker - что-то новое, слышу впервые, но про circuit breaker слышал
@f00b4r123 Жыл бұрын
Я думаю что имелось в виду SSL termination.
@voothi-it3 жыл бұрын
Интересный доклад
@voothi-it3 жыл бұрын
Базы данных микросервисов в PaaS в контейнерах работают в PROD-е? Какая система хранения используется? Ceph или отдельные ZFS?
@TheMMgo3 жыл бұрын
Как правило базы вне k8s живут. На отдельных контейнерах на bare-metal
@mikhailanazarov2 жыл бұрын
Хороший доклад
@Илья-ф9г5ы3 ай бұрын
Говорит используйте кирпичики готовые, только мы сделали везде самопис))6
@evtuhovdo Жыл бұрын
3к репозиториев! Клоните себе все зависимости?
@sodz51447 ай бұрын
Это не микросервисы(по определению микросервисов), это SOA. Я понимаю что не так модно звучит, зато более жизнено.
@niknt Жыл бұрын
Спасибо большое, интересно было узнать о технических моментах работы Avito. В докладе говорилось, что в Avito разрешены только 4 шаблона микросервисов: Go, Node, PHP, Python. Интересно, почему сюда не включили Java? Слишком медленная?
@RomanTchekashovАй бұрын
Раньше graalvm не было и фреймворков типа Quarkus, которые потребляют меньше ресурсов на одном инстансе. Если взять Spring Boot для одного микросервиса и запустить 1500 таких, то ресурсов цпу и памяти будет потреблять не мерено, большие расходы. А сейчас на Quarkus тоже немного потребляет, но у них уже 1500 микросервисов на Go и добавляя Java уже плохая идея, так как в компании уже не так много людей из других команд, которые знают Java и смогут поддерживать сервисы на ней.
@Covid_19_23 Жыл бұрын
каждые выходные авито стоит колом. не знаю, что там криво у вас.
@PlayGameToday2 жыл бұрын
39:25 что-о-о? "Денацифицировать зал" ? О май гад!
@dm.vortex41712 жыл бұрын
дезинфицировать от пэхапэшников надо главное. святая миссия
@kolabaka68518 ай бұрын
Когда разработчик говорит, что в продукте 1к микросервисов что он имеет в виду? 1000 уникальных микросервисов или напоимер 250 x, 250 y и 500 z микросервисов? Это же полный идиотизм, если всё идёт по первому сценарию!!!!
@sodz51447 ай бұрын
3:02 АТОМАРНОСТИ
@ГеоргийТрубецкой-й8й2 жыл бұрын
Выступление отличное. Но в целом Авито как проект имеет серьезные изъяны для конечного потребителя. Решайте проблемы здесь, на Земле, а не летайте на Марс. Нужно больше микросервисов! Ведь у нас все плохо только потому, что их мало, а не потому, что с точки зрения потребителя решение в целом неудачное. Дойдите до 3000 тысяч микросервисов, тогда все станет замечательно. Увеличьте штат ИТ ещё в 2 раза, чтобы уж наверняка. Нагрузка неравномерная? Надо больше мошностей. Но зачем их оптимизировать по регионам и по времени суток, верно? Можно же просто взять и добавить ещё. Микросервисов никогда не бывает много. У нас их 1500, но про пару сотен мы ничего не знаем. Значит надо добавить ещё! И да, учите Go, на нем все микросервисов написаны.
@kraken645 Жыл бұрын
россия богатая страна, денег не жалко.
@vivowalk6 ай бұрын
Суть доклада: 1. Авито вместо разработки играются микросервисами 2.в авито зашли на сайт с готовыми решениями, выбрали и настроили их
@timur28872 жыл бұрын
Ну в общем авито заросло легаси кодом, который ещё и частично мёртвый, верно?)
@anton6643 Жыл бұрын
Половину которого написал неизвестно кто и неизвестно нахуя.
@nikitasid494711 ай бұрын
Слабое связывание это называется. Класть, а не "ложить". ЭтоГО избежать. Throttling не начинается, а срабатывает. тОкен, а не токЕн. Русский язык, бл., как обычно. --- Тем временем, Авито, как ни зайдешь, вечно в дауне.
@divisionbyzero93802 ай бұрын
Какая-то херня. Доклад - хороший аргумент так не делать....
@kremen1571 Жыл бұрын
ну, Авито конечно говно)
@PlayGameToday2 жыл бұрын
Вот когда научитесь произносить PHP как "Пи Эйч Пи", а не "Пэ Ха Пэ", тогда и зовите!
@dm.vortex41712 жыл бұрын
скоро вообще никак не будут называть, ибо все забудут как это звучит и что это такое)
@kalmurza Жыл бұрын
Это русский суровый IT: пэхэпэ, аштимель, шедулер ))
@anatoly-k Жыл бұрын
@@kalmurza и это прекрасно.
@-dubok- Жыл бұрын
Да кому ты нужен?
@constantinegeist1854 Жыл бұрын
PHP - "персонал хоум пейдж". Поэтому Пэхэпэ тоже логично :)
@tertiumorganum5665 Жыл бұрын
полдоклада ниочем, еще бы рассказал из чего компьютер