Каждая микрослужба имеет уникальное имя (URL-адрес), по которому разрешается ее расположение. Возможность адресации микрослужбы должна существовать независимо от того, где она находится. Если вы не можете легко определить, на каком компьютере выполняется та или иная микрослужба, очень скоро могут возникнуть проблемы. Микрослужба должна иметь уникальное имя, чтобы ее текущее расположение можно было установить аналогично тому, как служба DNS сопоставляет URL-адрес с определенным компьютером. Микрослужбам требуются адресуемые имена, которые делают их независимыми от базовой инфраструктуры. Это означает наличие связи между развертыванием службы и ее обнаружением, то есть необходим реестр служб. Аналогичным образом, когда происходит сбой компьютера, служба реестра должна сообщать, где теперь выполняется служба.
Шаблон реестра служб является ключевым элементом обнаружения служб. Он представляет собой базу данных, содержащую сетевые расположения экземпляров служб. Реестр служб должен обладать высокой доступностью и быть актуальным. Клиенты могут кэшировать сетевые расположения, полученные из реестра служб. Однако эти сведения со временем устаревают, и в результате клиенты больше не могут обнаружить экземпляры служб. Поэтому реестр служб представляет собой кластер серверов, которые используют протокол репликации для обеспечения согласованности.
В некоторых средах развертывания микрослужб (называемых кластерами и рассматриваемых далее) функция обнаружения служб встроена. Например, среда службы Azure Kubernetes (AKS) обрабатывает регистрацию и отмену регистрации экземпляров служб. Она также запускает прокси-сервер в каждом узле кластера, который выступает в роли маршрутизатора обнаружения на стороне сервера.