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

Мне кажется, что за микросервисы оголтело топят те, кто никогда не отлаживал в сложной системе рейс сложного графа http вызовов

https://www.youtube.com/watch?v=FZEmZiMsm-0

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

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

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

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

3. Реализация такого функционала очень удобна для организации  сколько-нибудь сложных бизнес-процессов.

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

5. Более подробно можно посмотреть книжку Enterprise Integration Patterns (3) Книжка большая и несколько водянистая (так было принято писать в нулевые, что уж тут поделаешь)

6. Примеры реализации: Apache Camel, Spring Integrsation, Spring JMS, MDB из JEE. Различные реализации BPMN - jBPM, Activiti, Camunda... (интересно, что эти реализации используют СУБД, а не системы передачи сообщений). Отчасти DBMS_SCHEDULER из Oracle, pgpro_scheduler и много чего еще. Есть что-то для C#, но тут я точно не могу сказать.

7. Обычно все это крепко отдает кровавым энтерпрайзом, т.к. по своей сути именно им и является. Тем не менее я сделал себе подобную штуку для php и не вижу причин иметь ее хоть для NodeJS (с другой стороны так как это кровавый энтерпрайз и  интеграционное ПО, оно легко интегрируется хоть с шелловскими скриптами)


[1] https://ru.wikipedia.org/wiki/Сети_Петри
[2] https://en.wikipedia.org/wiki/Two-phase_commit_protocol
[3] http://www.enterpriseintegrationpatterns.com/

(c) fb.com/vpupken

Саш! Закон Амдала - это про ограничение на рост производительности при распараллеливании вычислений: «В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого длинного фрагмента».

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

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

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