Микросервисы с нуля / Семен Катаев (Авито)

[@OstretsovArtem]

коротко: - рантайм для контейнеров (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.

[@konstantin5021]

Cncf это что?

[@vladimirmakarov6344]

@@konstantin5021 cloud native computing foundation

[@valk9819]

Чисто по факту брат

[@Павел-ю5и]

Спасибо тебе.

[@SergeiCherkai]

коротко - несколько раз подумайте, прежде чем идти в микросервисы

[@sodz5144]

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

[@WarbeastMr]

Прикольно звучит. Набрали туеву хучу инженеров и думаем, чем бы их занять? А, точно, микросервисы же!!!

[@uralk434]

могут себе позволить))

[@alexeybobr4537]

Пипец 1К микросервисов в авито. Что там может быть такого на сайте объявлений? Современное программирование превращается в какой-то нелепый аттракцион для усложнения себе жизни с последующим его героическим преодолением.

[@PlayGameToday]

Просто не научились оптимизировать, и это далеко не "современное программирование", а "программирование в Авито", лол )))

[@namesurname3533]

Дело не в том, что есть на сайте, а в нагрузке. Представь сколько людей, каждую секунду заходит на авито

[@timur2887]

Типичная ситуация для большого количества разработчиков: никто не в состоянии удержать в голове всю систему, она превращена в помойку

[@agentdaun5699]

@@timur2887 Так для этого микросервисы и нужны. Разработчику рекомендательный системы не нужно знать что там в поиске. 1000 это не микросервисов, а инстансов.

[@timur2887]

@@agentdaun5699 да какая разница, помойка есть помойка)

[@maksimivanov8728]

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

[@vr29645]

это усложняет разработку для двух десятков программистов которые делают платформу, для остальных все элементарно

[@SlavaVy0]

Напоминает какое-то сравнение agile vs waterfall да никто никогда не писал монолиты, который запускается единым процессом и все статически линкуется. Точно также раньше в деплое была пачка всевозможных компонент, которые имели свой релизный цикл и все свое, другие команды просто ходили туда по API По авито складывается ощущение, что микросервис = класс(или небольшой набор классов), но потом постоить цепочки вызовов кто в какой сервис ходит становится мегапроблематично.

[@-dubok-]

А не лучше ли использовать DDD подход? При прямых связях между сервисами получается, по-сути, всё тот же монолит, так как вызовы прямые и сервисы обязаны знать друг о друге. Это порождает кучу межсервисных взаимодействий, прокси и прочего барахла. Такое должно быть тяжело поддерживать. Я считаю, что лучше изпользовать событийно-ориентированную архитектуру. Событие - это сообщение без указания адресата. При такой архитектуре каждый сервис связан только с шиной событий и больше ни о чём не знает. Это выглядит куда проще и, на мой взгляд, правильнее.

[@AgentFire0]

А какая принципиальная разница между микросервисом, являющимся мастер-хранилищем информации о сущности N, и некоей абстрактной доменной моделью (куда можно обратиться), представляющей эту же сущность N, но под капотом реализуемой, скорее всего, таким же одним микросервисом? Допустим такую ситуацию, где сервису нужно сходить за информацией об объекте N. 1. В случае со знанием "куда идти", мы делаем синхронный запрос в целевой микросервис (= имеем знание о нём, как об "ответчике" на такие запросы) 2. В случае с событиями, мы делаем асинхронное событие "хочу инфу по объекту N", и терпеливо ждём событие-ответ с нужными данными. (=имеем знание о том, что событие-запрос обязательно формирует событие-ответ) Имхо, оба варианты примерно эквивалентны.

[@-dubok-]

@@AgentFire0 микросервисы - это разбиение по функциям (службам, сервисам), а DDD - разбиение по предметным областям. Функции могут использоваться разными другими микросервисами для какой-то своей непонятной логики, а предметные области чётко делят приложение на независимые части. Функциональное разбиение делает приложение очень связным, и это прямые связи всегда. Короче, тот же монолит, но разбитый на отдельные, связанные по сети, части. А в предметной области большая часть происходящего (иди даже вся) независима от других предметных областей. В DDD какие-то функции могут повторяться в разных микросервисах, потому что главное - это независимость предметных областей, а не разделение труда по функциям. В DDD проще реализовать событийную архитектуру и именно она там и должна использоваться, а в микросервисах так не получится, потому что они заточены на прямые вызовы и очень зависимы друг от друга.

[@sergeypoprygin2670]

22:48 не работал с микросервисами, но secure breaker - что-то новое, слышу впервые, но про circuit breaker слышал

[@f00b4r123]

Я думаю что имелось в виду SSL termination.

[@Илья-ф9г5ы]

Говорит используйте кирпичики готовые, только мы сделали везде самопис))6

[@millkiway3682]

3:17 контейнеры не используются в продакшнне. К чему тогда был весь этот доклад с примерами докер контейнеров

[@voothi-it]

Интересный доклад

[@valk9819]

Может кто-то объяснит мне когда идет autoscale и downscale что происходит с данных из баз данных когда происходит downscale?

[@evtuhovdo]

3к репозиториев! Клоните себе все зависимости?

[@sodz5144]

Это не микросервисы(по определению микросервисов), это SOA. Я понимаю что не так модно звучит, зато более жизнено.

[@mikhailanazarov]

Хороший доклад

[@Covid_19_23]

каждые выходные авито стоит колом. не знаю, что там криво у вас.

[@PlayGameToday]

39:25 что-о-о? "Денацифицировать зал" ? О май гад!

[@dm.vortex4171]

дезинфицировать от пэхапэшников надо главное. святая миссия

[@niknt]

Спасибо большое, интересно было узнать о технических моментах работы Avito. В докладе говорилось, что в Avito разрешены только 4 шаблона микросервисов: Go, Node, PHP, Python. Интересно, почему сюда не включили Java? Слишком медленная?

[@RomanTchekashov]

Раньше graalvm не было и фреймворков типа Quarkus, которые потребляют меньше ресурсов на одном инстансе. Если взять Spring Boot для одного микросервиса и запустить 1500 таких, то ресурсов цпу и памяти будет потреблять не мерено, большие расходы. А сейчас на Quarkus тоже немного потребляет, но у них уже 1500 микросервисов на Go и добавляя Java уже плохая идея, так как в компании уже не так много людей из других команд, которые знают Java и смогут поддерживать сервисы на ней.

[@voothi-it]

Базы данных микросервисов в PaaS в контейнерах работают в PROD-е? Какая система хранения используется? Ceph или отдельные ZFS?

[@TheMMgo]

Как правило базы вне k8s живут. На отдельных контейнерах на bare-metal

[@vivowalk]

Суть доклада: 1. Авито вместо разработки играются микросервисами 2.в авито зашли на сайт с готовыми решениями, выбрали и настроили их

[@kolabaka6851]

Когда разработчик говорит, что в продукте 1к микросервисов что он имеет в виду? 1000 уникальных микросервисов или напоимер 250 x, 250 y и 500 z микросервисов? Это же полный идиотизм, если всё идёт по первому сценарию!!!!

[@sodz5144]

3:02 АТОМАРНОСТИ

[@ГеоргийТрубецкой-й8й]

Выступление отличное. Но в целом Авито как проект имеет серьезные изъяны для конечного потребителя. Решайте проблемы здесь, на Земле, а не летайте на Марс. Нужно больше микросервисов! Ведь у нас все плохо только потому, что их мало, а не потому, что с точки зрения потребителя решение в целом неудачное. Дойдите до 3000 тысяч микросервисов, тогда все станет замечательно. Увеличьте штат ИТ ещё в 2 раза, чтобы уж наверняка. Нагрузка неравномерная? Надо больше мошностей. Но зачем их оптимизировать по регионам и по времени суток, верно? Можно же просто взять и добавить ещё. Микросервисов никогда не бывает много. У нас их 1500, но про пару сотен мы ничего не знаем. Значит надо добавить ещё! И да, учите Go, на нем все микросервисов написаны.

[@kraken645]

россия богатая страна, денег не жалко.

[@timur2887]

Ну в общем авито заросло легаси кодом, который ещё и частично мёртвый, верно?)

[@anton6643]

Половину которого написал неизвестно кто и неизвестно нахуя.

[@divisionbyzero9380]

Какая-то херня. Доклад - хороший аргумент так не делать....

[@nikitasid4947]

Слабое связывание это называется. Класть, а не "ложить". ЭтоГО избежать. Throttling не начинается, а срабатывает. тОкен, а не токЕн. Русский язык, бл., как обычно. --- Тем временем, Авито, как ни зайдешь, вечно в дауне.

[@kremen1571]

ну, Авито конечно говно)

[@PlayGameToday]

Вот когда научитесь произносить PHP как "Пи Эйч Пи", а не "Пэ Ха Пэ", тогда и зовите!

[@dm.vortex4171]

скоро вообще никак не будут называть, ибо все забудут как это звучит и что это такое)

[@kalmurza]

Это русский суровый IT: пэхэпэ, аштимель, шедулер ))

[@anatoly-k]

@@kalmurza и это прекрасно.

[@-dubok-]

Да кому ты нужен?

[@constantinegeist1854]

PHP - "персонал хоум пейдж". Поэтому Пэхэпэ тоже логично :)

[@tertiumorganum5665]

полдоклада ниочем, еще бы рассказал из чего компьютер