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

Вам будут часто попадаться сообщения о людях, которым удалось обойти теорему CAP. Это неправда. Все, что им удается сделать, заключается в создании системы, где некоторые возможности относятся к категории CP, а некоторые — к AP. Математическое доказательство, подкрепляющее теорему CAP, остается незыблемым. Несмотря на неоднократные мои попытки обойти математику в школе, я понял, что сделать это невозможно.

И реальный мир

Многое, о чем мы говорим, относится к миру электроники — битам и байтам, сохраненным в памяти. Мы говорим о согласованности в какой-то манере, похожей на детские рассуждения. Мы представляем себе, что в пределах видимости созданной нами системы мы можем остановить мир и считаем, что во всем этом есть смысл. И еще многое из того, что мы создаем, — это просто отражение реального мира, и мы не в состоянии этим управлять, не так ли?

Вернемся к системе инвентаризации. Она отображается на физические товарные позиции реального мира. Мы в своей системе подсчитываем количество имеющихся альбомов. На начало дня было 100 копий альбома Give Blood группы The Brakes. Одну мы продали. Теперь у нас 99 копий. Все просто, не правда ли? Но что получится, если при отправке заказа кто-нибудь уронит копию на пол и случайно ее раздавит? Что произойдет? Наша система говорит «99», но на полке 98 копий.

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

Мы должны признать, что независимо от степени возможной согласованности наших систем и от них самих разобраться абсолютно во всем, что может произойти, невозможно, особенно если мы ведем учет происходящего в реальном мире. Это одна из основных причин, по которой во многих ситуациях AP-системы в конечном счете берут верх. Кроме того что CP-системы сложны для построения, они все равно не в состоянии решить все наши проблемы.

Обнаружение сервисов

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

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

Рассмотрим некоторые наиболее распространенные средства поставки сервиса и оценим доступные варианты.

DNS

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

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