Микросервисы и точки отказа.

Уволь себя, ты ж не состоянии следить за контекстом. Раз в час резольвится доменное имя. Это вообще никакая не проблема.

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

https://ibb.co/wY53Wvx

В случае использования DNS разница в 2мс. А ведь между неймсервером и сервером тоже есть ноды, и они будут вносить дополнительные задержки. А может и вообще выйдут из строя.

И, что самое главное - инструмент ЯП (например PHP curl) не выдаст тебе причину сбоя. Ну, connection timeout, да, но на этом всё. А файервол это исходящий, файервол входящий, неймсервер, хост, или сам микросервис - ни один дебаг не скажет.

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

Своей схемы данных в одной общей базе недостаточно?

А у тебя конкретные примеры есть, или «просто получается»?

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

Примеры видел и там где работал, и как клиент апишек озона, вайлдберриза, я.маркета и подобных. Когда у товара есть и id, и product_id, и offer_id, и про один из них написано, что он deprecated, а второй в редких случаях может быть равен нулю, но это значит что надо немного подождать, потому что для соседней апишки нужен именно он.

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

Компетентные разработчики сильно заняты, они пишут код на си без use after free и выходов за границы массива. Поэтому работаем с теми, кто есть.

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

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

ОЧЕНЬ ПРОСТОЙ ПРИМЕР: если что-то легло, то тебе придется проверять не только две софтины на двух серверах, а еще и маршрутизацию, и не просто «ping 192.168», а конкретно по тем же путям, что у тебя и работают микросервисы.

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

Был клиент. У клиента были не то что бы микросервисы, скорее два Вордпресса, которые это чудо пыталось перенести. Так вот, оказывается какой-то imunify360 или подобная ересь, позволяет блокировать запись в ФС на лету, если PHP-код содержит запретные слова.

То есть ты не можешь сохранить файл который редактируешь в текстовом редакторе, где есть строка «/home/user/public_html/wp-config.php», а меняешь на «/home/user/public_html/wp-».«config.php» - и файл сохраняется.

И логи этому естественно тебе никто не покажет. Это - пример как сбой 3rdparty может повлиять на работу микросервиса так, что сам микросервис тебе этого не покажет.

Нет.

Так читай выше: БД разные, они всё комитят в разнобой. Как это собирать — понятия не имею, пусть stalkerbss рассказывает.

Two-phase commit?

https://en.wikipedia.org/wiki/Two-phase_commit_protocol

Почему?

Не совсем верно.

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

Даже если на одном сервере, то микросервисы всё равно могут падать независимо. Например, из-за багов в самих приложениях (которые в любом случае имеются хоть в микросервисе, хоть в монолите). Главное ресурсы ограничивать, чтобы один микросервис не мог выжрать всю ОЗУ или ЦПУ.

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

Вообще бессмысленный топик с еще более бессмысленными спорами - монолитность vs микросервисность.

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

Спорить в общем виде что лучше - традиционный подход или микросервисный - это жуткий тупняк даже для ЛОРа. Это все равно что спорить, что лучше - белое или черное, мама или папа, доллар или евро. Всему свое место.

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

как и нормально написанный монолит спустя 1 смену команды в течение 1.5 лет :)

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

высокочастотный криптотрейдер на raspberry pi с отключенным кэшированием в локальных DNS-резолверах детектед. Почтительно рассматриваем удивительную мифическую редкость.

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

Вылезай из криокамеры. OpenAPI, GraphQL и прочие OAuth куда более стандартны и структурированы чем сраный текст в юникс-пайпах.

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

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

Я понимаю, что воспринимать новые идеи тяжело, но искать оправдание в обобщениях через говнокодеров, которые неправильно применяют эти идеи — глупо. Это все равно, что сидеть в сишном маня-мирке и обмазывать говном ООП, потому что синглтон абстрактной фабрики фасадов — хуйня и оверинжиниринг, а ФП — тоже говно, потому что косвенная рекурсия наебывает ТСО и рвёт стек. Знаешь, всякого говнокода повидал тоже =)

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

У меня аж смузи из монитора потёк.

То чувство, когда некогда прогрессивная профессия погрязла в старых пердунах =)

Если у тебя обращение к хосту идет по доменному имени, то резолвится оно при каждом обращении

Нет конечно, если ты не криворукожопый.

ни один дебаг не скажет

Для этого есть логи. Дебаг – для школоты с хеловордами.

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

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

Two-phase commit?

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

Нет конечно, если ты не криворукожопый.

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

Для этого есть логи. Дебаг – для школоты с хеловордами.

Логи чего ? В смысле чьи логи ?

Дебаг – для школоты с хеловордами.

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

Дебаг в распределенной системе — это жопа. Только логи с трейсингом и спасают.

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

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

Спойлер. У тебя классический когнитивный баис: для данного следствия ты подставляешь первые попавшиеся и укладывающиеся в твою картину мира причины. То есть, ты говоришь, что микросервисы тратят многократно больше ресурсов для достижения тех же результатов. На самом деле, это проблема управления, а не технологии. Уже давно известно, что в IT человеческий ресурс очень сложно масштабировать. Это не проблема новомодных технологий, но менеджмента. В качестве демонстрации ты можешь взять классический жизненный путь стартапа: силами нескольких разработчиков сделать крутой прототип (60-80% от предполагаемого «результата»), получить инвестиции, вырасти порядка х10, х20, х30, через год обнаружить, что продукт дорастил всего 5-10% «результата», денег нет, но вы держитесь.

Из этого следует два вывода:

1. Масштабировать людей сложно.
2. Каждый следующий процентный пункт «результата» требует все больше и больше трудозатрат (гугли эмпирическое правило 80/20).

А микросервисы, да, это в том числе и попытка более эффективного масштабирования голов, как тут уже отметил уважаемый господин byko3y.

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

Дебаг в распределенной системе — это жопа. Только логи с трейсингом и спасают.

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

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

Здрасте. Мне тяжело вспомнить хотя бы одну сложную софтину, которая бы не имела некоего более-менее независимого макросервиса. Да хотя бы та же БД — это тоже макросервис. Ты сам пишешь «единого монолита с единой базой» — но это двухсервисная архитектура, ку-ку. И потом ты же мне предъявляешь:

Чтобы не получалась та дичь, о которой ты думаешь

Конечно, может быть ты экстрасенс и читаешь мои мысли — тогда мне стыдно.

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

Если говорить про один из моих проектов, то там каждая транзакция требовала авторизации-аутентификации. Прям каждая-каждая. Чо делать? Кэшировать юзеров и их права на выполнялке транзакций? Ололо, ты получил монолит, который использует вспомогательный сервис в качестве холодного хранилища. Собственно, примерно так оно у нас и было спроектировано.

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

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

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

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

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

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

Мне кажется, что у тебя довольно особенное понимание термина «микросервисы», отличное от того, что под этим понимают гугл, спотифай, фейсбук, и прочие. Если я натягиваю на LAMP балансер и кэш — по-твоему у меня сразу «микросервисная» архитектура получается? Если вспомнить, что операционная система там независима — то вообще полный микросервис получается. Я же называю это «макросервисы», то есть, крупные функционально законченные софтины, у каждой из которых БОЛЕЕ ОДНОЙ ФУНКЦИИ, он выполняют семейство смежных функций. Например, БД может персистентить самые разные данные, с кэшами аналогично, балансер балансирует протокол, но ему пофигу, что там в этом протоколе.

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

Ок, пример: нужно провести оплату, апнуть юзеру подписку, отправить в обработку все что не влезло раньше из-за баланса и отправить уведомление обо всем этом. Ну и запрос идёт через скажем rest api.

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

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

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

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

А микросервисы, да, это в том числе и попытка более эффективного масштабирования голов, как тут уже отметил уважаемый господин @byko3y

Слово «попытка» здесь как нельзя к месту. Если у вас 100 разрабов в команде, то да, вам нужны те или иные формы изоляции команд — микросервис здесь далеко не единственный вариант, если чо. Другое дело, что почему-то обычно «пытаются эффективно масштабировать» разработку микросервисами на уровне команды из 5-10 разрабов. Ты представляешь, насколько много может сделать такая команда грамотных кодеров за полгода-год? Не оптимизаторов/велосипедистов/иерархов классов, а просто грамотных кодеров, которые будут писать фичи из максимально готовых кирпичей. Но даже если ты поднимаешься до уровня 20-50 кодеров, то ты не обречен на микросервисы — ты по можешь писать макросервисы, ты можешь писать модули, ты можешь разбить систему на уровни абстракций — например, кто-то пилит на Си каркас, периферийные крестовики пишут реализацию сложных модулей на C++, дизайнеры-аналитики ковыряют скриптовуху по высокоуровневой логике на каком-нибудь питоне. Это всё не микросервисы, но почему-то у многих сидящих в треде «не микросервис» обязательно обозначает «строго монолит, единый и неделимый». Не говоря уже о том, что здесь многие не верят в существование распределенных монолитов.

Ок, пример: нужно провести оплату, апнуть юзеру подписку, отправить в обработку все что не влезло раньше из-за баланса и отправить уведомление обо всем этом. Ну и запрос идёт через скажем rest api.

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

То есть, переводя на твой язык, здесь А апосредованно вызывает Б и В, но отказ одного из них не приводит к порче стейта.

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

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

Да нет же. То, что я описал — это же тоже микросервисы и вообще вся эта история с серверами авторизации и аксес-токенами — это дроч для микросервисов (как правило). Раньше сессию с кукисом запилил и доволен. Теперь дроч. Еще недавно все дрочили как хотели и изобретали колесо (буквально руками делая микросервис авторизации, микросервис ABAC и т.д.) но сейчас это более или менее стандартно. Остается часть бизнес-микросервисов, там тоже потихоньку что-то стандартизируется. Те же токены, GraphQL и свагер, разделение API и backend-for-frontend, ну и в целом уже есть ощущение, что индустрия приходит к взвешенному пониманию микросервисов. Когда приходит новый человек в команду, он довольно быстро входит в курс дела, потому что а) common-sense, б) небольшой скоуп знаний внутри одного сервиса, в) более или менее стандартные спеки.

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

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

А если это не платежные транзакции, то вообще пофигу.

Если честно, из своего опыта, я не понимаю, что может делать команда даже из пяти разработчиков, выделенная на один микросервис. Я ходил в пару таких контор, ну там натурально люди от безделья охуевают, торчат на митингах и играют в теннис. Не, я не против, ну такой у них work-life-balance. Но я стараюсь держать какой-то тонус, чтобы людям было интересно работать. Например одна команда может работать (maintain и редкое добавление новых фичей) над десятком тесносвязанных сервисов, или один (staff+) разработчик дизайнить и разрабатывать новый сервис. Как управлять 100+ человек я пока не знаю =) Точнее, не знаю куда ввалить такой ресурс.

То, что я описал — это же тоже микросервисы и вообще вся эта история с серверами авторизации и аксес-токенами — это дроч для микросервисов (как правило)

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

Те же токены, GraphQL и свагер, разделение API и backend-for-frontend, ну и в целом уже есть ощущение, что индустрия приходит к взвешенному пониманию микросервисов

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

разделение API и backend-for-frontend

Ты про «не дергай этот роут с такими-то параметрами, потому что завалится система?».

Когда приходит новый человек в команду, он довольно быстро входит в курс дела, потому что а) common-sense, б) небольшой скоуп знаний внутри одного сервиса, в) более или менее стандартные спеки

Вообще не понимаю, о каких ты проблемах мне хочешь рассказать. Я пишу модуль ядра линя. Мне нужно все 30 млн строчек читать? Нет. Есть здравый смысл, есть небольшая область внутри одной задачи, есть доки-спеки. И к чему тут микросервисы?

Как управлять 100+ человек я пока не знаю =) Точнее, не знаю куда ввалить такой ресурс

Во-во, для 99% проектов достаточно 5-10 разработчиков — больше просто некуда вваливать столько ресурсов. Проблема ведь не в том, что проекты слишком сложные, а в том, что индустрия пробивает новое дно и нанимает всё более никчемных обитателей индостана. Потому что айтишка стала массовой, и теперь типовой коммерс в принципе не способен отличить программиста, с трудом вяжущего пару фраз, от эффективного манагера, который на слух звучит так же солидно, но при этом не умеет кодить. И всё это на фоне наплыва школьников и гламурных кис в интернеты, то есть, падения квалификации потребителя.

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

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

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

Во-первых стек чего? У тебя 100500 инстансов/тредов.

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

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

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

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

Раньше сессию с кукисом запилил и доволен. Теперь дроч.

А теперь сделай SSO, да логин через Вконтакт, да одноразовые пароли, да чтобы пользователи из LDAP подтягивались, да из внешней БД читались. Дроч.

Все верно. GraphQL позволяет с полпинка сгенерировать API по схеме базы микросервиса. Для à la CRUD просто пушка! Насколько я знаю, сейчас есть тренд запихивать его именно в микросервисы, особенно и в первую очередь среди nodejs. Хуяк, хуяк, и, ну ты понял.

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

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

Так микросервисы - это и есть вновь оживших труп юникса.

Это как если у тебя есть grep, вывод которого можно направить только в awk, а если нужно в sed, то нужен другой grep или же какой-нибудь awk_to_sed_adapter.

Ну подожди. Лет через 20 что-нибудь стандартизируют.

чем по нормальному читабельному стектрейсу и логам
читабельному стектрейсу

Ох, лол.

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

Так о том и речь же, что детектив можно где угодно устроить.

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

Так так, что мы тут видим. Кодерки сделали говно и, ууу, как страншо, всё отваливается, транзакция не коммитистя целиком. Ууу, микросервисы - зло страшное, дооо.

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

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

Так читай выше: БД разные, они всё комитят в разнобой. Как это собирать — понятия не имею

man Теорема CAP

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

У клиента были не то что бы микросервисы, скорее два Вордпресса

Меняй окружение, лол.

Ничего, все когда-то там будут.

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

Вот так ГИС ЖКХ сделали монолит сраный, который работает в Москве и прикладывается спать, когда народ со всей страны начинает передавать в конце месяца платёжки. Такие же не криворукожопые делали с вёдрами вместо головы. Даже федерацию не смогли осилить, не то, чтобы какие-то там тестовые окружения.

Кинул запрос, прочитал ответ.

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