Где я должен отфильтровать ответ внешней службы уровня MS в шаблоне архитектуры микросервиса?

Question

Я использую шлюз API (BFF) перед своими микросервисами для обработки потребностей пользовательского интерфейса.

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

В пользовательском интерфейсе I не нужна (СЕЙЧАС) вся информация, которую предоставляет внешний сервис. Должна ли моя MS передавать только самые необходимые данные в BFF или передать весь ответ, и я должен «отфильтровать» ответ MS в BFF?

Например:

Answer 1

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

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

Если будет возможен один из двух вышеупомянутых случаев, и я очень настойчиво предлагаю вам избежать последовательного подключения синхронных веб-запросов, поскольку это значительно снижает доступность (если каждая служба 95% доступно, два вместе - 90%, а не 95%, и это быстро ухудшается). Задержка - это проблема (как справедливо упоминает @picolino), но, по моему опыту, она гораздо реже, чем проблема доступности. В любом случае, выравнивание стека вызовов значительно сократит время, необходимое для обработки запроса.

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

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

Answer 2

Все зависит от того, как вы хотите использовать службу внешних пользователей.

Если вы считаете, что служба будет обслуживать различные типы запросов, а лучше возвращать всю информацию, служба должна вернуть все. И тогда ваш BFF будет фильтровать, чтобы он возвращал только необходимые данные.

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

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

Answer 3

Ответ на ваш вопрос зависит от коэффициента скорости .

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

Если внешний уровень обслуживания имеет только один путь выполнения и один API, в котором вы нуждаетесь, вы можете просто отфильтровать дополнительные данные на стороне микросервиса. Это сокращает объем передачи данных между MS и уровнем Frontend.

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

Что, если коэффициент скорости не так важен?
Обычно, увеличение скорости и / или производительности заставляет вас писать больше кода, например, отдельное выполнение дорожки или что-то. Если коэффициент скорости не так важен, вы можете уменьшить объем кода и повторно использовать один и тот же путь выполнения между обычными и отфильтрованными запросами с результатами фильтрации на стороне внешнего интерфейса.

Это оказывает положительное влияние на вашу кодовую базу. Меньше кода - меньше проблем.

Answer 4

С точки зрения принципа единой ответственности, лучше возвращать только связанные данные, больше информации означает более чем одну ответственность за метод или действие. Потому что вы не единственный пользователь в системе. Это сбивает с толку других пользователей, когда они вызовите метод getUsers, но получите информацию, не связанную с пользователями.