×Закрыть

Есть ли смысл углубляться в микросервисы «почти» java миддлу?

Если да, то какие подводные камни? Какие знания в основном требуют на проекты с микросервисами/облачными технологиями?

LinkedIn

Лучшие комментарии пропустить

не надо. Зачем тебе новые полезные знания? Кушай себе сыры по 500 да и все, зачем всяким голову забивать?

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нікакіх, на проекті з мікросервісами вже є розумний чувак який засетапив RPC, Service Discovery, черги і тд а також деплоймент, ти будеш копирсатися в свому маленькому мікросервісу спілкуючись з зовнішнім світом по http (або grpc якщо розумний чувак був мазохістом) і нічим твоя робота не буде відрізнятись від роботи без мікросервісів.

Building Microservices — прекрасная книга, почитайте на досуге.

Микросервис — как микропенис.
О нём рассказывают, но никто не показывает.

Если не знаешь что делать, подожди немного, возможно завтра о них никто не вспомнит..

ага, примерно так же как никто не вспомнил чиловекочитаемого ассемблера в своё время,
потом никто не вспомнил ЯП высокого уровня.
потом никто не вспомнил про ООП
ну и так далее никто ничего не вспоминает с развитием технологий.

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

Решаться то они могут кем угодно, что чтобы рости дальше и развиваться в подобные вещи стоит вникать. Иначе, как уже писали ниже, будешь клепать формочки как местные синьеры.

Раз он тут задаёт вопросы. То клепать он будет полюбому.

Говноформы и говносервисы далеко друг от друга не ушли

Да ну и что. Зато в резюме можно скил добавить

Ну ок, буду на собесе тщательнее проверять.

А может и не будут. Просто продадут клиенту который хочет микросервисов)))

Вот благодаря таким советам клепают говно. System Design это то что делает разработчика вменяемым, это практически самое важное и это то что надо учить с самого начала, конечно это не освоится за пару недель но дорогу осилит идущий

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

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

жаль что топ компании об этом не знают, правда?...

Топ-компании часто занимаются всякой хернёй. Набирают хипстеров, финансируют проект — а потом выкидывают годы хипстерской работы (и самих хипстеров) на помойку. Мол, пошли не тем путём, бывает...

Топ-компании часто занимаются всякой хернёй.

всякой херней? это миллиарды зарабатывают что ли? )))))

Проекты есть разные. Зарабатывают-то не хипстерщиной.

ты вообще не понимаешь о чем говоришь, серьезно

Я в курсе. Только хипстеры, с микросервисами головного мозга — понимают и знают жизнь.

это как рассуждать о вкусе устриц не пробуя их никогда. Откуда тебе знать как топ компании работают? На заборе написали?

Откуда тебе знать как топ компании работают? На заборе написали?

Я работаю за 1к/день в компаниях, которые могут так платить нужным людям годами. Полагаешь, так могут себе позволить платить «рога и копыта»? :)

А потом, всё ведь с микросервисами на поверхности. Для небольшой системы — микросервисы избыточны. Для большой системы — представляют из себя затык по скорости и ресурсам. При этом, сложны (намного сложнее монолита) в поддержке (технической экплуатации), разработке, отладке. В общем, где при всех этих «достоинствах» место микросервисов? Где-нибудь на помойке в универах.

Это даже хуже другой хипстерщины — функциональщины. По-крайней мере, у ней есть ниша в небольших проектах, где нужно быстродействие небольшого (до, скажем, 10к строк) кода, а ООД при этом избыточен.

Я работаю за 1к/день в компаниях, которые могут так платить нужным людям годами. Полагаешь, так могут себе позволить платить «рога и копыта»? :)

- Могут, некуй делать. Я работал одно время на крупную европейскую контору, которая платит очень солидные гонорары, но в их так называемом «IT отделе» типы не могли дату отформатировать бригадой в 15+ человек. Так что солидный бабос, который контора платит, порой никак не коррелируется с технологичностью. Сам работал в топах аля Гугл/Фэйсбук или теоретик?

в их так называемом «IT отделе»

В «ИТ-отделах» европейских контор — протирают штаны «ИТ-специалисты», переученные из географов на 3-хмесячных курсах. Работают не за 1к/день — но за 40к/год.

P.S. И это, кстати, твой довод оратору выше. Теперь представь себе оркестр микросервисов, в исполнении этого «так называемого „IT отдела“». Получится реальная красота. И что концерн потом сделает с этой красотой — я уже написал выше.

Эти спецы и в монолит такого наконтрибьютили, когда на простое логическое действие нужно сделать 5 запросов, которые могут данные оставить в неконсистентном состоянии. На самом деле, нужно отталкиваться от потребностей, а не городить несовместимые «паттерны» направо и налево.

Работают не за 1к/день — но за 40к/год.

— там улетали за сотку, как с гордостью было много раз сказано не одним коллегой на очередном билдинге. 40 — то в австрийском селе.

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

Если они, с з/п более сотки понаделали херни в монолите — представляешь, что бы у них были за микросервисы?

Я работаю за 1к/день

Меня это как-то должно впечатлить?
Ну и как там сказал другой комментатор, месье таки просто теоретик в вопросах как топ компании работают. (Компании типа Гугла и Фейсбука).
Про сложность поддержки и разработки большую, чем у монолита, поржал. Расскажи ка мне как ты будешь строить монолит, над которым 100 человек работают. А 1000?

обычно где платят 1к в день. это какой-то банк,типа того, где я сейчас на контракте. Это легаси и монолит которому не меньше 10 лет. Компаний как гугл, фейсбук бесконечно мало. поэтому кодерок в чем-то прав.

так он же за гуглы с фейсбуками говорит. А не за легаси в банках

так он же за гуглы с фейсбуками говорит. А не за легаси в банках

Про гуглы с фейсбуками начал писать ты, назвав их некими «топ-компаниями». Но я понял твой посыл: аж 2 компании в мире пользуют микросервисы — значит, очень полезная вещь. Непременно учить!

С другой стороны, а где ты у них увидел микросервисы? Фейсбук (платформа) — монолит. Андроид — монолит. Всякие мэпсы/эрзы — монолит. Хром — тоже монолит. У мелкомягких немеренно открытого кода — микросервисов среди него нет. В закрытом коде (винда, sql-сервер, прочий офис) тоже сплошь монолиты. Где они, таинственные и столь популярные в «топ-конторах» микросервисы? :)

А что касается сложности разработки монолитов — так индустрия последние 30 лет занимается тем, что производит монолиты размером порядка несколько сот тысяч человеко-дней. Но таких решений на микросервисах нет. Т.к. всё, что больше 10к строк распределённого по микросервисам кода кода — превращается в тормознутое и выжирающее всю доступную память говно, неприспособленное для какой-либо отладки.

Собственно, я даже пойду далее и напишу, что если у чела в резюме хипстерщина типа функциональщины и прочих микросервисов — на проект не брать. Т.к. чел 1) хипстер, работающий не за деньги, а для развлечения/удовольствия 2) напихает для развлечения/удовольствия в проект хипстерищны 3) будет заниматься тем, что нравится, а не тем, что требудется 4) в один прекрасный момент покинет проект, т.к. «надоело» или «не дают развиваться».
А его хипстерщину потом — попробуй разгреби.

Дальше личные наблюдения.

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

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

Шаренный код не выстраивает естественных границ

Это смотря как кодировать. Если на проекте шарятся исключительно интерфейсы, правильно пользуется инъектирование зависимостей — все классы вполне могут быть непубличны (т.е. недоступны вне сборки с этим классом). Это оговаривается, легко проверяется, за публичные классы бъётся по рукам.

Более того, в условиях монолита нет никаких проблем с дроблением класса до тех пор, пока он не станет выполнять 1 функцию и т.о. станет (выражаясь хипстерской терминологией) «микроклассом» — особых накладных расходов в связи с этим не возникает.
В случае проблем, нет проблем с отладкой, логгингом, итп.

В случае же «микросервисов», выбор между декомпозицией на несколько жирных сервисов (которые, собственно, сами являются немаленькими монолитами) — либо, если дробить начинают на реальные микросервисы, наступает эпик-фейл и летальный исход всего проекта.

чувак, хорош. Ты никогда не работал над большими системами. Я тебя спросил, как работать с монолитом, над которым работает 100 человек ОДНОВРЕМЕННО. А тысяча? А ты погнал в хипстерение и прочую чушь.

Я тебя спросил, как работать с монолитом, над которым работает 100 человек ОДНОВРЕМЕННО. А тысяча?

Ну как работают 1000 чел, над теми же операционками? Так и работают — закатывают рукава и пашут. А не картинки из микросервисов рисуют.

30 лет уже делают нехилые монолиты — но находится хипстер, рассказывающий «так это же не монолит, а операционка» или «это же не монолит, а приложение», итп...

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

Ну и да, раньше и на перфокартах кодили, продолжим так же? Ведь справлялись же

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

Тем не менее, это «монолит» — т.к. 1) система централизована 2) компоненты живут на одной машине (часто даже в одном процессе).

А то, что в разных проектах — то особенности реализации. К рантайму отношения не имеющие.

да, потому что это операционная система, невозможно на разных машинах. Потому я и говорю — глупый пример с твоей стороны.
что с перфокартами?

Это все великолепно, жалко только, что это фантазия. В больших проектах работают законы вероятностей и больших чисел. То, что вы описали — когда соберутся команды из замечательных лидов и сеньоров, может случиться, но лишь в некотором временном срезе. В долгосрочной перспективе будет накладываться «среднее арифметическое» — мидлы будут ревьювить код джунов (и пропускать откровенный трэш), сеньоры будут «я сеньор, я не хочу ничего решать, я хочу новое платишко и на ручки» и т.п. В итоге получаются неповоротливые монстры с невнятными классами, у которых — невнятные обязанности и невнятные тесты.

Мой поинт не в том, что микросервисы or whatever — панацея, а в том, что микросервисы могут быть, в частности, удобным механизмом контроля и ограничения бизнес-контекстов при разработке больших систем.

В итоге получаются неповоротливые монстры с невнятными классами, у которых — невнятные обязанности и невнятные тесты.

А в это время, такая же (по квалификации) команда в микросервисах... :)

Если написанный такой командой монолит, хоть как-то будет шевелиться и будут возможности отладки доведение напильником — то написанные микросервисы просто не дружно лягут и проект на этом закончится.

Ну во-первых, распределенная система зачастую и правда не рождается из ничего. Сначала пишут монолит, получают с ним головняк, потом понимают где у него явные швы и по ним разрывают на сервисы.

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

Любопытное наблюдение. Только если есть архитекторы/лиды, которые умеют в поддомены, думаю, они и ревью могут сделать и форсить правильное разделение подсистем в монолите.

Netflix стоит и ржет в голос, Google с его gRPC вообще подавился от смеха, все остальные компании, от твиттеров с уберами до всяких стартапов делают рукалицо. Чувак, хорош загонять, я серьезно. Ты несешь откровенную дичь.
Хром и андроид, винду и офиc на микросервисах построить... ))) Это операционные системы и приложения! Не серверные системы... Пипец, вот это жесть

Google с его gRPC вообще подавился от смеха

Удалённый вызов процедур — это очень давние технологии из мира полноценных сервисов-монолитов, а отнюдь не изобретение гугла. Хипстеры тебя разыграли. :)

пойди почитай для чего gRPC в первую очередь создан. По поводу другого будут ответы? или только выбираешь что тебе удобно, игноря остальное?

пойди почитай для чего gRPC в первую очередь создан.

Ты как сегодня родился. :) Для чего обычно протоколы удалённого вызова процедур создаются? Для удалённого вызова процедур.

Или гугл чегой-то другого этим RPC хотел сказать?

я ж говорю, погугли. основная идея была — замена тормознутого реста поверх http 1 с помощью http2 решения для построения микросервисов

Netflix стоит и ржет в голос

Та понятно, что Netflix не одно большое приложение запущенное на одном компе.

Внутри там 100500 комманд, отвечающих за совершенно разные вещи, кто за кодек в браузере, кто за CDN, кто за контент менеджмент, кто за сбор данных и статистики, кто за рекомендации, кто за билинг, итд итп. Системы абсолютно разные, и все держится на прбитых кровью и потом «интерфейсах» _между_ этими системами. Где рест, где Грпц, где кафка, а где и файл в S3 залить, или в шаренную базу данных засунуть. А вот что там внутри каждой подсистемы — дело наживное, может быть 100500 микросервисов, а может быть и «распределенный избыточный монолит» — на уровень успеха нетфликса это не влияет.

но Нетфликс — один из тех, кто активно использует (и пропагандирует) микросервисы

мікросервіси ідуть від філософії Unix

мікросервіси ідуть від філософії Unix

В Юниксах компилируется ядро (как монолит), со всеми встраиваемыми туда «микросервисами». :)

А те юниксы, что попробовали стать микроядерными — скорее, мертвы.

Я так понял это когда устроился на день рашьше чем новоприбывший джуниор)

Почти мидл хочет писать почти микросервисы

Ну если вам интересно то углубитесь. В чем проблема

Какой-то больной ублюдок в не помню каком блоге написал, если вам понадобился sql join, то вы должны дальше разбивать на микросервисы до тех пор пока не будет 1 таблица в бд на 1 микросервис. Я тогда подоухуел от ужаса подобного идиотизма и возненавидел микросервисы ни разу их даже не попробовав.

вы должны дальше разбивать на микросервисы до тех пор пока не будет 1 таблица в бд на 1 микросервис

А потом начать склеивать их обратно.

микросервис должен замыкать домен по нормальному — а сколько надо для этого таблиц или коллекций никого не должно волновать т.к. это детали имплементации

Правила работы с микросервисами такие:
1. Дополнительную функциональность, пытайся встроить в имеющийся монолит.
2. Если функциональность встроить невозможно — делай в виде микросервиса.
3. Прежде чем делать в виде микросервиса (п.2) — попытайся встроить в монолит снова.

есть, если это все используется на проекте. Я с трудом себе представляю, как почувствовать всю прелесть и боль на своем лаптопе, пусть даже с миникубом.

ну, ознакомится с технологией и быть готовым с ней работать же нужно как-то

не надо. Зачем тебе новые полезные знания? Кушай себе сыры по 500 да и все, зачем всяким голову забивать?

почему люди плюсуют троллей?

Потому что Vasya дело говорит. Ты либо развиваешься либо нет.

Вася сидит дома и гадит во всемирную паутину в свободное(или нет) от работы время, вот что он делает. Все подряд не выучишь, поэтому нужно использовать время обучение эффективно и выбирать на что его тратишь, мне казалось это очевидно.

Зачем тогда топик создавал? Учи ангуляр.

Разверну немного. Человек делится опытом. Вот тебе еще немного опыта:

Distributed systems are here to stay. If you don‘t like it, change careers. Maybe open a restaurant.

www.youtube.com/watch?v=TPctjavH_Zw.

Какая версия моего коммента вызвала затруднение?

Вариант до редактирования, без ссылки на видео.

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

если ты тут увидел только троллинг, то мне за тебя грустно

норм сарказм не является трололо

а вы сарказм от троллинга отличаете?

Смотря что под этим понимать. Это архитектурный паттерн, поэтому если не занимаешься архитектурными решениями, то и не увидишь их. Плюс они связаны с тесно с контейнеризаций и devops, т. е. опосредовано docker, kubernetes, openshift тоже про микросервисы и их надо знать в любом случае. Плю разного рода асинхронные коммуникации через очереди или топики, как основной способ коммуникации (grpc к ним не относится, кчтати и мало отличается от того же soap). Плюс паттерны работы с данными как CQRS или Saga, но тут мидл с ньюансами не столкнется.

но тут мидл с ньюансами не столкнется

"Тут" — это где?

Тут, это паттерны работы с данными.

А-а, да вполне может столкнуться. Зависит от того, насколько захочет углубиться во все это.

Ну скорее всего все сделает архитект или тех лид, а миддл будет просто методы чтения-записи реализовывать, которые не сильно отличаются. Но знать надо, что и зачем.

У нас на проекте CQRS+ES и саги/агрегаты/проекции и т.д. описывают даже джуны)) Не понял что вы подразумеваете под методами чтения записи?)
P.S. до докера не доросли еще.

Чтение — запись:реализация патиернов в коде. Это проще, чем стандартный хиьернейтовский говногод, но вот саги и cqrs опичывать дело не джунов и даже не миддлов. Во-первых сомнительно, что джун будет работать над несколькими микросервисами, чтобы этим заниматься, а во-вторых внедрить эти паттерны работа сложная, и требует глубокого анализа предметной области.

Та вполне под силу нормальным мидлам. Столько разных туториалов в инете. Да и как опыт получать, если не делать.

Эти паттерны уже введены на старте проекта в «core» проект который тянется как зависимость микросервисами, деву остается манкикодинг под свою задачу)

Плюс они связаны с тесно с контейнеризаций и devops, т. е. опосредовано docker, kubernetes, openshift тоже про микросервисы и их надо знать в любом случае.

Эм, ну докер конешн стандарт, и некий опыт не повредит. Все остальное — на каждом проджекте свой зоопорк инфраструктуры, даже кубернейтис все еще не стандарт, не говоря уже про опеншифт — это вообще что такое :-) Жаба мидлу так вообще это все знать особо не нужно — по мере задачи разбереться\научат.

Плю разного рода асинхронные коммуникации через очереди или топики, как основной способ коммуникации

Откуда это вообще взялось ? Есть где умных статей на тему ?

И вообще, вы точно в люксофте работаете, а не в глобале ?

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

Что касается асинхронных коммуникаций, через меседж брокеры или как-то еще, то это осноаа микросервисов, иначе вместо независимых микросервисов получаем распределенный монолит.

Есть ли гдето умных ссылок почитать на эту тему? Ато я таких дифинишинов не встречал, и по на ивности продолжаю полагать что «сервисы» == рестик.

Не работаю в люксофте уже давно.

Скорее всего вы мой коллега, сочуствую.

Не скорее всего, а точно. Доберусь до компа, скину подборку докладов и статей)

Есть ли гдето умных ссылок почитать на эту тему?

blog.christianposta.com/...​about-microservices-data

Могу книгу порекомендовать Сэм Ньюмен — Создание микросервисов, там в главе 4 автор неплохо все по полочкам разложил. Спойлер: рест приводит к сетевым задержкам, но если нужен респонс, то никуда не деться. Месседж кью производительней, но нет респонса. Есть еще разная екзотика, типа RPC, но там автор говорит что-то типа «Не ходите дети в Африку гулять».

За наводку спасибо. И интересно почитать что он видит экзотического в rpc, и в чём принципиальная разница между рестом vs rpc по http(s).

REST — это про HATEOAS, когда можно менять контракт не ломая клиентов.

Пожалуй действительно в этом ключевая разница — встроенная discoverability и пускай api driven подход.
Хоть и не все кто делают «rest» api реализуют HATEOAS, и в rpc можно встроить подобные механизмы, но всё же ему это не свойственно.

когда можно менять контракт не ломая клиентов

все же понимаем что в общем случае это утопия — показывали в клиенте баланс пользователя, поменяли/убрали название поля, без изменения клиента не обойтись. Присылать/запрашивать схемы/мапинги — это и с rpc не проблема. Всё равно такие проблемы версионированием решаются в общем случае.

Основная разница в том, что REST более гибкий по сравнению с RPC. Например, добавление нового параметра GET запроса не сломает уже существующею коммуникацию между микросервисом и его клиентами. В то же время, если изпользовать RPC, добавление нового параметра в API микросервиса требует внесения изменений во всех его клиентах.

Старые клиенты просто проигнорируют это новое поле и всё. Может от реализации клиента зависит, но это частности и в общем случае разницы нет. Ну и от версионирования всё равно не уйти что rest, что rpc.

Есть еще разная екзотика, типа RPC, но там автор говорит что-то типа «Не ходите дети в Африку гулять».

Thrift, protobuf, и прочее — экзотика ? Спасибо, но походу можно не читать :-)

Во-первых книга 2015-го, а писалась еще раньше, а во-вторый для многих проектов это таки экзотика 🙂.

Типа того, большинство веб разработчиков знакомо с REST и мало кто знаком с Thrift или Protobuf.

Как можно сравнивать protobuf и RPC? Только руководствуясь принципом «это экзотика»? Ньюман рассматривает «RPC» и прочее мыло именно в контексте громоздкости и сильного каплинга между клиентом и сервером. Протобуф в этом плане куда ближе к Ресту, несмотря на бинарность.

Современные rpc всё же больше не про «мыло», а JSON-RPC и gRPC (protobuf просто формат, как и в ресте никто не запрещает xml использовать вместо json’а). Которые монструозными назвать сложно и может даже проще если сравнивать с правильным rest-сервисом, реализующим полноценно hateoas (он то штука хорошая, но в больших публичных сервисах, а для внутренних сервисов не всегда и нужная).

RPC это remote procedure call,

А внутри там рест (с нектороми поправками), соап, протобуф, или, прости господи, java rmi — суть таже самая, разница в деталях и применении.

это что-то новое в мире микросервисов

Плю разного рода асинхронные коммуникации через очереди или топики, как основной способ коммуникации

Откуда это вообще взялось ? Есть где умных статей на тему ?

микросервисы имеют дурацкую особенность ложиться как раз тогда, когда их никто не просит. Пока кубернетес убьет его, пока он поднимется — а данные получить нужно. Можно ждать, пока поднимется, а можно с какого нибудь S3 вытащить. Плюс, микросервисы обычно не рассчитаны на обработку множества запросов, помимо своей основной работы, поэтому проще отработать и выплюнуть в MQ или storage, которые задизайнены для раздачи данных оптимальным способом.

Если задача «когданибуть потом вітащить данные», то безусловно MQ или S3 — не самый плохой вариант. Но вот если надо квернуть, да побыстрее, то эт не всегда оптимальный вариант.

лейтенси же .

В высшеприведенной ссылке пример, аля когда букаете авиабилет, то конфирмейшн когдато потом по почте приходит — оок.

Но если букать отель на букинге, никакой конфирмейшн потом не приходит, он отображаеться сразу, через несколько секунд, после нажатия кнопки.

о, тебе понравится доклад фаулера по базам данных =) а еще курс системного дизайна.

В ситуации, которую ты здесь привел, на моментальное отображение конфирмейшна не нужно ничего. Если вкратце — то бизнес всегда выбирает между решениями конфликта и юзер экспириенсом — т.е. смотри, если выбрали решение конфликта, то юзеру всегда сразу отвечают ОК, без проверки реальных данных (доступен этот номер или нет). Обычно отель имеет пул номеров на случай овербукинга или просто потом напишут письмо с извинениями — это дешевле.

Проблема в репликации данных — если 2 человека из разных точек мира одновременно букают номер в одном отеле — тебя никакой микросервис не спасет, т.к. такой сервис всегда будет отвечать тебе в твоей локации.

тебя никакой микросервис не спасет, т.к. такой сервис всегда будет отвечать тебе в твоей локации.

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

Веб сервер, который отдает хтмл и дж — должен, а вот почему микросервес должен — оч неочевидно.

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

так латенси ж?
Все будет находиться в твоей локации, а данные будут реплицироваться потихоньку.

Без шуток, посмотри курс по системному дизайну

Вобще ты мож и права, я както забыл, что там еще есть промежуточная страница «ок я забукаю», типа подтвердить имя, выбрать карту, ввести пароль и прочее — вполне достаточно времени чтобы запрос через кучу систем прошел, и на подтверждении уже реальное подтверждение выдать.

Без шуток, посмотри курс по системному дизайну

Наверняка вообще ничего нового, но ок, возьму на заметкен.

Наверняка вообще ничего нового, но ок, возьму на заметкен.

удивишься, там будет все новое

Удивишся, но все это — веб сервисы, очередя, CQRS, eventual consitency, и прочее все было и 10 лет назад. Небыло хипстерских названий, ну и докера с го.

я в курсе, я скорее отсылалась к этому вопросу

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

В микросервисах, да и cqrs по понятию , вполне ок иметь транзакционную запись, но eventual consistent чтение. И да, букинг ком подтверждает букинг сразу и имеет транзакционною запись я больше чем уверен — как и большинство других систем такого класса. ниодин product owner в своём уме, не запрувит такую систему где нет гарантированного подтверждения бизнес критической операции на практике, не по фаулерсовским размышлениям :) что бы иметь отдел людей, которые будут руками разруливать concurrency сценарии что бы ваша система имела низкую latency — это из разряда фантастики и вымышленной реальности. мы уже это проходили не раз.

Обычно отель имеет пул номеров на случай овербукинга или просто потом напишут письмо с извинениями — это дешевле.

Это только у фаулера дешевле:) или в книгах. В реальной жизни все по другому :)
букал много раз на Букинге — не слышал что бы там были ситуации
подобной этой, более того если прошла оплата они дают гарантию букинга сразу в ответе.

Проблема в репликации данных — если 2 человека из разных точек мира одновременно букают номер в одном отеле — тебя никакой микросервис не спасет, т.к. такой сервис всегда будет отвечать тебе в твоей локации.

Для faceted search — вполне, во время букинга очень не факт, что там используется distributed субд. В таких случаях сто раз подумают, что лучше иметь 100-200 мс на latency при нечастой операции модификации данных или мнимая latency которая на ux в этом случае практически не влияет.

Звучит логично. 200мс не такая большая задержка для букинга или, тем более, билетов на самолёт.

Ведь, eventual consistency может быть на сервере, а для клиента все выглядеть синхронно. Read my own writes и т.п.

А можно ссылочку или название курса системного дизайна?

И тут я судорожно вспомнил, как недавно склеивал кассандру и с3 хранилище, чтобы физически данные только в с3 и существовали.
Омерзительно звучит, но работает в принципе сносно: при четырёх потоках синтетика выдавала 2.7к на запись, 3.1к на чтение, mean latency в районе 1-2 мс.

Пример, конечно, не production-ready на данный момент, да и вряд ли там когда-либо появится хайлоад, но в принципе с3 не такой уж и медленный.

snowflake — вполне себе прадакшен кассандра (даж скорей мемсиквел, чтобы это не значело) поверх s3.

Однако делать подтверждение билетов или букингов, но основе эвеншл консистенси стореджа — яхз.

билеты можно) овербукингом больше, овербукингом меньше)

И как snowflake в реальной жизни? Я так понимаю, есть вполне реальный опыт с этим продуктом?

Там фича в оч быстрой заливке мульйонов записей жсона\авро и прочего напрямую, с этого самого S3 Ну и модель оплаты, за собственно компутейшн кверей — не самая плохая, если кверей немного и они продуманы.

Ну быстрая заливка — это то что нам показывали, да. Но как бы ничего такого что поражает воображение. Идея же использовать снежинку для хранилища данных вместо Оракла мне кажется подозрительной.

Оракл, это полноценные индексы, джоины, локи таблиц и транзакционность, матеарилайз вью, тригеры, и прочее прочее.

В снежинке почти ничего этого нет (как и в любом другом nosql).

С другой стороны, как мне говорили, для сценария «нужно хранить много оч много данных, и иногда кверить репорты» — цена не сопостовама.

Ладно, посмотрим. Есть интересные «фичи» типа кеширования результатов и автоскейлинга на сложных запросах, но я подозреваю что на больших объемах и активном использовании цена будет приближаться к стоимости лицензии от оракла. Ну или нужно делать промежуточный слой для создания результатов отчетов.

Я хз как оно счас, но было «не без багов» :-)

Пока кубернетес убьет его, пока он поднимется — а данные получить нужно

множественные копии сервиса?

микросервисы обычно не рассчитаны на обработку множества запросов

кем не рассчитаны? и чем они отличаются от монолита в этом плане?

проще отработать и выплюнуть в MQ или storage

эээ, синхронный и асинхронный ответ эт как-бэ разные задачи вообще, никак от микросервисов (или любой другой парадигмы построения системы) не зависят

множественные копии сервиса?

да, реплики выручают

кем не рассчитаны? и чем они отличаются от монолита в этом плане?

у нас большинство сервисов бегают в контейнере stateless с лимитом cpu: 1000m, memory: 1024Mi. Т.е. чтобы отдать данные, ему нужно сходить в базу и спросить их. Точно так же другой микросервис может сам сходить в ту же базу и спросить те же данные. Или не в базу, не суть.

эээ, синхронный и асинхронный ответ эт как-бэ разные задачи вообще, никак от микросервисов (или любой другой парадигмы построения системы) не зависят

а я чет другое сказала разве?

у нас большинство сервисов

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

а я чет другое сказала разве?

я о том что это вообще не о микросервисах, так как встречается повсеместно, в тч и в монолитах.

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

а как выглядит паттерн?
У тебя так или иначе где-то но будет single point of failure, либо латенси из-за репликации

ну если все ходят в базу за одними и теми же данными возникает огромная проблема с контролем бизнес-правил, целостностью данных и изменением структуры данных (схемы). Это ж вообще может быть "опа такое менеджить.

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

Ложиться то еще фигня. Их докер или какой другой менеджер переподнимут быстро. А вот тупо не отвечать на запросы — это повеселее.

Можно ждать, пока поднимется, а можно с какого нибудь S3 вытащить.

Вы пользуете на AWS K8S? Оригинально!
Или только S3, а сам датацентр онсайт или baremetal с какого-нибудь Хетцнера (иначе нафига нужен k8s)?

Плюс, микросервисы обычно не рассчитаны на обработку множества запросов,

Как раз вполне заточены как правило. Но только весьма ограниченного набора однотипных запросов. Дабы балансер не изображал из себя тот самый монолит, от которого на микросервисы сбежали.

поэтому проще отработать и выплюнуть в MQ или storage

Только в кейсе асинхронной обработки, да и то не всегда. А медленнее стораджа разве что мыло и голубиная почта.

Вы пользуете на AWS K8S? Оригинально!

Amazon предоставляет hosted kubernetes ( EKS), точно также как и гугл

Это как бы не новость (с июня 2018, насколько помнится).
Вот только нахлобучивание трех виртуализаций с собственными системами управления друг на друга не самая удачная идея, если только вам не зажало жизненно важные органы по типу «у нас здоровый ЦОД на к8с, но питалово в нем закончилось а нужно срочно развернуть еще 100500 инстансов».
Амазон, конечно, с удовольствием наварится на таких клиентах, но самого клиента они не красят.

Почитай доку и туториалы по gRPC, посмотри пару видео с конференций на ютубе — для начала хватит.

Grpc вообще не про микросервисы, а просто еще один rpc, которых уже легион.

Согласен. Когда я писал про „посмотри видео” я имел в виду посмотреть видео по микросервисам. А если хочется поиграться и подизайнить чего, то gprc это хороший выбор, особенно когда начинаешь.

Я, в принципе, предпочитаю начинать изучение чего-либо с практики и ковыряния в песочнице. И gRPC для этого неплохое решение.

Даже эта маленькая страничка хорошо задает направление копания
grpc.io/blog/principles

Google has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across our data centers for over a decade. Our internal systems have long embraced the microservice architecture gaining popularity today. Having a uniform, cross-platform RPC infrastructure has allowed for the rollout of fleet-wide improvements in efficiency, security, reliability and behavioral analysis critical to supporting the incredible growth seen in that period.

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

правильно, сиди себе формочки шлепай, буть вечным мидлом (кстати, еще и украинским)

Нет же, «почти мидл» придет на проэкт и скажет — а теперь давайте пилить микросервисы. Услышав куда ему идти, он придет домой и напишет новую пэт клинику, но уже на микросервисах. И со спокойной совестью добавит микросервисы в резюме )

Хотя постойте, для этого достаточно было того, что рекомендовал Олег?

Ну я ж говорю, не надо ничего изучать. На сыры хватает и ок. Шлепай формочки в лидере рынка и достаточно.

По факту так и есть, так как все равно будешь клепать формочки и фиксить говно-баги на галере, чтобы ты при этом не знал из теории. Вечный миддли или сеньйор — вопрос в том как себя продашь. Технология не имеет смысла без привязки к проекту и серьезному опыту работы с ней. Почитал про микросервисы, потыкал hello-world-ы, через полгода забыл — и нафига?

ну кто-то вечно фиксит формочки, а кто-то так не думал, развивался и попал в компании, где работает над другими совершенно задачами

После ЕПАМА у многих появляется травма мозга, какой-то неуместный цинизм, негативное отношение к жизни. Может быть там в вентиляцию какие-то вещества распыляют, я не знаю, но с подобным mindset’ом оттуда выходят большинство тех, с кем я знаком.

Ох блин, прям два экстрасенса и гадателя по аватарке вывели меня на чистую воду )))

На всю их микроглубину!

Ты все шутки-прибаутки, но ведь у тебя 100% есть мнение по этому поводу

Я лишь о том, что там нет сильно глубоких знаний. Есть готовые технологии, бери да пользуй.

Ну, для меня этот все-таки совсем другая архитектура, другие фреймворки и паттерны. Хочется не сесть в лужу при случае.

Чем микросервисы принципиально от макросервисов отличаються ?

сейчас уже модно минисервисы

Я принципиально перестал употреблять это слово. Сервисы меня более, чем устраивают. А размер определяется многими факторами.

Эх, к чему мы пришли :( раньше у нас были серверы, теперь у нас — только сервисы... Обмельчал народ...

Внимание, правильный вопрос: «Чем микросервисы принципиально от монолита отличаются?» 🙂

Выживаемостью и масштабируемостью, плюс бонус короче цикл релиза. Если правильно реализована архитектура, то падение куска не приводит к оос аппликации, partion tolerance +availability. Этим правилом можно пользоваться при анализе того, что получилось — нарисовал схему, вычеркнул половину узлов и смотришь, продолжит работать или нет, и как именно продолжит работать. Это же проаеряется через злобный chaos monkey.

Если правильно реализована архитектура

А в реальном мире хипстеры реализуют распределенный монолит, для которого правильным ответом будет: «Функции вызываются через RPC, а не у объектов в памяти.»

Так и есть, но это ведь не будет микросервис архитектурой)

Только об этом не все догадываются 🙂.

Выживаемостью и масштабируемостью, плюс бонус короче цикл релиза.

Тут надо говорить по сравнению с чем — говнищем-все в одном на все случа жизни разрабатываемом бухгалтерами в банках на протяжении 10 последних лет и при условии что в новой команде есть люди с опытом разработки микросервисов и прошедшие все pitfalls желательно не один раз.
Во всех остальных случаях — а это от 80 до 95 процентов случаев разработки приложений с веб сервисами — монолитная архитектура будет быстрее, масштабируемей , дешевле и проще в сопровождени.

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

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

Хорошо спроектированный монолит не будет особо отличаться — там будут аккуратные модули по предметным областям и та же eventual consistency. И его, при необходимости, можно легко разбить на разные физические процессы. В противном случае микросервисы будут ничем не лучше монолита, как я писал выше.

Но большие компание, вроде букинга, просто не в состоянии обходиться монолитами, даже сделанными на мейнфреймах.

Сколько там тех мейнфреймов , но да где-то можно найти применение и микросервисам и оно даже будет в тему :)

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

А в микросервисах она по всей видимости дешевеет или не меняется ;)

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

Монолит может быть выпущен только целиком, поэтому по мере роста количества функций и тестов к ним, релиз будет дольше с каждым разом.

по вашему до 2010 года типичное монолитное распределенное SOA приложение не могли покомпонентно задиплоить? лол
Цена изменений что там, что там — обратная совместимость контрактов то ли в веб сервисе, то ли в service bus, то ли в СУБД на таблице. Чем больше изменения и затронуты контракты интеграция, тем более плачевный будет диплоймент и тем больше будет требовать времени обеспечение обратной совместимости и прогонка тестов, что в одном, что в другом случае.

SOA по определению не монолитно, более того, микросервисная архитектура — это тоже SOA.

Пусть вас это не смущает. замените SOA на, компоненты распределеной монолитной системы любого другого рода, из которых состоит система и которые можно задиплоить или следуя вашей логике любая система состоящая из компонентов не монолит? :)

Тогда можно открыть дискуссию, на сколько эта стстема и правда монолит. Если один из компонентов отказал, откажет ли вся систтема? Можно ли тестмровать и деплоить их независимо друг от друга? И так далее. В слусае монолита ответ на первый вопрос да, а на второй нет. В промежуточных вариантах можно подискутировать.

Ага, ну я понял. Все, что плохо сделано — монолит, все что хорошо — микросервис :)

Монолит может быть и хорошим, но монолитным. Потому и монолит)

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

До тех пор, пока новые требования непривносят изменний которые затрагивают сразу много сервисов. Банально добавить новое поле в протокол коммуникации, и внезапно, релиз 100500 сервисов по отдельности.

Почитай что ли про те же protocol buffers или thrift. Там все как раз построено в расчете на backward/forward compatibility.

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

Можно пример такой ситуации? С условием, что она не решается версионностью и правильным определением bounded context?

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

Какоето очень спорное утверждение. Там где в монолите нужно зафиксить одну строчку кода и передеплоить одно приложение (и соотвецтвенно протестировать), в микросервисах, часто надо поменять код в N независимых местах, и передеплоить\протестировать кучу этих микросервисов.

Только в монолите процедура деплоймента будет занимать операционную тиму на пару часов и обращаться для всех — от программеров до проджект менеджеров — большой головной болью. Для разработчика монолит обернется постоянной головной болью типа «как запустить это г*но на моей машине?» Не говоря уж о том, что любые системы интересного размера просто _невозможно_ запустить на одной машине.

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

Типа если внезапно нужно передеплоить 100500 микросервисов то головной боли меньше.

Для разработчика монолит обернется постоянной головной болью типа «как запустить это г*но на моей машине?»

Запустить 100500 сервисов на локальной машине чтобы протестировать работает ли вся фича вцелом, а не отдельный сервис в вакууме — бывает не намного проще.

Не говоря уж о том, что любые системы интересного размера просто _невозможно_ запустить на одной машине.

Микросервисов эт тоже касаеться.

Идея микросервисов, что тебе не надо деплоить все, а только один измененный. Плюс даже при минималтном изменении в монолите, ты должен провести полный цикл тестирования, что займёт кучу времени.

Вы сравниваете теплое с мягким вот уже который пост под ряд. Тот монолит, о котором вы тут говорите, смахивает на единый процесс, собираемый из миллионов строк кода в котором все элементы зависят от всех и весь код абсолютно шаредный. Такого в реальной жизни не бывает. Любой сложный монолит состоит из частей и по мере роста сложности живет в разных изолированных единицах — процессах, сервисах, контейнерах даже, если хотите, которые взаимодействуют между собой. Когда тестируется — проверяется функционал, который задет изменениями и только, а не вся система, когда диплоится — изолированный компонент, в котором находиться затронутый кусок, а не обязательно вся система(причем там тоже может быть девопс и CI) и для этого необязательно микросервисы иметь.

Монолит, именно потому и монолит, что не может быть поставлен по частям, иначе это уже не монолит. И система, которая построена на SOA и разбита на разные нехависимые сервисы, которая коммуницирует через ESB монолитна.

теперь неплохо бы понять, что это за архитектура такая, которая уже не монолит, но еще не микросервисы. :)

и? я поменял фронт енд задиплоил фронт енд. Зачем мне тестировать или диплоить бекенд енд в таком сценарии? :)

Если это часть одной апликации, тот же самый деплоймент юнит, то полный тест. По крайней мере так было га проектах, где я работал. И только emergency fix мог быть задеплоин по сокращенной процедуре.

открою вам секрет — надо было разбить на два jar’ника фронт и бек и упростить себе жизнь. :) или слои логиги разобьете на разные SOA сервиса и сделать между ними SOAP и продолжить разрабатывать такой же монолит как и прежде, но диплоить и тестировать его по частям :)

jar не является отдельным деплоймент юнитом, изменили jar или WEB-INF, значит изменился war и мы должны выполнить полны тест. Что касается SOA сервисов, то если мы говорим о SOA, то значит сервисы слабосвязные и независимые (low-coupled), взаимодействуют посредством ESB, и конечно могут деплоиться отдельно и даже отказ одного из них не приводит к отказу системы. Если этого не происходит, то это не SOA.И да, в больших компаниях SOA используется полным ходом, и сервисы и приложения независимы и взаимодействуют посредством BPEL провайдера или подобного от Tibco, Vitria, WebMethods, WebSphere или кого-то еще. И это не монолитные системы, хотя отдельные компоненты могут быть монструозными огромными приложениями.

По описанию похоже на правильные микросервисы.

Потому что микросервисы, это тоже SOA

так как я описал были сделаны большинство корпоративных систем до появления микросервисов :). Даже то, что выше называют SOA которая комуницирует через ESB по какому нибудь SOAP в синхронном стиле, в случае чего падает полностью в меньшей или большей степени если отпадает какой-то Core сервис или например сервер шаредной базы данных где хоститься как его называют выше «независимый SOA сервис» :)

Хз, в тех проектах, на которые я приходил, такой архитектуры не встречал. Даже если были распределенные сервисы, они все равно были сильно связаны. Вообще книга по DDD, которая описывает принципы, по которым стоит выделять поддомены и сервисы, вышла в 2003 году. Так что да, ничего нового. Сегодня просто больше инструментов для всего этого безобразия.

ну да, они действительно было связанны, были сихнронные интеграции, часто shared state и т.д. на даже такие системы диплоили поотдельности — обратную совместимость в интерфейсах коде/сервисах/структурах данных придумали благо намного раньше появления микросервисов

Это все хорошо звучит в сферической теории в вакууме.

На практике девелоперам приходят фичереквесты которые затрагивают сразу много микросервисов подряд.

Приведу пример недалекий от реального: приходит фичереквест добавить юзерам адрес и запилить на сайте поиск юзеров по зип коду.

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

В хипстерских микросервисах, это есть микросервис который работает с юзерами, а есть микросервис который работает с адресами. Надо добавить функций в оба, а еще заинтродюсить третий сервис, который объединяет поиск по этим двумя; А еще нужно поменть внутренюю (жсон) структуру Юзер, добавить туда ключ адреса. Не забыть про четвертый сервис который по какомуто там запросу Юзеров откудато копирует, что теперь у них есть адреса и ключи. Это я уже молчу про саму вьюху. В результате вместо деплоя одного\двух апликейшнов, редеплоим 5 апликейшнов, и не факт что ничего нигде не забыли.

тут только один сервис — тот что работает с юзерами. все.

Вы уверены ? :-)

А если адреса это нечто «особое» ? Например вы разрабатываете почтовую систему, и там гораздо больше функциональности нежели простое «у юзера есть адрес» ? :-)

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

в конктретно примере выше я вижу только один сервис

Да, один «жирный» сервис. Но где же тогда микросервисы? :)

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

которым нужны данные о клиентах

Данные о клиентах — это, скажем, ФИО, национальность, год рождения... Собственно, даже национальность — это уже отдельный домен (страны, в т.ч. бывшие). Адреса тоже (местоположения).

Но если пихать в «данные клиента» всё — тогда получится не микросервис, а нормальный такой жирный многофункциональный сервис. Монолит.

Да уж, видно не видел ты никогда большие системы...
(адреса и национальности бессмысленны без людей, все что ты тут описал только лишь показывает что ты не понимаешь концепта микросервисов)

Да уж, видно не видел ты никогда большие системы...
(адреса и национальности бессмысленны без людей, все что ты тут описал только лишь показывает что ты не понимаешь концепта микросервисов)

бла-бла-бла...

Юрлица тоже имеют адреса и национальности. :)
Так что там в данных клиента, у микросервиса должно быть? Генеалогическое дерево!

ох... в каждой задаче свое разбиение будет. можешь дальше продолжать вводить условия, которых не было изначально, чтоб показать что ты типа прав (ха-ха)

Я карочь вменяемого разделения между микросервисами и макросервисами не услышал.

Все, что плохо сделано — монолит, все что хорошо — микросервис :)

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

Все на уровне ощущений, пожалуй

Теоретически, микросервис — это специализированный сервис с единственной функцией. Или, уж во всяком случае, работающий лишь в одном предметном домене.
А если больше — начинаются «жирные» сервисы, а-ля монолиты.

Микромонолиты! Соблюдайте терминологию!

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

Это говорит о неправильном выделении сервисов.

Это говорит о неправильном выделении сервисов.

Сервисов — неправильно, т.к. сервисы многофункциональны и монолитны.

Но тут обсуждают не сервисы, а микросервисную хипстерщину.

Это говорит о неправильном выделении сервисов.

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

Затем, что ФИО это уже достаточно сложно. Со странами не особо проще. Инет-адреса ещё сложнее. Если всё запихнуть в 1 сервис — получится не «микро», а «жирно».

Что это за бизнес-домены — «имя-фамилия», «страна»? 😀 «- ты в какой команде работаешь? — я разрабатываю имя-фамилию! — о, а я страну!» 👌

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

я разрабатываю имя-фамилию! — о, а я страну

С ФИО возникает куча проблем, как то:
— неоднократная смена имени и фамилии (не только, при выходе замуж)
— различные написания разными языками
— фамилии из многих слов
— всякая индусятина и бразильятина с фамилиями из 10 слов — могущая каждый раз делать новую уникальную «фамилию», сочетанием разных слов
— итп

Для страны:
— различные написания (и даже названия) в разных языках
— несуществующие/исчезнувшие страны (скажем, как предыдущее гражданство чела)
— непризнанные или признанные отдельными странами «страны», раздающие свои гражданства
— страны, оккупированные другими странами и гражданства, выданые во время оккупации
— итп

Объедини такое в один сервис — и получишь не разделение обязанностей, а монолитную жирноту.

Вы извините, но вы просто не понимаете, о чем говорите. Если после разбиения системы на (микро)сервисы у вас все еще есть необходимость одновременного деплоя или одновременного запуска на одной машине всей этой колымаги, то можете записать этот сплит в свои фейлы.

Крайне рекоммендую прислушаться к советам и почитать книжку Ньюмана — она не толстая, простая для понимания и в то же время очень полезная.

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

Вот только инженеры букинга на интервью туда, в 2018 в Амстердаме, сами говорит что у них там адский монолит, который они сейчас с болью и страданиями пытаются разрезать на сервисы. Так что как раз они в состоянии и обходятся очень долгое время.

Мы сейчас упираемся в связанность релизов, например, поэтому в нашем случае имеет смысл, чтобы получить возможность релизить подсистемы независимо. Но в каждом случае нужно ясно понимать для чего это делается, какие проблемы решает и какие создает.

Если код разрабатывается одной командой, если это один физический процесс (+ реплики, если нужно) и все модули релизятся вместе то, конечно, незачем.

В то же время, с распределенными системами работать интересно, если такая необходимость есть и решения оправданы — то умение в микросервисы может оказаться очень кстати.

Типа если один инстанс веб/рпц сервиса, который например с базой общаеться — то эт распределенный монолит?

А если тупо тотже сервис, но много инстансов, с ELB какимнить, или там на худой конец зукипером — это что? микросервис или все еще нет?

Или там обязательно должено быть по отдельному инстансу для каждой таблицы, только тогда это достаточно «микро». ?

А если тупо тотже сервис, но много инстансов, с ELB какимнить, или там на худой конец зукипером — это что? микросервис или все еще нет?

похоже на HA

Или там обязательно должено быть по отдельному инстансу для каждой таблицы, только тогда это достаточно «микро». ?

зависит. Из моего опыта — микросервис отвечает за какую-то одну процедуру. Например добавить/удалить тенантов из таблицы и создать для них юзеров (черт, тут уже целых 2, но кода там все равно не много). Или вытащить данные из одного места, пережевать и положить в другое. Или тесты запустить.

зависит. Из моего опыта — микросервис отвечает за какую-то одну процедуру. Например добавить/удалить тенантов из таблицы и создать для них юзеров (черт, тут уже целых 2, но кода там все равно не много). Или вытащить данные из одного места, пережевать и положить в другое. Или тесты запустить.

не хочется ставить диагнозы по фотографии, но по описанию это страшно напоминает distributed objects и, соответственно, chatty interfaces между ними, что тот же Фаулер считает антипаттерном, и с чем я согласен.

ага, я поняла о чем речь, нет у нас distributed objects — я просто плохо описала

тем что микросервис отвечает за одну конкретную функционалность. макросервис — это уже крупная программа, объединяющая несколько функциональностей.
если вы делаете толстые «микросервисы», возмодно вы просто не понимаете зачем они нужны

Искать по юзерам и по адресам — это одна функциональсть, или две ? или три ? Сколько вы сервисов сделаете в данном случае ? :-)

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

Подписаться на комментарии