Создание микросервисов

При работе с экземплярами сервиса в других средах мне приходилось наблюдать эффективную работу шаблона домена на основе соглашений. Например, у нас может быть шаблон, определяемый как <имя_сервиса>-<среда>.musiccorp.com, дающий входы типа accounts-uat.musiccorp.com или accounts-dev.musiccorp.com.

Более совершенным способом управления различными средами является использование для разных сред серверов с разными доменными именами. Это позволяет предположить, что accounts.musiccorp.com — это место, где я всегда смогу найти сервис счетов, но данный адрес может разрешаться указаниями на различные хосты в зависимости от того, где я выполняю поиск. Если у вас уже есть свои среды, размещенные в разных сегментах сети, и вам удобно управлять собственными DNS-серверами и записями, это может стать отличным решением, но если вы не извлекаете из такого подхода никаких других преимуществ, можно счесть его слишком трудоемким.

У DNS множество преимуществ, и одно из основных заключается в том, что этот стандарт настолько хорошо продуман и имеет настолько богатый положительный опыт применения, что его поддерживают практически все технологические стеки. К сожалению, когда внутри организации существует несколько сервисов для управления DNS, для среды, в которой мы работаем с высокодоступными хостами, предназначены только некоторые из них, что существенно затрудняет обновление DNS-записей. В компании Amazon неплохо справляется с этой работой сервис Route53, но мне еще не попадался достаточно хороший, самостоятельно занимающий хост вариант, хотя (в чем мы вскоре убедимся) в этом вопросе нам сможет помочь такое средство, как Consul. Кроме трудностей с обновлением DNS-записей, ряд проблем может создать и сама спецификация DNS.

DNS-записи для доменных имен имеют указание времени жизни информации (TTL). Это время означает, как долго клиент может считать запись свежей. Когда мы хотим изменить хост, на который ссылается доменное имя, мы обновляем запись, но нужно учесть то обстоятельство, что у клиента будет храниться старый IP-адрес, по крайней мере пока не истечет TTL. DNS-записи могут кэшироваться во многих местах (даже JVM-машина будет кэшировать DNS-записи, пока вы не заставите ее не делать этого), и чем больше мест, в которых запись кэширована, тем более устаревшей она может быть.

Одним из способов обхода этой проблемы является содержание записи доменного имени для вашего сервиса, указывающего на балансировщик нагрузки, который (рис. 11.9), в свою очередь, указывает на экземпляры сервиса. При развертывании нового сервиса можно удалить старый из записи балансировщика нагрузки и вместо него добавить новый. Некоторые специалисты используют DNS в режиме круговой конкуренции, где сами DNS-записи ссылаются на группу машин. Эта технология считается крайне проблематичной, поскольку клиент скрыт от используемого хоста и потому не может справиться с остановкой маршрутизации трафика на один из хостов в случае его отказа.

Рис. 11.9. Решение проблемы устаревших DNS-записей путем использования DNS для направления на балансировщик нагрузки

Как уже упоминалось, технология DNS хорошо продумана и пользуется весьма широкой поддержкой. Но у нее все же имеется один или два недостатка. Прежде чем выбрать что-нибудь более сложное, я все же посоветовал бы вам разобраться в том, насколько эта технология сможет подойти для решения именно ваших проблем. Когда у вас имеются только отдельные узлы, использования DNS, ссыла­ющейся непосредственно на хосты, может оказаться вполне достаточно. Но в тех ситуациях, где нужно иметь более одного экземпляра на хост, лучше подойдет использование DNS-записей, разрешенных направлением трафика к балансировщику нагрузок, который может справиться с вводом в строй и с выводом из строя отдельных хостов.

Динамическая регистрация сервисов

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

Zookeeper

Средство Zookeeper изначально разрабатывалось как часть проекта Hadoop. Оно используется в невероятно большом количестве случаев, в том числе в качестве средства управления конфигурациями, синхронизации данных между сервисами, выбора лидера, выстраивания очереди сообщений и (что полезно для нас) в качестве службы имен.