Является ли сервис Discovery микросервисным нарушением идеи о свободной связи?

Question

Как механизм для подключения микросервисов и их работы обычно предлагается использовать API и сервисное обнаружение. Но они обычно работают как собственные микросервисы, но эти, видимо, должны быть «жестко закодированы» в других, поскольку каждый микросервис должен регистрироваться у них и запрашивать местоположение других микросервисов. Разве это не нарушает идею ослабления связи, поскольку потеря службы обнаружения означает, что другие не могут общаться?

Answer 1

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

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

Но есть еще один способ взглянуть на обнаружение службы: когда он используется клиентами службы, такими как приложение SPA или API Gateway, это может быть очень полезно. Клиенты и шлюзы должны знать об API обслуживания, иначе все это не имеет смысла. Но они могут использовать реестр, чтобы сделать его более гибким/динамичным.

Итак, подведем итоги:

• если услуги используют открытие, чтобы получить больше информации друг о друге - это, вероятно, плохо и недостаток дизайна (довольно уверен, что есть угловые случаи, когда это может быть действительным сценарий, пожалуйста, напишите комментарий, если вы его знаете)
• Если обнаружение используется другими частями приложения, например SPA или API Gateway, это может быть полезно, но не обязательно всегда.

PS: Чтобы избежать высокой сцепки, рассмотрите возможность чтения series of articles by Jeppe Cramon, которые очень хорошо иллюстрируют проблему и возможные решения.

Answer 2

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

Я бы сказал, что это имеет значение, как вы проектируете свое местоположение службы. если ваш код знает о другой службе, то есть OrderService.Send(SubmitOrderMessage); (где «OrderService» является экземпляром прокси-сервера другой службы) в отличие от transportAgent.Send(SubmitOrderMessage); (где «transportAgent» является экземпляром прокси-сервера транспорта, то есть службой/агентом очередей и фактическим адрес очереди может быть в вашей конфигурации), это уменьшает связь и код бизнес-логики (Service) и делегирует маршрутизацию в вашу инфраструктуру.

Смысл?

Answer 3

Ожидается, что каждый микросервис будет функционально независимым. Для взаимодействия с другими микросервисами он должен полагаться только на вызовы rest api. Служба Discovery играет роль, чтобы поддерживать сервисы довольно свободно в сочетании друг с другом. Также из-за динамического характера URL-адресов службы удаляются жесткие зависимости. Надеюсь, что это поможет

Answer 4

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