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

Помните, в главе 5 мы говорили о распределенных транзакциях? Основная причина затруднений при их реализации заключалась в проблеме обеспечения согласованности между несколькими узлами.

Обеспечить согласованность между несколькими узлами настолько трудно, что я буду весьма настоятельно рекомендовать при возникновении насущной потребности в этом не пытаться заниматься изобретательством. Лучше подобрать такое хранилище данных или такую службу блокировки, которые предлагают нужные характеристики. К примеру, такое средство, как Consul, которое вскоре будет рассмотрено подробнее, реализует совершенно согласованное хранилище пар «ключ — значение», разработанное для совместного использования конфигурации несколькими узлами. За лозунгом «Друзья не должны позволять своим друзьям писать собственные системы криптографии» должен следовать лозунг «Друзья не должны позволять своим друзьям создавать собственные распределенные согласованные хранилища данных». Если вы полагаете, что вам нужно написать собственное хранилище данных, обладающее свойствами CP, прочитайте сначала все статьи по данной теме, затем получите степень кандидата наук и потом подумайте, стоит ли тратить несколько лет на получение неработающего хранилища. А в это время я воспользуюсь чем-нибудь уже готовым или, что более вероятно, очень постараюсь создать вместо этого системы, обладающие свойствами AP и согласованностью, возникающей по прошествии некоторого времени.

А как насчет принесения в жертву терпимости к разделению?

Нам ведь нужно понять, какие два свойства из трех выбрать, не так ли? Мы уже получили приобретающую согласованность по прошествии некоторого времени AP-систему. У нас есть согласованная, но трудная в создании и масштабировании CP-система. Почему не создать еще и CA-систему? Итак, как же нам пожертвовать терпимостью к разделению? Если у системы отсутствует терпимость к разделению, она не сможет запускаться по сети. Иными словами, ей нужно быть единым процессом, выполня­емым локально. CA-систем среди распределенных систем просто не бывает.

AP или CP?

Каков должен быть правильный выбор: AP или CP? В реальности нужно решать, что от чего зависит. При создании какой-нибудь системы всегда приходится идти на компромиссы. Нам известно, что AP-системы проще поддаются масштабированию и их легче создавать, и мы знаем, что CP-система потребует больших трудозатрат из-за сложностей при поддержке распределенной согласованности. Но мы можем не понимать влияния этих компромиссов на бизнес. Подойдет ли для системы инвентаризации пятиминутная задержка с обновлением записи? Если ответ положительный, то выбор будет за AP-системой. А как насчет сведений о балансе клиента банка? Могут ли они быть устаревшими? Без знания контекста, в котором используется операция, мы не можем решить, как правильно поступить. Осведомленность о существовании теоремы CAP просто помогает понять, что такие компромиссы существуют, и разобраться в том, какие вопросы следует задавать.

Это не все или ничего

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

Но даже отдельные сервисы не обязательно должны быть либо CP, либо AP.

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