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

При проработке инструкций и размышлении насчет компромиссов, на которые необходимо пойти, нужно определить и такой очень важный момент, как допустимая степень изменчивости вашей системы. Одним из основных способов определения неизменных качеств для всех сервисов является установка критериев отбора тех из них, поведение и качество которых не выходят за рамки допустимого. Какой же из сервисов станет добропорядочным жителем вашей системы? Какими возможностями он должен обладать, чтобы гарантировать управляемость системы, и то, что один негодный сервис не приведет к сбою всей системы? Ведь здесь как с людьми: добропорядочность жителя в одних условиях не определяет то, на что он может стать похож в каких-либо других условиях. И тем не менее есть некие общие характеристики подходящих сервисов, которых, на мой взгляд, очень важно придерживаться. Существует ряд ключевых областей, в которых допустимость слишком больших отклонений может привести к весьма жарким временам. Согласно определению Бена Кристенсена (Ben Christensen) из компании Netflix, когда мы мысленно рисуем себе крупную картину, «должна быть стройная система из множества мелких деталей с автономными жизненными циклами, способная представлять собой единое целое». Следовательно, нужно найти разумный баланс оптимизации автономии отдельно взятого микросервиса, не теряя при этом из виду общую картину.

Рис. 2.1. Практический пример принципов и инструкций

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

Мониторинг

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

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

Интерфейсы

Выбор небольшого числа определенных технологий интерфейса помогает интегрировать новых потребителей. Лучше всего иметь один стандарт. Два — тоже неплохо. А вот наличие 20 различных стилей объединения уже никуда не годится. Это относится не только к выбору технологии и протокола. Если, к примеру, выбор пал на HTTP/REST, что вы будете использовать, глаголы или существительные? Как станете работать со страничной организацией ресурсов? Как будете справляться с управлением версиями конечных точек?

Архитектурная безопасность

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

Игра по правилам важна и тогда, когда речь заходит о кодах. Если предохранители полагаются на HTTP-коды, а в отношении одного из сервисов принято решение о возврате для ошибок кодов вида 2XX или коды 4XX перепутаны с кодами 5XX, то все меры безопасности окажутся тщетными. Те же опасения возникнут, даже если вы не используете HTTP. Знание того, в чем заключается разница между подходящим и корректно обработанным запросом, плохим запросом, при котором сервис удерживается от каких-либо действий по отношению к нему, и запросом, который может быть в порядке, но точно этого сказать нельзя, поскольку сервер не работал, является ключом уверенности в возможности быстрого отказа и отслеживания возникших проблем. Если наши сервисы будут пренебрегать этими правилами, система получится более уязвимой.

Управление посредством кода