Архитектура Microservice - междоменная chattiness

Question

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

У меня есть три основных вида услуг, скажем foo-service, bar-service и baz-service. Эти службы никогда не нуждаются в общении, но все три службы регулярно разговаривают по HTTP-запросам до security-service. Я хочу, чтобы это прекратилось по целому ряду причин: самым большим является то, что каждый запрос к моим индивидуальным службам вызывает запрос в службу безопасности, который может превратиться в несколько дополнительных перелетов, когда вы учитываете балансировку нагрузки и т. Д. Я читал «Шаблоны архитектуры программного обеспечения» Марка Ричардса, и он рекомендует в этих случаях обмениваться базами данных и нарушать DRY: скопировать необходимые функции в каждую службу. Тем не менее, он использует этот пример с меньшими классами «полезности», которые могут не применяться в этом случае.

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

Итак, мой вопрос, следует ли мне скопировать и вставить код или создать модуль, который приносит каждый сервис? Благодаря!

Answer 1

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

ПРОФИ уходящий как отдельная услуга:
- изменения в бизнес-логику безопасности влияют только на службу безопасности и не требуют изменений к обслуживанию клиентов.

PROS о перемещении логики безопасности в клиентские услуги:
- Скорость/производительность.
- Еще один сервис для управления может означать снижение эксплуатационных расходов.

Скорость (производительность) может превзойти здесь, в зависимости от требований, но она будет иметь увеличенные затраты на разработку.

Если вы переместите логику безопасности в свой собственный повторно используемый модуль, который может быть вызван из других сервисов, просто сделайте хорошую работу по его инкапсуляции и следуя базовому дизайну с тесной связью. Кроме того, поскольку вам, возможно, придется отстаивать это решение на долгие годы, пожалуйста, получите хорошее объяснение, чтобы ваш будущий босс не уволил вас, когда она спрашивает, почему это так дорого, чтобы обновить нашу логику безопасности. Имеют легкодоступные тесты, люди лгут, цифры нет. У меня когда-то были результаты теста на одну страницу для новой БД, которую я просил. Меня несколько раз спрашивали у разных людей о том, почему я пошел с новой БД ... Я бы просто отправил им одну страницу и больше не слышал никаких вопросов от этого человека.

Это видео может заставить вас чувствовать себя лучше с учетом STO обратная тенденция: https://www.youtube.com/watch?v=StCrm572aEs

Это показывает, как и почему Netflix нарушил тенденцию и не идут с REST архитектуры для их API. В основном архитектура является клиентом требований и стоимости, а не наоборот.

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

Answer 2

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

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

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

Answer 3

Безопасность как отдельный сервис, который вам нужен для каждого запроса, поскольку вы описываете его, это очень плохая идея. Могу ли я отнести вас к основным идеям модуляции, которые Парнас описал так красноречиво в On the Criteria To Be Used in Decomposing Systems into Modules. Отсутствие сцепления также означает отсутствие сцепления, а техника - это поиск сладкого пятна на этой оси.

Вопреки распространенному мнению, микроуслуги должны быть довольно большими, чтобы иметь возможность масштабирования. Пределы масштабируемости в основном связаны с коммуникациями, поэтому они должны быть спроектированы так, чтобы не быть болтливыми. Проблема в основном (если вы не netflix) не пропускная способность, а задержка.

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