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

Два конкретных примера изучения эффективности автоматизации. Наверное, объяснить эффективность качественной автоматизации полезнее всего на двух конкретных примерах. Одним из наших клиентов является компания RealEstate.com.au (REA) из Австралии. Кроме всего прочего, она предоставляет объекты недвижимости для розничной торговли и коммерческих клиентов в Австралии и в других местах Азиатско-Тихоокеанского региона. В течение ряда лет компания переводит свою платформу на распределенную микросервисную модель. В самом начале этого пути ей пришлось потратить много времени на получение подходящих для сервисов инструментов, облегчающих разработчикам предоставление машин, развертывание их кода или отслеживание его работы. Для запуска проекта пришлось сконцентрировать все усилия с самого начала.

За первые три месяца REA смогла перевести в производственный режим использования только два новых микросервиса, при этом команда разработчиков взяла на себя полную ответственность за их сборку, развертывание и поддержку. В следующие три месяца удалось запустить в том же режиме еще 10–15 сервисов. К концу 18-месячного периода в REA работали свыше 70 сервисов.

Действенность подобной схемы подтверждается и опытом компании Gilt, с 2007 года занимающейся продажей через Интернет модной одежды. Использовавшееся в Gilt монолитное Rails-приложение стало испытывать трудности с масштабированием, и в 2009 году компания решила приступить к декомпозиции системы на микросервисы. И опять автоматизация, особенно оснащенная инструментарием для помощи разработчикам, стала ключевым обоснованием активного перехода компании Gilt к использованию микросервисов. Год спустя у Gilt работали десять микросервисов, к 2012-му — уже свыше 100, а в 2014 году, по собственному подсчету Gilt, — свыше 450 микросервисов. Иными словами, на каждого разработчика в Gilt приходилось примерно по три сервиса.

От физического к виртуальному

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

Традиционная виртуализация

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

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

В мире виртуализации у нас есть такие же издержки, как и перегородки в ящике для носков. Чтобы понять природу возникновения этих издержек, посмотрим, как чаще всего выполняется виртуализация. На рис. 6.9 для сравнения представлены два типа виртуализации. Слева показано использование нескольких различных уровней так называемой виртуализации второго типа, которая реализуется в AWS, VMWare, VSphere, Xen и KVM. (К виртуализации первого типа относятся технологии, при которых виртуальные машины запускаются непосредственно на оборудовании, а не в виде надстройки над другой операционной системой.) В нашей физической инфраструктуре имеется основная операционная система. Под управлением этой операционной системы запускается так называемый гипервизор, имеющий две основные задачи. Во-первых, он отображает ресурсы, подобные ресурсам центрального процессора и памяти, с виртуального хоста на физический хост. Во-вторых, он работает в качестве уровня управления, позволяющего манипулировать самими виртуальными машинами.