How to serve requests: encapsulation vs. efficiency

[Palych]

Имеется куча микросервисов. Они разбросаны по всей стране и вызываются из разных гуев и проч.
Многие из них для запроса требуют справочную информацию, хранящуюся на других сервисах.
Получаются целые деревья: чтобы вызвать сервис A нужно вызвать сервис B, а для него - сервис C...
Над всем этим строят сервисы-агрегаторы, которые вызывают весь этот зоопарк "со смыслом", стараясь сделать вызовы проще:
типа клиент вызывает сервис A, а мы делаем всю грязную работу...
При этом клиент редко вызывает один агрегированный сервис: от плетет свои сети из вызовов, агрегируя агрегированные сервисы в мега конгломераты...
В итоге забота о клиенте часто выходит боком: агрегированные вызовы работают медленно.
Кроме всего прочего время тратится на многократный lookup справочной информации: клиент вызывает один агрегированный сервис, внутри ищется информация, затем вызывается другой сервис, для него ищется та же, или пересекающаяся информация.
Иными словами: на один вызов большого, агрегированного сервиса некоторые "листовые" сервисы этого дерева могут быть вызваны несколько раз.

Вопрос: есть ли какое-то фундаментальное и всеобъемлющее решение этой проблемы?

[Palych]

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

[Vladimir Kr.]

welcome to microservice antipatern!
microservice + сервисы-агрегаторы ---> performance? really?
зато имеем independent development, etc!

нет проблем join SQL сколько нyжно раз, особенно небольших справочных таблиц.

по поводу решения - cache call, поможет некоторое время, но в итоге все будет сложнее чем monolitic app.
фундаментальное решение - a не надо multiservices replace with microservices.

сеичас придyт и скажyт, что performance optimization ето не главное в microservices.

[Palych]

welcome to microservice antipatern!
microservice + сервисы-агрегаторы ---> performance? really?
зато имеем independent development, etc!

нет проблем join SQL сколько нyжно раз, особенно небольших справочных таблиц.

по поводу решения - cache call, поможет некоторое время, но в итоге все будет сложнее чем monolitic app.
фундаментальное решение - a не надо multiservices replace with microservices.

сеичас придyт и скажyт, что performance optimization ето не главное в microservices.

Спасибо за мысли!
Читал, думал.

Про SQL join понятно, тут я затупил: Базы вынимают данные из одного места (гусары молчать!), добавить колонку-другую на скорость особо не повлияет.

Фундаментальное решение к сожалению не подойдет: microservices были там изначально, изменить это можно только уничтожив систему вместе с конторой.

Cache как таковой тоже не подойдет: данные (как минимум в некоторых use cases) нужны "живые".
"Кэширование" возможно (и даже необходимо) в рамках запроса(транзакции), самого "верхнего" запроса...

У меня есть мысль: "вывернуть" запросы наизнанку... Как-нибудь изложу подробнее...

[Palych]

Стало быть: имеем микросервисы, хранящие кусочки мозаики, и аггрегирующие сервисы, которые инкапсулируют некое Знание о том как собирать Картину Бытия из микросервисов.

Идея такая: А ну как вместо больших сервисов выкладывать некие "скрипты", описание Картины бытия на некотором сакральном языке?

В качестве языка - тот же Javascript...

[Vladimir Kr.]

BPEL ?

[Palych]

BPEL ?

Спасибо!
Я про него смотрел как-то давно, надо будет копнуть глубже:
Хотелось бы видеть сям что-то типа монады, которая бы обращалась к REST сервису (желательно асинхронно), сохраняла результаты в некоем контексте, и если в другой раз нужны были данные из того же URL с тем же контекстом - мгновенно их возвращала...

[Vladimir Kr.]

вы же сказали надо актуалные данные, и cache не поидет.
кто будет следит за cache i.e. synchronize, evict, etc?

[Palych]

вы же сказали надо актуалные данные, и cache не поидет.
кто будет следит за cache i.e. synchronize, evict, etc?

Контекст будет передаваться между участниками запроса.
Время жизни контекста - запрос на самом высоком уровне агрегации.

[Palych]

В общих чертах получается как-то так:
- клиент вызывает некий "meta service"
- с сервера приходит некий код в виде чего-то типа Promises, которые вызывают реальные сервисы.
- клиент может выполнить полученный код с некоторой "прослойкой" (библиотекой), которая подставляет параметры, адреса, пароли явки...
- А если клиент сам является "мета сервисом" - он соорудит более заковыристый Promise...

"Пусть безумная идея - не рубайте сгоряча..."

[katit]

Выглядит как dependency injection with reusable objects. Как один раз копию получили так и будет она использоваться в контексте вызова

[Вячеслав Викторович]

Имеется куча микросервисов. Они разбросаны по всей стране и вызываются из разных гуев и проч.
Многие из них для запроса требуют справочную информацию, хранящуюся на других сервисах.
Получаются целые деревья: чтобы вызвать сервис A нужно вызвать сервис B, а для него - сервис C...
Над всем этим строят сервисы-агрегаторы, которые вызывают весь этот зоопарк "со смыслом", стараясь сделать вызовы проще:
типа клиент вызывает сервис A, а мы делаем всю грязную работу...
При этом клиент редко вызывает один агрегированный сервис: от плетет свои сети из вызовов, агрегируя агрегированные сервисы в мега конгломераты...
В итоге забота о клиенте часто выходит боком: агрегированные вызовы работают медленно.
Кроме всего прочего время тратится на многократный lookup справочной информации: клиент вызывает один агрегированный сервис, внутри ищется информация, затем вызывается другой сервис, для него ищется та же, или пересекающаяся информация.
Иными словами: на один вызов большого, агрегированного сервиса некоторые "листовые" сервисы этого дерева могут быть вызваны несколько раз.

Вопрос: есть ли какое-то фундаментальное и всеобъемлющее решение этой проблемы?

кэширование решает практически все проблемы. возможно и с прелоадом, там где это имеет смысл.

[Palych]

кэширование решает практически все проблемы. возможно и с прелоадом, там где это имеет смысл.

Кэширование может решить проблемы при двух условиях:
1. Одни и те же данные запрашиваются много раз.
2. Данные меняются "редко", т.е. п.1 выполняется между изменениями

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

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