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

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

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

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

Итак, резюмируя:

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

PS: чтобы избежать сильной связанности, рекомендуем прочитать серия статей Йеппе Крамона, которые очень хорошо иллюстрируют проблему и возможные решения.

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

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

Имеет смысл?

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

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