Коллеги,
Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.
У каждого микросервиса — собственная выходная очередь. Создание большого кол-ва очередей, их администрирование и аутентификация решается через автоматизацию девопса.
Здравствуйте, Gattaka, Вы писали:
G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.
В SOA (которая Service-oriented architecture) есть два подхода к тому, как делается связка сервисов:
Service choreography — когда каждый сервис передает управление следующему, тот следующему и т.д.. При этом нет какого центрального узла, который бы следил за тем, кто когда и с какими данными получает управление.
Service orchestration — когда есть центральный сервис (business-process management, workflow, ESB, ...) который выстраивает весь процесс работы: там, обычно есть некое описание (часто — графическое) последовательности взаимодействия сервисов (причем нормальная практика, когда процесс инициируется обращением к какому-то сервису)
Собственно, пляшите отсюда.
Если вам нужны названия конкретных библиотек/продуктов, то надо сначала узнать ваши условия (чем пользуетесь, где хостите, ...).
P.S. По моим ощущениям хореография куда сложнее в поддержке, если число сервисов начинает расти, у оркестровки, за счет того, что весь процесс описан в одном месте, гораздо проще делать сквозные изменения. Но зато этот центральный узел обычно становится узким местом.
Здравствуйте, Gattaka, Вы писали:
G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.
Здравствуйте, Михаил Романов, Вы писали:
МР>Service choreography — когда каждый сервис передает управление следующему, тот следующему и т.д.. При этом нет какого центрального узла, который бы следил за тем, кто когда и с какими данными получает управление. МР>Service orchestration — когда есть центральный сервис (business-process management, workflow, ESB, ...) который выстраивает весь процесс работы: там, обычно есть некое описание (часто — графическое) последовательности взаимодействия сервисов (причем нормальная практика, когда процесс инициируется обращением к какому-то сервису)
А как оба варианта организуются технически? Есть где почитать подробнее?
Здравствуйте, Nikolay_Ch, Вы писали: N_C>А как оба варианта организуются технически? Есть где почитать подробнее?
Прямо конкретную литературу я, наверное, не назову...
Если же описать на пальцах, то получится примерно так. Сhoreography
Каких-то специальных решений я не видел, и, подозреваю, их нет. По большому счету, всё делается путем вызова одних сервисов их других, причем это может быть вызов в режиме Request-Replay, а может быть через передачу сообщения.
В первом случае получается этакое дерево вызовов, где каждый "вышележащий" сервис ждет завершения всех своих дочерних сервисов.
Во втором, как уже писали коллеги, каждый сервис использует входящий endpoint в виде очереди сообщений, которую и разгребает потихоньку, при этом формируя сообщения для других.
Собственно, техническая часть — это протоколы самих сервисов, в первую очередь SOAP (т.к. он поддерживает как режим Request-Replay, так и передачу в очередях сообщений), фреймворки для создания Web Services, а также очереди сообщений.
Orchestration
Вот здесь всё куда интереснее.
Дело в том, что идея очень здорово пересеклась с популярными в 2005-2010 годах концепциями процессного управления (Business process management, BPM) и сервисного подхода в организации (Service-oriented architecture, SOA).
Эти концепции попытались перенести и в IT. Т.е. идея, по сути была в том, что:
У нас есть ряд систем, каждая из которых решает свою задачу (разной степени широты или узости).
Вместо того, чтобы делать тысячи интеграций каждой пары систем или пытаться заменить все системы одним большим монстром, мы делаем из каждой системы сервис с фиксированным интерфейсом (не обязательно это Web Service или очередь сообщений — может и обмен файликами или пересылка данных через таблицу БД).
В центре же у нас стоит специальный сервер, задача которого организация процессов, которые соединяют множество систем. Например, процесс приема нового сотрудника инициируется из системы работы с кандидатами, проходит через кадровый учет, бухгалтерию и отдел безопасности, а если человек пришел с госслужбы, то должна сработать отдельная ветка, где пойдет задача, например HR-ам, уведомить госорганы, что человек у нас начал работу.
В результате образовался целый класс систем для работы с BP.
Там есть достаточно большая терминологическая путаница, но можно с большой долей вероятности утверждать, что BPMS (Business Process Management Systems) и ESB (Enterprise Service Bus) — суть одно и то же.
Такая система обычно включает в себя:
Инструменты для описания бизнес-процессов. Это как правило графическая рисовалка на базе одной из распространенных нотаций
Инструментария разработчика (редко когда всё можно было чисто мышкой нарисовать)
Движка исполнения процесса (чаще всего его называют BPM Engine или Workflow Engine)
Коннекторов к разным системам и/или протоколом, от универсальных (типа email, web service, database, flat file, ...) до специализированных типа коннектора к 1C и SAP.
Инструментов мониторинга и анализа (чтобы понимать, где узкие места)
Иногда еще отдельно называют UI для конечных пользователей (типа система назначенных заданий), но чаще это делает через что-то стороннее — например задания выдаются письмами.
Конкретные системы, которые можно назвать: IBM WebSphere ESB, TIBCO, Vitria, Oracle Enterprise Service Bus, Microsoft BizTalk, OpenESB, ... В большинстве своем они достаточно монструозны и дороги.
Что касается средств описания и разработки...
Тут тоже полно всего (у многих систем долгое время была своя нотация, у некоторых она так и осталась своя ...) но из всего это я бы выделил 2 стандарта:
Первый это язык описания процессов в виде диаграмм.
Он включает в себя и сами диаграммы и формат для их хранения и передачи. Диаграммы выглядят примерно так:
BPMN диагармма
Второй — это XML язык, который в декларативной форме описывает выполнение процесса. Он, например, позволяет:
Описывать поток управления (последовательно, ветвления, циклы)
Описывать вызовы веб-сервисов
Описывать некие преобразования информации, которые происходят внутри (там можно и переменные объявить, и действия над ними сделать и потом результат отдать сервису и получить ответ)
Т.е. вообще это чистой воды язык для оркестровки.
Выглядит примерно так
<?xml version="1.0"encoding="utf-8"?>
<!-- Asynchrnous BPEL process -->
<process name="BusinessTravelProcess"
targetNamespace="http://packtpub.com/bpel/travel/"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:trv="http://packtpub.com/bpel/travel/"
xmlns:emp="http://packtpub.com/service/employee/"
xmlns:aln="http://packtpub.com/service/airline/" >
<partnerLinks>
<partnerLink name="client"
partnerLinkType="trv:travelLT"
myRole="travelService"
partnerRole="travelServiceCustomer"/>
<partnerLink name="employeeTravelStatus"
partnerLinkType="emp:employeeLT"
partnerRole="employeeTravelStatusService"/>
<partnerLink name="AmericanAirlines"
partnerLinkType="aln:flightLT"
myRole="airlineCustomer"
partnerRole="airlineService"/>
<partnerLink name="DeltaAirlines"
partnerLinkType="aln:flightLT"
myRole="airlineCustomer"
partnerRole="airlineService"/>
</partnerLinks>
<variables>
<!-- input for this process -->
<variable name="TravelRequest" messageType="trv:TravelRequestMessage"/>
<!-- input for the Employee Travel Status web service -->
<variable name="EmployeeTravelStatusRequest" messageType="emp:EmployeeTravelStatusRequestMessage"/>
<!-- output from the Employee Travel Status web service -->
<variable name="EmployeeTravelStatusResponse" messageType="emp:EmployeeTravelStatusResponseMessage"/>
<!-- input for American and Delta web services -->
<variable name="FlightDetails" messageType="aln:FlightTicketRequestMessage"/>
<!-- output from American Airlines -->
<variable name="FlightResponseAA" messageType="aln:TravelResponseMessage"/>
<!-- output from Delta Airlines -->
<variable name="FlightResponseDA" messageType="aln:TravelResponseMessage"/>
<!-- output from BPEL process -->
<variable name="TravelResponse" messageType="aln:TravelResponseMessage"/>
</variables>
<sequence>
<!-- Receive the initial request for business travel from client -->
<receive partnerLink="client"
portType="trv:TravelApprovalPT"
operation="TravelApproval"
variable="TravelRequest"
createInstance="yes" />
<!-- Prepare the input for the Employee Travel Status Web Service -->
<assign>
<copy>
<from variable="TravelRequest" part="employee"/>
<to variable="EmployeeTravelStatusRequest" part="employee"/>
</copy>
</assign>
<!-- Synchronously invoke the Employee Travel Status Web Service -->
<invoke partnerLink="employeeTravelStatus"
portType="emp:EmployeeTravelStatusPT"
operation="EmployeeTravelStatus"
inputVariable="EmployeeTravelStatusRequest"
outputVariable="EmployeeTravelStatusResponse" />
<!-- Prepare the input for AA and DA -->
<assign>
<copy>
<from variable="TravelRequest" part="flightData"/>
<to variable="FlightDetails" part="flightData"/>
</copy>
<copy>
<from variable="EmployeeTravelStatusResponse" part="travelClass"/>
<to variable="FlightDetails" part="travelClass"/>
</copy>
</assign>
<!-- Make a concurrent invocation to AA in DA -->
<flow>
<sequence>
<!-- Async invoke of the AA web service and wait for the callback -->
<invoke partnerLink="AmericanAirlines"
portType="aln:FlightAvailabilityPT"
operation="FlightAvailability"
inputVariable="FlightDetails" />
<receive partnerLink="AmericanAirlines"
portType="aln:FlightCallbackPT"
operation="FlightTicketCallback"
variable="FlightResponseAA" />
</sequence>
<sequence>
<!-- Async invoke of the DA web service and wait for the callback -->
<invoke partnerLink="DeltaAirlines"
portType="aln:FlightAvailabilityPT"
operation="FlightAvailability"
inputVariable="FlightDetails" />
<receive partnerLink="DeltaAirlines"
portType="aln:FlightCallbackPT"
operation="FlightTicketCallback"
variable="FlightResponseDA" />
</sequence>
</flow>
<!-- Select the best offer and construct the TravelResponse -->
<switch>
<case condition="bpws:getVariableData('FlightResponseAA','confirmationData','/confirmationData/aln:Price')
<= bpws:getVariableData('FlightResponseDA','confirmationData','/confirmationData/aln:Price')">
<!-- Select American Airlines -->
<assign>
<copy>
<from variable="FlightResponseAA" />
<to variable="TravelResponse" />
</copy>
</assign>
</case>
<otherwise>
<!-- Select Delta Airlines -->
<assign>
<copy>
<from variable="FlightResponseDA" />
<to variable="TravelResponse" />
</copy>
</assign>
</otherwise>
</switch>
<!-- Make a callback to the client -->
<invoke partnerLink="client"
portType="trv:ClientCallbackPT"
operation="ClientCallback"
inputVariable="TravelResponse" />
</sequence>
</process>
Что на сегодня
Мое глубоко личное мнение: в том виде как описано выше, системы BPMS не прижились. ESB я в основном встречал в банках. Ну и более-менее их подходы сейчас есть в российских системах документооборота. Правда там в основном они используются чисто как Workflow движок, который используется для процессов внутри системы, а оркестровка внешних — чисто в дополнение.
Однако, полностью от идеи оркестровки вендоры отказаться не могут и время от времени появляются более легковесные решения типа Azure Logic Apps или Microsoft Flow
Также большой вопрос по чисто программистским инструментам. В том же .Net выход Windows Workflow Foundation практически напрочь уничтожил конкурентов, но сам WF... ну не то чтобы приказал долго жить, но практически встал в развитии.
Добавлю про ESB — основная проблема оркестрации, помимо быстродействия, это скоуп. Доработки сервисов влекут за собой доработки правил ESB, на который завязаны все сервисы. Это означает, что сломаться, в принципе, может любая функциональность в любом микросервисе.
Я считаю, что хороший микросервис должен быть максимально изолированным и полезным сторонним разработчикам без доступа к исходникам, а ESB — это фактический монолит, прикрытый фиговым листочком правил роутинга сообщений.
Здравствуйте, scf, Вы писали:
scf>У каждого микросервиса — собственная выходная очередь. Создание большого кол-ва очередей, их администрирование и аутентификация решается через автоматизацию девопса.
Это работает ровно до того момента, пока у тебя линейная цепочка сервисов. Это работает в целом ряде юзкейсов. Если же правила игры несколько сложней(например нужен реквест-реплай, броадкастинг и тд), то начинается велосипедостроение и в конечном итоге можем получить неподдерживаемого монстра.
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.
Решения ессна же есть. Но не зная деталей сложно присоветовать в каком направлении двигаться. Я бы рекомендовал начать с этого, затем перейти к чему нить типа этого или вот этого а потом уверенно асилить это ну и контрольный в голову.
Затем несколько лет практики, набивания шишек — и все получится
Здравствуйте, itslave, Вы писали:
I>Это работает ровно до того момента, пока у тебя линейная цепочка сервисов. Это работает в целом ряде юзкейсов. Если же правила игры несколько сложней(например нужен реквест-реплай, броадкастинг и тд), то начинается велосипедостроение и в конечном итоге можем получить неподдерживаемого монстра.
Ну, с броадкастингом всё хорошо, не вижу особых проблем читать нескольким получателям из одной очереди(если не стоит остро проблема удаления старых данных из очереди).
Про реквест-реплай через очереди — этот кактус жуют многие банки, т.к. распределенная архитектура на JMS durable queue с транзакциями хорошо проработана теоретически и обкатана практически.
Моё мнение — что очереди нужны только там где есть необходимость данные буферизировать — к примеру, если апстрим хочет отдать и коммитить данные быстрее, чем даунстрим способен их обработать.
Здравствуйте, scf, Вы писали:
scf>Моё мнение — что очереди нужны только там где есть необходимость данные буферизировать — к примеру, если апстрим хочет отдать и коммитить данные быстрее, чем даунстрим способен их обработать.
Твое мнение канечна интересно, но есть чуваки, которые с тобой не согласны. В чем я их поддерживаю чуть боле чем полностью.
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, scf, Вы писали:
scf>>Моё мнение — что очереди нужны только там где есть необходимость данные буферизировать — к примеру, если апстрим хочет отдать и коммитить данные быстрее, чем даунстрим способен их обработать.
I>Твое мнение канечна интересно, но есть чуваки, которые с тобой не согласны. В чем я их поддерживаю чуть боле чем полностью.
Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.
edit: прочитал подглаву "Why Use Messaging?". Судя по набору доводов, книжка и правда устарела. Часть доводов применима и к RPC, часть упирает на отсутствие асинхронности и троттлинга в RPC(давно сделано), часть исходит из надежности железа и ненадежности сети (в современном виртуализованном мире железо ненадежно!), а остальные входят в категорию "нам действительно нужно хранить данные т.к. скорость отправителя выше скорости получателя".
RPC крут именно тем, что он stateless — нам не нужно ничего хранить. Сервис очередей требует внимания DBA, как и база данных. Очередь может переполниться, данные из очереди могут быть потеряны (кто делает бэкапы очередей?), при проблемах в системе нужно смотреть содержимое очередей (для большей части систем такой возможности нет).
Здравствуйте, scf, Вы писали:
scf>Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.
А что изменилось за пять лет в HTTP/REST?
scf>Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.
В этой книжке устарело только то, что описанные паттерны не надо имплементировать вручную, просто выбрать нужный сервис бас. Все.
scf>edit: прочитал подглаву "Why Use Messaging?". Судя по набору доводов, книжка и правда устарела. Часть доводов применима и к RPC, часть упирает на отсутствие асинхронности и троттлинга в RPC(давно сделано), часть исходит из надежности железа и ненадежности сети (в современном виртуализованном мире железо ненадежно!), а остальные входят в категорию "нам действительно нужно хранить данные т.к. скорость отправителя выше скорости получателя".
В совеременном микросервисном виртуальнмо мире сеть так же ненадежна как и у динозавров rpc.
А книжку почитай по диагонале. scf>Очередь может переполниться, данные из очереди могут быть потеряны (кто делает бэкапы очередей?), при проблемах в системе нужно смотреть содержимое очередей (для большей части систем такой возможности нет).
Если коротко, то почитай про SLA очередей. Некоторые из них кстате идут as a service в клаудах.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>А что изменилось за пять лет в HTTP/REST?
Появились асинхронные клиенты и асинхронные серверы. Количество параллельных подключений уже не является ограничением, сотни и тысячи одновременных коннектов — дешевы.
Окончательно оформилась концепция Future/Promise. Сложный асинхронный код уже не так сложен. Кто писал логику реконнекта с таймаутами и прочей мишурой меня поймет.
Появляются нормальные библиотеки для работы с сетью как для клиентов, так и для серверов. Умеющие таймауты, реконнекты, троттлинг с разнообразным поведением.
Современные стеки json/http могут обрабатывать тысячи запросов в секунду без значительного оверхеда.
Здравствуйте, itslave, Вы писали: I>В этой книжке устарело только то, что описанные паттерны не надо имплементировать вручную, просто выбрать нужный сервис бас. Все.
ESB — это для избранных, я себя к ним не отношу.
I>В совеременном микросервисном виртуальном мире сеть так же ненадежна как и у динозавров rpc.
Ненадежность сети, это, право, такая незначительная проблема по сравнению с ненадежностью хранения данных...
I>Если коротко, то почитай про SLA очередей. Некоторые из них кстате идут as a service в клаудах.
SLA означет ресурсы и людей, которые его будут обеспечивать. Силами команды — дорого.
Я двумя руками за as a service, т.к. самому админить хранилище данных — дело непростое и требующее постоянного присмотра. Но помимо чисто технических вопросов (работает не так, как мы хотим) есть еще вопросы финансовые — что в случае всплеска использования ресурсов получается либо даунтайм, либо счет от хостера на произвольную сумму.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, Nikolay_Ch, Вы писали:
N_C>>А что изменилось за пять лет в HTTP/REST?
scf>Появились асинхронные клиенты и асинхронные серверы. Количество параллельных подключений уже не является ограничением, сотни и тысячи одновременных коннектов — дешевы.
У меня для тебя плохие новости. Проблема с10к была сформулирована почти 20 назад и с тех пор ничего не поменялось — хочешь обрабатывать больше 10000 одновременных реквестов — надо приседать, вне зависимости от языка программирования.
scf>Окончательно оформилась концепция Future/Promise. Сложный асинхронный код уже не так сложен. Кто писал логику реконнекта с таймаутами и прочей мишурой меня поймет.
Асинхронность была придумана в 60х, на платформе x86 она реализовывалась прерываниями. Про int 21h ты наверняка не слышал
scf>Современные стеки json/http могут обрабатывать тысячи запросов в секунду без значительного оверхеда.
Ровно тоже самое можно было делать 20 лет назад. Только вместо json-а был xml.
Иех, молодежь.....
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, itslave, Вы писали: I>>В этой книжке устарело только то, что описанные паттерны не надо имплементировать вручную, просто выбрать нужный сервис бас. Все. scf>ESB — это для избранных, я себя к ним не отношу.
Непонятно почему ESB — для избранных. Но ок, есть еще валом просто service bus, без приставки enterprise.
scf>Ненадежность сети, это, право, такая незначительная проблема по сравнению с ненадежностью хранения данных...
Хм, она настолько незначительна что привела всего лишь к CAP теореме, отказу от ACID в пользу BASE, (частично) к event-driven модели....
scf>Я двумя руками за as a service, т.к. самому админить хранилище данных — дело непростое и требующее постоянного присмотра. Но помимо чисто технических вопросов (работает не так, как мы хотим) есть еще вопросы финансовые — что в случае всплеска использования ресурсов получается либо даунтайм, либо счет от хостера на произвольную сумму.
Ну раз есть всплеск — значит бизнес работает, получает прибыль. Отдать небольшую часть хостеру не жалко.
Я в недоумении. про с10к — вы последний абзац читали? select/IOCP это не приседания, это уже мейнстрим. IO на тредпулах в 2017 делаться не должно. int21h в досе — это программное прерывание для вызова сервисов DOS и было оно *синхронным*. Аппаратные прерывания — это вообще не то и никто пользовательскому софту не даст переопределить обработчик. Кому в 1997 были нужны XML-сервисы, обрабатывающие 1000 запросов в секунду и на каком языке их писали? Гугль утверждает, что service bus — это ESB. CAP-теорема про *данные* и касается только stateful микросерисов. Нет данных — нет проблем с consistency, пиши AP и радуйся жизни. Нагрузка на систему != прибыль. Это может быть DoS, это может быть баг в системе, в случае очередей под нагрузкой объем хранимых данных зависит не от нагрузки, а от отношения скоростей работы отправителя и получателя (что вообще сложно предсказать в динамике)
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, itslave, Вы писали:
scf>Я в недоумении. про с10к — вы последний абзац читали? select/IOCP это не приседания, это уже мейнстрим. IO на тредпулах в 2017 делаться не должно.
Да собственно говоря еще в 70х народ очень четко понимал различие между асинхронностью и многопоточностью. И тогда еще придумали совершенно разные механизмы для этих кейсов и успешно использовали все это время. Если кто-то в 2010 году использовал тред пул для эмуляции асинхронности... то у меня для этого человека есть пару плохих новостей. Ессна ж лавинообразный рос ит индустрии и как следствие — понижение квалификации девов внесли свою лепту, но это же совсем не повод говорить про какие то новые свершения в 2017 году.
Да, синтаксического сахара добавили, порог входа понизили.... и всё
scf>int21h в досе — это программное прерывание для вызова сервисов DOS и было оно *синхронным*. Аппаратные прерывания — это вообще не то и никто пользовательскому софту не даст переопределить обработчик.
А тогда этого и не надо было. Но разработчики операционных систем очень четко понимали что асинхронность — это не многопоточность и провайдили интерфейсы, актуальные для своего времени.
scf>Кому в 1997 были нужны XML-сервисы, обрабатывающие 1000 запросов в секунду и на каком языке их писали?
на С++ есна же. И они были нужны, было относительно много софта для таких кейсов, как правило ентерпрайз, финансы...
scf>Гугль утверждает, что service bus — это ESB.
Он врет.
Всякие кафки, мулы от апачей и даже нсервис басы — это не совсем ентерпрайз(там есть монстры от оракла, майкрософта, тибко).
scf>CAP-теорема про *данные* и касается только stateful микросерисов. Нет данных — нет проблем с consistency, пиши AP и радуйся жизни.
Ну вот обычно внезапно получается что сервисы без данных никому не нужны.
scf>Нагрузка на систему != прибыль. Это может быть DoS, это может быть баг в системе, в случае очередей под нагрузкой объем хранимых данных зависит не от нагрузки, а от отношения скоростей работы отправителя и получателя (что вообще сложно предсказать в динамике)
Если нагрузка != прибыль, то это баг который надо чинить. И все. Да, фикс некоторых багов, невыявленных вовремя, стоит очень дорого. Вот сходу вспомнился баг с антенной в айфоне 4(или 3 или 5). Казалось бы мелочь, но сколько он стоил...
PS
какой то сумбурный пост вышел. Наверное потому что ответил на сообщение, в котором тоже смешались кучу кони, люди...