×
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

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

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

Что можно вынести в микросервис? Аутентификация и генерация токенов, процессинг изображений, видео, и вообще каких-то данных, менеджмент каких-то общих данных, которые потребляют другие сервисы (к примеру курсы валют, погода, и т.д.).

Микросервисы это зло

Нет ничего глупей, чем называть любой инструмент или технологию злом. Это инструмент. А у любого инструмента есть плюсы и минусы, и любой инструмент нужно применять правильно и уместно. И вот с уместностью применения микросервисов (да и многих других вещей) я вижу большие проблемы.

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

А теперь давайте разберем по порядку все эти пункты:
1. Масштабируемость. Теоретически — позволяет переварить любую нагрузку путем простого добавления нод под каждый сервис. На практике, для этого требуется использовать распределенную БД, оначе рано или поздно это упрется в производительность обычной реляционной базы. При этом для 99.9% проектов эта масштабируемость никогда не понадобится. Sad but true: большинство проектов так и не выстреливают, а многие из тех, кто начинают зарабатывать, не пробиваются среди конкуретнов и не добиваются той пользовательской базы, при которой вообще потребуется масштабирование.
То есть, чтобы получить профит от этого пункта, мы должны иметь огромную базу юзеров, которая обеспечит нам нагрузку, при которой эта масщтабируемость потребуется в принципе.
2. Отказоустойчивость. Работает только при правильном проектировании: отказ одного микросервиса должен минимально затрагивать работу остальных сервисов. Если это условие не выполняется — отказоустойчивость такого решения еще меньше, чем монолита, так как монолит хоть быстро передеплоить или отдебажить можно.
3. Большее время разработки, сложность деплоя. Однозначно при разработке микросервисов вы позже выйдете на рынок. Ну просто потому, что физически монолит пилится проще и быстрей: весь код в одном месте, тестирование и деплой проще и быстрей. А значит вы позже сможете получить первых юзеров и заработать первые деньги. А еще играет роль то, что в любом проекте постоянно что-то меняется, особенно на старте. И адаптировать монолит под эти изменения в разы проще, чем микросервисы.
4. Требует больше железа. Вам таки понадобятся деньги на аренду или покупку железа чтобы все это крутить. Причем тех денег, которые вы пока что не заработали.
5. Производительность. Все будет работать медленней, чем на монолите. Поначалу так точно, а выиграть вы сможете (возможно) когда-то потом, когда юзеров станет очень много (а это, как я писал выше, почти никогда не случается).
6. Сложность с транзакционностью. Транзакционность — очень удобная вещь, она позволяет реализовать многие вещи проще и надежней. Да, когда вы дорастете до миллионов пользователей и десятков тысяч запросов в секунду, вам, возможно, таки приется с ней распрощаться, но до этого сначала надо дожить, а простая работа с транзакционностью в монолите позволит вам дешевле и быстрей разработать ваш бекенд и выйти на рынок, чтобы привлечь юзеров и заработать первые деньги.

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

Мое личное мнение, что разработка с нуля на микросервисной архитектуре — просто ошибка. Микросервисная архитектура на старте не даст вам вобще никаких преимуществ и только задержит в разработке. Наперед вы все равно не угадаете как сделать правильно, ваш продукт будет меняться в процессе разработки, спрогнозировать реальную нагрузку невозможно без реальных пользователей и работающего приложения. Правильное решение — это начать с важного: продукт, релиз и пользователи. А микросервисы начинать применять тогда, когда:
— возникнут условия, при которых они проявят свои преимущества (если эти условия вообще когда-нибудь наступят)
— нагрузка объективно возрастет до уровня, когда монолит перестанет справляться или когда стоимость его работы станет слишком дорогой
И именно в этот момент вы сможете грамотно начать выделять действительно нужные микросервисы и, в перспективе, отказаться от монолита полностью. Да, это нужно будет делать заранее, а не в момент, когда все уже ляжет, но точно не с самого начала, когда у вас нет ни одного реального пользователя и только идея на миллиард и мечта об очережном гугле или фейсбуке.

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

Уважаемые айтишники!

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

На данный момент, особенно прочитав статью Фаулера про микросервисы, и обобщив свои наблюдения, я могу назвать следующие недостатки монолитов:

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

2) Плохая работа согласованностью данных между доменами. Если домены разные, а сущности используются для разных целей то необхимо писать врапперы либо использовать schema-less EAV модель.

3) Слишком высокий уровень концентрации логики затрудняет работы разработчиков.

Приглашаю всех делиться своими наблюдениями по поводу микросервисов!

Пробывал машину «Мерседес», все хорошо, вот только пепельница забивается быстро, приходится новую машину покупать.... фигня.

Імхо, мікросервіси — то не про мікро і не про сервіси. Це про команди та розробку.

Інтернетами блукає такий мандат ще Джефа Безоса, кажуть, ще з 2002 року: homepages.dcc.ufmg.br/...​v/pmcc/modularization.pdf

— усі команди публікують функціонал через інтерфейси
— усі команди використовують лише ті інтерфейси
— оці інтерфейси повинні бути мережевими, жодних бекдорів
— начхати на технології, що CORBA, що REST
— всі інтерфейси потенціально публічні

У цього мандату є такі наслідки:
— кожен інтерфейс є контрактом щонайменше двох команд
— жоден розобник не може піти і просто змінити щось у інтерфейсі
— кожен сервіс може мати свій SLA та деплоймент
— зміну кожного сервісу можна тестувати окремо, використовуючи решту як надійне оточення
— кожен сервіс/команда має свободу вибору технологій (стек, база)

Я як описую ці принципи своїм розробниками, вони мені кажуть, що то ж мікросервіси і є :)

Як ці принципи застосувати, то й патерни запрацюють як треба. От, наприклад, сага: якщо сервіси доступні 99.9% часу, всі про це знають та використовують circuit breaker, та є ідемпотентні дії та компенсуючі дії, то сага може надійно забезпечити потрібний рівень цілісності даних. Вартість того буде вище, ніж в одній базі, але ж і розподіляється значно краще. А як передумови не виконати, то буде ж дурня, звичайно.

Там ще Кріс Річардсон пише про дорожні ями на шляху до мікросервісів. Він добре розповідає про них на усіляких конференціях: m.youtube.com/watch?v=RFiOjywaELg Імхо, усі ті патерни чи Architecture Assessment Platform допоможуть оминути ями лише якщо про них знати, тому й знати про них потрібно :)

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как прочитал, так и вздрогнул, у нас всё на микро сервисной архитектуре...

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

, минус — в грануляции логики, приходится четко разделять, что за что отвечает

хіба це мінус, це ж ще один плюс

Капітан-археолог :D

And then what they end up doing is creating 50 deployables, but it’s really a distributed monolith.

Может их просто не сумели приготовить

Микросервисы это зло

добра на всех не хватит! «deal with it» ©

Eсть плюсы и минусы. Больше команд работают лучше и меньше мешают друг другу однозначно, упрощает получение короткого цикла разработки, натуральней ложиться на scale out подходы, выкатывание многовёрсионных апишек тоже безопасней чем версионирование в коде монолита, упрощает например разработку multitenant систем с шаренными данным в нескольких регионах, усложняет работу с локальной отладкой, работу со стёйтом — введение новых агрегатов,версионирование данных в нескольких источниках сложней — data conversions, Es, это цена за скейл по командам и по нагрузке. как кто-то верно подметил часто отдельные сервиса совсем не micro отталкиваясь от domain boundaries, а попытка разделить их искусственно приводит к возникновению проблем, особенно если где-то нужна strong consistency при чтении. Это в микросервисах реально имеющих low coupling между собой(асинхронные интеграции и не очень длинные саги). Технически надо координировать больше — особенно если в основе дизайна сервисов cqrs+es. Использование контейнеров де-факто стандарт, но далеко не обязательно есть оркестрирование процессов на железе или paas функций с полным фаршем — service discovery/auto scaling/monitoring/mesh — это например если дебажить контейнеры сложно было кому-то, как аргумент в пользу монолита.

Микросервисы — это оправданное зло.
Допустим — вы банк и у вас есть старое приложение на коболе и едрене фене. Которое с ростом клиентской базы начинает потреблять манфреймы от IBM миллионами и это начинает быть совсем невыгодным.
И вы как банк решаете отдать один миллион из десяти, которые платите за майнфреным, чтоб посмотреть можно ли распилить это лайно на микросервисы.
Внезапно оказывается, что можно — более того, оно крутится на облаке, защищенном по PCI-DSS, и вы очень радуетесь, что экономите оставшиеся 9 миллионов ежемесячно.
Ну а то, что там внутри айтишникам надо думать о транзакциях и прочей ерунде — вас не колышет, ведь у вас есть свободных 9 миллионов и вы еще можете влить денег в это зло, чтоб оно приемлемо заработало.

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

Не можно. Потому чтоб собрать монолит — надо 3 недели компиляции и миллион долларов на ресурсы.

по-твоему разнося функционал на отдельные программы он начинает потреблять меньше ресурсов и быстрее компилиться?)

Конечно. Ведь для изменения функционала в каком-то модуле не надо компилировать все микросервисы. Достаточно только тот, который его исполняет.

ясно, понятно, а что ресурсы?)

Тоже самое. Ты можешь разнести их по разным железкам/облакам.

От этого дешевле что ли?)

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

Ну если все копировать, то не дешевле.
Но микросервисы дают контроль и мониторинг ЧТО ИМЕННО у вас потребляет ресурсы, потому вы запускает на 100500 задач на простаивающем железе, а только то, что реально не влазит. Всего остального запускаете просто по два(для failover).

это исключительно миф и фантазия
а теперь реальный пример, по замене мечтательными пионерами старого монолита, на микросервисное приложение с модным интерфейсом, как это на самом деле выглядит в дикой природе:
— в обоих случаях нет никакого горизонтального масштабирования, потому что сколько не показуй никому не нужное масштабирование на фронтенд-серверах, а затык всегда на уровне OLTP-базы, которая традиционно линейно масштабируется только вертикально
(когда-то видел слайд, с распределением нагрузки для многоуровневых приложений по соответсвующим уровням для разных секторов/направлений их применения
так вот, банковский сектор — это традиционно 70+% нагрузки приложения на уровне СУБД)
— пионерский микросервис, при прочих равных, создает нагрузку на базу на 1-2 порядка(!) выше, чем монолит (написанный к слову, ну вообще не корифеями), просто из-за дикого количества коннектов, потому что кучка микросервисов по сути выполняет умножение кол-ва пользовательских сессий

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

а это уже диагноз, предсмертный

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

Ну так если нужно горизонтальное масштабирование, то нужно использовать отдельную базу для каждого микросервиса, или БД которая тоже масштабируется горизонтально.

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

Сколько не говори «халва, халва» — во рту слаще не станет
P.S. помню одного друга владельца банка, он вот тоже как то утверждал, что 3 млн — это меньше чем 1 млн, пока дружба не закончилась :-)

Если ты не умеешь, то это не значит что другие тоже

Какраз работал недавно на проекте который в продакшене с 60, на ибмовских майнфреймах. И большая часть коду там на менфреймном ассемблере.

Контора уже 20 лет пытаетсья слезть с менфреймов, все никак да никак.

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

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

Тогда переход происходит плавно и незаметно.

это только до тех пор пока этот специалист не умрёт от старости ))

Если будет очень очень плавно, просто оставит след окаменелости на этом мейнфрейме и по нему еще несколько лет будут изучать бизнес логику :-)

Кстати на хабре была статься про четт подобное, Норвежский банк с каким-то неимоверно лютым и старым овном, пенсионерами, технологиями на окаменелостях :-)

если норвежский то это не пенсионеры а викинги ))

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

Да ладно. Такой переход занимает 5-7 лет. Вполне реальная цифра.

5-7 человеколет? т.е. 5-7 лет работу 1 (одного) того самого специалиста? не 20 и не 200?

а ну ок ))

Это работа специалиста типа архитектора, который делает чертежи. А рабочие (программисты) пишут код (строят по чертежам).
Так вот — такой проект занимает где-то 5-7 лет.

а что уже существующая система не по чертежам сделана?

угу и все как одина а) знают встроенный ассемблер б) знают встроенную архитектуру

5-7 лет это на много тим. Старт на нескольких тим, которые пилят «инфрастуктуру», потом подключение нескольких тимов которые будут ядро пару лет пилить. И как ядро готово, потом еще подулючение кучи тимов (с паралельным переучиванием дедушек с асемблера на джаваскрипт) для попила «много бизнес логики».

а ну ок ))

ЗЫ: я смотрю Родина (впрочем не только но конечно в данном контексте об Нём) полна жопаных аццких мичтатилей типа «ну а чо там как программа с мэйнфрейма посадим побольше за 5-7 лет запилим!» б.дь в реальной реальности средний реальный аутсорс пилит средний реальный плагин к среднему реальному веб-верверу общими усилиями 20 +/- человеколет а тут конечно главное

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

ЗЫ: т.е. б.дь в реальной реальности на оригинальном продукте никакой архитектуры и документации нет не н.й срать они её за 5-7 напишут! с ассемблера! ну а чо! #facepalm aka #ё.йп.ц

У меня на райчике Васян на пэхопэ пишет сайты любой сложности, а ты тут плачешься ! :-)))

Плохая у тебя реальность, постарайся ее избегать

на проекте который в продакшене с 60, на ибмовских майнфреймах.

Там наверно прикол в том,
что невозможно ни «взять всё и переписать», ни «распилить на микросервисы», ни «повыкусывать микросервисы».

Ком-то может и плохо, но не ассемблерщикам ))

На самом деле есть два типа систем, системы с состоянием и системы без состояния. На системах с состоянием транзакционность (ACID — концепция) реализуется намного проще. Но оба типа систем можно реализовать как на монолите так и на микросервисах
www.geeksforgeeks.org/...​ss-and-stateful-protocol

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

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

То есть:
* Если нужны транзакции за пределами микросервисов — в 90% случаев это ошибка проектирования, остальные 10% — превращаем распределенную транзакцию в многоступенчатую операцию
* Если возникает проблема с производительностью вызова — скорее всего, сервис спроектирован как библиотека, это ошибка
* Если нужно шарить базы — ну такое, иногда это нужно, например, для отчетов или аггрегатов

Пару преимуществ микросервисов:
* Очень легко поддерживать версионность АПИ — это реально нужно в случаях публичного АПИ, с монолитом это ручная работа (либо запуск копии монолита на каждую версию), с микросервисами — запуск копии микросервиса, что иногда проще.
* Возможность использовать разные платформы для разных сервисов — очень полезно
* Возможность переиспользования сервисов для разных приложений — сервис это самодостаточная система, ей не нужны зависимости и т.д., если она работает — то просто работает, и соответственно у нее самые низкие затраты на реюз

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

* Очень легко поддерживать версионность АПИ

Ни разу не согласен.

это ручная работа

Что за ручная «работа» чем она от работы над микросервисами отличаеться.

запуск копии монолита на каждую версию

Никто в здравом уме копию монолита не запускает. Все поддерживают версионность в рамках одного монолита. Это не являеться какойто особой проблемой.

с микросервисами — запуск копии микросервиса, что иногда проще.

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

* Возможность использовать разные платформы для разных сервисов — очень полезно

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

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

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

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

Классы в ООП и запущенные экземпляры сервиса — это совсем разные вещи, очевидно. Хотя бы потому, что классы — это только код, а сервис — это код + данные + окружение. Ради интереса попробуйте поднять к примеру OAuth2 сервер из исходников, скажем, IndentityServer.NET, и сравните с настройкой готового (к примеру, AWS Cognito, хотя там все относительно непросто).

Классы легко переиспользовать только в простых случаях.

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

Лично моя проблема в том, что я не хочу учить, или иметь какое либо дело с нодой. Но именно изза таких умников решивших зделать небольшой скрейпинг сервис на ноде — приходиться. И не только в ноду — и в питон, и в го и еще в черти что. При Сталине монолитах такой фигни небыло.

Ради интереса попробуйте поднять к примеру OAuth2 сервер из исходников, скажем, IndentityServer.NET, и сравните с настройкой готового

Я непонял в чем сравнение? Попробуйте на стороне сервиса тотже OAuth2 через спринг-секюрити прикрутить, или с нуля вручную все написать ?

Классы легко переиспользовать только в простых случаях.

Мой поинт что микро-сервисы тоже.

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

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

Да ладно. Это еще маленький монолитик если его просто без напряга можно поднять локально.

Можно и на dev енве подебажить, было и такое когда очень нужно а монолит подымать геморно.

Ну и большой монолит не значит сложный в деплое. На том же int и проде подымают то как-то.

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

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

Ну как бы да, но теперь в контейнерах.

«Тепер, з банановим смаком!» :-)

Суть то тут проста. Примеров проектов которые начались и успешно развились как монолит — великое множество. Примеров успешных проектов на микросервисной архитектуре, особенно когда распиливали монолит, откровенно мало. Можно сколько угодно кричать избитые фразы про «инструмент» и «вы не умеете их готовить», но по-моему выводы более чем очевидны.

Списки можно посмотреть?

Считайте субъективным мнением. Такие списки никто не будет озвучивать ввиду нда.

Примеров успешных проектов на микросервисной архитектуре, особенно когда распиливали монолит, откровенно мало.

или бубен их не видел....

Очень «люблю» выражение «а давайте распилим это всё на микросервисы».

Звучить як лозунг корупціонера...

это ближе к Фрейду- предвкушение неизбежных страданий и совокуплений.

Что-то я смотрю, уважаемые господа, что о таких штуках как KISS и YAGNI тут мало кто слышал.

дальше простых CRUD-приложений на них не уедешь.

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

Потрясно. Вот только некоторые не тратят много времени на микросервисы — ибо дефолт фреймворка и вообще — не в первый раз.

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

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

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

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

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

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

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

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

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

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

Но я не уверен что вопрос велосипедостроения стоит смешивать с концепцией изоляции.

Если есть возможность сделать сервисы полностью независимыми (не шаряшими идшники и не ждущими ответа друг от друга) — то всё хорошо. Проблема в том, что в 90% случаев этой возможности нет. Не говоря уже об отсутствии необходимости. Микросервисы обходятся дорого.

АЙдшники иметь общие — это не проблема даже. Код разделить — вот тут тяжелее.
1) вы там выше не провели различие между микросервисами и подпроектами солюшенов.
2) Ну, допустим, 95% проектов эта какая-то монолитно-изолированная штуковина на 1-2 человеко-года работ. И че? Что делать остальным?

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

1) Отличие в том, что всё это будет подниматься одной кнопкой и поддерживать все отладочные средства. Работать будет быстрее, потому что прямые вызовы на порядок быстрее http запросов. Деплоится тоже будет не в пример легче.
2) Вот те 5%, для которых преимущества микросервисов перевешивают огромные недостатки, пусть их и используют. А пихать в каждый второй проект, потому что модно — не нужно.

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

Ну это и есть микросервисы, насколько я понимаю.

Ну есть еще лямбда-экстремалы, которые любую команду деплоят отдельно)

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

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

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

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

Так не интересно, надо придумать проблему и героически ее решать.

Когда-то давно говорили, что Java — это зло и скоро исчезнет. Даже приводили сроки и кандидаты на роль «убийц Java». Но время идет, а Java. Может потому, что люди научились на ней писать

джава действительно зло :) но надеятся что исчезнет глупо

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

Java образца 2004 года исчезла, отчасти и потому, что Sun оказалась в положении когда сообщество дружно послало EJB 2 в лес. И EJB 3 написали уже в стиле в котором были альтернативы.

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

Что лучше уметь только ифы или ещё и циклы с массивами?)

Вы на собеседованиях тоже такие вопросы задаете?

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

вообще-то «зависит от ...»

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

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

а так да, согласен, берем простенький микросервис и — вот видите, какой он простенький!

ну так возьмите простенький класс из хорошо декомпозированного монолита, и скажите тоже самое:
видите, как просто писать монолиты — просто пишем простенькие классы, и все само будет работать!

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

Проще сейчас не означает проще в будущем.

Сложнее сейчас — не означает проще в будущем
Если вы пишите монолит в котором для вывода «Hello world» используются фабрики стратегий конфигуруемые DSL для неформальных грамматик, — то даже если проекту нужно прожить 5 лет, его саппорт будет сжирать тьму денег, и после очередной передачи «индусам» будет принято решение начать отпиливать от него куски и переписывать.

Упоротость — она такая, какой ей лучший способ не дай, она и не поймет, намеков, что дело в наличии здравого смысла, а не банальщины «что лучше — быть молодым и бедным, или старым и богатым»

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

Дык для микросервиса (если он на джабе) все тоже самое — спринг бут, DI, простыни конфигов, «мудреное аннотирование», итд. И какбы никуда не деться, потомучто без спринга коду будет 10 в 10 раз больше — совсем не то чего микросервисники хотят.

Дык для микросервиса (если он на джабе) все тоже самое — спринг бут, DI, простыни конфигов, «мудреное аннотирование», итд.

обманываете!

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

:)

Ну, то есть, про тот же Quarkus или Micronaut месье не слышал?

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

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

легковестные фреймворки есть в каждой экосистеме. и будут появляться.
яркий пример — javascript — там тьмы легковестных фреймворков.
а почему же основными остаются — React+"Redux«, Angular, Vue?

потому что каждый легковестный фреймворк построен по принципу «80-20»

в 80% случаев нам нужно только 20% функционала.
так давайте напишем только эти 20%!

И каждый доклад типа «Антон Кекс: Как нам спасти Java?»
о том же. И каждый докладчик — прав.

Проблема только в том, что будет с проектом когда понадобится что-то чего не просто нет в легковестном фреймворке, а на уровне его идеологии — не предусмотрено расширение до требуемого функционала из того редкого 80%.

Поэтому при выборе технологии — выбирающие учитывают — риски.
Или не учитывают, риски от этого не исчезнут :)

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

Считаете что нечто лучше? ну так вперед, берите и используйте :)

яркий пример — javascript — там тьмы легковестных фреймворков.
а почему же основными остаются — React+"Redux«, Angular, Vue?

потому что каждый легковестный фреймворк построен по принципу «80-20»

в 80% случаев нам нужно только 20% функционала.
так давайте напишем только эти 20%!

Я конечно извиняюсь, но мне показалось или вы действительно не углублялись в изучение Angular, React, Vue? Там нет ни какой легковесности. Angular использует TypeScript — это относительно новый язык, он поддерживает статическую типизацию, чего нет в самом Js. Именно по этому Angular рекомендован к разработке больших полновесных приложений. Ну и с React тоже не всё так просто. Кстати везде в этих фреймворках можно писать на чистом js, только вот ни у кого охоты такой не возникает.

... Angular, React, Vue? Там нет ни какой легковесности.

ок, читаем вместе

яркий пример — javascript — там тьмы легковестных фреймворков.
(то есть можно выбирать из большого числа — легковестных. на любой вкус)

а почему же основными остаются
(НО, выбирают в основном, противоположные, т.е. НЕ легковестные)
— React+"Redux«, Angular, Vue
(и далее написано почему выбирают НЕ легковестные)

но вывод у вас да, сразу:

но мне показалось или вы действительно не углублялись в изучение

зависит от значения слова «углублялись».
riot.js и Vue у меня основные, в зависимости от задач
подумываю поковырять preact, для использования вместо riot.js. но вряд ли, у riot.js есть жирный плюс — он может обходиться без этапа транспайлинга и сборки, его «кастомные теги» легко инлайнятся.

но думаю что тут проблемы у вас с пониманием русского языка :)

я написал:
React+"Redux", Angular, Vue — не легковестные, и аргументировал почему их, несмотря на это выбирают (то есть даже если не поняли пары фраз, дальше аргументацией задан их контекст)
вы мне
почему это вы называет React+"Redux", Angular, Vue легковестными?
они не легковестные!

а я что написал?

только вот ни у кого охоты такой не возникает

Как вы прям за всех расписались

простыни конфигов, «мудреное аннотирование», итд.

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

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

Она то бывает, но если потенциально нужно быстро связать все со всем, да еще и код шарить, то спринг на сегодняшний день один из самых безгеморных фреимворков на рынке. И «безгеморность» никак не отменяет

DI, простыни конфигов, «мудреное аннотирование», итд.
кто-то еще и в спринг не умеет

Вам из танка, безспорно, виднее.

Скорее так: Что проще написать одни класс и реюзать его, или 10 раз откопипейстить, и если чтото нужно менять то делать это 10 раз, а еще 10 раз от тестировать от интегрировать и передеплоить...

Общие библиотеки и системы управления артифактами? Не, не слышал

Общие библиотеки и системы управления артифактами? Не, не слышал

Вот я хз чего вы, «микросервисники» ©, об этом не слышали.

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

микросервисы, использующие старую версию библиотеки, так и продолжат ее использовать

о это очень хороший вопрос очень сложный вопрос на самом просто потому что исходная архитектура может таки предусматривать замену версии библиотеки для всей системы сразу ну хотя бы б потому что разные версии библиотеки влекут за собой разные сайдэффекты об которых при её написании никто никак и не задумывался и «поддержать» такой кейз соотв. просто некому разве что своими силами что возвращает нас к интересным вопросам а) разных версий одной и той же ж библиотеки в масштабах системы (а сколько? 2 версии? 3? а когда менять на общую?) б) деплоя разных версий вообще как принципа просто потому что разные версии ведь бывают не только у библиотек но и у самих сервисов и у протоколов и даже у несущих операционок не говоря уже об гипервизорах

ну вот вышел ... ну положим RHL не так иллюстративно но пусть будет фря )) и переехали мы частью сервисов с 8-й на 9-ю ... а они там внутре бинарно уже несовместимы даже не по ABI а просто по API там немножко нового есть и нам как раз нннада! очень полезный такой мы его в новых сервисах используем а старые теперь что переписывать? просто пересобрать? ещё как?

непродуманная система деплоя версий (которой кстати занимается отдельный отдел постоянно держа в курсе что мы вообще используется на что можно переезжать на что пока не стоит и на что нужно ещё вчера в виду разных там уязвимостей или у вас и этим каждая команда сама по себе?) это прямой шаг или даже прыжок к хаосу и то что в старину на микрософтовинде звалось DLL Hell ))

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

Их нет. Но на нет м суда нет)

ИТТ: иксперты по хайлоаду из аутсорса.

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

Я хз, у нас 2 хоста и одна MySQL база. Всьо работает.

Это была шутка про «монолит» Амазона в контексте данного треда. У меня и хоста не 2 и MySQL уже нет.

Коментар порушує правила спільноти і видалений модераторами.

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

Получается, микросервисы это зло, потому что неправильно используются людьми? Если бы роботы писали проекты, то все бы замечательно работало?

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

Микросервисы это зло

Нет ничего глупей, чем называть любой инструмент или технологию злом. Это инструмент. А у любого инструмента есть плюсы и минусы, и любой инструмент нужно применять правильно и уместно. И вот с уместностью применения микросервисов (да и многих других вещей) я вижу большие проблемы.

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

А теперь давайте разберем по порядку все эти пункты:
1. Масштабируемость. Теоретически — позволяет переварить любую нагрузку путем простого добавления нод под каждый сервис. На практике, для этого требуется использовать распределенную БД, оначе рано или поздно это упрется в производительность обычной реляционной базы. При этом для 99.9% проектов эта масштабируемость никогда не понадобится. Sad but true: большинство проектов так и не выстреливают, а многие из тех, кто начинают зарабатывать, не пробиваются среди конкуретнов и не добиваются той пользовательской базы, при которой вообще потребуется масштабирование.
То есть, чтобы получить профит от этого пункта, мы должны иметь огромную базу юзеров, которая обеспечит нам нагрузку, при которой эта масщтабируемость потребуется в принципе.
2. Отказоустойчивость. Работает только при правильном проектировании: отказ одного микросервиса должен минимально затрагивать работу остальных сервисов. Если это условие не выполняется — отказоустойчивость такого решения еще меньше, чем монолита, так как монолит хоть быстро передеплоить или отдебажить можно.
3. Большее время разработки, сложность деплоя. Однозначно при разработке микросервисов вы позже выйдете на рынок. Ну просто потому, что физически монолит пилится проще и быстрей: весь код в одном месте, тестирование и деплой проще и быстрей. А значит вы позже сможете получить первых юзеров и заработать первые деньги. А еще играет роль то, что в любом проекте постоянно что-то меняется, особенно на старте. И адаптировать монолит под эти изменения в разы проще, чем микросервисы.
4. Требует больше железа. Вам таки понадобятся деньги на аренду или покупку железа чтобы все это крутить. Причем тех денег, которые вы пока что не заработали.
5. Производительность. Все будет работать медленней, чем на монолите. Поначалу так точно, а выиграть вы сможете (возможно) когда-то потом, когда юзеров станет очень много (а это, как я писал выше, почти никогда не случается).
6. Сложность с транзакционностью. Транзакционность — очень удобная вещь, она позволяет реализовать многие вещи проще и надежней. Да, когда вы дорастете до миллионов пользователей и десятков тысяч запросов в секунду, вам, возможно, таки приется с ней распрощаться, но до этого сначала надо дожить, а простая работа с транзакционностью в монолите позволит вам дешевле и быстрей разработать ваш бекенд и выйти на рынок, чтобы привлечь юзеров и заработать первые деньги.

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

Мое личное мнение, что разработка с нуля на микросервисной архитектуре — просто ошибка. Микросервисная архитектура на старте не даст вам вобще никаких преимуществ и только задержит в разработке. Наперед вы все равно не угадаете как сделать правильно, ваш продукт будет меняться в процессе разработки, спрогнозировать реальную нагрузку невозможно без реальных пользователей и работающего приложения. Правильное решение — это начать с важного: продукт, релиз и пользователи. А микросервисы начинать применять тогда, когда:
— возникнут условия, при которых они проявят свои преимущества (если эти условия вообще когда-нибудь наступят)
— нагрузка объективно возрастет до уровня, когда монолит перестанет справляться или когда стоимость его работы станет слишком дорогой
И именно в этот момент вы сможете грамотно начать выделять действительно нужные микросервисы и, в перспективе, отказаться от монолита полностью. Да, это нужно будет делать заранее, а не в момент, когда все уже ляжет, но точно не с самого начала, когда у вас нет ни одного реального пользователя и только идея на миллиард и мечта об очережном гугле или фейсбуке.

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

Что не отменяет факта, что в определении всех необходимых интерфейсов EJB 1-2 зашифрован код для вызова сатаны.

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

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

И вот в случае монолита все становится далеко не так однозначно, мягко говоря.

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

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

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

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

аб том и вапрос что в сабжевой теме люди столкнулись с тем что «микросервисы» есть а как их готовить никто не знает равно как и скорее всего «а зачем?»

ЗЫ: лично я например последних 20 лет периодически встречаю «реализацию микросервиса по нужде» )) когда 2 или более «разносторонних команд» (в т.ч. разных компаний) интегрируют свои «сервисы» в общее приложение но при этом какой-то из «сервисов» (ну а то и все разом) не обладает достаточной степенью надёжности (привет самолётам аирбас которые приходится перезапускать каждых сколько там? 50 часов?) и соотв. «принцип падучести» прямо закладывается в устройство системы как архитектурная особенность уже высшего уровня

проще говоря если когда-то давно мы обнаружили что «чужой код» тупо зависает но его можно тупо перезапустить и мы его просто вынесли и тупо написали к нему «сторонний скрипт» который бы б тупо делал это каждый полчаса условно то теперь это вполне себе называется «микросервисы» ))

ЗЫ: плюс «производители облаков» активно продвигают эти «фичи» то ли пользуясь хайпом то ли его и организуя и предлагая в качестве end point какие-нибудь serverless architectures и «лямбды как функциональный конец любого сервиса»

новые фичи, которые легко «подключить» и «отключить» или переделать

Точно так же делается (я делалось мной многократно) в монолите.

Понятно, что делается. Я тоже так делал многократно.

Я бы в плюсы микросервисов добавил maintainability.
Куда проще допилить (или даже переписать в случае необходимости) 1 небольшой сервис с очевидными входом и выходом и покрыть изменения юнит и интеграционными тестами, нежели перепиливать кусок функциональности монолита с неочевидным количеством регрессионных ошибок после изменения.

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

есть какие-то специальные причины не делать такое и в монолите? ))

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

Микросервисы от этого тоже не застрахованы, особенно если кодбаза разнесена по разным репозиториям.

Особенно если не разнесена

если не разнесена — то абсолютно тоже самое что и с монолитом.

У нас вся тима правит все проекты которые в разных репах и шарят между собой dll-ки, это блджат адъ.

Dll hell вручную, бггг

Неочевидны связи между сущностями в монолите. Особенно, если используется шаренная база, к примеру.
Например, есть задача: добавить 1 поле в 1 таблице в БД.
Сколько и каких различных модулей в монолите сломается? Ответ неизвестен.
С другой стороны, если такая же задача ставится для микросервиса — ответ вычислить на порядок проще. Изменился формат ответа для сервиса (добавилось то же 1 поле в ответе). Сколько сервисов связаны с изменённым — посчитать нетрудно. Для ленивых достаточно даже тупо прогнать интеграционные тесты, которые моментально покажут изменение схемы ответа.

Монолит точно также замечательно делится на bounded contexts, с единственной разницей, что между несколькими bounded contexts может шариться инфраструктурный код (cross-cutting concerns)

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

От добавить поле — обычно нисколько

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

В моём опыте ломалось, когда сервис задеплоили а базу проапдейтить забыли)

Та есть и работает. Просто на тестовый инстанс накатить забыли

Сколько и каких различных модулей в монолите сломается? Ответ неизвестен.
Сколько сервисов связаны с изменённым — посчитать нетрудно.

Вы там, обкурились чтоли все ?

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

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

Вы там, обкурились чтоли все ?

наверняка.

а может в этом и секрет строчки в вакансиях:
«... умение читать чужой код ...»

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

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

Я говорю с точки зрения тестирования, не кода.

В монолите открываеться иде, делаеться «файнд бай юседж» — и находиться использование поле

На JS такое работает не всегда, но в целом да

Архитектуру нужно нормальную делать, тогда всегда всё найдёт в веб шторме.

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

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

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

Как себе представляешь такого архитектора в системе, в которой сотни микросервисов?

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

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

— микросервисные системы разрабатываются без проектирования архитектуры, самими разработчиками — а давайте наши два сервиса свяжем вот так! зачем нам пиэмы, тьху, архитекторы!

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

это да, ниасиляторы монолитов — великие спецы в более масштабных проектах :)

О, ну что ещё можно ждать от кого-то с зашкаливающим чсв, когда ему нечего сказать? — только хамства

Как себе представляешь такого архитектора в системе, в которой сотни микросервисов?

Наверняка в нетфликсе (или где) отличный архитектор.

Мой личный опыт — архитектор либо выполняет роль мебели, либо занимаеться космическими кораблями бороздящими просторы необъятного космосу. Комуникацию между микро, макро, и нано сервисами делают сами девелоперы, они делают кучу недокументируемых изменений; в конце концов никто не имеет полной картины, и не знает как оно работает. И ситуация не шибко лучче чем на большом монолите.

в Нетфликсе нет архитектов...

и? Первые две позиции по инфраструктуре (то есть не софт), а дальше позиции не архитект.

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

Вы шо гонете или шо? Связи в монолите тяжело увидеть??? Сириусли? Вы в нотпаде педалите?

Неочевидны связи между сущностями в монолите.

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

На мой тайтл глянь :)
Я говорю с точки зрения покрытия тестами таких изменений.

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

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

Супер!!! Спасибо что написал, я когда почитал сабж — хотел тоже самое сказать, потом был занят, а потом перегорел. Да и потом — на доу не любят когда какие то БА умничают :)))

Імхо, мікросервіси — то не про мікро і не про сервіси. Це про команди та розробку.

Інтернетами блукає такий мандат ще Джефа Безоса, кажуть, ще з 2002 року: homepages.dcc.ufmg.br/...​v/pmcc/modularization.pdf

— усі команди публікують функціонал через інтерфейси
— усі команди використовують лише ті інтерфейси
— оці інтерфейси повинні бути мережевими, жодних бекдорів
— начхати на технології, що CORBA, що REST
— всі інтерфейси потенціально публічні

У цього мандату є такі наслідки:
— кожен інтерфейс є контрактом щонайменше двох команд
— жоден розобник не може піти і просто змінити щось у інтерфейсі
— кожен сервіс може мати свій SLA та деплоймент
— зміну кожного сервісу можна тестувати окремо, використовуючи решту як надійне оточення
— кожен сервіс/команда має свободу вибору технологій (стек, база)

Я як описую ці принципи своїм розробниками, вони мені кажуть, що то ж мікросервіси і є :)

Як ці принципи застосувати, то й патерни запрацюють як треба. От, наприклад, сага: якщо сервіси доступні 99.9% часу, всі про це знають та використовують circuit breaker, та є ідемпотентні дії та компенсуючі дії, то сага може надійно забезпечити потрібний рівень цілісності даних. Вартість того буде вище, ніж в одній базі, але ж і розподіляється значно краще. А як передумови не виконати, то буде ж дурня, звичайно.

Там ще Кріс Річардсон пише про дорожні ями на шляху до мікросервісів. Він добре розповідає про них на усіляких конференціях: m.youtube.com/watch?v=RFiOjywaELg Імхо, усі ті патерни чи Architecture Assessment Platform допоможуть оминути ями лише якщо про них знати, тому й знати про них потрібно :)

Все так и есть. Скрам тоже у кого-то работает, а у кого-то «новомодная хрень, с бессмысленными митингами».

Совершенно верно. Айтишнеги вроде все такие умные, ылита человечества итд ипт. А рынок технолгий, стеков и методик очень недалеко ушел от магазина «мобилчка». Где смышленые пацанчики впаривают лохам очередной ифон (теперь с тремя камерами!!!). И увидев рекламу, они как зомби таки бежат его покупать.

Где смышленые пацанчики впаривают лохам очередной ифон (теперь с тремя камерами!!!)

Передам привет людям с арахнофобией, их трёхглазый айфон напугает

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

Уже почти 20 лет как новомодная)

Уважаемые айпишники!

Как следует ознакомившись с женщинами, я пришел к выводу что это просто зло. Я с женщинами в каком — то смысле столкнулся еще в 2011 году, когда мы писали набор REST — приложений, устанавливаемых под OSGi — контейнер Apache Karaf. Еще там мне стало понятно что быть беде.

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

1) Женщины очень плохо реализуют транзакционность. Если используются несколько баз данных, то надо использовать 2PC протокол. Он не рекомендован к применению в женщинах, вместо него рекомендуют паттерн Сага. Но Сага не обеспечивает реальной консистентности и согласованности в данных, это просто дурня. Поэтому для приложений, где требуется корректность, женщины уже подходят плохо.

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

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

Приглашаю всех делиться своими наблюдениями по поводу женщин!

Микросервисы очень плохо реализуют транзакционность.

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

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

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

Не плохая, а другая. Надо быть готовым что 100% consistency в конкретный момент в целом никогда не будет. Будет eventual со всеми вытекающими: мониторить нужно задержку этой eventuality, сверять согласованность по данным изменившимся ранее этой задержки и т.п.

Согласованность, ИМХО, основная сложность отхода от монолитной ACID модели данных с микросервисами или без них.

Хорошая новость — эту проблему все равно нужно решать на границах системы (интеграция с другмими системами) или с ростом сложности системы.

Если используются несколько баз данных, то надо использовать 2PC протокол.

НЕТЪ! 2PC мертв. Читаем, например, dataintensive.net если пропустили.

Приглашаю всех делиться своими наблюдениями по поводу микросервисов!

Знаете ли вы в первую очередь ЗАЧЕМ вам нужны микросервисы? По вопросам не похоже. Может вам и не нужно? Уже следующий вопрос — как их дробить и строить.

1) ...
Вы не умеете в микросервисы
2) ...
Вы не умеете в микросервисы
3) ...
Вы не умеете в микросервисы

А если кроме шуток, то такие темы могут возникнуть только у того, кто никогда не работал над чем-то действительно большим (ну а откуда большое в аутсорсе?). Я бы посмотрел бы с удовольствием на того, кто написал бы монолитом Гугл или Нетфликс или Фейсбук какой-нить.

Я бы посмотрел бы с удовольствием на того, кто написал бы монолитом Гугл или Нетфликс или Фейсбук какой-нить.

2+ больших монолитов взаимодействующих между собой микросервисами не станут, монолитами так и останутся

написать Гугл или Нетфликс или Фейсбук можно группой монолитов

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

а если 10 или 100? и связи на другие монолиты обязательны?

ну да, пусть делает 100 бизнес-задач. Потом когда только одна начнет тормозить, мы просто побольше инстансов добавим. И не важно что 99 других задач прекрасно и на меньшем кол-ве инстансов работали, пусть простаивают ресурсы. У нас же инстансы бесплатные, память бесплатная.
Ну и неважно что у нас на каждой команде всего несколько бизнес-задач. Мы их все 100 запихнем в один монолит. Ну и что что деплоймент и мердж в ад превращается. Неважно что тесты часами проходят (задач то мы 100 запихали туда).
Ах, вы хотите деливерить в прод несколько раз в день? Ах, у вас пейджер звенит что на проде баг и надо срочно обновить версию? Ну извините, у нас 100 бизнес-задач запихано в один монолит и вон тот тест, что тестирует 57-ю, он сломался. Ну да, мы ждали 3 часа пока тесты все пройдут и он сломался.
Ах кто-то из другой команды запилил изменение в мастер а надо срочно в прод выкатить? Ну можно отбранчеваться от последней стабильной версии, накатить фикс и в прод... Ой, а другая команда свою фичу делала и теперь им надо ребейс сделать а он ругается на конфликты... Жаль. Ну это пофик, главное что не дадим микросервисам и шанса!

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

Мы их все 100 запихнем в один монолит.

мы напишем 100 микросервисов!
каждый со своим API

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

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

Ах, кто-то срочно обновил микросервис, с крохотным изменением в API. за 30 минут написал, тесты проходят за 10 минут.
и в продакшн!

ну и пофик что на продакшене с десяток остальных микросервисов «в недоумении» отвалились.
зато ж — тесты 10 минут бегут всего, и код у микросервиса простой.
классно быть разработчиком микросервиса!

не надо ничего рефакторить «в монолите», мерджить с разрешенеим конфликтов.
конфликтов то нет, как и мерджей. у каждого свой простенький микросервис
вот оно, счастье то наконец.

Ну это пофик, главное что не дадим микросервисам и шанса!

ну почему ж. принимайте решение — и переводите свой проект на микросервисы. делов то :)

мы напишем 100 микросервисов!

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

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

если это простое действие является законченным бизнес кейсом то да. В чем проблема опроса десятка микросервисов?

Ах, кто-то срочно обновил микросервис, с крохотным изменением в API. за 30 минут написал, тесты проходят за 10 минут.
и в продакшн!

обратная совместимость? Запрет на любые изменения в апи, кроме добавления необязательных параметров или добавления новых эндпоинтов? Использование всяких там protobuf — ов ? Версионирование? Поставка со своим сервисом клиента, который разруливает изменения в апи прозрачно для юзера сервиса? — не, ни о чем таком не слышал.

и переводите свой проект на микросервисы

пока на доу думают категориями «проектов» а не системами, в которых тысячи сервисов и сотни команд их разрабатывающие, те, кто работают в таких компаниях, уже давно пишут все на микросервисах и понимают что по-другому практически невозможно

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

в бизнес-логике все просто:
продать товар А покупателю Б, с учетом скидок на товар А, и бонусов покупателя Б.
сколько самодостаточных сервисов можно напилить с этого?
они будут «самодостаточны в плане бизнес-логики»?

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

бизнес кейс выше:
продать товар А ...

Запрет на любые изменения в апи, кроме добавления необязательных параметров или добавления новых эндпоинтов?

то есть в монолите нельзя запретить изменения публичных интерфейсов, а вот тут — бац, и запросто?

Версионирование?

про версионирование должны знать остальные сервисы

пока на доу думают категориями «проектов» а не системами, в которых тысячи сервисов и сотни команд их разрабатывающие,

это не на доу так думают.
это реалии — бизнесов, которых, с тысячями сервисов и сотнями команд 0,0001%

уже давно пишут все на микросервисах и понимают что по-другому практически невозможно

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

в бизнес-логике все просто:

информации недостаточно для построения архитектуры

то есть в монолите нельзя запретить изменения публичных интерфейсов, а вот тут — бац, и запросто?

Ну да. Бац и запросто. Вот бывает такое. Сложно представить, верю, но да, бывает

про версионирование должны знать остальные сервисы

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

это не на доу так думают.
это реалии — бизнесов, которых, с тысячями сервисов и сотнями команд 0,0001%

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

и вы, будучи программистом в компании с тысячами сервисов и сотнями команд пишите.

Пишу, спасибо

информации недостаточно для построения архитектуры

кто писал такую логику — сразу дополнит не на один абзац :)

Остальные, кому интересно, почитают документацию

действительно. Программный код от коллег по монилиту прочитать не могут, а вот документацию да :)

и говорят что невозможно микросервисами ничего достичь

всего можно достичь и используя ассемблер.

другие, работающие в таких вот 0,0001% бизнесах, делают это каждый день и понимают что по-другому просто никак

у этих — 0,0001%
забыли вы уточнить :)

Пишу, спасибо

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

господин совсем упорот? Мое первое сообщение в ветке этой

Я бы посмотрел бы с удовольствием на того, кто написал бы монолитом Гугл или Нетфликс или Фейсбук какой-нить.
Ах, кто-то срочно обновил микросервис, с крохотным изменением в API. за 30 минут написал, тесты проходят за 10 минут.
и в продакшн!

SOLID нічого не каже, власне «Open/Closed Principle»

якщо цей принцип порушують «в монолітах», то що забороняє його порушувати у «мікросервісах»?

якщо цього принципа дотримуватись у «моноліті», то звідки там будуть братися ті проблеми, котрі обіцяє вирішити «мікросервісність»?

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

в моноліті може бути так херня як ООП і наслідування,

ну то зрозуміло що ООП — мертва парадигма, і тільки йолопи та дурні її використовують.

і тоді зміна одного компонента тягне переписування 100500 класів.

звісно, ці всі 100500 класів були зайві.
той же функціонал можна реалізувати у 1005 простеньких мікросервісів.

А мікросервісі, ланцюжок залежностей швидко обірветься.

так, а система буде й далі собі працювати, просто без цього функционалу.
ну тіпа — перевірили баланс покупця, сервіси всі щось відповідають незрозуміле, та й нехай собі! продамо все одно покупцю, бо це головний функционал системи

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

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

Was that sarcasm?

в моноліті може бути так херня як ООП і наслідування, і тоді зміна одного компонента тягне переписування 100500 класів.

вообще-то ооп это точно такой же ж «апи контракт»

А мікросервісі, ланцюжок залежностей швидко обірветься.

да уж конечно

Что мешает не создавать длинные цепочки наследования и заменять его композицией, как советовали ещё в GOF 20 лет назад?

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

питання до тих, хто такі моноліти пише?
я ж читатєль

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

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

Мешает принцип shared nothing, так как, во-первых, изменения в этой библиотеке потребуют редеплоя всех зависящих от неё микросервисов, а во-вторых, такой подход автоматически означает отказ от одного из основных преимуществ микросервисов: polyglot programming.

На который ирл почти всегда болт кладут. Что логично, так как большинство микросервисов создаются по принципу «мы пилили монолит». А раз оно было монолитом — то у него должны быть общие части. Короче говоря, появление библиотеки типа Common.Utils — практически неизбежно.

Короче говоря, появление библиотеки типа Common.Utils — практически неизбежно.

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

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

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

Ок — расскажите как 5-10-20 человек не толкаясь независимо тестируют деплоят и программируют классический монолит с 100-200 таблицами в базе не создаваю друг другу проблем по ресурсам, зависимостям, изменениям и вообще.

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

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

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

эм... ну как делается есть 2 основных варианта и +100500 вариантов их реализации № 1 когда спагетти код и

открываете метод, собираетесь менять, допустим вы не пропустили подсказки от доброй ИДЕ, что он используется в 26 местах

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

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

только для варианта № 2 нужно много всяких процессов это дорого очень в первую очередь для мозгов и очень немногие человеки готовы реально на это пойти (да и способны чисто биологически впрочем тоже) на переходе команды от 20 человек к больше 20 и там примерно от 150 и выше ну положим больше 1000 человек на 1 проект я уже не знаю обычно он на этом уровне уже таки «порезан» (ну хотя бы б потому что он просто «сшит из подходящих кусков» наподобие франкенштейна) в общем это уже совсем другая история

так вот уровень 20 человек не преодолевает никто )) из известных мне просто выставляют всех на мороз а проект передают в Индию Украину или простите Запорожьё )) так тоже бывает я проверял

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

сколько митингов надо провести чтобы понять должно быть ваше изменение глобальным или нет?

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

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

Переиспользование кода — это прежде всего введение зависимости, а не снижение издержек на нажатие кнопочек

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

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

По факту я уж как ни будь справлюсь с конструкциями

if (isSpecificLogic)
{
Do();
}

или

strategy.Do();

без всякого эскалирования. В крайнем случае — сначала покрою старый метод 100% юнит тестами.

Откуда такой ужас перед зависимостями? Неужели настолько трудно разобраться, что метод делает, прежде чем его менять?

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

Это основа научного метода познания — догм нет, всё можно подвергнуть сомнению.

Это основа научного метода познания — догм нет, всё можно подвергнуть сомнению.

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

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

Ну если счеты с блокчейном и блютусом!? Разве не передете?

Да тут один уже подключал деревянный кубик к интернету и выдавал это за инновацию.

Зато энергонезависимые и экологичные! А сброс регистров наклоном — вообще шик! )

вы там уже определитесь

принцип shared nothing,

или

Общие библиотеки и системы управления артифактами? Не, не слышал

такой подход автоматически означает отказ от одного из основных преимуществ микросервисов: polyglot programming.

Имхо это один из недостатков.

Каюсь — не совсем верно трактовал принцип shared nothing применительно к повторному использованию кода.

Реюз кода здорового человека в микросервисах:

  1. Системы управления артефактами и семантическое версионирование
  2. Общие библиотеки могут реализовывать только утилитарные / инфраструктурные функции. Никакая бизнес-логика шариться между микросервисами не должна

Это всё применимо и к монолитам.

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

Если микросервис создаётся по принципу разделения монолита на части — он зло.

Приехали.
Жил-был монолит.
Год с одним программистом.
Два с двумя.
Три с пятью.

Вырос. Пришла пора разделять.
Где тут зло?

Зло в том, что после разделения он так и останется монолитом. Только начнёт общаться сам с собой http запросами.

В монолите разные bounded contexts вызывают напрямую друг друга? Нет, потому что иначе нарушается принцип low coupling.

Тогда, что меняется кроме механики деплоймента, если один или более этих bounded contexts становятся отдельными микросервисами?

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

Если две части монолита не коммуницируют друг с другом напрямую — их можно выносить в разные приложения. Но в 90% случае это не так. На микросервисы режут прямо по прямым связям.

Авторизация — это бизнес-логика? Как вы реализуете права доступа в микросервисах?

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

Например, если это claims в JTW token’е, то шарить между микросервисами имеет смысл код для проверки наличия определённого клэйма в JWT, а уже сама логика проверки «имеет ли право пользователь произвести такое-то действие» будет уникальной для каждого микросервиса, но при этом полагаться на общий код работы с JTW.

JWT — это аутентификация.

Я говорил о правах/ролях/политиках — вот этом вот всем.

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

Т.е. каждому микросервису по собственной системе авторизации?

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

А назначает их кто?

Тот кто jwt создает и обладает исчерпывающей информацией о всех ролях пользователя.

...
И кто-же это?
И где он берет свои знания, и как поддерживает их up to date?

Он знание не берет, а является единственным в системе источником знаний о юзерах. А кто именно, зависит. Например keycloak, okta, wso2 и любой другой подобный сервис. Единственное, что проверяет бизнес сервис — подписан ли правильно токен и добавлена ли в него нужная роль.

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

Это задача не про авторизацию, а про бизнес логику. Решается, например, так: сервис лотереи подписан на domain events, публикуемые сервисом покупок в общую шину, и ведёт внутри себя список совершивших покупки в течение текущего квартала.

Причем, заметь, в монолите, спроектированном по принципам DDD, эта задача решалась бы точно так же.

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

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

Я думаю, что смысл этих сложных слов ты попросту даже не попытался понять, иначе бы не ставил знак равенства между явной зависимостью между двумя микросервисами (которая действительно нарушает изоляцию) и decoupling через подписку на domain events (в которой микросервис лотерей вообще не интересует, кто и как публикует события о покупках — достаточно знать схему самого события и где на него подписаться).

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

Давай как-то скромнее

Ивенты не подходят, ибо а) их раньше не посылали, и если писать их для тебя — то где автономность (и это integration events)
б) идет речь о покупках за квартал (в прошлом), а лоторею надо запустить через недельку и к событиям прошлого (если они были вообще) доступа нет (если это не общая база — но это уже не шина).

Это к тому, кто и что попытался понять.

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

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

Там еще есть вариант когда между контекстами начинаются взаимоотношения в разрезе иерархии и вложенности, авторизацию можно выделить в интегрирующий слой Shared/Common.

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

Ивенты не подходят, ибо а) их раньше не посылали,

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

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

Здесь вижу, как минимум, два варианта.

Первый — если bounded context покупок написан с использованием event sourcing, то можно при запуске микросервиса лотерей сделать replay всех внутренних событий контекста покупок «от начала времён» и, таким образом, во внешнюю шину будут опубликованы события обо всех прошлых покупках.

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

насколько затруднительным и хрупким является разделение контекстов/микросервисов

Так с этим я и не спорил — задача правильного разделения действительно является очень нетривиальной.

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

Таким образом мы попадаем в мир в котором, якобы изолированный контекст имеет тенденцию к нарастанию в спагетти-монстра

Предложил бы определить, что есть «спагетти-монстр», иначе не совсем понятно, о чём именно спорим.

одно дополнительное предложение в описании таски приводит к изменению границ между сервисами

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

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

Подробности — в студию!

авторизацию можно выделить в интегрирующий слой Shared/Common

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

Первое, как правильно заметили выше, довольно реализуется через сторонний security token service (Keycloak, Okta и иже с ними), второе — детали реализации того микросервиса / контекста, к домену которого эти бизнес-правила относятся.

И это — предметный разговор, а вот это ваше — авторзация ничего не знает о бизнесе, тяп-ляп, эвенты в шине, домен в контексте

Вот вы сами просили скромнее, и сами же снова срываетесь на эмоции...

Нет ничего военного в том, что вы раньше не сталкивались с DDD. Но, мне кажется, тогда было бы корректнее спросить «а как в этом подходе решаются вот такие-то и такие-то задачи», а не опускаться до аргументации «тяп-ляп» и «у теоретиков всё в шоколаде».

Для начала мне кажется в своих размышлениях вы смешиваете DomainEvents с EventSourcingEvents и не различаете EventBus от EventLog.
Шина в общем случае — это канал передачи, а не общее хранилище с безлимитным сроком хранения и богатыми инструментами выборки.
Обеспечить безпроблемную повторную публикации события в шину (через три месяца) вам будет не просто. Ну и мы уже говорим о созависимом деплойменте как минимум.

Только, снова-таки, давайте не путать авторизацию в смысле выдачи определённых прав доступа администратором системы, и бизнес-правила, которые разрешают / запрещают определённые операции на основании предыдущих бизнес-транзакций.

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

Подробности — в студию!

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

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

мне кажется, тогда было бы корректнее

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

Для начала мне кажется в своих размышлениях вы смешиваете DomainEvents с EventSourcingEvents и не различаете EventBus от EventLog.

И, наверное, именно поэтому в предыдущем сообщении я специально обращал внимание на разницу между внутренними событиями контекста (event sourcing events) и публикуемыми во внешнюю шину (domain events)? :)

Делаем replay event sourcing events => получаем в шине повторную публикацию всех нужных domain events.

Обеспечить безпроблемную повторную публикации события в шину (через три месяца) вам будет не просто.

Почему непросто? Для этого же давно придуман такой механизм, как идемпотентность. Или в чём сложность тогда?

мы уже говорим о созависимом деплойменте как минимум.

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

Ни DDD, ни микросервисы не настаивают на горизонтальных отношениях между сервисами/контекстами

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

В частности:

«The reason that calling out to an external BC is discouraged is because it requires for both BCs to be operational at the same time» (а это вдвойне актуально для микросервисной архитектуры)

И вот, собственно, описание решения очень похожей на ваш пример с авторизацией задачи:

«An alternative is to have the Game BC subscribe to events from the User BC and keep local copies of the data it needs, which in this case is information about whether a user is a group leader. In this way, when the Game BC needs to determine whether a user is a group leader, it doesn’t need to call out to the User BC, it just reads locally stored data.» (источник: stackoverflow.com/a/16717369/370209)

в рамках контекста мы обращаемся к платежной системе, мы можем обратится к лоторейной системе — это к вопросу вложенности.

Я не уверен, что именно вы понимаете под вложенностью.

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

Лотерейная система — это составная часть бизнес-логики нашего приложения, находится внутри глубинного слоя business domain и изолирована в своём bounded context. Обращаться к ней напрямую — значит, повышать связность, потому что мы закладываем в систему знание одной её логической части о существовании других логических частей на том же архитектурном слое. А вот именно это — прямая дорога к спагетти-монстру.

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

Так может быть в традиционной N-tier архитектуре, где нет изоляции по бизнес-доменам. И то, практика ИМХО сомнительная, т.к. логика «размазывается» между подсистемой правил и, собственно, слоем бизнес логики. Это ухудшает cohesion и усложняет отладку.

В DDD так не делают, потому что бизнес-правила могут относиться к разным бизнес-доменам, и, соответственно, реализовываться в разных bounded contexts. Объединение всех бизнес-правил в какую-то единую подсистему — это прямое нарушение изоляции между BC.

от людей не отличающих шину от лога

То есть, вариант, что человек прекрасно различает эти понятия, но рассматривает вариант применения Kafka, которая одновременно является и тем и другим — вам в голову не приходит?

Конечно, если по каким-то причинам нецелесообразно использовать Kafka, то можно хранить event log отдельно. Но зачем, если есть удобный комбайн «два в одном»?

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

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

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

В ссылке на стековерфлоу автор ответа прямо замечает:

The challenge of this event-driven alternative is synchronizing the events.

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

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

Three-tier и DDD — не антиподы, контекст вполне может быть реализован как Three-tier.

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

Насколько я понимаю проблематику, то разговор о изоляции без взаимодействия/пересмотра границ — не имеет смысла: на практике контексты взаимодействуют, и их границы перемещаются — никто мнения программиста об этом не спрашивает.

Собственно аббривиатура DDD подразумевает, что рулит предметная область, и структуризация проводится прежде всего исходя из предметной области (понимание которой меняется !).

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

В частном случае можно хранить все, но этот сценарий далек от универсальности, ввиду больших скоростей нарастания объемов хранимых данных (репликация — она не бесплатная)

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

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

По истечении этого срока — ни о какой идемпотентности (это, кстати, свойство) не идет и речи.

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

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

Такое вполне себе случается, и решается версионированием схемы событий.

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

Под платёжной системой я, вероятно, ошибочно понимал какой-то внешний сервис наподобие Stripe.

Если же это что-то внутри системы, то тогда из условий задачи непонятно, почему платёжная система выделена в отдельный bounded context / микросервис, а не является составной частью того же контекста покупок?

Three-tier и DDD — не антиподы, контекст вполне может быть реализован как Three-tier.

Внутри контекста может быть всё, что угодно, в том числе и Three-tier. С этим никто и не спорит.

Я возражаю против попыток натягивания подходов из three-tier на DDD вне рамок отдельно взятого контекста — в первую голову, фильтров доступа на базе бизнес-правил как отдельного слоя, находящегося над bounded contexts. И, ключевое здесь — «на базе бизнес-правил».

то разговор о изоляции без взаимодействия/пересмотра границ — не имеет смысла: на практике контексты взаимодействуют

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

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

и их границы перемещаются

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

структуризация проводится прежде всего исходя из предметной области (понимание которой меняется !).

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

В этом ключе предложения Фаулера про «сначала монолит» — впечатляют, и для контраргументации сторонникам сильной изоляции

Так «сначала монолит» никак не противоречит сильной изоляции. Более того, Фаулер предлагает делать и то, и другое :)

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

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

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

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

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

Такое вполне себе случается, и решается версионированием схемы событий

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

Именно изменение границ может произойти только при очень сильном перекраивании предметной области.

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

да, от DDD будет больше вреда, чем пользы.

На самом деле я сторонник DDD, особенно(!) в динамичных условиях, (и при этом противник EventSourcing в динамичных областях).
Просто я не думаю, что мы научимся дешево двигать границы контекстов, если спрячемся от критики. Есть проблема — ее решения надо искать.

Я возражаю против попыток натягивания подходов из three-tier на DDD вне рамок отдельно взятого контекста

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

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

Самый простой вариант: передавать текущую версию сущности как одно из полей события. Получатель тоже хранит у себя последнюю версию, для которой он получил и обработал изменения. Если версия в событии старее, чем та, которая хранится у получателя — событие отбрасывается как уже ранее обработанное.

tuhrig.de/...​ts-with-revision-numbers

одно предложение в тупом, как двери, случае «перекраивает» предметную область.

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

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

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

Ну, откровенно говоря, ваш пример с лотереей на «новую реальность» не тянет.

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

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

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

Вот, как мне кажется, довольно хороший подход к определению границ контекстов: medium.com/...​rkshop-recipe-1f123e592ab

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

Я собственно попрошу вас уточнить ваши возражения.

Мои возражения базируются на двух очень простых вещах:

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

Ваша идея с дополнительным слоем бизнес-авторизации явно противоречит этому инварианту.

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

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

Ну, откровенно говоря, ваш пример с лотереей на «новую реальность» не тянет.

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

Мои возражения базируются на двух очень простых вещах:

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

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

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

Прошу заметить: хранит read-only копию, причём только тех данных о продажах, которые нужны для принятия решений по запуску лотереи.

Это вполне допускается, и, более того — рекомендуется в DDD подходе.

Можно вместо этого ходить с запросами в API самого сервиса покупок, можно даже сделать shared database table с нужными данными. Но и тот, и другой вариант увеличивают зависимость между лотерейным сервисом и сервисом покупок — в частности, требуют работоспособного состояния API / базы данных сервиса покупок всякий раз, когда нужно принять решение о запуске лотереи. И если в монолите это не такое уж и большое зло, если он в обозримом будущем продолжит оставаться монолитом — то в микросервисной архитектуре зависимость одного микросервиса от работоспособности другого — это прямой путь к гораздо большему злу под названием «распределённый монолит».

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

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

Вот назначение ролей пользователям и отзыв прав — это отдельный контекст, да. Остальные контексты узнают о том, у кого какие права через информацию, помещённую в security token.

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

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

Как правило, для сводной отчётности делается отдельный контекст, который использует подходящее для эффективного построения отчётов хранилище данных (например, OLAP куб или колоночная БД). А вот данные из других контекстов могут попадать в это хранилище разными способами, и через доменные события в шине в том числе.

Всё, опять же, зависит, насколько мы хотим достигнуть инфраструктурной независимости между контекстами. Если это монолит, то, наверное, можно относительно безопасно использовать специальные read-only views, которые являются составной частью публичного контракта каждого контекста, и информация из которых регулярно собирается в общее хранилище для отчётности.

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

А вот данные из других контекстов могут попадать в это хранилище разными способами

Можно список разных способов?

И что делать с изменениями схем сообщений/таблиц?

Собственно, у вас выходит, что если DDD приложение не музейная редкость без сквозной отчетности, то должен существовать некоторый отчетный контекст, в который «разными способами» попадает вся(!) информация, которая некоторым волшебным способом всегда именно в формате, понятном движку отчетности, вне зависимостти от того, что там мутят разработчики в отдельном контексте? Я все верно прочитал?

Можно список разных способов?

Шина, запрос через публичный API контекста, запрос через shared database view.

И что делать с изменениями схем сообщений/таблиц?

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

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

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

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

Этот волшебный способ называется публичными контрактами.

Вопрос был про что делать с изменениями схем.

Вот решил я изменить схему «специального database view» — каким боком мне знать, кто его читает (кроме всевидящей отчетности), и что они готовы к изменениям? Не деплоить пока не написали новый импорт/обработчик в отчетный контекст?

Кстати, поздравляю — у вас появился общий контекст, который всегда обновляют при изменениях схем/API.

По факту у вас теперь распределенный монолит.

Вот решил я изменить схему «специального database view» — каким боком мне знать, кто его читает (кроме всевидящей отчетности), и что они готовы к изменениям?

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

Не деплоить пока не написали новый импорт/обработчик в отчетный контекст?

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

B — backwards compatibility.

Собственно, тот же подход, что и с версионированием API.

Кстати, поздравляю — у вас появился общий контекст, который всегда обновляют при изменениях схем/API.

Почему же всегда? Если старой версии схем/API вполне хватает для продолжения нормальной работы этого «общего контекста» — он спокойно продолжает работать себе дальше.

Причиной обновления этого «общего контекста» могут быть новые требования к отчётности, для удовлетворения которых потребуются данные, которые есть только в новой версии схем/API.

Ага, так называемые микромонолиты

или Нетфликс

А че нетфликс ? Там самое главное это CDN все остальное похер совсем, пиши хоть монолитом хоть сервисами. Ну да разумно вынести поиск, или там рекомендейшн енджин в отдельные аппы, но это не зделает их микросервисами. Но конеш можно заморочиться и иметь 100500 микросервисов, и ад деплоймента.

в Нетфликсе сотни (если не тысячи) микросервисов и чет ада нет

важно не количество инстансов, а количество их типов.
а так хоть на всех датацентрах мира крутится — 1 тип инстанса.
и что?

спасибо, кеп. Я не о инстансах.

в Нетфликсе сотни (если не тысячи) микросервисов и чет ада нет

Потому что подситемы там почти никак не связанны друг с другом.

ох... Я реально уже устал слушать как Нетфликс работает внутри....

Я бы посмотрел бы с удовольствием на того, кто написал бы монолитом Гугл или Нетфликс или Фейсбук какой-нить.

ти не гугл. і не нетфлікс. і швидш за все ніколи навіть не наблизишся до їх масштабів.

так само як і більшість з тутешніх.

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

Именно. Людям хочется нового и модного настолько, что анализа плюсов и минусов никто не делает. Имхо, микросервисы — это для больших проектов с несколькими командами. А не в 1-2 программиста десяток микросервисов лепить.

Иногда имеет место делить на сервисы имея 1-2 программистов, правда обычно это будут не микросервисы а обычные сервисы

Даже с 1-2 программистами вполне может иметь смысл лепить десяток микросервисов. Уметь писать и поддерживать монолиты не такой простой скилл, если этому монолиту не первый год. А в реальных условиях когда постоянно накапливается технический долг, микросервисы помогают как минимум не сваливать весь этот долг в одну кучу, и разгребать по мере важности. Условно говоря рефакторинг куска монолита зачастую требует полного регрешена, а рефакторинг микросервиса, если не менялся внешний интерфейс, то только функционала самого микросервиса.
Покажите мне хоть одного человека, который за всю карьеру при работе с монолитами не имел класса helper с парой тысяч срок и сотней статических методов, часть из которых делает одно и то же? :)

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

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

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

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

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

а ты точно архитект? Хотя да, мы ж на доу...

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

конечно нет. Но я и не об этом. Я о

никогда не получится поменять только один сервис

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

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

а если архитектор пришел на проект, которому несколько лет? или так не бывает?

А если метиорит упал на землю? То есть не будем использовать что-то, потому что может прийти новый архитект через 5 лет на проект?

ты в порядке?

-архитект должен следить за архитектурой
-а если проект стартовал без него?
-а если метеорит?

там написано «никогда» а не «в случае если кто-то запилил архитектуру неправильно»

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

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

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

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

Неумение использовать инструмент это не минус инструмента...

опасные бритвы — для профи
безопасные для ремесленников и неумех

Аккуратным водителям не нужны ни знаки, ни светофоры!
Настоящим пилотам не нужны автопилоты!

Опасность бритвы, перекрестки без светофоров, самолеты без автопилотов — не минус инструмента!

это не рефакторинг.

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

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

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

Неумение использовать инструмент это не минус инструмента...

ты вообще о чём?

Да, я знаю только в теории, ты прав :-D :)

а ти що, інтерфейси рефакториш?

Ну архитекты именно этим же и занимаются, разве нет?

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

є редизайн, а є рефакторинг,
моя думка, що якщо змінювати public АРІ, то це вже редизайн

я же написал что машинально использовал не подходящее слово...

Для этого существуют определённые принципы построения API, следуя которым не будет таких проблем.

Можно начать c вот этой, главы 5 и 6 :)
www.ca.com/...​practices-and-culture.pdf

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

походу рефакторинг это и есть «подкрутить только внутренности для красоты» и соотв. то что ты обписываешь это как бы б не совсем «рефакторинг» от слова вообще ))

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

«Нельзя создать систему проще ее функционала»
Сложнее да, можно. Но проще — никак.

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

к менее болезненному рефакторингу

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

а значит к легче поддерживаемому коду

а системы в целом?

более простой пример, в вебщине:
есть старый способ — генерируем html на сервере. Монолит?
и SPA — пишем отдельно бек и фронт, а их взаимодействие по API

какой способ дешевле? какой подход — быстрее в разработке?
а почему?

Разрабатывать «взаимодействие по API» — дороже, дольше, чем вот у нас интерфейс в ЯП, вот классы которые его реализовывают
И писать, а главное читать код, который статичен, который по клику в IDE еще и связан, гораздо быстрее, чем по спецификациям врубаться в порядок «взаимодействия по API».

И, если «абстракции текут» при разработке обычного «монолита», то разве они не текут при разработке системы основанной на микросервисных компонентах?

Мало того
Вот есть два сервиса на разных ЯП
API то они должны поддерживать одинаковый?
значит у нас есть две библиотеки для поддержки этого API
и если его надо изменить — то надо изменить обе.
А если подможество этого API должен поддерживать еще и третий сервис, на третьем ЯП?
вот вам еще и третий вариант реализации того же API.

Итого, меняем спеку, менять нужно три библиотеки.
Это дешевле обычного рефакторинга в «монолите»?

более простой пример, в вебщине:
есть старый способ — генерируем html на сервере. Монолит?
и SPA — пишем отдельно бек и фронт, а их взаимодействие по API

какой способ дешевле? какой подход — быстрее в разработке?
а почему?

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

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

И дешевле/быстрее сильно зависит от задачи.

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

а вот когда начинают более сложную технологию предлагать как «упрощение» — вот оно лукавство.

микросервис писать проще чем монолит!
ну да, «модуль» написать проще чем систему состоящую из модулей :)
даешь холивар — «модульная компоновка» vs монолит!

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

я про логику обмана:
микросервисы круче монолита, потому что один микросервИС писать проще одного монолита
2 микросервиса проще писать чем 1 монолит
3 микросервиса проще писать чем 1 монолит
...
пока они там пишут 1 монолит, мы уже 10 микросервисов написали!

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

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

Вы точно уверены в этом?

а вот когда начинают более сложную технологию предлагать как «упрощение» — вот оно лукавство.

Ишь чего придумали, изуверы! Монолит навсегда в моем сердце сидит!

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

любую хорошую идею можно плохо реализовать.

Вы точно уверены в этом?

Вы точно хотите поговорить об истории развития технологий программирования?

любую хорошую идею можно плохо реализовать.

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

Вы точно хотите поговорить об истории развития технологий программирования?

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

этот тезис — классика демагогии:

Потому что если микросервисы пишутся из понимания что это та же самая «модульная компоновка» только с модным названием, то и получается плохая реализация хорошей идеи

Какие новые или «более сложные» задачи решали технологии NoSQL

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

«старая технология» — реляционная БД, требует проектирования перед написанием системы.
NoSQL позволяет отложить это проектирование на потом, по мере необходимости.

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

NoSQL вернулись в силу развития интернета, когда возникла необходимость писать системы без проектирования структур данных, либо в силу того что структуры данных будут изменяться непредсказуемо, либо просто ради скорости выпуска — сырого, MVP, продукта

Потому что если микросервисы пишутся из понимания что это та же самая «модульная компоновка» только с модным названием

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

хранение и выборка данных с сложной структурой,

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

Причем, до реляционных систем такие уже были

Как бы из своего названия следует что они появились после того как были SQL-базы данных. Ну конечно были другие технологии неструктурированного хранения данных, файловая система, например. Только при чем тут noSQL?

А до этого их не хранили?

хранили.
просто потребителей таких данных был мизер

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

я уже написал какие именно, и почему :)

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

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

Как бы из своего названия следует что они появились после того как были SQL-базы данных.

Как бы каждый сезон мода одежды предлагает нечто новое, чего не было у модниц ранее :)

Как бы из своего названия следует что они появились после того как были SQL-базы данных.

Вообще-то было минимум два класса систем хранения:
сетевые и иерархические

я писал на дореляционной БД. и мне как-то неважна культулогическая история термина «NoSQL»

Только при чем тут noSQL?

при том что все новое — это хорошо забытое старое.

как недавно в паузе между докладами мне молодой человек возразил, на мое:
— я говорю на основании своего опыта..
— а опыт неважен!

вот это аргументище!
а вы мне — "

Как бы из своего названия следует что они

"
ну да, аргумент силы
Если Бога не существует то почему вампиры боятся распятья?

все же
— а опыт неважен!
поубойней будет :)

просто потребителей таких данных был мизер

Типа компьютеров меньше было, или каких потребителей вы имеете в виду?
Есть например задача — хранить картографические навигационные данные. Эта задача гораздо легче решается «новыми технологиями», чем старыми. Не задачи новые или более сложные, а технологии новые предлагают более простое решение. Быстрее разрабатываемое, менее требовательное к ресурсам, легче масштабируемое. И таких примеров в той самой истории развития программистских технологий можно вспомнить тысячи.
Микросервисы решают проблемы эффективной масштабируемости больших систем, распределённых систем, и да, в случае больших команд они решают обычные задачи, с которыми сталкиваются те же самые команды с монолитной архитектурой — сильная связанность, взаимозависимость модулей, сложность покрытиям тестами и их долгое выполнение, частота мерджей и связанных с этим конфликтов, сложность использования наиболее эффективных технологий для решения задач, уменьшают время даунтайма как при деплоях, так и при проблемах.
Но даже с одной небольшой командой тоже не всегда, но часто есть смысл использовать микросервисную архитектуру. Зависит от того какие проблемы решает продукт, какие к нему требования и из кого состоит команда

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

Носиквел вполне использовали задолго до того как появилось это слово.

Можете расскрыть мысль, что конкретно, какие технологии вы имеете в виду?

Хорошо, давайте так, идем на сайт движения nosql-database.org и читаем:

NOSQL DEFINITION: Next Generation Databases mostly addressing some of the points: being non-relational, distributed, open-source and horizontally scalable.
Next Generation Databases

Что как бы намекает.

Хорошо, давайте так, идем на сайт движения nosql-database.org и читаем:

Какойто очередной говносайт.

Идем на википедию

https://en.wikipedia.org/wiki/NoSQL

и читаем

Such databases have existed since the late 1960s, but did not obtain the „NoSQL” moniker until a surge of popularity in the early 21st century, triggered by the needs of Web 2.0 companies.

Что как бы намекает.

Next Generation Databases

Объективно, вся новизна — это «distributed» и «horizontally scalable».
Что действительно является необходимым свойством для решения задач масштаба Netflix, Facebook или Google Analytics.

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

Проблема в том, что, также как и микросервисы, SPA настолько разрекламировали, хайпу навели. Что почти любой новый проект — это только спа, только хардкор, альтернативы даже не рассматривают.

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

Это что ещё за закон сохранения связанности такой? Связанность кода ортогональна сложности системы.

более простой пример, в вебщине:
есть старый способ — генерируем html на сервере. Монолит?
и SPA — пишем отдельно бек и фронт, а их взаимодействие по API
какой способ дешевле? какой подход — быстрее в разработке?
а почему?

А у вас есть конкретный ответ на такой вопрос?

И писать, а главное читать код, который статичен, который по клику в IDE еще и связан, гораздо быстрее, чем по спецификациям врубаться в порядок «взаимодействия по API»

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

API то они должны поддерживать одинаковый?
значит у нас есть две библиотеки для поддержки этого API
и если его надо изменить — то надо изменить обе.
А если подможество этого API должен поддерживать еще и третий сервис, на третьем ЯП?
вот вам еще и третий вариант реализации того же API.

Что ещё за библиотеки для поддержки API? Мы про какой API говорим, не Win32 случаем? 🤷🏻‍♂️

Это что ещё за закон сохранения связанности такой?

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

Связанность кода ортогональна сложности системы.

Уменьшение связности происходит за счет увеличения количества кода.
Потому что надо вводить абстракции. а их введение должно быть описано — все тем же программным кодом. (или конфигами, аннотациями, или еще каким мета описанием)

Каким же «чудом» — мы уменьшаем связность, но без увеличения количества кода, или количества абстракций?

А у вас есть конкретный ответ на такой вопрос?

А вы можете высказываться без вопросительного знака на конце?

Что ещё за библиотеки для поддержки API?

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

Мы про какой API говорим

википедия:
API (программный интерфейс приложения, интерфейс прикладного программирования) (англ. application programming interface, API [эй-пи-ай][1]) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой.
API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

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

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

сюрприз-сюрприз но да

итого, если 10 ти сервисам нужно обратится к 1му
будем иметь 11 реализаций :)

Потому что каждый микросервис — отдельная независимая единица с одним единственным контрактом,

понимаете, хайпу вокруг микросервисов не один год
как и этой байке.
давайте посвежее что-то :)

который она обязуется исполнять — спека.

если есть спека на контракт модуля, класса — то в чем же разница при реализации «монолита»?
и чем проще контролировать 11 реализаций на соответствие спеке, чем 1ну реализацию?
как так получается, что 11 это меньше чем 1?

Каждая команда сама решает как реализовать спеку. Но обычно есть какие-то рекомендации и команды приходят к каким-то общим решениям. Также очень часто авторы микросервисов пишут под них еще и клиенты на нескольких языках (вручную или генерятся они, тот же gRPC умеет это, например. Под рест тоже плагины есть. И тп), тогда команда-пользователь микросервиса просто берет библиотеку-клиент и использует и пофик что там внутри по версиям, апи, протоколу и тп.

Зачем? потому что есть задачи, нерешаемые монолитом в принципе.
Цитирую себя же

ну да, пусть делает 100 бизнес-задач. Потом когда только одна начнет тормозить, мы просто побольше инстансов добавим. И не важно что 99 других задач прекрасно и на меньшем кол-ве инстансов работали, пусть простаивают ресурсы. У нас же инстансы бесплатные, память бесплатная.
Ну и неважно что у нас на каждой команде всего несколько бизнес-задач. Мы их все 100 запихнем в один монолит. Ну и что что деплоймент и мердж в ад превращается. Неважно что тесты часами проходят (задач то мы 100 запихали туда).
Ах, вы хотите деливерить в прод несколько раз в день? Ах, у вас пейджер звенит что на проде баг и надо срочно обновить версию? Ну извините, у нас 100 бизнес-задач запихано в один монолит и вон тот тест, что тестирует 57-ю, он сломался. Ну да, мы ждали 3 часа пока тесты все пройдут и он сломался.
Ах кто-то из другой команды запилил изменение в мастер а надо срочно в прод выкатить? Ну можно отбранчеваться от последней стабильной версии, накатить фикс и в прод... Ой, а другая команда свою фичу делала и теперь им надо ребейс сделать а он ругается на конфликты... Жаль. Ну это пофик, главное что не дадим микросервисам и шанса!

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

так в чем ноу-хау?

я процитировал свое сообщение. Жду решение проблемы монолитом.

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

но хайп вокруг микросервисов построен на «обмане», что есть и другие преимущества, даже если у вас нет ни первой потребности, ни второй ситуации.
о том и написал.
перечитайте и вы :)

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

то есть есть места где без микросервисов никак
Так а в чем тогда спор со мной?

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

там где нет альтернативы — ее нет.

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

и с ростом и усложнением их бизнеса и дописывались — «сервисы».
и еще, и еще.

Никакой Безос, открывая свой интернет-магазин в 1994ом — не сзывал умнейших программистов планеты, и те ему не советовали: знаете, вам нужен NoSQL, микросервисы, и т.п. Монолиты вашему бизнесу не подходят!

И никакой Безос, Цукерберг, Брин не нанимал сразу сотни команд для разработки.

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

Кроме Гуглов с Амазонами и Фейсбуками есть кучи компаний с проблемами, решаемыми только микросервисами.

И почему-то эти «проблемы» внезапно появились вместе с хайпом про микросервисы, да? :)

А до того, как микросервисы стали трендом — этих компаний не существовало? Или они, всё же, решали те же проблемы каким-то другим способом? ;)

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

новое ради нового — признак юного программиста :)

если внимательно следить за проектами, то часто можно встретить подобное от опытных:
Я по-прежнему рекомендую стартапам избегать новых причудливых штук — постарайтесь просто использовать MySQL. Доверьтесь мне.
Marty Weiner | Pinterest engineer, BlackOps

Pinterest — это поисковый движок для всего, что вам интересно. С точки зрения данных, Pinterest является крупнейшим графом человеческих интересов во всем мире. Он содержит более 50 миллиардов пинов, которые были сохранены пользователями на более чем миллиард досок. Люди сохраняют одни пины себе и ставят лайки другим пинам, подписываются на других пиннеров, доски и интересы, просматривают домашнюю ленту всех пиннеров, досок и интересов, на которые они подписаны.
Шардинг Pinterest: Как мы масштабировали наш парк MySQL

ведь раньше кодили на перфокартах

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

незачем пересаживаться на более старое железо :)

так и надо продолжать

надо думать головой, а не приходить в восторг от хайпа.

масштабировать mysql — то еще веселье, и для шустрого text search со стемингом и прочими — часто не очень.

но таки ты прав — для 90% популярных задач его более чем достаточно, особенно если брать во внимание что многие не могут в документно ориентированные БД, пытаются натягивать реляционную модель на монго (и ему подобные) — что как бы не работает

вообще, лучше всего работать в своем стеке, и понимать что в него не вписывается

масштабировать mysql — то еще веселье, и для шустрого text search со стемингом и прочими — часто не очень.

Кто мешает использовать CQRS и отдельную read model для полнотекстового поиска, хранящуюся в каком-нибудь Elasticsearch?

И, следите за руками — это всё ещё старый добрый монолит.

А где я хоть словом о базе данных говорил? Зачем мне тут ссылки на MySQL? Я сам считаю что sql-базы достаточно в подавляющем большинстве случаев и люди прикручивают всякие кассандры с монгами только чтоб прикрутить.

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

...Уметь писать и поддерживать не такой простой скилл :) Вот иллюстрация к тому что вы написали dou.ua/...​rums/topic/28384/#1673541

Условно говоря рефакторинг куска монолита зачастую требует полного регрешена, а рефакторинг микросервиса, если не менялся внешний интерфейс, то только функционала самого микросервиса.

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

Вот иллюстрация к тому что вы написали dou.ua/...​rums/topic/28384/#1673541

Ага, на форуме все такие безгрешные. Как будто я в украинском (и не только) айти не работал и не знаю как большинство проектов выглядит :)

Вот вам пример изменения функционала:

А каким образом монолит защитит от такого?

А каким образом монолит защитит от такого?

Никак :) Это всего лишь демонтрация неверности вашего утверждения о более простом тестировании микросервисов.

Возможно оно не всегда верно. Но практика с микросервисами точно отличается от практики с монолитами.

Это не рефакторинг а изменения апи, о которых уже писали.

Условно говоря рефакторинг куска монолита зачастую требует полного регрешена, а рефакторинг микросервиса, если не менялся внешний интерфейс, то только функционала самого микросервиса.

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

Уметь писать и поддерживать монолиты не такой простой скилл, если этому монолиту не первый год.

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

Условно говоря рефакторинг куска монолита зачастую требует полного регрешена, а рефакторинг микросервиса, если не менялся внешний интерфейс, то только функционала самого микросервиса.

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

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

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

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

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

Мало того, когда бизнес логика размыта тонким слоем по кодбазе

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

Уметь писать и поддерживать 100500 микросервисов если им не первый год,

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

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

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

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

Ну действительно, как же без хелпера жить? :))

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

Мне чет кажеться что учасники данной дискусии сравнивают «старый, овно мамонта монолит, написанный в прошлом столетии на миллионы строк коду» с новым небольшим проектом на сотню микросервисов.

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

Холивар начинается уже на попытке определить правильное использование.

Коментар порушує правила спільноти і видалений модераторами.

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

Microservices это просто идея. Такая же самая идея как и agile. Здесь ни о чем разговаривать потому что понятие о microservices разные у каждой компании. Есть даже те которые этим практикуется но они это называют это так.

Некоторые из нас уже практиковались такой архитектурой ещё до того как все начали называть это microservices.

Некоторые из нас уже практиковались такой архитектурой ещё до того как все начали называть это microservices

Service-Oriented Architecture предыдущая волна называлась вроде.

просто ти недоріс
п.с.
ааа, тримайте наркомана, п"ятниця!

спокойно, шабат вже давно))

Если вам надо делать 2РС для согласования данных между микросервисами и репликацию, значит у вас дублируются таблички. Не надо так делать. Про каждую отдельно взятую табличку должен знать только один сервис и выставлять API для других сервисов. А вообще я за то, чтобы что-то выносимое в микросервис было максимально stateless.

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

Не только. Типичная проблема в жалании иметь strong consistency и не желании/не готовности работать с eventual consistency.
Простой пример:
Есть сервис который работает с заказами и второй который обрабатывает балансы пользователей. Дублирования «табличек» нет, но бизнес не готов видеть необновленные балансы по закрытым ордерам.

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

Но тут главное, откуда потребность в консистенси берется?

Из требований бизнеса: надо чтобы все цифирки на всех страничках были консистентные :)
Фишка в том что такое требование может прийти ни как фича, а как баг в уже продакшн систему.
Я не пытаюсь защищать тот или иной подход, просто привел пример появления 2РС без дублирования табличек.

Между стронг и евентуалии куча промежуточных вариантов.

Можете привести примеры? Я сходу не могу придумать ни одного.

Из требований бизнеса: надо чтобы все цифирки на всех страничках были консистентные :)

не показывайте не те странички! :)

Бізнес значить ще не доріс до реального життя :)

Напевне в них ще не було анулювання ануляції гарантійного документа, бо «ми документ анулювали, а вагони вже поїхали».

В складських системах є таке священнодіяння, як інвентаризація, що виводить на світ божий усушку, утруску та інші гріхи.

Чим довше живу, тим більше приходжу до думки, що аналітичні системи треба проектувати як системи реального часу — баланс має зійтися не пізніше певної дати, але нікого не цікавить, щоб баланс був привильний після кожної операції.

А якщо не зійшовся — або списати (залізо/бюджет витягне), або скомпенсувати (з прибутку/резервного рахунку/резервного заліза тощо)

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

А зачем нужно разделять на отдельные сервисы (т.е., независимые проекты) два куска логики и данных, которые жёстко связаны между собой (заказ и баланс)? Почему нельзя сделать это единой транзакцией в одном месте?
Если из-за нагрузки: ок, тогда 2РС может понадобиться так и так, и это вопрос не о микросервисах вообще. И кроме того, если реально нужно strong consistency, то в любом случае это придётся делать синхронно и ждать, пока всё везде обновится.
Если же из-за горячего желания всё распилить на сервисы любой ценой... Ну хз тогда, моча в голове, медицина бессильна.

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

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

И кроме того, если реально нужно strong consistency, то в любом случае это придётся делать синхронно и ждать, пока всё везде обновится.
Фишка в том что такое требование может прийти ни как фича, а как баг в уже продакшн систему.

Повторяю:

Я не пытаюсь защищать тот или иной подход, просто привел пример появления 2РС без дублирования табличек.

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

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

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

И все севрисы будут обращаться к одному, и будет тот-же bottleneck что и в случае с общей базой. А если этот сервис упал или обновляется, вся система встанет колом и путь весь мир подождет.

Коментар порушує правила спільноти і видалений модераторами.

Отличная мысль! Зло должно быть микросервисом.

Сага не обеспечивает реальной консистентности и согласованности в данных, это просто дурня

Сагочка если тебе на нгавится, сними Хатиму, она таки опытнее

микросервисы — модная фишка потому их ми суют куда попало. особенно те кто не понимает
что кроме микросервисов и монолитов есть еще такое понятие как модульная архитектура.

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

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

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

Микросервисы зло и монолит зло. OSGI вообще п..ц, ejb 1-2 сделано для более удобного жертвоприношения сатане. А все потому что нашим миром правит князь тьмы (

Зато ща в моде серверлесс архитектура!

Практикуешь серверлес архитектуру — регулярно поклоняешься Вельзувулу!

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

Амазон — зло (и местами работает как овно). И статьи — проплаченые.

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

Мир шире перечисленных кейсов.

мы писали набор REST — приложений, устанавливаемых под OSGi

Чур тебя, чур, три раза перекреститься. Оно умерло и слава богу.

1) Микросервисы очень плохо реализуют транзакционность.

Точно так же на ферари очень плохо мешки с картошкой перевозить.

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

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

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

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

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

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

На Golang не пишу, справка о психическом здоровье есть :)

Но, таки да — shared nothing, иначе теряется одно из основных преимуществ микросервисов: независимое масштабирование.

>

На Golang не пишу, справка о психическом здоровье есть :)

Но, таки да — shared nothing, иначе теряется одно из основных преимуществ микросервисов: независимое масштабирование.

А потом борд/заказчик смотрит на счет, который придет за 40+ RDS инстансов и думает, а нужен ли такой CTO))

Так может там и не нужны были микросервисы, если денег не хватает?

Но, таки да — shared nothing, иначе теряется одно из основных преимуществ микросервисов: независимое масштабирование.

Проблема всех этих дискусий в том, что народ который «продает»

независимое масштабирование

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

OSGi
чур, три раза перекреститься.

OSGi was a fairly good piece of technology and was important to help develop modular applications in
Java

www.quora.com/...​adoption-of-microservices

Оно умерло и слава богу.

де почитать некролог?

Ну ок, ктото гдето еще использует. Но найти новый проэкт — надо постараться. Аминь.

і на чому нові: на 9й жабі і JPMS, чи на Go/Rust?
ах да, мабуть на С++17

Когда-то сервера были большими, а программы — маленькими. Тогда придумали теорему CAP и реляционные СУБД. И все это прекрасно работало когда в подвале офиса компании стоял один сервер с данными и все работали только с ним.
НО только совсем тупой человек может не понимать что в глобальном интернете теорема CAP теряет смысл! Невозможно иметь одну всегда достоверную копию данных. Невозможно залочить весь мир что бы поменять ее без конфликтов. Два пользователя в разных полушариях не могут получит одновременно новую версию данных.
Пора смириться с тем, что каждый пользователь и каждый сервис работает со своей копией данных. Актуальных для него на данный момент. А в следующий момент в сети возникает сотня новых версий этой записи — и это неизбежно.
Забудьте про транзакции — невозможно остановить время и невозможно «откатить» ни одного мгновения. Что сделано — то сделано. Можно только разруливать коллизии или компенсировать ошибки.
Монолиты были когда программы были маленькими! Человек физически не способен уместить в голове даже не слишком сложные структуры. Схемы современных процессоров разрабатывают исключительно компьютеры. Человек даже не способен охватить взглядом все эти миллионы транзисторов если даже ему нарисовать их на чертеже размером с футбольное поле. А все это помещается в кристалл — «монолит» размером с кулак!
Что происходит если этот «монолит» дает сбой? Правильно — можно только выбросить и заменить целиком! Подпаять не получится.
По сравнению с компьютером — человек как ребенок — даун, которому все нужно объяснять на пальцах. Или на кубиках. При этом кубики должны быть максимально простыми!
И ИТ тут просто идет по пути, который давно прошла инженерная мысль. В любых машинах есть узлы и агрегаты. В любом приборе есть платы с типовыми элементами. Все собирается из стандартизированных компонентов. Никто не берет монолитную глыбу металла что бы напильниками выточить из нее паровоз!
Я не буду даже писать про микросервисы — это настолько частный случай! До них были модули, были COM, были Beans, было SOA ... все это об одном и том же: «съесть слона по частям»!
Я напомню о другом — о древнем принципе ООП, который многие знают, но не многие задумываются что он значит. open closed principle — задумайтесь что он говорит?
А он говорит что раз написанный код нельзя менять! Написал, протестировал со всех сторон — это твой «кирпичик». Твой транзистор, твой болтик. Поломался? Работает не так? НЕЛЬЗЯ ЧИНИТЬ!
Нужно выбросить и заменить на новый! Именно так это работает в реальной жизни.
И только в ИТ пытаются до последнего удержать покосившийся монолит с помощью заплаток, костылей и подпорок.

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

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

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

А он говорит что раз написанный код нельзя менять! Написал, протестировал со всех сторон — это твой «кирпичик». Твой транзистор, твой болтик. Поломался? Работает не так? НЕЛЬЗЯ ЧИНИТЬ!

Че ты там обкурился ?

о древнем принципе ООП, который многие знают, но не многие задумываются что он значит. open closed principle — задумайтесь что он говорит?

open closed principle — це не про ООП, решту двачую

А чем отличается микросервис от просто сервиса?

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

моноліт — гімно
мікросервіси — гімно
serverless — гімно
soa — гімно

Увидеть цвет кишок гопника — бесценно. /Кожаев/

Серьёзный минус у микросервисов только один — нужны скилловый девопс и архитектор (не энтерпрайз солюшнс звездобол, а понимающий в инфраструктуре и проектировании DSL).

Для небольших галер этот недостаток может стать фатальным.

проектировании DSL

Вот это поворот! С этого места поподробнее.

Пробывал машину «Мерседес», все хорошо, вот только пепельница забивается быстро, приходится новую машину покупать.... фигня.

У микросервисного подхода есть одна неочевидная, но важная проблема — он требует более высокой квалификации разработчиков и (даже в большей мере) архитекторов. Что очень часто не учитывается — и в результате в попытке решения N каких-либо проблем с помощью перехода на M микросервисов, получается M*N проблем, просто в чуть меньшем масштабе каждая

неа, микросервисы хорошая штука, диплоймент продакшина на ходу чего стоит :)

Уважаемые айтишники!

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

На данный момент, особенно прочитав статью Фаулера про микросервисы, и обобщив свои наблюдения, я могу назвать следующие недостатки монолитов:

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

2) Плохая работа согласованностью данных между доменами. Если домены разные, а сущности используются для разных целей то необхимо писать врапперы либо использовать schema-less EAV модель.

3) Слишком высокий уровень концентрации логики затрудняет работы разработчиков.

Приглашаю всех делиться своими наблюдениями по поводу микросервисов!

А по сути

Поговорил с копипастой — день прожит не зря!

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

Не факт, в случае некоторых сервисов основным стоппером может быть CPU/GPU. Например, надо распознать некоторое изображение/видео.

1) Вопреки распространенному заблуждению, транзакции не предотвращают одним своим присутствием Race Conditions по волшебству — так что из коробки дают они не так много. В то-же время никто не отменял примету, что границы транзакционной целостности — это и есть границы сервиса. Так что совсем отказываться от транзакций не обязательно. Особенно если позволить сервису владение более чем одной таблицей.

2) Границы сервисов можно рефакторить.

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

учитесь практическому програмированию а не чтению теоретиков

дякую дядь без тебе не розібралися б ))))

а пишут книги о том как надо программировать — за это платят намного больше

так треб книжки вчитися писати щоб гроші заробляти а не програмувати за копійки ))))

Проблема микросервисов в том, что тяжело определится с ответами на два вопроса,
а) микро — это сколько?
б) сервис — это что?

1) Кроме производительности, есть проблемы с эволюцией схемы — она склонна эволюционировать по принципу спагетти, давайте на чистоту, хомо сапиенс ’анализирующий’ схему из 100 таблиц — это рецепт катастрофы.

2) Согласование между доменами вообще центральная проблема этого всего. Примечание

EAV модель

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

3) Не уверен, что вы называете концентрацией логики. Но отсутствие видимых границ и присутствие кода из других контекстов затрудняет понимание.

Существенным вызовом нахожу разбиение монолита на несколько хранилищ, в условиях наличия "сквозных’ сущностей (например пользователь или заказ) участвующих во многих подсистемах. В некоторой степени EAV модель можно имитировать, в том же смысле как можно имитировать разделенные базы неймспейсингом таблиц.

Применять термин микросервис в условиях разделяемой базы — затруднительно (бесполезно?).

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

1) Микросервисы очень плохо реализуют транзакционность. Если используются несколько баз данных, то надо использовать 2PC протокол. Он не рекомендован к применению в микросервисах, вместо него рекомендуют паттерн Сага. Но Сага не обеспечивает реальной консистентности и согласованности в данных, это просто дурня. Поэтому для приложений, где требуется корректность, микросервисы уже подходят плохо.
2) Плохая работа с согласованностью данных между базами данных. Если базы данных разные, необходимо использовать либо событийную модель, либо какие — то механизмы репликации данных в базах.

Упомянутая saga делает несколько фаз на уровне коммуникаций между сервисами, при грамотной реализации проблемы в его использовании не слишком отличаются от проблем 2PC (в котором нужен менеджер транзакций для того, чтобы установить глобальное состояние prepared транзакций, которые почему-то не завершились), в случае микросервисов необходим будет cleanup, если процесс обмена сообщений не дошел до конца.

При желании объединить несколько баз данных в современных СУБД не так уж и трудно, от логической репликации нужных таблиц до внешних данных с помощью SQL/MED, когда данные в СУБД таблице являются не локальными, а берутся из таблицы в другой СУБД, не обязательно такого же типа (например, PostgreSQL может читать данных из ClickHouse).

И если не быть фанатиком, то microservices don’t imply micro-databases. Единицей хранения данных микросервиса может быть не база данных, а схема или таблица, с возможностью контроля согласованности на уровне СУБД.

Если нет пересечений по таблицам, то отлаживать не так уж и сложно — либо дамп части строк нужных таблиц с production, либо вообще mock СУБД. Если есть — то это не здорово, сочувствую.

Та saga, которая описана на microservices.io/patterns/data/saga.html, опирается на локальные транзакции в СУБД отдельных сервисов и коммуникацию между ними для реализации распределенного изменения состояния нескольких сервисов. Это по-сути не слишком отличается от 2PC, которое также реализуется отдельными локальными транзакциями. 2PC, например, не дает гарантии Atomic на всем множестве вовлеченных баз данных, так как commit prepared может пройти на одном сервере и не дойти до другого. Я выше как раз про это писал, что 2PC требует отдельного менеджера транзакций для того, чтобы знать состояние глобальной транзакции на тех серверах, к которым не дошел commit/rollback prepared.

Disclaimer: я про транзакции и СУБД знаю значительно больше, чем про шаблоны микросервисов, так что возможно я неправильно понял идею saga.

может вообще не быть базы. database-less архитектура

Я с микросервисами в каком — то смысле столкнулся еще в 2011 году, когда мы писали набор REST — приложений, устанавливаемых под OSGi — контейнер Apache Karaf.

А с EJB не работали? Это же тоже «микросервисы в каком-то смысле» :)

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

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

3) Слишком высокий уровень дробления приложений

Вот тут проблама № два: Почему-то думают что если куски деплоймента маленькие, то мы получим __микро__сервисы.

---

Чтобы микросервисы работали нормально нужно чтобы они были разбиты по домену/назначения. Но тогда __для многих проектов__ получится целесообразно иметь 1-5 «микросервисов», а это не круто.

Ну а по домену можно и монолит дробить.

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

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

масштабирования отдельных сервисов. И тут оказывается что с микросервисами это делать проще и более естественно чем с монолитом.

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

Чтобы микросервисы работали нормально нужно чтобы они были разбиты по домену/назначения. Но тогда __для многих проектов__ получится целесообразно иметь 1-5 «микросервисов», а это не круто.

Неистово плюсую.

а еще до Java были COM(+) и CORBA . ничего нового в этом мире, микросервис это всего лишь новое название для модульной архитектуры ПО

получится целесообразно иметь 1-5 «микросервисов»

прям мой проект описал )) но как по мне это очень удобно, хоть и не модно

Может для пятничных срач тем отдельную ветку форума завести?

Краще зробити окремий блок де будуть виводитися дотепні коментарі про п’ятницю з кожного треду.

Отдельную от чего? Здесь другие темы уже редкость, а пятница у многих 24/7

А так...говно не код, говно чуваки которы им рулят.

Моя любимая картинка про монолит и микросервисы pbs.twimg.com/...​media/CBr9bynW8AErzIv.jpg

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

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

Что можно вынести в микросервис? Аутентификация и генерация токенов, процессинг изображений, видео, и вообще каких-то данных, менеджмент каких-то общих данных, которые потребляют другие сервисы (к примеру курсы валют, погода, и т.д.).

и это были технически изолированные сервера, с общением между собой по НТТР или даже бинарному поверх ТСР?

Можно еще тут thehost.ua/hosting/plans посмотреть разные варианты для себя. Есть разные тарифные планы, трафики и так далее. Отзывы отличные, цена нормальная. Но это как из вариантов

Согласен, микросервисы — это зло, если архитектура построена неправильно. Если бизнес-логика работает в примерно взаимосвязанных темах, то разделение только вредит. Скорее можно перечислить, когда разделение имеет смысл.
1) Если задача микросервиса не пересекается вообще никак с остальным кодом. Например, проверка данных авторизации, или обработка изображений.
2) Для балансировки нагрузки, в том случае, если это хайлоад.
Ну и пожалуй, всё.

про тестирование еще забыли упомянуть, есть какая то еще альтернатива микросервисам?

микросервисы проще тестировать, чем монолитную архитектуру

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