Простейшая форма владения — наличие единственной копии сервиса. Поскольку в каждый момент времени работает лишь один экземпляр сервиса, он по умолчанию является владель-цем всего и никакой выбор не нужен. Преимущество такого подхода — в простоте создания и развертывания приложения. Его недостатки заключаются в снижении доступности и надеж-ности такого сервиса. Однако для многих приложений простота данного подхода перевешивает потерю надежности. Давайте рассмотрим этот момент подробнее.
Глава 9. Выбор владельца 153
Рис. 9.1. Протокол выбора владельца в действии: сначала владельцемявляется первый экземпляр сервиса, а в случае его отказа полномочия берет на себя третий экземпляр
154Часть II. Паттерны проектирования обслуживающих систем Допустим, вы запускаете сервис-одиночку в оркестраторе кон-тейнеров вроде Kubernetes. В таком случае у вас есть следу-ющие гарантии.
Если контейнер откажет, он будет перезапущен. Если контейнер зависнет, а у вас реализована проверка ра-
ботоспособности, он также будет перезапущен. Если произойдет аппаратный сбой, контейнер будет пере-
мещен на другую машину.
Благодаря наличию этих гарантий сервис-одиночка, работа-ющий под управлением оркестратора контейнеров, как правило, имеет достаточно высокий процент времени безотказной рабо-ты. Чтобы уточнить, насколько высок «достаточно высокий» процент, рассмотрим, что происходит в случае каждого из пере-численных отказов. Если запущенный в контейнере процесс от-кажет, приложение будет перезапущено через несколько секунд. Предположим, контейнер сбоит раз в день. Это примерно соот-ветствует доступности на уровне 3–4 девяток (99,9–99,99 %) — 2 секунды недоступности в день примерно равны 99,99 % до-ступности. Если контейнер отказывает реже, то доступность будет еще лучше. При отказе оборудования Kubernetes потре-буется некоторое время, чтобы понять, что машина вышла из строя, после чего он переместит контейнер на другую машину. Допустим, это зай мет 5 минут. Если каждая машина в кластере отказывает раз в день, то доступность сервиса составляет две девятки, или 99 %. Честно сказать, если у вас в кластере каждая машина отказывает раз в день, то низкая доступность сервиса — наименьшая из ваших проблем.
Конечно, стоит учесть, что недоступность сервиса может быть вызвана и другими причинами. При развертывании ПО на загрузку и установку новой версии приложения требуется не-Глава 9. Выбор владельца 155
которое время. Старая и новая версии синглтона не могут ра-ботать одновременно, поэтому на время обновления придется отключить старую версию приложения, а при большом размере образа процесс может занять несколько минут. Следовательно, при ежедневном развертывании, на которое требуется 2 мину-
ты, доступность сервиса будет на уровне двух девяток (99 %), а при ежечасном — ниже 90 %. Развертывание, конечно, можно ускорить путем предварительной загрузки образа на обновля-емую машину. Это уменьшит время развертывания очередной версии до нескольких секунд, но привнесет дополнительную сложность, которой мы избегали изначально. Несмотря на это, существует ряд приложений (например, фо-новая асинхронная обработка), в которых такой компромисс между уровнем доступности и простотой приложения допустим. Один из ключевых аспектов проектирования распределенной системы — следить, чтобы распределенность не слишком ее усложняла. Но есть и ситуации, когда высокая доступность (че-тыре девятки и больше) является критической характеристикой приложения. В таких системах необходимо иметь несколько экземпляров сервиса, среди которых только один является владельцем. Проектирование такого рода систем описывается в последующих разделах.
Основы процесса выбора владельца Представим себе сервис Foo в трех экземплярах: Foo-1, Foo-2 и Foo-3. Допустим, есть также некоторый объект Bar, которым одновременно может владеть только один экземпляр сервиса. Этот экземпляр часто называется владельцем . Соответственно, процесс, описывающий то, как выбрать начального владельца и в случае отказа текущего — очередного владельца, называется выбором владельца .
Читать дальше