В чем смысл микросервисов?

Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?

Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.

Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.

Зачем все это? Ради чего?

S>Зачем все это? Ради чего?

Чаще всего это resume driven development. Но в некоторых случаях бывает и реально полезно.

Здравствуйте, Shmj, Вы писали:

S>Зачем все это? Ради чего?

Вот тут есть рассказ о том, как они помогли в реальной жизни

S>Зачем все это? Ради чего?

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

Здравствуйте, Shmj, Вы писали:

S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
да, в большинстве случаев так лучше и не стоит связываться с микросервисами.

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

Здравствуйте, Shmj, Вы писали:

S>Зачем все это? Ради чего?

Карго-культ. Если мы будем делать всё как большие компании, мы станем большой компанией.

S>В чем смысл микросервисов?
Сам не пользую, но периодически слушаю подкасты с обсуждением.
Основноая идея — что это позволяет гибко балансировать нагрузку и на лету подключать/отключать.

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

Какие такие транзакции?, это же вам не банк.

Средний такой pet-project(англ. проект собачьей будки) содержит около ~20 микросервисов, в каждом сервисе обычно от 3 до 50 строк кода.

Здравствуйте, Shmj, Вы писали:

S>Зачем все это? Ради чего?
1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро. Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;
2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.

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

А вообще, для многих задач хорошо в свое время подходила просто сервисная архитектура. Если имеем распределенные системы, эта SOA уже в мейнстриме лет 15 минимум. Но когда эта SOA стала приобретать популярность, необходимым аттрибутом этой SOA стали тяжеленные сервера приложений. В результате рестарт приложения занимал иногда часы. Микросервисная архитектура — это тоже SOA, но на более легких решениях. Не нужна тяжеленная дорогущая промышленная шина, можно использовать легкую опенсорсную бесплатную библиотеку, и самому разобраться в нормальной документации, а не платить бешенные деньги за техподдержку какого то монстра, который к тому же глючит и тормозит. Простейшие микросервисы поднимаются вообще мгновенно. Тяжелые сервисы тоже никуда не делись, от них никуда. Но так как теперь сервисы стало писать и обслуживать гораздо легче, стало легче дробить функционал на сервисы. Некоторые сервисы по прежнему довольно тяжелые, и поднимаются довольно долго. Но у них строго один функционал, и время подъема зачастую там из за того, что идет пересчет каких то показателей, выполнение различных расчетов, поднятие и построение первичного кеша и т.д. Сами коммуникации то поднимаются мгновенно.

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

Здравствуйте, Shmj, Вы писали:

S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.

S>Зачем все это? Ради чего?

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

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

Здравствуйте, Shmj, Вы писали:

S>В чем смысл микросервисов?

S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?

S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.

S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.

S>Зачем все это? Ради чего?

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

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

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

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Shmj, Вы писали:

S>>Зачем все это? Ради чего?
E>1) Ради масштабирования

Я думаю, сэр, вы гоните дичь. Причём тут масштабирование, если это МИКРОсервисы? Каждый ест по чуть-чуть. Можно, конечно, отловить самый прожорливый микросервис, но боюсь, узкое горлышко будет совсем в другом месте.

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

И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?

E>2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.

Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет. Как только в проект вносят ещё один язык, на проект сразу взваливают ещё одну ненужную проблему — поддержку этого языка, т.е. людей. Люди — это ВСЕГДА ПРОБЛЕМА. При тысячах резюме, подходят по уровню лишь десятки. И только паре из них можно навешать второстепенную задачу "вы тут микросервисом позанимайтесь". Причём отдавать этот сервис студоте вы явно не захотите. Ну а кто мнит себя даже "просто разрабом", хочет за свои услуги будто он всю систему писал! И даже согласные могут заболеть, найти лучшую вакансию и т.п. В команде 10 джавистов вы всегда найдёте, кому перекинуть сервис. В команде 10 джавистов и два Перловика ваш "перлосервис" будет дамокловым мечом — заслуженным наказанием за свою бестолковость "язык под задачу". По этой фразе можно сразу увольнять с работы, моё мнение.

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

Микросервисы там вообще не причём. Их главная задача — масштабирование и решается она куда проще.

Здравствуйте, Kolesiki, Вы писали:


K>Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет.

Кстати, хотел тебя спросить про c# -- оно еще не сдохло?

S>Зачем все это? Ради чего?

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

Часто бывает такая ситуация: в начале проектирования системы видно, что функцию A надо делать вот так, функцию B надо делать примерно вот так, функцию C надо делать пока что хрен знает как, но она должна быть; вместо функции D надо пока сделать заглушку, а функция E, возможно, появится в будущем. И нагрузка на эту функциональность будет пока что непонятно какая.

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

Здравствуйте, Kolesiki, Вы писали:

K>И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
Вообще то микросервисы крутятся в каком то кластере. Корпоративном или облачном. Этот кластер уже есть, он уже сконфигурирован. И там уже есть независимые от задачи механизмы распределения нагрузки. Уже готовые, уже сконфигурированные, и на этом кластере гоняются десятки приложений. Если кто то под каждое приложение обслуживает отдельно, а не централизованно кластер — у кого то реально большие проблемы.

K>Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет.
Вот потому и появилась мода на фулстек. И на идиотизм, когда из за того, что фронтэндер хочет писать фронтэнд на JavaScript, на нем же и фигачат огроменную бекэнд логику. Ибо фронтэнд в современном мире будет по любому на JavaScript. Соответственно так как мы хотим, чтоб язык был один, этим языком будет JavaScript. Ибо от него не избавиться. И на нем все так или иначе умеют. Ибо фронтэндера современного хрен заставишь писать на статически типизированном языке, даже если бы инструменты были. Ибо ему пофиг, его задача отображение, там сложности обычно только с версткой и с приколами особенностей браузеров. И из за того, что так удобно фронтэндеру, многие додумываются проекты на миллионы строк писать на этом убожестве. Также советую попробовать пересадить математиков на что то, отличное от питона. В коде математиков один черт кроме них хрен кто разберет, там проблема не с языком. Кто будет писать кучу математических либ, которые существуют на питоне, под другие языки? Или мы будем всю систему фигачить на питоне, когда расчетная часть это весьма небольшая часть? Переписывать код математиков потом — это двойная работа. И пока ты переписываешь код математиков нормально, добиваясь чтоб то, что ты понаписал, считало аналогично, там уже к чертям требования черти как изменятся и код математиков уйдет далеко.

Здравствуйте, elmal, Вы писали:

E>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.

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

E> Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;

Нет, не готова.

E>2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.

Зачем для этого создавать распределенную систему?

E>Естественно есть и недостатки у такой архитектуры. Ибо увеличение сложности на ровном месте, затраты на коммуникации, нужна облачная инфраструктура.

Ты про САР-теорему забыл, бессердечную суку, грозу всех хипстеров.

Здравствуйте, scf, Вы писали:

scf>И минусы:
scf>- Сложность. Микросервисная архитектура требует огромных вложений в единую архитектуру системы, девопс, мониторинг, логгирование и аналитику.
scf>- Еще раз сложность. Правильно разбить еще не написанное приложение на микросервисы — задача нетривиальная и при ошибке реализация каждой фичи затрагивает множество микросервисов, что серьезно стопорит разработку
scf>- И еще раз сложность. Отказ от распределенных транзакций и сетевое взаимодействие требуют очень вдумчивого подхода к обработке ошибок.

А еще снижение стабильности и надежности системы в целом.

Здравствуйте, klopodav, Вы писали:

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

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

Здравствуйте, Shmj, Вы писали:

Проблема в том, что то, что вы называете microservices — это антипаттерн. На который наступают периодически. Антипаттерн называется Entity Service. Подробнее, например, здесь:

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

Обычно в случае с микросервисным подходом нужно стремится к eventual consistency. Таким образом, чтобы каждый из микросервисов был независимой подсистемой. В этом очень помогает понятие bounded context из DDD. Для начала попробуйте определить агрегаты в вашей системе, многое станет понятным.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А еще снижение стабильности и надежности системы в целом.

Исключительно из-за роста сложности или есть другие соображения?

Здравствуйте, elmal, Вы писали:

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

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

Здравствуйте, Kolesiki, Вы писали:

K>И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
Пытаться уличить человека, что он гонит дичь и, при этом, гнать дичь самому — конфуз .

Здравствуйте, Ночной Смотрящий, Вы писали:

E>>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.
НС>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.
E>> Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;
НС>Нет, не готова.

а где аргументация?

Здравствуйте, Privalov, Вы писали:

P>Похоже, я отстал от жизни. Математики, с которыми я работал, писали исключительно на Фортране. Как их удалось пересадить на Питон?
Сейчас математики пишут либо на питоне, либо на матлабе. Причем именно на питоне куча библиотек машинного обучения, которые к тому же могут гоняться на видеокартах. Все курсы используют питон. У матлаба кластеризация из коробки, гоняют расчеты сразу на кластере. И всему этому учат прямо в институтах.

Здравствуйте, Kolesiki, Вы писали:

K>Я думаю, сэр, вы гоните дичь. Причём тут масштабирование, если это МИКРОсервисы? Каждый ест по чуть-чуть. Можно, конечно, отловить самый прожорливый микросервис, но боюсь, узкое горлышко будет совсем в другом месте.

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

Здравствуйте, Nikita Lyapin, Вы писали:

NL>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.

Далее, сервисы нужны, если функциональность для них достаточно обширная. При этом снаружи они, действительно, могут выглядеть как get/set методы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, elmal, Вы писали:

E>>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.

НС>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.

Этого с чего вдруг? Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.

Здравствуйте, Shmj, Вы писали:

S>В чем смысл микросервисов?
В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс).
Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).

Микросервисы это инструмент позволяющий увеличить связанность и уменьшить зацепление на верхнем уровне архитектуры.
Высокая связность и низкое зацепление показатель качества любой архитектуры.
Микросервисы позволяют уменьшить не только design-time, но и run-time зацепление.

Здравствуйте, Cyberax, Вы писали:

NL>>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
C>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.

Почему?
И как делать без транзакций?

Здравствуйте, De-Bill, Вы писали:

S>>Зачем все это? Ради чего?

DB>Чаще всего это resume driven development. Но в некоторых случаях бывает и реально полезно.

Никогда такого выражения не слышал. Оно?

résumé driven development
when you ignore requirements and pick implementation approaches based on how good they look on your resume.

Здравствуйте, MadHuman, Вы писали:

MH>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.

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

Здравствуйте, klopodav, Вы писали:

K>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто).

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

Здравствуйте, Философ, Вы писали:

MH>>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.
Ф>У меня в руках новый микроскоп, хотелось бы его опробовать в действии, а в от эта задача вроде-бы подходит под возможности инструмента. Не важно, что его возможности ты знаешь плохо, и тут лучше бы молоток подошёл...
Ф>Поубивал бы!!!

А есть реальные примеры таких проектов?

Здравствуйте, mrTwister, Вы писали:

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

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

Здравствуйте, TG, Вы писали:

TG>Нивапрос.
TG>Заказчик отдаст свои деньги другим более проворным ребятам.

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

Здравствуйте, elmal, Вы писали:

E>Сейчас математики пишут либо на питоне, либо на матлабе. Причем именно на питоне куча библиотек машинного обучения, которые к тому же могут гоняться на видеокартах. Все курсы используют питон. У матлаба кластеризация из коробки, гоняют расчеты сразу на кластере. И всему этому учат прямо в институтах.

Эх, молодежь... ©

Раньше все математики всё писали на Фортране, и не особо использовали чужие библиотеки. Точнее, числодробительные библиотеки получились в результате их работы.
Когда я работал с командой математиков, там использовалась только одна сторонняя библиотека: Графор. Меня тогда еще попросили сделать к ней подключение из Си. Тогда еще не было таких Интернетов, как сейчас. И математики были старше меня, успели каждый себе написать все, что требовалось.
А сейчас в институтах учат, как подключить к Питону библиотеку. Н-да...

Здравствуйте, mrTwister, Вы писали:

T>а микросервисы делают рефакторинг оооочень дорогим.

Можно ентот тезис подробнее раскрыть?

Здравствуйте, Privalov, Вы писали:

P>Эх, молодежь... ©
P>Раньше все математики всё писали на Фортране, и не особо использовали чужие библиотеки. Точнее, числодробительные библиотеки получились в результате их работы.
P>Когда я работал с командой математиков, там использовалась только одна сторонняя библиотека: Графор. Меня тогда еще попросили сделать к ней подключение из Си. Тогда еще не было таких Интернетов, как сейчас. И математики были старше меня, успели каждый себе написать все, что требовалось.
P>А сейчас в институтах учат, как подключить к Питону библиотеку. Н-да...

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

Здравствуйте, Sharov, Вы писали:

T>>а микросервисы делают рефакторинг оооочень дорогим.
S>Можно ентот тезис подробнее раскрыть?

тут смотря что подразумевать под "рефакторингом".

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

Здравствуйте, neFormal, Вы писали:

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

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

Здравствуйте, Sharov, Вы писали:

T>>а микросервисы делают рефакторинг оооочень дорогим.

S>Можно ентот тезис подробнее раскрыть?

Тут хорошо объяснено:
https://martinfowler.com/bliki/MonolithFirst.html

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

Здравствуйте, Privalov, Вы писали:

F>>короче, вы развлекались за чужой счёт, а молодёжь пытается добиться результата.
P>А библиотеки, которыми молодежь пользуется, появились сами, я верно понял?

а их по делу делали, а не из желания понаписать код.

сориентируйте по терминологии. обычное MVC приложение с конечным набором веб-методов + база данных — это микросервис или монолит?

Здравствуйте, TG, Вы писали:

TG>Здравствуйте, Философ, Вы писали:

MH>>>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.
Ф>>У меня в руках новый микроскоп, хотелось бы его опробовать в действии, а в от эта задача вроде-бы подходит под возможности инструмента. Не важно, что его возможности ты знаешь плохо, и тут лучше бы молоток подошёл...
Ф>>Поубивал бы!!!

TG>А есть реальные примеры таких проектов?

Прямо сейчас у меня нет, но в своей практике я с таким сталкивался с последствиями. Были одновременно Firebird, MS SQL, My SQL в купе с Delphi, .net, PHP. Это давно было.
Про такой подход неоднократно слышал: люди рвуться попробовать что-то прямо в продакшене, впендюрить туда что-то, о чём они недавно прочитали.

Здравствуйте, Shmj, Вы писали:

S>В чем смысл микросервисов?

S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?

S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.

S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.

S>Зачем все это? Ради чего?

1. У микросервисов есть чётко очерченные интерфейсы. Твой IAccountService можно прикастовать к AccountService и через reflection поменять ему какие-нибудь приватные переменные, хе-хе. Да, это плохо, но если есть возможность, такое будет. Причём снаружи этого видно вообще не будет, это можно увидеть только читая код пользователей класса. Микросервис это, скажем, HTTP-интерфейс и все входы-выходы обычно документированы так или иначе.

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

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

Здравствуйте, zverjuga, Вы писали:

Z>сориентируйте по терминологии. обычное MVC приложение с конечным набором веб-методов + база данных — это микросервис или монолит?

и то, и то в зависимости от контекста применения.

Здравствуйте, vsb, Вы писали:

vsb>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.

Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?

Здравствуйте, Cyberax, Вы писали:

C>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.
C>Далее, сервисы нужны, если функциональность для них достаточно обширная. При этом снаружи они, действительно, могут выглядеть как get/set методы.

пиши еще принципал инженер Cyberax! а потом Панкай или Раджеш с компании Х приходит и ты думаешь — ну е мае люди так нужны, что бы полегче спросить?? а вот транзакция — проще простого?
что такое транзакция Панкай? И он гордо в ответ — вестимо антипаттерн — это мне мой принципал инженер обьяснил!

Здравствуйте, Shmj, Вы писали:

S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?

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

Здравствуйте, Shmj, Вы писали:

vsb>>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.

S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?

account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.

Здравствуйте, a_g_99, Вы писали:

C>>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.
C>>Далее, сервисы нужны, если функциональность для них достаточно обширная. При этом снаружи они, действительно, могут выглядеть как get/set методы.
__>пиши еще принципал инженер Cyberax! а потом Панкай или Раджеш с компании Х приходит и ты думаешь — ну е мае люди так нужны, что бы полегче спросить?? а вот транзакция — проще простого?
__>что такое транзакция Панкай? И он гордо в ответ — вестимо антипаттерн — это мне мой принципал инженер обьяснил!
А об чём ржач-то? Как ты предлагаешь транзакции обеспечивать в распределённой системе? Microsoft Transaction Server?
Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом.

Здравствуйте, ·, Вы писали:



·>А об чём ржач-то? Как ты предлагаешь транзакции обеспечивать в распределённой системе? Microsoft Transaction Server?
Да какой микрофософт ? При чем тут микрософт какой-то ? Вы еще сюда виндоуз добавьте и щарепоинт и получится ваше резюме!

·>Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом.
Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему и прочее что ухватил с курсов "транзакции за 21 день"

Здравствуйте, TG, Вы писали:

NL>>>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
C>>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.
TG>Почему?
TG>И как делать без транзакций?
https://martinfowler.com/articles/microservice-trade-offs.html#consistency

Здравствуйте, a_g_99, Вы писали:

__>·>А об чём ржач-то? Как ты предлагаешь транзакции обеспечивать в распределённой системе? Microsoft Transaction Server?
__>Да какой микрофософт ? При чем тут микрософт какой-то ? Вы еще сюда виндоуз добавьте и щарепоинт и получится ваше резюме!
А что же тогда? EJB/XA? Открой тайну-то!

__>·>Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом.
__>Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему и прочее что ухватил с курсов "транзакции за 21 день"
Понятно. По сути сказать ничего не можешь.

Здравствуйте, ·, Вы писали:

·>А что же тогда? EJB/XA? Открой тайну-то!
Вы друг мой смотрите на 25 лет назад, а вам надо взглянуть на 10 лет назад хотя бы. Ну про современные подходы я не буду говорить, ни к чему вам этим голову забивать раз у вас какой микрософт и EJB в голове

·>Понятно. По сути сказать ничего не можешь.
так было бы с кем поговорить я бы поговорил . а так времени жалко тратить на ликбезы

Здравствуйте, a_g_99, Вы писали:

__>·>А что же тогда? EJB/XA? Открой тайну-то!
__>Вы друг мой смотрите на 25 лет назад, а вам надо взглянуть на 10 лет назад хотя бы. Ну про современные подходы я не буду говорить, ни к чему вам этим голову забивать раз у вас какой микрософт и EJB в голове
Так что же тогда? Рафты и прочие консенсусы? Просвети уж убогих.

__>·>Понятно. По сути сказать ничего не можешь.
__>так было бы с кем поговорить я бы поговорил . а так времени жалко тратить на ликбезы
А тебя сюда никто не приглашал, ты сам припёрся и всё слюной забрызгал.

Здравствуйте, a_g_99, Вы писали:

__>вы вообще слышали про envoy? господи как страшно жить когда такие имитации называют себя "программист", "инженер" и пр.

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

По теме есть что сказать?

__>У вас вообще есть самосознание?

Определи что такое самосознание. Дай научное определение.

Здравствуйте, TG, Вы писали:

C>>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.
TG>Почему?
Потому, что они не работают так, как этого хотелось бы.

TG>И как делать без транзакций?
Делать без транзакций. На eventual consistency.

Здравствуйте, a_g_99, Вы писали:

__>·>Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом.
__>Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему и прочее что ухватил с курсов "транзакции за 21 день"
Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.

Здравствуйте, a_g_99, Вы писали:

__>пиши еще принципал инженер Cyberax! а потом Панкай или Раджеш с компании Х приходит и ты думаешь — ну е мае люди так нужны, что бы полегче спросить?? а вот транзакция — проще простого?
__>что такое транзакция Панкай? И он гордо в ответ — вестимо антипаттерн — это мне мой принципал инженер обьяснил!
И что дальше-то? Как это опровергает то, что транзакции в распределённых системах не работают?

Здравствуйте, Философ, Вы писали:

DB>>Чаще всего это resume driven development. Но в некоторых случаях бывает и реально полезно.

Ф>Никогда такого выражения не слышал. Оно?
Ф>

Ф>résumé driven development
Ф>when you ignore requirements and pick implementation approaches based on how good they look on your resume.

Да, оно. Термин "RDD" (Résumé Driven Development), насколько я помню, сначала появился как камень в огород на "TDD" (Test Driven Development), потом уже прижился и для всего остального.

Здравствуйте, neFormal, Вы писали:

F>а где аргументация?

А где аргументация у того, кто утверждение делал? Микросервисы и кластеризация — ортогональные понятия. Кластеры, нацеленные на резервирование и перформанс это не просто набор разрозненных микросервисов. И даже решения типа Service Fabric эту задачу полностью не решат. Ее надо решать целенаправленно, и микросервисы лишь могут облегчить начало пути, не более.

Здравствуйте, Nuzhny, Вы писали:

N>Как раз масштабироваться проще, а балансировкой нагрузки может заниматься сама ОС. Я, например, разбивал систему видеонаблюдения на множество сервисов, каждый из которых занимался анализом видео с отдельной видеокамеры и записывал архив.

Это не микросервисы.

Здравствуйте, Sharov, Вы писали:

НС>>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.
S>Этого с чего вдруг?

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

S> Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.

Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы.

Здравствуйте, scf, Вы писали:

НС>>А еще снижение стабильности и надежности системы в целом.
scf>Исключительно из-за роста сложности или есть другие соображения?

Из педивикии

The microservices approach is subject to criticism for a number of issues:

Services form information barriers
Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
Testing and deployment are more complicated
Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.

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

Здравствуйте, mrTwister, Вы писали:

K>>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто).
T>Вот этого делать не стоит

Не делай. Конкуренты сделают это за тебя.

T>, так как при недостаточных и неполных данных надо часто рефакторить систему

Надо.

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

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

Здравствуйте, Cyberax, Вы писали:

C>Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.

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

Здравствуйте, Hardballer, Вы писали:

S>>В чем смысл микросервисов?
H>В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс).
H>Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).

И при чем тут микросервисы? Ты уже третий тут, кто путает микросервисы и кластеры.

Здравствуйте, a_g_99, Вы писали:

__>Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему

А ее что, уже отменили?

Здравствуйте, vsb, Вы писали:

vsb>1. У микросервисов есть чётко очерченные интерфейсы. Твой IAccountService можно прикастовать к AccountService и через reflection поменять ему какие-нибудь приватные переменные, хе-хе.

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

vsb>2. Микросервисы можно писать на разных языках. В том числе плавно переписывая систему, если захочется. В случае монолита это делать гораздо сложней.

Это чего это вдруг?

vsb>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.

И нулевым, а скорее отрицательным результатом.

Здравствуйте, Shmj, Вы писали:

S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?

Чо, серьезно?
https://en.wikipedia.org/wiki/Load_balancing_(computing)

Да, к микросервисам это совершенно ортогонально.

Здравствуйте, Cyberax, Вы писали:

C>Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.

да что вы со своими БД носитесь как девственники с мохнаткой? боже мой мужикам по 40 лет больше половины жизни прожили и до сих пор мыслят маркетинговыми буклетиками.
Все таки МС молодцы — они сайбас купили раз в 80х и до сих пор его продают без каких либо изменений. И внедрили идею в головы средних людей что БД и транзакции вещи неразделимые. Гениально!

Ну как вас так озарило что транзакция может быть только в БД в виде какой то там процедуры? Но обьясните мне ход вашей мысли принципал инженер Cyberax??

Здравствуйте, Hardballer, Вы писали:

S>>В чем смысл микросервисов?
H>В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс).
H>Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).

Ты всё правильно написал. С поправкой на то, что всё это не имеет никакого отношения к микросервисам, а точнее даже противоречит их концепции.

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

Есть один современных подход, в котором одна и та же задача исполняется параллельно на множестве компьютеров. Это подход hadoop'а и ему подобных кластеров. И именно этот подход ты описал в своём сообщение. Очень полезная вещь для многих задач с высокой нагрузкой. Причём такой распределённый кластер может служить и числодробилкой и базой данных (nosql) и клиентским сервисом и ещё много чем.

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

P.S. Я уже давно (с самого появления моды на эту глупость) с усмешкой наблюдаю за тем, как всеми силами развивают сложнейшие инструменты для управления за получаемой хренью, в то время как для управления моими сайтами (отлично держащие большие нагрузки) легко хватает какой-нибудь простейшего scp/sftp.

Здравствуйте, Ночной Смотрящий, Вы писали:

scf>>Исключительно из-за роста сложности или есть другие соображения?

НС>Services form information barriers
Вообще-то это считается преимуществом
НС>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
Да, но эти затраты невелики и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно.
НС>Testing and deployment are more complicated
НС>Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
НС>Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.
да, сложно. да, при неправильном разбиении на микросервисы будет много боли

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

-

Здравствуйте, a_g_99, Вы писали:

__>Ну как вас так озарило что транзакция может быть только в БД в виде какой то там процедуры? Но обьясните мне ход вашей мысли принципал инженер Cyberax??
Я вообще не понимаю твой рвотный поток сознания. В чём вопрос-то?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, vsb, Вы писали:

vsb>>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.

S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?

Точка входа одна. А дальше, тот же самый HAProxy, ELB (или любой другой HW LB). Или просто, DNS на несколько адресов.


Далее, (hash(login) mod N), если межлогинного (социального) взаимодействия между аккаунтами нет. По крайней мере, если нет активного взаимодействия.

Неактивное можно делать на фоне, так как можно чем-то пожертвовать из CAP (теоремы). А в большинстве случаев, это так.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Чо, серьезно?
НС>https://en.wikipedia.org/wiki/Load_balancing_(computing)

НС>Да, к микросервисам это совершенно ортогонально.

Давайте на примере с нашим ClientService. Вам нужно проверить не занят ли логин. Вы разбили ClientService на несколько серверов, каждый из них имеет свою базу данных. Допустим, на первом сервере хранятся все клиенты, логин которых начинается с буквы "a". Так? Теперь вам нужно проверить не используется ли email. Ваши действия.

Здравствуйте, Shmj, Вы писали:

S>Давайте на примере с нашим ClientService. Вам нужно проверить не занят ли логин. Вы разбили ClientService на несколько серверов, каждый из них имеет свою базу данных. Допустим, на первом сервере хранятся все клиенты, логин которых начинается с буквы "a". Так? Теперь вам нужно проверить не используется ли email. Ваши действия.
Это не микросервисы, а вообще непонятно что.

Для примера, если взять сетевой магазин, то в микросервисной модели будет:
1) Отдельный сервис, отвечающий за поддержку корзины покупок.
2) Отдельный сервис для обработки карточек.
3) Отдельный сервис для валидации адреса доставки.
4) Отдельный сервис для расчёта бизнес-статистики для директора магазина.
...

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

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Не делай. Конкуренты сделают это за тебя.
...
НС>А потому микросервисы на помоечку.

Дак я не понял: на помоечку, или конкуренты их сделают за меня?

C>Для примера, если взять сетевой магазин, то в микросервисной модели будет:
C>1) Отдельный сервис, отвечающий за поддержку корзины покупок.
C>2) Отдельный сервис для обработки карточек.
C>3) Отдельный сервис для валидации адреса доставки.
C>4) Отдельный сервис для расчёта бизнес-статистики для директора магазина.

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

Но юные хипстеры ВНЕЗАПНО

— обозвали эту схему красивым словом
— объявили чем-то принципиально новым
— забили все интернеты своими высерами о том, как это круто и какие лохи те, кто это не использует

Здравствуйте, Аноним931, Вы писали:

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

А>Но юные хипстеры ВНЕЗАПНО

Ты про SOA? Это близко, но не совсем то. У SOA фокус на повторное использование сервисов и создание приложений на единой платформе, используя сервисы в качестве кирпичиков. В микросервисной архитектуре плевать на повторное использование сервисов и единую платформу, фокус на изолированность и независимость сервисов друг от друга при максимальной декомпозиции по функционалу и данным. Можно сказать, что микросервисы — это развитие SOA архитектуры, когда из нее убрали ESB, единое хранилище, единую платформу, единые стандарты коммуникаций и перефокусировались от повторного использования к максимальной изоляции сервисов друг от друга

T>Ты про SOA?
Я про схему, описанную Цибераксом, и названную им "микросервисной"

Здравствуйте, Аноним931, Вы писали:

А>Но юные хипстеры ВНЕЗАПНО
А> — обозвали эту схему красивым словом
А> — объявили чем-то принципиально новым
А> — забили все интернеты своими высерами о том, как это круто и какие лохи те, кто это не использует
Юные хипстеры эту схему реально довели до ума. В частности:
1) Начали разбираться с трассировкой и отладкой: https://opentracing.io/
2) Управление траффиком, в том числе throttling и load shedding: https://linkerd.io/
3) Субстрат, на который легко разворачивать приложения (Docker, Kubernetes).

Здравствуйте, Ночной Смотрящий, Вы писали:

F>>а где аргументация?
НС>А где аргументация у того, кто утверждение делал? Микросервисы и кластеризация — ортогональные понятия. Кластеры, нацеленные на резервирование и перформанс это не просто набор разрозненных микросервисов. И даже решения типа Service Fabric эту задачу полностью не решат. Ее надо решать целенаправленно, и микросервисы лишь могут облегчить начало пути, не более.

обычно под "микросервисной архитектурой" понимают весь комплекс проблем.

Здравствуйте, alex_public, Вы писали:

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

почему обязательно на одной машине?

Здравствуйте, scf, Вы писали:

scf>- Масштабирование. В целом, монолитные приложения масштабируются хорошо, в отличие от огромной БД монолитного приложения. И наличия внутреннего состояния, которым грешат монолиты.
scf>- Устойчивость к отказам. Отказ от транзакций и необходимость тщательной обработки ошибки позволяет строить системы, адекватно реагирующие на перегрузку и отказ отдельных компонентов.
Как организовать совместную работу одного микросервиса со своей ДБ (пусть будет монгоДВ) чтобы обеспечить хоть как-то согласованность данных при маштабировании? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токенами доступа в этой БД.

Здравствуйте, Kernan, Вы писали:

K>Как организовать совсемтную работу одного микросервиса со своей ДБ (пусть бует монгоДВ) чтобы обеспечить хотья как-то согласованность данных в ней? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токеми доступа в этой БД.
Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы.

А кто говорил, что будет легко?

C>Юные хипстеры эту схему реально довели до ума. В частности:
C>1) Начали разбираться с трассировкой и отладкой: https://opentracing.io/
C>2) Управление траффиком, в том числе throttling и load shedding: https://linkerd.io/
C>3) Субстрат, на который легко разворачивать приложения (Docker, Kubernetes).
Я вас с этим, конечно, поздравляю, только вот все это никак не опровергает мои слова

Здравствуйте, Cyberax, Вы писали:

C>Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы.
Как оно реализуется на практике? Чере ещё один микросервис?
C>А кто говорил, что будет легко?
Фаулер говорил

Здравствуйте, vsb, Вы писали:

vsb>account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.

А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а) всех хостов, реализущих данный сервис? Я так понимаю, что в основе всех
высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?

Здравствуйте, alex_public, Вы писали:

_>которые совместно решают целевую задачу. Это и есть те самые микросервисы.

Ни о какой совместности речи нет, совместность это mapreduce\hadoop, акторы наконец. А это именно однотипные изолированные функции.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, vsb, Вы писали:

vsb>>account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.

S>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а) всех хостов, реализущих данный сервис?

Как настроишь, так будет. Можно вернуть все адреса. Приложение должно стучаться во все адреса в указанном порядке, пока не найдёт рабочий. Можно один вернуть.

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

Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.

Здравствуйте, vsb, Вы писали:


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

vsb>Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.

Речь идет именно о возможности использовать доменные имена. Т.е. я у себя в сервисе прописываю account.mysite.com и все. Далее, когда мне будет нужен соотв. функционал, я делаю запрос по http://account.mysite.com/api1 и
инфраструктура мне вернет какой-нибудь инстанс. Доменные имена использовать проще, нежели ip, кмк.

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

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы.

Микросеривсы -- это идея, подход. Кластеры -- одна из возможных реализаций.

Здравствуйте, Sharov, Вы писали:

S>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
Это называется "round-robin load balancer", его ещё называют "балансировщиком для бедных". Просто регистрируем N A- (или CNAME) записей для одного и того же хостнейма, которые бы стреляли в разные IP адреса.
Теперь у нас при каждом запросе эти IP адреса будут отдаваться более-менее равномерно.

Настоящий load balancer отличается от вот этого подобия вот чем:
1. Умеет отключать вышедшие из строя сервера (обращение к мёртвому серверу стоит клиенту длительного таймаута)
2. Умеет отслеживать фактическую нагрузку
3. Умеет поддерживать session и client affinity

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
S>Это называется "round-robin load balancer", его ещё называют "балансировщиком для бедных". Просто регистрируем N A- (или CNAME) записей для одного и того же хостнейма, которые бы стреляли в разные IP адреса.
S>Теперь у нас при каждом запросе эти IP адреса будут отдаваться более-менее равномерно.

S>Настоящий load balancer отличается от вот этого подобия вот чем:
S>1. Умеет отключать вышедшие из строя сервера (обращение к мёртвому серверу стоит клиенту длительного таймаута)
S>2. Умеет отслеживать фактическую нагрузку
S>3. Умеет поддерживать session и client affinity


С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?

Здравствуйте, Kernan, Вы писали:

K>Как организовать совместную работу одного микросервиса со своей ДБ (пусть будет монгоДВ) чтобы обеспечить хоть как-то согласованность данных при маштабировании? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токенами доступа в этой БД.

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

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

Здравствуйте, Sharov, Вы писали:

S>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?

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

Здравствуйте, neFormal, Вы писали:


S>>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?

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

Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.

Здравствуйте, Sharov, Вы писали:

S>>>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?
F>>если используется какой-нить распределённый конфиг, то днс можно и не использовать, имена будут в конфиге.
S>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.

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

Здравствуйте, neFormal, Вы писали:

S>>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.

F>"распределённый конфиг" — это что-то типа NoSQL-бд.
F>к нему все цепляются, читают содержимое, подписываются на изменения полей.
F>там нет понятия "распространение".

Вообще-то есть, иначе это не распределенный конфиг. Т.е. изменения могут дойти не сразу. Отсюда, видимо, все эти service discovery и т.д.

Здравствуйте, Sharov, Вы писали:

S>>>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
F>>"распределённый конфиг" — это что-то типа NoSQL-бд.
F>>к нему все цепляются, читают содержимое, подписываются на изменения полей.
F>>там нет понятия "распространение".
S>Вообще-то есть, иначе это не распределенный конфиг. Т.е. изменения могут дойти не сразу.

если ты записал что-то в БД, её изменения сразу станут доступны клиентам? сразу. вот и тут то же самое.

S>Отсюда, видимо, все эти service discovery и т.д.

сервис дискавери — это про другое. это про "более позднее связывание".

Здравствуйте, Sharov, Вы писали:


S>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?
Эмм. Вы смешиваете три несвязанные вещи.
1. Микросервисы
2. Highload
3. DNS

Что может мне помешать поставить взрослый load-balancer с фиксированным IP-адресом и раскидывать запросы по стоящим за ним серверам? Вот есть, к примеру, очень популярный сервис с общеизвестным адресом 8.8.8.8 — чем вам не highload? При этом никаких микросервисов там нет, и никакого round-robin тоже нету.

Никто не может мне помешать делать "внешний" load-balancing путём возврата 302 на входящие запросы, раскидывая клиентов по настоящим адресам сервис-нодов.
И это мы ещё даже не начали копать.

Здравствуйте, Sharov, Вы писали:

S>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
Неудобно != невозможно. Существуют вполне себе готовые архитектуры, которые именно так и работают.
Вы же понимаете, что DNS — это не чудо господне, а всего лишь распределённая иерархическая СУБД? Причём у неё единожды и навсегда зафиксированная архитектура.
Поэтому если вас не устраивает тот механизм распространения, который применяется в DNS, то нет ничего сверхъестественного в использовании своей собственной архитектуры по распространению изменений.

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

Здравствуйте, Sinclair, Вы писали:

S>Никто не может мне помешать делать "внешний" load-balancing путём возврата 302 на входящие запросы, раскидывая клиентов по настоящим адресам сервис-нодов.
S>И это мы ещё даже не начали копать.

А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do?

Здравствуйте, Sharov, Вы писали:

S>А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do?
Не очень понятно, что вы имеете в виду. У запроса жизненный цикл простой — он начался и закончился. Это никак не зависит от архитектуры

Здравствуйте, Sinclair, Вы писали:

S>>А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do?
S>Не очень понятно, что вы имеете в виду. У запроса жизненный цикл простой — он начался и закончился. Это никак не зависит от архитектуры

Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А.
Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B.
И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?

Здравствуйте, neFormal, Вы писали:

F>обычно под "микросервисной архитектурой" понимают весь комплекс проблем.

Статья в педивикии такое обычное понимание не демонстрирует.

Здравствуйте, Sharov, Вы писали:

НС>>Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы.
S>Микросеривсы -- это идея, подход. Кластеры -- одна из возможных реализаций.

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

Здравствуйте, scf, Вы писали:

НС>>Services form information barriers
scf>Вообще-то это считается преимуществом

Кем считается?

НС>>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
scf>Да, но эти затраты невелики

Голословно.

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

Фигня.

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

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

Здравствуйте, mrTwister, Вы писали:

НС>>Не делай. Конкуренты сделают это за тебя.
T>...
НС>>А потому микросервисы на помоечку.
T>Дак я не понял: на помоечку, или конкуренты их сделают за меня?

И то, и другое

Здравствуйте, Sharov, Вы писали:

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

vsb>>Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.

S>Речь идет именно о возможности использовать доменные имена. Т.е. я у себя в сервисе прописываю account.mysite.com и все. Далее, когда мне будет нужен соотв. функционал, я делаю запрос по http://account.mysite.com/api1 и
S>инфраструктура мне вернет какой-нибудь инстанс. Доменные имена использовать проще, нежели ip, кмк.

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

S>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.

Load Balancer это концепция, некая сущность, которая распределяет нагрузку. DNS это один из вариантов. Другой вариант это reverse proxy, это сервер, который принимает HTTP-соединения (ну в общем случае не HTTP, но щас всё HTTP), возможно делает какие-то манипуляции с ними и пробрасывает уже тому серверу, который его будет обрабатывать. Т.е. по сути вся работа тут передавать байты от клиента к одному из рабочих серверов и назад.

Здравствуйте, scf, Вы писали:

scf>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.

Это и есть обещанная изоляция по данным?

Здравствуйте, Sharov, Вы писали:

S>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а) всех хостов, реализущих данный сервис?

Нет. Он вернет какой то один. Называется round robin dns. Я ссылку выше давал, сходи и почитай.

S> Я так понимаю, что в основе всех
S>высоконагруженных сервисов и тем более микросервисов находится dns.

Нет. Это самый примитивный и старый способ. В современных сервисах как правило используется reverse proxy с набором правил и health check.

Здравствуйте, Sharov, Вы писали:

S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А.
S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B.
S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, scf, Вы писали:

scf>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.

НС>Это и есть обещанная изоляция по данным?

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

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>У каждого сервиса собственный LB, для остальных сервисов он выглядит монолитом. В чем проблема?

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

Здравствуйте, Cyberax, Вы писали:

C>Я вообще не понимаю твой рвотный поток сознания. В чём вопрос-то?

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

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

Здравствуйте, Sharov, Вы писали:

S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А.
S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B.
S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?

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

Здравствуйте, Shmj, Вы писали:

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

Не не не, с микросервисной шизой к ее адептам.

Здравствуйте, Ночной Смотрящий, Вы писали:

scf>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.

НС>Это и есть обещанная изоляция по данным?
Изоляцию обещали не между экземплярами микросервиса, а между микросервисами.

Здравствуйте, vsb, Вы писали:

vsb>Над DNS обычно мало контроля. Протокол старинный, мало кто готов написать DNS-сервер со своей логикой. С точки зрения клиента ещё хуже, общеупотребительные библиотеки кешируют ответы, если есть промежуточный сервер, он тоже может закешировать и тд. Это удобно, когда нужно абсолютный минимум от масштабирования. Но если тебе надо направлять на нужный сервер в зависимости от значения HTTP Cookie, то, конечно, тут уже DNS не подойдёт.

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

Здравствуйте, scf, Вы писали:

scf>>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.
НС>>Это и есть обещанная изоляция по данным?
scf>конкретные претензии есть, или опять "голословно" "фигня" и поиск каких-то авторитетов, как будто своих мозгов нет?

Ты на вопрос ответь.

Здравствуйте, neFormal, Вы писали:

F>"распределённый конфиг" — это что-то типа NoSQL-бд.
Необязательно. Например, в некоторой бразильской речной компании используют gossip-схему. Для каждого узла назначается список buddy-узлов и они обмениваются блоками информации. В блоках содержатся данные координаторов и маска активности узлов кластера.

См.: https://en.wikipedia.org/wiki/Gossip_protocol

Здравствуйте, Cyberax, Вы писали:

F>>"распределённый конфиг" — это что-то типа NoSQL-бд.
C>Необязательно. Например, в некоторой бразильской речной компании используют gossip-схему. Для каждого узла назначается список buddy-узлов и они обмениваются блоками информации. В блоках содержатся данные координаторов и маска активности узлов кластера.
C>См.: https://en.wikipedia.org/wiki/Gossip_protocol

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

Здравствуйте, Kernan, Вы писали:

C>>Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы.
K>Как оно реализуется на практике? Чере ещё один микросервис?
Нет, силами самого сервиса.

C>>А кто говорил, что будет легко?
K>Фаулер говорил
Сервисная архитектура — это очень непростая вещь. Она требует планирования и большого опыта для правильного дизайна. Потому она оправдана только для уже реально больших и сложных приложений, над которыми работают множество команд.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а) всех хостов, реализущих данный сервис?
НС>Нет. Он вернет какой то один. Называется round robin dns. Я ссылку выше давал, сходи и почитай.

можно же и весь список запросить. RR просто прокручивает список на каждом запросе.

Здравствуйте, elmal, Вы писали:

K>>Ибо фронтэнд в современном мире будет по любому на JavaScript.

С появлением WebAssembly теперь писать фронт-енд можно (почти) на чём угодно. Хоть на плюсах.

Здравствуйте, namespace, Вы писали:

N>Средний такой pet-project(англ. проект собачьей будки) содержит около ~20 микросервисов, в каждом сервисе обычно от 3 до 50 строк кода.

Желаю удачи это всё дебажить.

Здравствуйте, Sharov, Вы писали:

S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А.
S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B.
S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
Обратится к сервисам B, C, D. В чём проблема?
Именно так и работают все современные системы — когда вы размещаете заказ в веб-магазине, там за кадром участвуют сервисы процессинга кредитных карт и служб доставки.
Не говоря уже обо всяких левых штуках типа "программы лояльности" и гугл-аналитики. При этом все эти сервисы, естественно, сидят за load balancer-ами.

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

Здравствуйте, Shmj, Вы писали:

S>В чем смысл микросервисов?
Смысл в том, что еще одно техническое решение, подход. Со своими достоинствами и недостатками. И если для конкретной задачи достоинства перевешивают недостатки сильнее, чем у других подходов, имеет смысл использовать именное его.

Здравствуйте, Dym On, Вы писали:

S>>В чем смысл микросервисов?
DO>Смысл в том, что еще одно техническое решение, подход. Со своими достоинствами и недостатками. И если для конкретной задачи достоинства перевешивают недостатки сильнее, чем у других подходов, имеет смысл использовать именное его.

А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

S>В чем смысл микросервисов?

вопрос.

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

Здравствуйте, Dym On, Вы писали:

НС>>А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом.
DO>Совершенно верно, но именно такой ответ может быть на такой
DO>

S>>В чем смысл микросервисов?

DO>вопрос.

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

DO>Задаешь общий вопрос, получаешь общий ответ. На тему «В чем смысл микросервисов» можно монографию в 5 томах написать, и то не осветишь все тонкости и нюансы.

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