Хватит везде делать микросервисы

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

Вы все еще катите руками?

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

На единственном сервере

Ну тогда полностью согласен — Вам не нужны микросервисы.

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

Стоит разделять понятие «монолита» и приложения на единой кодовой базе

«Монолит» является анти-паттерном: синонимом "легаси", плохо спроектированного, сильно и неявно связанного, не тестируемого приложения

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

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

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

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

> А когда микросервисы — это хорошо? — Когда у вас несколько команд, которые независимо делают разные компоненты сервиса.

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

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

Я бы добавил еще следующие плюсы-минусы микросервисов.
Плюс:

• (на мой взгляд) Легче держать в голове 10 маленьких микросервисов, чем одно огромное приложение.

Минус:

• Запуск микросервиса — это, по-хорошему, запуск приложения, для которого нужно применять процесс Launch Readiness Review (в разных компаниях называется по-разному, но не суть), и запуск из 2-3 дней превращается легко в 2-3 недели. Хотя это недостаток относительный.

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

дык берите уже готовые решения, не?

Микросервисы это всегда про масштаб — масштаб проекта, масштаб команды, масштаб нагрузки.

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

По опыту работы в реальном времени (QNX) мне всегда казалось удобным делать все именно в микросервисах, так гораздо проще настраивать и соблюдать время исполнения

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

На старте проекта монолит прекрасно может быть надёжно декомпозирован внутри кода даже между между разными независимыми командами через разработку отдельных пакетов (npm-пакет, jar, dll и т.д.) и впоследствии декомпозирован на реальные микросервисы.

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

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

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

Резюмируя.
Архитектуру проекта можно реализовывать так, чтоб на одной и той же кодовой базе, в любой момент времени можно было двумя разными CI-pipeline собрать две разные версии продукта: (1) монолит, все сервисы которого работают на одном хосте в рамках одного процесса; (2) набор микросервисов, работающих на разных хостах и взаимодействующих друг с другом по сети;

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

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

Я один считаю, что это умозаключение устарело лет на 5 и никто уже достаточно давно не делает все на микросервисах? Из каждого утюга просто все говорят «все хотят себе микросервисы», а я чет не вижу таких продуктов. Не туда смотрю, получается?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Энтропия. Фактически все минусы возникают в неосознанном и неумелом контроле энтропии в системе. Ее «утечка» происходит, либо в меру нелинейного роста сложности топологии при неосозанном подходе к декомпозиции (так как степень свободы в топологии растет в общем случае квадратично N^2, а конфигуративное множество — факториально, следовательно редукцию делать все сложнее), либо в меру вытеснения в мета-конфигурации (вытеснение конфигурирования частей системы в рантайм — фактически это так называемая проблема интерпретации в контексте нейросетей), создает ощущение «минусов», либо очевидные с практической точки зрения ограничения. Но все эти минусы и ограничения — это следствия малой степени осознания процесса управления сложностью (контроль энтропии).

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

Так в чем же сакральный смысл микросервисов?

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

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

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

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

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

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

Иными словами, микросервисная архитектура позволяет создавать масштабируемые системы (любого масштаба), которые пытаются «скальпировать» реальность с минимальным latency, но лишь при условии, что создатели осознают высокую стоимость сериализации на передачу сигналов, а также зависимость между стоимостью сериализации и степенью параллелизма, которые и формируют сходимость системы к некоторому минимальному latency в процессе проекции асинхронных потоков в глобальное состояние (в global state — с точки зрения понятия statefull, что упрощенно можно представить как некий консолидированный map-reduce по всем данным, или «отчет»), которое в свою очередь будет консистентно на момент времени t-1, но в настоящий момент времени будет оставаться принципиально неактуальным по аналогии с вашим намерением прокрутить скролл на странице с самим фактом прокручивания и наблюдением результата в меру latency на «сериализацию» данных через органы восприятия.

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

P.S. На правах моего субъективизма.

Есть ситуации и приложения, где МС не нужны. Но если вам нужен ХА, то забудьте про АСИК и монолиты.
Куча контор думают, что возьми динозавров, которые ничего кроме монолитов не делали и дай им задание, то они, без опыта, простой копипастой со стэковерфлоу, построят им КД на МС. Нет, они построят микролиты на ручной интеграции, сложность возрастет и все будет падать в разы чаще, количество велосипедов и говнокода будет расти в геометрической прогрессии.
Потери АСИК такие разрабы тоже не способны, по крайней мере сразу, пережить и начинается борьба бобра со злом, пока люди не придут к «как минимум раз» семантике, а там и ФП начинает махать радостно ручкой.
Нужны практики и опыт выстраивания таких систем (композиции их), которые работают и приносят удовольствие — это кластерные платформы типа к8с, окд а может и ранчер. Это использование ХА персистенц, что тоже очень не тривиально и далеко не все спецы это умеют. Это мониторинг и логинг этих решений, который тоже не прост. Отсюда далеко не всем крупным то компаниям понятен объем работ и разрыв знаний, который у них есть и тот, что нужен. Отсюда и появляются такие статьи.
А серверлесс — это дальнейшее развитие этих идей, где ФП и ДДД господствуют на сегодня.

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

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