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

Consul является совершенно новым средством, и из-за сложности используемых в нем алгоритмов я, как всегда, испытываю некоторые сомнения, рекомендуя его для столь важного задания. Тем не менее Hashicorp — команда, занимающаяся его поддержкой, несомненно, имеет солидный послужной список в создании весьма полезных технологий с открытым кодом (в виде как Packer, так и Vagrant). И я разговаривал с некоторыми специалистами, успешно использующими данное средство в производственном режиме. Исходя из этого, думаю, к нему стоит присмотреться.

Eureka

Разработанная компанией Netflix система с открытым кодом под названием Eureka не следует тенденциям, наблюдающимся в таких системах, как Consul и Zookeeper, и не пытается быть универсальным хранилищем конфигураций. Она имеет весьма узкую специализацию.

Eureka предоставляет основные возможности обеспечения сбалансированности нагрузки тем, что может поддерживать круговой поиск экземпляров сервисов. Эта система предоставляет конечную точку на REST-основе, поэтому вы можете создавать своих клиентов или использовать ее собственных Java-клиентов. Java-клиент предоставляет такие дополнительные возможности, как проверка состояния работоспособности экземпляров. Разумеется, при отказе от собственного клиента Eureka и переходе непосредственно к конечной точке на REST-основе вам придется заниматься всем этим самостоятельно.

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

Прокатка собственной системы

Один из подходов, которым я пользовался сам и использование которого видел в других местах, заключался в прокатке собственной системы. В одном из проектов мы интенсивно использовали инфраструктуру AWS, в которой предлагалось воспользоваться возможностью добавления к экземплярам меток. При запуске экземпляров сервиса я хотел применить метки, чтобы помочь определить, каким был этот экземпляр и для чего он использовался. Это позволило бы связать расширенные метаданные с заданным хостом, например:

• service = accounts (сервис = accounts, то есть счета);

• environment = production (среда = производство);

• version = 154 (версия = 154).

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

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

Не забывайте про людей!

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

Документирующие сервисы

Разбиением систем на узкоспециализированные микросервисы мы надеемся показать множество стыков в виде API-интерфейсов, которые люди могут использовать для создания многих, надеюсь, замечательных вещей. Если обнаружение проведено правильно, мы знаем, где что есть. Но как узнать, чем все это занимается или как всем этим пользоваться? Один из очевидных вариантов заключается в применении документации, описывающей API-интерфейсы. Разумеется, документация может часто устаревать. В идеале хотелось бы обеспечить постоянное соответствие документации состоянию API-интерфейса микросервиса и облегчить просмотр этой документации, когда мы знаем, где находится конечная точка сервиса. Воплотить это в реальность пытаются две различные технологии, Swagger и HAL, и обе они заслуживают рассмотрения.

Swagger