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

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

Снижение уровня функциональных возможностей

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

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

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

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

Архитектурные меры безопасности

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

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

Фактически это пример приложения-душителя, где новая система перехватывает вызовы, совершаемые в адрес ранее существова­вших приложений, и постепенно полностью заменяет собой эти приложения. В рамках этого проекта мы уже были на полпути к списанию прежних приложений. Мы только что перешли к использованию самых крупных объемов и самых прибыльных продуктов, но многие рекламные объявления по-прежнему обслуживались целым рядом прежних приложений. С точки зрения как количества поисковых запросов, так и дохода от этих приложений быстро избавиться от них не представлялось возможным.

Рис. 11.1. Сайт классифицированных рекламных объявлений, на котором происходит постепенное избавление от устаревших приложений