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

B>а я кстати тут вот понял, что без кубера и докера у меня бы точно были проблемы. Читал, что вроде нормально это всё под линухом работает.
B>а у меня на проде венда + mssql.

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

M>Это сильно упрощает разработку, когда у тебя в сервисе меньше 10к строк и один разработчик.
M>Нет ни мердж конфликтов,

+1

M>не нужно ни с кем договариваться, не нужна документация,

Как минимум нужно предоставить документацию на API и получить feedback

M> планирование, архитектура.

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

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

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

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

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


G>>2) яндекс на старте не был микросервисным

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


G>>3) cd\cd без микросервисов работает лучше
B>звучит что микросервисы удел либо больших компаний либо крупных систем.

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

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

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

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

M>Как минимум нужно предоставить документацию на API и получить feedback

Прелесть RMM L3 в том, что он самодокументируемый и на 99% фидбека можно сразу отвечать: "это не RESTful, мы этого делать не будем"

M>слабо верится, и над архитектурой нужно тоже думать, и планировать (хотя бы по срокам имплементации этого самого API)

Так RMM L3 однозначный, там не над чем думать. Размышлений требует дефиниция ресурсов, но она в 90% случаев типовая и там опять же думать не над чем.

M>Так это вроде и без микросервисов всегда так было. Есть проблемы с производительностью — отвечает автор кода, являющегося узким местом.

Это вопрос не производительности, а потребляемых ресурсов. Микросервис суперпросто поднять, но суперсложно удалить. Например, компания, которая ввела внутренний биллинг, обнаружила себя тратящей несколько десятков миллионов в месяц на порядка тысячи микросервисов, которые непонятно кто и с какой целью поднял. Причем административными средствами проблема не решалась, потому что всегда оказывалось что микросервис поднял Вася пять лет назад для проекта X и за 5 лет Вася уволился, проект X влили в проект Y, который заменили на проект Z, в процессе два раза сменив команду и три раза сделав пивот на 180 градусов. И теперь концов уже не найти, нужен ли этот сервис СЕЙЧАС и если нужен, то ДЛЯ ЧЕГО.

M>Прелесть RMM L3 в том, что он самодокументируемый и на 99% фидбека можно сразу отвечать: "это не RESTful, мы этого делать не будем"

Чисто для общего развития.
RMM L3 — это когда, получив первый ресурс, мы по link/rel определяем, что с ним дальше можно сделать (и на какие url слать соответствующие запросы), так ведь?

Можно пример какого-нибудь публичного REST API, которое именно классический RMM L3 (т.е. не Graph QL и т.п.)?

Просто в моей микросервисной практике все попытки внедрить hypermedia в конечном итоге скатывались либо в полноценную Open API/Swagger спеку, либо в Graph QL, либо в текстовую документацию.

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

RD>RMM L3 — это когда, получив первый ресурс, мы по link/rel определяем, что с ним дальше можно сделать (и на какие url слать соответствующие запросы), так ведь?

Да, но не только. Это как с третьей нормальной формой, RMM L3, это RMM L2 + HATEOAS. В первую очередь хорошее API обеспечивается правильным разделением на ресурсы, с которыми можно оперировать с помощью HTTP глаголов. HATEOAS на это просто очень удачно ложится и позволяет не размывать логику между клиентом и сервером.

RD>Можно пример какого-нибудь публичного REST API, которое именно классический RMM L3 (т.е. не Graph QL и т.п.)?

PayPal API

RD>Просто в моей микросервисной практике все попытки внедрить hypermedia в конечном итоге скатывались либо в полноценную Open API/Swagger спеку, либо в Graph QL, либо в текстовую документацию.

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

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

G>В этом случае может быть выгодно иметь микросервисы как раз по границам команд. Других адекватных причин использовать MSA я не видел.

Ну ещё ограничить failure domain. Чтобы бага в одном углу приложения клала его не целиком, а только блокировала отдельные сценарии.

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

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

RD>>RMM L3 — это когда, получив первый ресурс, мы по link/rel определяем, что с ним дальше можно сделать (и на какие url слать соответствующие запросы), так ведь?

M>Да, но не только. Это как с третьей нормальной формой, RMM L3, это RMM L2 + HATEOAS. В первую очередь хорошее API обеспечивается правильным разделением на ресурсы, с которыми можно оперировать с помощью HTTP глаголов. HATEOAS на это просто очень удачно ложится и позволяет не размывать логику между клиентом и сервером.
Я не вижу каких-то прямо практически значимых преимуществ HATEOAS.
1. Discoverability немножко улучшается, но не очень значительно. Вот мы дёрнули какой-то ресурс GET-ом. Он прислал нам
— набор ссылок на объекты внутри своих свойств (типа "owner": "https://our-api-enpdoint/users/23412312-ws-44"}
— набор ссылок на "глаголы" в коллекции links (типа {"href": "https://api-m.paypal.com/v1/payments/sale/36C38912MN9658832/refund","rel": "refund","method": "POST"})
Дальше что? Всё равно, без чтения документации невозможно понять,
— можно ли в качестве owner использовать URL юзер-аккаунта в другом скоупе
— что делает глагол refund, и какие у него будут параметры, и где их брать
2. Evolvability улучшается крайне незначительно. У нас нет никакого способа научить клиентов всегда ходить только по указанным нами ссылкам. Если мы решили перенести endpoint для рефандов в другое место, то недостаточно просто отдавать новую ссылку в links. Примерно 99% разработчиков клиента зашьют логику генерации ссылки в своё приложение, вместо того, чтобы прикапывать URL для каждого платежа в своей системе (и тратить место; и опять же рисковать пойти по устаревшей ссылке) или там бегать всякий раз делать GET и искать этот ./links[@rel=refund] (и увеличивать нагрузку на сеть и латентность своих сервисов). Нам так или иначе придётся до каждого из них дойти и убедиться, что они переписали своё приложение
3. Накладные расходы значительно увеличиваются. Там, где в RMM L2 мы обходились GUID-ом, а то и вообще int-ом, теперь мы тащим длиннюшие урлы с совершенно бесполезными обрамлениями. Можно немножко починить это путём компрессии реквестов и респонсов, но всё равно — растёт allocation size для каждого запроса, учащаются сборки мусора, снижается общая эффективность, повышается расход электроэнергии.

Здравствуйте, busk, Вы писали:
B>Первое что хотел сказать, что везде пишут микросервисы это где много команд часто или много функционала. В этом проекте ни того ни другого не будет,
B>но зато скоп определен четко и подумал прекрасная возможность потренироваться, чтобы потом уверенее пробовать в большом проекте.
Это — хорошая идея.
B>Тут я понимаю, что проще было бы сделать монолит, но для обучения вполне годный вариант?
Да, проще. Да, годный — невозможно сходу научиться резать монолит на микросервисы так, чтобы не стало хуже, чем было.

B>Второе и собственно основное я так понял из книг, что самое сложное это определить границы сервисов.
Да, совершенно точно.

B>Вот прошу тут помощи как нарезать на сервисы и базы?

B>Приложение: — Система контроля доставок грузов в разных странах (стран 10).
B> — Юзеры заходят по user/pswd и система определяет страну и подгружает данные этой страны. Новый юзер сам может зарегаться по логину выданному ему и восстановить пароль.
B> — В системе будет 4 роли: sysadmin, admin, manager, driver. В каждой стране свои пользователи. Один пользователь = 1 страна.
B> — Сами заказы поступают в эту систему из другой. В этой надо только мониторить и делать разные действия если доставка задержалась или не приехала.
B> — В каждой стране много складов и поэтому когда заказы поступают в систему то они сразу попадают на нужный склад и спец алгоритм распределяет на водителей.

B> — sysadmin управляет только техническими настройками разными (кому когда отчеты отсылать, как в системе заводить оптуска, сколько часов в сутки можно работать, заводит праздники), остальное всё только в режиме просмотра видит.
B> — admin видит всё, не может только технические настройки менять. Следит за водителями, чтобы они всрок доставляли всё — по юаю специальному, вносит отпуска, больничные их, ставит им рабочее время. Если водитель увольняется — удаляет изи системы.
B> — manager следит за водителями своего склада только, может посмотреть по всем своим водителям информацию и по всем доставкам, но менять не может
B> — driver видит только по себе все сделанные доставки и предстоящие. Каждый раз когда он начинает и заканчивает доставку то в системе нажимает Start delivery\End delivery. Если доставка не укладывается в
B>предполагаемые сроки то пишет к доставке комментарий почему не успел

Важно, чтобы микросервисы как можно меньше взаимодействовали между собой. Если не получается — значит, границы выбраны неверно.
По вашему описанию не вполне понятно, что собственно должна делать система. Распределять заказы между водителями?
Смотрите:
0. Сервис аутентификации. Его хочется делать крайне надёжной, т.к. если никто не может зайти, то не работает вообще всё. Очень опасно делать монолит, в котором выкат какой-нибудь мелкой фичи типа "а давайте поздравим всех водителей-женщин с 8 марта" способен сломать логин. То есть эту штуку мы как можно реже релизим, и при каждом выкате покрываем тестами в шесть слоёв. Отдельные пацаны аудируют код на предмет потенциальных уязвимостей, т.к. кража базы паролей — почти самое плохое, что с нами вообще может случиться. Сам сервис скорее всего раскатан в нескольких экземплярах с геодистрибуцией и офигенной избыточностью — чтобы отключение света в нижегородском ДЦ не валило всю федеральную сеть водителей.
(Кстати, очень часто мы захотим это вообще делегировать наружу, чтобы не заниматься дорогостоящими инвестициями в эти пять девяток и прочие особенности. Привинчиваем OAuth и полагаемся на Google/Facebook/etc)
1. Сервис авторизации. После того, как пользователь залогинился, нам нужно ещё и получить набор его прав. В большинстве случаев это довольно-таки типовая структура, вроде ролей. Опять же, требования к ней довольно-таки жёсткие, т.к. она нужна в каждом первом сценарии. Ещё можно заметить, что она в значительной мере дублирует информацию из 0-й системы — как минимум, у нас должен быть тот же самый список пользователей. Поэтому в современном мире зачастую 0 и 1 объединяют в одну.
2. Сервис профилей. Всякие личные данные, предпочтения, и прочее. Набор этих данных меняется относительно часто, поэтому несмотря на структурную похожесть с предыдущим сервисом, его имеет смысл держать отдельно. Если даже кто-то очень криво выкатит обнову, которая даёт пользователю вместо фоточки на аватару выкладывать короткий ролик, логины и права продолжат работать.
Опять же, данные этого сервиса подпадают под всякие регуляторные нормы типа GDPR и его аналогов, поэтому имеет смысл их держать в отдельной базе с отдельными полисями бэкапа, контроля доступа, и функций своевременной очистки.
3. Сервис флагов/пользовательских настроек. Иногда его объединяют с предыдущим, но в большой системе лучше разделять. Потому что требования разные — флаги и настройки не являются personal information, зато постоянно нужны другим сервисам для принятия решений типа "а можно ли этого водителя назначить на рейс в Европу".

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

Обратите внимание, во всех сервисах, которые пока что были перечислены, есть понятие "пользователя". Типичной ошибкой начинающих проектировщиков является идея "а давайте мы всех пятерых подключим к одной базе данных — в конце-концов, список пользователей-то у нас общий! Зачем его дублировать?".
Вот это — плохая идея: получите все недостатки МСА без её достоинств. Да, список пользователей будет дублироваться. Да, на это придётся потратить немножко усилий. Но на самом деле всё не так уж и плохо — в том смысле, что, к примеру, настоящее имя пользователя и его дата рождения хранится только в одной системе, а какие-нибудь данные о его трудовой биографии — в другой. Дублирования не так уж и много; основное затруднение — невозможность контролировать ссылочную целостность. У вас всегда будет риск получить в четырёх базах "подвисшие" записи для пользователей, логин которых был забанен в 0м сервисе навсегда. Уборка мусора становится отдельной maintenance задачей.

Едем дальше — вот у нас что-то там про доставки. Собственно, тут пояснений недостаточно, придётся фантазировать. Очевидно, нужен какой-то сервис, который показывает водителю его доставки и позволяет с ними взаимодействовать.
Раздача доставок по водителям может быть частью этого сервиса, а может быть отдельной подсистемой. Чтобы опять же нововведения в алгоритме раздачи заявок не могли ничего отломать в учёте статуса доставок — у водителя в пути не всегда есть возможность "подождать до четверга", чтобы отметить статус заявки. Этому сервису будут нужны данные о том, кто когда планируется на смене — из того сервиса, где учитывались больничные/отпуска и т.п. Обратите внимание, что ему не надо никаких подробностей — можно придумать относительно стабильный, узкий API, по которому этот сервис запрашивает доступность того или иного водителя.

Наверняка нам потребуются какие-нибудь отчёты. Вот тут обычно начинаются приключения, потому что отчёты запросто могут соединять данные изо всех систем. Типа "а давайте посчитаем корреляцию между выработкой водителя, его возрастом и стажем работы". Кроме того, у этих отчётов совсем другой цикл работы, и отдельные требования к надёжности. Поэтому, опять же в предположении большой или очень большой системы, мы не будем их привинчивать ни в какой из упомянутых сервисов. И не будем их привинчивать поверх общей базы данных. Вместо этого у нас будет отдельный data warehouse, куда будет собираться первичная инфа изо всех сервисов (и заодно в "активных" сервисах будут подчищаться архивы, чтобы избежать деградации производительности над текущими задачами), а уже в этот warehouse, который выступает отдельным сервисом, будет даден доступ всем уполномоченным и заинтересованным.

Вот примерно так это и должно работать.

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

S>Я не вижу каких-то прямо практически значимых преимуществ HATEOAS.

HATEOAS позволяет не размазывать логику между сервером и клиентом. Клиенту не нужно думать, можно ему дергать какой-то ресурс или нет. Прислали ссылку, значит можно. Не прислали -- нельзя. Вместе с OPTIONS это такой подход позволяет полностью перенести авторизацию с клиента на сервер. Или, например, пейджинг: клиенту не нужно вычислять сколько страниц всего, какая предыдущая, какая следующая и т.п. Вместо этого ему сразу приходит список страниц, которые можно дернуть.

S>- можно ли в качестве owner использовать URL юзер-аккаунта в другом скоупе

HATEOAS это про чтение, что ты собрался использовать при чтении. Можно ли поменять owner? Надо пробовать, может да, может нет, может в каких-то случаях да, а в остальных нет. Даже OpenAPI не позволяет описать настолько сложные контракты.

S>- что делает глагол refund, и какие у него будут параметры, и где их брать

Это же ресурс, делаешь GET, смотришь, меняешь, делаешь PUT.

S>2. Evolvability улучшается крайне незначительно. У нас нет никакого способа научить клиентов всегда ходить только по указанным нами ссылкам. Если мы решили перенести endpoint для рефандов в другое место, то недостаточно просто отдавать новую ссылку в links.

Правильно делать GET перед PUT, потому что ссылки могут измениться, и вообще конкурентные обновления. Если разработчики не умеют пользоваться REST API это их проблема. Можно тупо менять ссылки при каждом запросе, чтобы даже желания сохранять их куда либо не возникало.

S>3. Накладные расходы значительно увеличиваются.

Я тебя умоляю, мы видео в 4К по сети гоняем и GUID вместо id используем. Несколько ссылок погоды не сделают.

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

M>HATEOAS позволяет не размазывать логику между сервером и клиентом. Клиенту не нужно думать, можно ему дергать какой-то ресурс или нет. Прислали ссылку, значит можно. Не прислали -- нельзя.
Это заблуждение. Авторизация проверяется совершенно отдельно. Ещё не хватало в представлении ресурса показывать разный набор ссылок в зависимости от transient штуки вроде Bearer-токена.

M>Вместе с OPTIONS это такой подход позволяет полностью перенести авторизацию с клиента на сервер.
Размещение авторизации ортогонально HATEOAS. Естественно, она полностью выполняется на сервере. Если вы хотите прятать кнопки на клиенте на основе правил авторизации, то это в большинстве случаев контрпродуктивная идея.

M>Или, например, пейджинг: клиенту не нужно вычислять сколько страниц всего, какая предыдущая, какая следующая и т.п. Вместо этого ему сразу приходит список страниц, которые можно дернуть.
Да, пейджинг — это один из немногих случаев корректного и полезного применения ссылок. Но вообще, его изготовить правильно — очень сложно. Сильно сложнее, чем кажется на первые три взгляда. В частности, "список страниц, которые можно дёрнуть" — плохая идея, которая ломается в большом количестве сценариев.

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

M>HATEOAS это про чтение, что ты собрался использовать при чтении.
Нет конечно. HATEOAS — это про идентификацию ресурсов. REST сам по себе (даже без HATEOAS) — как раз про то, что все действия выполняются через управление представлением состояния.
В частности, приделывание к платёжке ссылки refund с методом POST — это RMM не L3, а L1. Потому, что нормальный способ — это PUT либо PATCH, которые прямым либо косвенным образом меняют состояние платежа на refunded.

M>Можно ли поменять owner? Надо пробовать, может да, может нет, может в каких-то случаях да, а в остальных нет. Даже OpenAPI не позволяет описать настолько сложные контракты.
Конечно позволяет. Вот у вас есть объект, у него есть представление. Всё, можно делать PUT этого представления. Если что-то запрещено бизнес-правилами — приедет 409. Если правами доступа — 403.

S>>- что делает глагол refund, и какие у него будут параметры, и где их брать
M>Это же ресурс, делаешь GET, смотришь, меняешь, делаешь PUT.
Нет конечно. Это не ресурс, это адрес для POST запроса.

M>Правильно делать GET перед PUT, потому что ссылки могут измениться, и вообще конкурентные обновления. Если разработчики не умеют пользоваться REST API это их проблема. Можно тупо менять ссылки при каждом запросе, чтобы даже желания сохранять их куда либо не возникало.
Ну, у нас же нет REST-полиции. Никто вас не арестует за такую реализацию (и за любую другую). Но на практике людям больше нравятся сервисы, которые не требуют от них делать лишние запросы, увеличивая трафик и латентность.
Особенно когда гипотетическая нужда переноса URL-ов для parent payment не наступает никогда.

M>Я тебя умоляю, мы видео в 4К по сети гоняем и GUID вместо id используем. Несколько ссылок погоды не сделают.
Сделают. Стоимость эксплуатации складывается из мелочей. Два-три десятка таких идиотских решений — и вот уже ваш стейкхолдер вместо одного виртуального сервера оплачивает ферму из восьми выделенных.

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

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

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

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

Я бы начал с ответа на вопрос: зачем вообще тебе микросервисы? Просто попробовать или действительно есть нужда? Просто пробовать на боевом проекте это почти всегда или фиаско, или бессонные ночи. Иногда сразу оба варианта В моём случае я оба раза выбирал микросервисы по прочине нехватки ресурсов для реализации всего функционала. Но не надо путать с нехваткой ресурсов для написания микросервисов как таковых — что монолит, что микросервисы потребовали бы целой команды, а я был один. Поэтому я разбил проект на непересекающиеся модули и для каждого использовал фреймворк или библиотеку, которая на старте давала 80% функционала из коробки. Например, нужен обыкновыенний CRUD? — Берём сразу Rail и не думаем. Илитных икспертов, которые расскажут, что Ruby медленный, посылаем в /dev/null — современный Ruby можно горизонтально масштабировать, а выигрышь от ускорения за счёт использования другого языка никогда не окупит время разработки эквивалентного функционала на этом языке. Теперь помимо CRUD нужно добавить возможность запускать процессы (например, мы пишем свой godbolt), изолировать их и контролировать. Отлично! Используем systemd для запуска процессов, а контроль осуществим через DBus. И как круто, что есть возможность генерировать интерфейсы классов на Python для DBus — не нужно руками прописывать вызовы API! Теперь у нас есть Ruby и Python. Просто связываем их через БД (вообще любая подойдёт). И вот у нас уже микросервисы. А если пойти дальше, то выяснится, что пресловутые микросервисы это REST гипертрофированный до размера операционной системы — состояние хранится где-то на диске (или в памяти в особо тяжёлых случаях), вызовы происходят через сервисы, а корректность состояния осуществляется через блокировки хранилища. Другого пока не придумали. Сложности и ошибки возникают, когда какой-то smart ass, решает, что он очень уж smart и пытается вынести контроль целостности данных с уровня хранилища на уровень приложения. Не надо так делать, и всё будет хорошо. И не надо бояться использовать разные языки. Лично я не понимаю, какой вообще смысл микросервисов, если мы всё пишем на одном языке? Теряется вся гибкость, всё преимущество возможности стоять на плечах гигантов и использовать готовые решения.

B>Третий вопрос. Если без докеров то как настроить этот набор микросервисов? тут их немного будет и читал что можно настроить без докер контейнеров если что.

Это вообще ортогональный вопрос. Контейнеры и микросервисы никак не связаны, но контейнеры позволяют изолировать многие процессы, в том числе и процесс выкатывания обновлений. Если, например, сервис это .exe то вообще никакой выгоды от контейнеров. Ну и при горизонтальном масштабировании не приходится настраивать систему с нуля. Но если не нравится докер, то есть контейнеры systemd, если lxc — выбирай на свой вкус.

Резюме: 80% написанного в личных блогах про микросервисы это каргокульт, можно не читать. Микросервисы это вообще обыкновенная архитектура — 100% современных автомобилей используют микросервисную архитектуру ещё с нулевых, не нужно её бояться. Купи книгу с кабанчиком (Клепман) и прочти её три раза.

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

C>Так, во-первых не слушай старых пердунов (ну, или молодых смузихлёбов , утверждающих, что для микросервисной архитектуры нужны большие ресурсы. Я целых два(!!!) раза успешно реализовывал микросервисы в одиночку.
Мы все видели твои решения в некоторых разделах. Что ты там успешно напроектировал и реализовал — большой вопрос .

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

G>В этом случае может быть выгодно иметь микросервисы как раз по границам команд. Других адекватных причин использовать MSA я не видел.
В мною виденных трейдинговых системах — везде сабж. Одна команда (~10 девов) пилит пол-сотни приложух, которые разворачивачивется в ~тысячу сервисов на десятках хостов в пятёрке датацентров.
И да, сервисы не через REST взаимодйествуют, а через pub-sub сообщения (kafka/29west/mq/fix/аналоги).

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

C>Я бы начал с ответа на вопрос: зачем вообще тебе микросервисы?
Дайте своё определение микросервисов.

C>А если пойти дальше, то выяснится, что пресловутые микросервисы это REST гипертрофированный до размера операционной системы — состояние хранится где-то на диске (или в памяти в особо тяжёлых случаях), вызовы происходят через сервисы, а корректность состояния осуществляется через блокировки хранилища.
Это Вы Кафку и прочие MQ REST-ом обозвали? Зачем?

C>Купи книгу с кабанчиком (Клепман) и прочти её три раза.
"Кабанчик" хорош, но его мало. Например, он никак не поможет определить границы сервисов.

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

M>Это вопрос не производительности, а потребляемых ресурсов. Микросервис суперпросто поднять, но суперсложно удалить. Например, компания, которая ввела внутренний биллинг, обнаружила себя тратящей несколько десятков миллионов в месяц на порядка тысячи микросервисов, которые непонятно кто и с какой целью поднял. Причем административными средствами проблема не решалась, потому что всегда оказывалось что микросервис поднял Вася пять лет назад для проекта X и за 5 лет Вася уволился, проект X влили в проект Y, который заменили на проект Z, в процессе два раза сменив команду и три раза сделав пивот на 180 градусов. И теперь концов уже не найти, нужен ли этот сервис СЕЙЧАС и если нужен, то ДЛЯ ЧЕГО.

Как-то не очень в такое верится.
"Тысячи микросервисов" — это при инстансы или типы сервисов?

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

S>Обратите внимание, во всех сервисах, которые пока что были перечислены, есть понятие "пользователя". Типичной ошибкой начинающих проектировщиков является идея "а давайте мы всех пятерых подключим к одной базе данных — в конце-концов, список пользователей-то у нас общий! Зачем его дублировать?".
S>Вот это — плохая идея: получите все недостатки МСА без её достоинств. Да, список пользователей будет дублироваться. Да, на это придётся потратить немножко усилий. Но на самом деле всё не так уж и плохо — в том смысле, что, к примеру, настоящее имя пользователя и его дата рождения хранится только в одной системе, а какие-нибудь данные о его трудовой биографии — в другой. Дублирования не так уж и много; основное затруднение — невозможность контролировать ссылочную целостность. У вас всегда будет риск получить в четырёх базах "подвисшие" записи для пользователей, логин которых был забанен в 0м сервисе навсегда. Уборка мусора становится отдельной maintenance задачей.

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

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

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

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

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

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

API приложения полностью зависит от нужд потребителя. Договариваться придётся.
И документация на API нужна (даже если у вас RMM L3). Людям нужно знать не столько функционал отдельного эндпойнта, сколько возможность осуществить некоторый сценарий. Свагер такого не описывает.

M>Выставляешь Restful API и проблема других сервисов как этим API воспользоваться.
Даже условный Яндекс с его, например, Картами не может себе такого позволить и думает о потребителях, иначе конкуренты сожрут.

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

C>>Я бы начал с ответа на вопрос: зачем вообще тебе микросервисы?
TG>Дайте своё определение микросервисов.

Зачем?

TG>Это Вы Кафку и прочие MQ REST-ом обозвали? Зачем?

Ну, это было очень грубое сравнение. Просто мало людей понимают, что есть данные и есть код, и код изменяет данные. И можно придумывать велосипед снова и снова и говорить про принципиально новые подходы к разработке, но суть меняется мало. Например, возьмём понолит, реализуем ключевые функции через динамические библиотеки, реализуем механизм горячего обновления функций при измении соответствующего файла библиотеки — опа! У нас получилась микросервисная архитектура. Или не микросервисная — как посмотреть. Я работал в разных проектах — от социальных сетей до роботов, и везде было одно и то же: код, данные, шины обмена данными, интерфейсы взаимодейсвтия. И когда начинают сраться по поводу микросервисов и монолитов, я в упор не понимаю, в чём реально принципиальная разница? Если открыть произвольную статью про проблемы микросервисов, то 99% нытья сведётся к тому, что архитектура получилась слабосвязная, валидации никакой нет, поэтому команды каждый день ломают друг другу совместимость. Но это норма. Когда-то срались по поводу REST vs. XML RPC (хотя это ложная дихотомия, одно не отменяет другого), потом конечно же RPC вернулся в виде gRCP и Thrift, только об этом стыдливо умолчали, ведь сколько людей было унижено на собеседовании вопросами об абсолютном доминировании REST.

TG>"Кабанчик" хорош, но его мало. Например, он никак не поможет определить границы сервисов.

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