Микросервисная архитектура перестала быть темой докладов и пришла в реальные проекты. Системы дробят на десятки независимых сервисов, каждый разворачивают и масштабируют отдельно. И сразу возникает вопрос, который в монолите не стоял: как сервис A узнаёт, по какому адресу и порту сейчас живёт сервис B? Прописать IP в конфиге не выйдет – в динамической среде адреса меняются при каждом переразвёртывании. Эту задачу решает Service Discovery.
Зачем нужен реестр сервисов
В классической схеме адреса фиксированы, и балансировку делает железный или программный балансировщик с ручным списком бэкендов. Как только сервисы начинают подниматься и гаснуть автоматически, статический список устаревает за минуты. Нужен реестр, в который каждый экземпляр сервиса записывает себя при старте и из которого вычищается при остановке или после провала health-check.
Реестр снимает с разработчика заботу об адресах. Сервис спрашивает: «где сейчас платёжный шлюз?» и получает актуальный список живых экземпляров. Дальше клиент сам выбирает узел (client-side discovery) либо обращается через прокси, который знает реестр (server-side discovery). Первый вариант гибче, второй проще для команд, не желающих тащить логику обнаружения в каждый сервис.
Чем регистрировать: Consul, etcd, ZooKeeper
На сегодня сложилось три рабочих инструмента.
ZooKeeper – ветеран из мира Hadoop и Kafka. Надёжный, проверенный, но тяжёлый: Java-стек, заметное потребление памяти, неудобный API. Брать его ради одного Service Discovery – стрелять из пушки по воробьям.
etcd от команды CoreOS – компактное распределённое key-value хранилище на Raft с простым HTTP/JSON-интерфейсом. Хорошо ложится на инфраструктуру с Docker и системами оркестрации, которые сейчас активно появляются.
Consul от HashiCorp вышел около года назад и уже выглядит наиболее цельным решением именно под обнаружение сервисов. Из коробки даёт встроенные health-check, DNS-интерфейс (сервис доступен как payment.service.consul), хранилище ключей и поддержку нескольких дата-центров. Последнее важно для распределённых ведомственных систем.
Выбор сводится к контексту: уже есть ZooKeeper в кластере обработки данных – переиспользуйте его; строите инфраструктуру с нуля – присмотритесь к Consul или etcd. На этом этапе важно заранее продумать проектирование и сопровождение инфраструктуры, чтобы реестр сервисов не остался единственной точкой, за которой никто не следит.
Безопасность и требования госсектора
Реестр сервисов – критический узел. Кто пишет в реестр, тот управляет маршрутизацией всего трафика. Подмена записи перенаправит платежи или персональные данные на чужой узел. Поэтому доступ к реестру закрывают ACL, а обмен между узлами шифруют TLS – это продолжение той же дисциплины, что и шифрование данных на дисках. Health-check тоже стоит защищать: фальшивый «здоровый» ответ выведет из-под нагрузки рабочий узел.
Для госзаказчиков добавляется регуляторный слой. Курс на импортозамещение, заданный после событий прошлого года (мы разбирали его в обзоре безопасности за 2014-й), затрагивает не только СУБД, о чём мы писали в материале про замещение баз данных, но и инфраструктурный слой. Перечисленные инструменты – открытый код, что снижает зависимость от конкретного вендора, но разворачивать их следует на подконтрольных мощностях, а не во внешних облаках.
Вывод
Service Discovery – не модная деталь, а несущий элемент микросервисной архитектуры. Без живого реестра динамическая инфраструктура рассыпается на ручное администрирование. Начинайте с простого: один инструмент, обязательные health-check, закрытый ACL и TLS доступ. Усложняйте только тогда, когда этого потребует реальный рост числа сервисов.
