Содержание


Микрослужбы в действии

Часть 1. Введение в микрослужбы

Меньше, быстрее, сильнее: создание «с нуля» более качественных облачных приложений

Comments

Серия контента:

Этот контент является частью # из серии # статей: Микрослужбы в действии

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Микрослужбы в действии

Следите за выходом новых статей этой серии.

На протяжении 2014 и 2015 года микрослужбы стали новой «горячей темой», быстро вытесняя облако. Это первая статья из серии статей, посвященных реализации микрослужб. В ней я расскажу об истории микрослужб и о том, что значит построить архитектуру микрослужб, а в следующих статьях представлю основу для построения и анализа реальных приложений на основе микрослужб. В заключении мы поговорим на некоторые темы, освещаемые в этой серии статей, включая возможности микрослужб, которые появятся в IBM Bluemix до конца этого года и в следующем году.

Успехи Netflix: рождение популяризованных микрослужб

Я уверен, что даже те из вас, кто ничего не слышал о микрослужбах, слышали о компании Netflix. И я готов держать пари, что вы слышали от Netflix Open Source Software (NOSS) – благодаря успехам Netflix в области создания и выпуска программного обеспечения для управления облачной инфраструктуры — ПО, лежащего в основе империи потоковых цифровых развлечений Netflix.

Начиная примерно с 2009 года Netflix — увлеченная API-интерфейсами и оседлавшая первую волну того, что мы теперь называем микрослужбами, — в корне изменила свои модели разработки и эксплуатации приложений. В то время отраслевые наблюдатели насмешливо отзывались компании: «Ребята, да вы просто сумасшедшие!» или «Может, это и работает у Netflix, но больше никто не сможет этого повторить». Перенесемся в 2013 год, когда эти настроения сменились другими: «Будущее за микрослужбами». Более 525 000 результатов поиска Google по ключевому слову microservices свидетельствуют о том, что это определенно действенная и мощная концепция.

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

Рисунок 1. Концептуальное представление микрослужб
Концептуальное представление микрослужб
Концептуальное представление микрослужб

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

В телеконференции Адриан Кокрофт, работавший в Netflix, определил микрослужбы как «мелкомодульную SOA (сервис-ориентированную архитектуру)». Читателю не нужно иметь детальное представление о SOA (архитектурном стиле, придуманном более десятилетия назад) – достаточно знания терминов, используемых в этой аббревиатуре. В идеале вся архитектура с самого начала строится из служб. При подходе микрослужб каждая из этих служб имеет единственную цель без всяких побочных эффектов, что позволяет охватить больший масштаб работ меньшим количеством выделенных инженеров.

Для определения микрослужб и связанных с ними архитектур я адаптирую и модифицирую девиз современных спортсменов: «больше, быстрее, сильнее»: меньше, быстрее, сильнее (см. рисунок 2). По сути, микрослужбы – это множество мелких архитектурных компонентов, которые быстро строятся и выпускаются, становясь все сильнее – как по отдельности, так и вместе.

Рисунок 2. Микрослужбы: меньше, быстрее, сильнее
Схема трех основных принципов микрослужб: меньше, быстрее, сильнее
Схема трех основных принципов микрослужб: меньше, быстрее, сильнее

Меньше

Микрослужбы означают конец монолитных конструкций. Монолитные конструкции громоздки, неуклюжи, медлительны и неэффективны, как Grim Monolith на рисунке 3. Мы уходим от мира 2-ГБ WAR-файлов (да и просто WAR-файлов. Никакого сервера приложений и никаких компонентов операционной системы. Это истинная правда!) к миру, населенному множеством служб по 500 МБ каждая, содержащих в себе полные приложения, серверы и необходимые компоненты операционной системы.

Рисунок 3. Grim Monolith
Фото Grim Monolith, характеризующее традиционные, непродуктивные методы разработки приложений

Переход от мейнфреймов к архитектурам клиент/сервер стал важным шагом вперед, которому, тем не менее, противились многие компании и разработчики. С аналогичным противодействием столкнулся последующий переход от центральных серверов веб-приложений к принятию SOA. Многие компоненты серверов приложений прошлых лет приспосабливаются к микрослужбам; тем не менее, они по-прежнему упакованы внутри многогигабайтных двоичных файлов. Например, на рисунке 4 показана архитектура традиционного веб-приложения, развернутого с применением компонентов WebSphere® Application Server и Java™ Enterprise Edition.

Рисунок 4. Стандартная архитектура приложения WebSphere Application Server
Стандартная архитектура приложения WebSphere Application Server
Стандартная архитектура приложения WebSphere Application Server

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

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

На рисунке 5 показан один из примеров реализации микрослужб.

Рисунок 5. Концептуальная схема приложения потокового видео
Концептуальная схема приложения потокового видео
Концептуальная схема приложения потокового видео

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

Сравнивая рисунки 4 и 5, можно заметить разницу в способах развертывания аналогичных приложений. На рисунке 4 все развертывается в едином процессе на вертикально масштабируемой системе. Когда требуется повысить пропускную способность, тиражируется весь сервер – снова и снова. Каждый сервер выполняет свой собственный процесс. Единственный способ получить более высокую пропускную способность Механизма веб-сервисов или Контейнера EJB на рисунке 4 – масштабировать весь JVM-сервер на новый экземпляр в кластерной среде. Однако это приведет к созданию еще одного Web-контейнера, еще одного Встроенного HTTP-сервера, еще одного Механизма обмена сообщениями и т.д, независимо от того, нужно ли масштабировать эти компоненты.

В отличие от способа масштабирования архитектуры, изображенной на рисунке 4, компоненты архитектуры, изображенной на рисунке рисунка 5, масштабируются независимо друг от друга. Об отдельных компонентах и способах их масштабирования я расскажу в разделе Быстрее, а пока мы сосредоточимся на распределенной природе каждого компонента и каждой службы. В отличие от примера приложения, показанного на рисунке 4, – для которого требуется полный набор компонентов высоконадежного сервера веб-приложений — эти компоненты распределены по своей природе и обеспечивают только одну конкретную функцию, часто с использованием технологий, отличных от технологий других компонентов. Эта структура позволяет архитектуре приложения развиваются гораздо быстрее и впитывать все новые технологии, а также новые версии, независимо от других компонентов.

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

Быстрее

Еще одно модное словечко, появившееся вместе с облакомDevOps. Движение DevOps позволяет разработчикам контролировать больше кода вдоль конвейера выпуска, обеспечивать непрерывную интеграцию и достигать большей видимости. Основные принципы DevOps, как показано на рисунке 6 по часовой стрелке, – это наблюдение, выбор направления, принятие решения и действие.

Рисунок 6. Принципы DevOps
Схема основных принципов DevOps:

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

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

С микрослужбами хорошо сочетаются циклы разработки, связанные с DevOps. Вы нацелены на короткие циклы разработки с непрерывным добавлением новой функциональности, вместо длительных циклов со сборкой всей целостной картины сразу. Эта методология разработки, называемая гибкой разработкой (Agile), лежит в основе успеха DevOps. Выбираете ли вы итеративную или инкрементальную разработку, сочетание микрослужб, культуры DevOps и гибкого планирования позволяет быстро создавать полную инфраструктуру за время, которое в прошлом ушло бы только на планирование первого цикла «водопада».

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

Возвращаясь к предыдущему примеру, на рисунке 5 представлены серверы и клиенты Реестра служб. Эта функция имеет решающее значение для приложения на базе микрослужб. В данном примере в состав пограничных служб входят источники Movie Service и Review Service. В зависимости от нагрузки эти службы масштабируются в разном темпе; поэтому всеми ими уже нельзя управлять одинаковым образом с одним и тем же масштабом.

При масштабировании Movie Services реестр служб автоматически узнает о создании новых экземпляров служб. Когда Edge Service пытается обработать запрос, она обращается к реестру служб и получает клиентские ссылки на все службы, от которых зависит. Клиентская служба Movie Service, скорее всего, новая, созданная совсем недавно, тогда как для Review Service может повторно использоваться старый экземпляр. Такие возможности реестра служб позволяют микрослужбам функционировать по принципу «одна из многих» – со слабо выраженной зависимостью между компонентами, но высокой надежностью благодаря мобилизации при необходимости большего количества экземпляров компонентов.

На рисунке 7 показана та же концептуальная архитектура приложения для потокового видео, представленного на рисунке 5, с добавлением дополнительных экземпляров микрослужб Movie Service.

Рисунок 7. Концептуальный пример масштабирования приложения потокового видео
Концептуальный пример масштабирования приложения потокового видео
Концептуальный пример масштабирования приложения потокового видео

Эффективное масштабирование по мере необходимости, когда системы сами узнают о появлении новых экземпляров. Нет, это не Skynet. Это то, что делает приложения, построенные на архитектуре микрослужб, гораздо сильнее.

Сильнее

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

Стадо вместо питомцев

С микрослужбами развернутые системы становятся, скорее, подобными стаду, чем домашним питомцам:

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

Адаптировано из презентации Гэвина Маккейнса Эволюция центра обработки данных CERN.

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

Чтобы проверить эту основу прочности конструкции, Netflix взялась укрощать хаос — точнее, Chaos Monkey (рисунок 8). Chaos Monkey — это компонент облачных приложений, который Netflix использует для внесения в работу приложения систематического хаоса.

Рисунок 8. Функция Chaos Monkey
Chaos Monkey — это компонент облачных приложений, используемый для внесения в работу приложения систематического хаоса.
Chaos Monkey — это компонент облачных приложений, используемый для внесения в работу приложения систематического хаоса.

Эта функция проходит через инфраструктуру и целенаправленно отключает службы и экземпляры служб, имеющие решающее значение для ее функционирования. Зачем Netflix это делает? Как можно при этом выжить?

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

Во-вторых, как. Netflix выживает благодаря методу дробовика, о котором я уже упоминал. Идея проста: обеспечить достаточное количество экземпляров службы, чтобы успешно выполнять 99,9999% запросов. Любые неудачные запросы будут работать на повторение. Если отключить экземпляр службы, ее место займет другой, находящийся поблизости. Если отключить всю службу целиком, система компенсирует ее или перенаправит пользователей в другие доступные зоны или регионы, где эта служба работает. Если больше ничего нет, пользователь или запрос должен быстро получить отказ, не дожидаясь таймаута.

Netflix расширила концепцию Chaos Monkey и предложила функцию Simian Army (см. рисунок 9), куда входят компоненты облачных приложений Chaos Monkeys, Janitor Monkeys, Conformity Monkeys и Latency Monkeys, которые вносят хаос в определенные операции, включая задержки и проблемы нормативно-правового соответствия.

Рисунок 9. Функция Simian Army
Функция Simian Army

Как видите, Netflix (и другие компании, внедрившие микрослужбы) поддерживает идею, что то, что убивает ваше приложение, делает его сильнее.

Заключение

Итак, вот основные преимущества микрослужб, о которых я говорил:

  • их мелкий размер позволяет программистам работать максимально продуктивно;
  • каждую службу легко освоить и проверить;
  • можно надлежащим образом обрабатывать отказы любых зависимых служб;
  • уменьшается влияние взаимозависимых отказов.

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

Множество служб означает больше соглашений между группами, так как необходимо поддерживать интерфейсы, и разные версии API становится более распространенным явлением. Часто это достаточно хорошо решается внутри модели DevOps, независимо от того, создаете ли вы архитектуру на основе микрослужб или нет.

Возможно, вы заметили, что я не затрагивал конкретные технологии, используемые для реализации приложений на основе микрослужб. В следующих статьях мы рассмотрим, как IBM разрабатывает и развертывает свои собственные службы на основе архитектуры микрослужб, на примере служб Watson (см. рисунок 10) и IBM Containers в Bluemix. В их число входит все от Docker до Node.js, Netflix OSS и собственных органических возможностей IBM.

Рисунок 10. Облачные службы IBM Watson на базе микрослужб
Логотип IBM Watson

Читайте в следующих статьях этой серии углубленный анализ и описание практических примеров применения микрослужб в облаке IBM Cloud и за его пределами. Чтобы продолжить обсуждение, вы можете обращаться прямо по адресу @rosowski или оставлять свои комментарии ниже.

Благодарности и источники изображений

Я хотел бы поблагодарить Джонатана Бонда за его презентацию, которая позволила мне собраться с мыслями и из которой я взял несколько изображений (рисунки 1, 5, 6 и 7).

Внешние источники изображений: рисунок 3 , рисунок 4, рисунок 8, рисунок 9.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Web-архитектура
ArticleID=1022547
ArticleTitle=Микрослужбы в действии: Часть 1. Введение в микрослужбы
publish-date=11262015