Термин «Microservice Architecture» возник в течение последних нескольких лет, чтобы описать особый способ разработки программных приложений разрабатываемых и развертываемых независимо друг от друга. В то время как нет четкого определения этого архитектурного стиля, есть определенные общие характеристики ему присущие: автоматизированное развертывание и децентрализованное управление его компонентов и данных.
Короче говоря, этот архитектурный стиль представляет собой подход к разработке единого приложение как набора небольших сервисов, каждое из которых работает в своем собственном процессе и общается с сервисами, часто используя HTTP REST API. Существует абсолютный минимум централизованного управления этими услугами, которые могут быть написаны на разных языках программирования и использовать различные технологии хранения данных.
Монолитные приложения могут быть весьма успешными, хотя все больше людей чувствуют себя крайне разочароваными, особенно когда эти приложения развернуты в облаке. После внесенния в небольшой части приложения изменения, требуется пересобрать весь монолит и заново развернуть его в облаке. Со временем часто бывает трудно сохранить хорошую модульную структуру приложения, после изменения, которые должны затрагивать лишь только один модуль, что повышает накладные расходы на сопровождение продукта.
Scalability: Flat vs 3D
Горизонтальное масштабирование (X-axis scaling) позволяет запускать только множество экземпляров всего приложения, а не той ее части которая требуют большего ресурса, за балансировщиком нагрузки. Если есть N копий приложения, то каждая копия обрабатывает 1 / N нагрузки. Это простой и часто используемый подход масштабирования приложение. Одним из недостатков такого подхода заключается в том, что, поскольку каждая копия потенциально получает доступ ко всем данным, чтобы быть эффективным, кэши требуется больше памяти. Еще одна проблема этого подхода заключается в том, что он не учитывает последующее развития и увеличения сложности приложений.
Вертикальное масштабирование — увеличение производительности каждого компонента системы с целью повышения общей производительности. Масштабируемость в этом контексте означает возможность заменять в существующей вычислительной системе компоненты более мощными и быстрыми по мере роста требований и развития технологий. Это самый простой способ масштабирования, так как не требует никаких изменений в прикладных программах, работающих на таких системах.
Параметрическое масштабирование (Z-axis scaling) — каждый экземпляр выполняет идентичную копию кода. В этом отношении он похож на (X-axis scaling). Большая разница в том, что каждый сервер отвечает только за своё подмножество данных. Некоторый компонент системы отвечает за маршрутизацию каждого запроса на соответствующий экземпляр. Один из критериев маршрутизации является как правило атрибут запроса, другим распространенным критерием маршрутизации критерием является тип клиента. (Z-axis scaling) имеет ряд преимуществ и обычно используются для масштабирования баз данных. Каждый экземпляр имеет дело только с своим подмножеством данных. Это улучшает использование кэш-памяти и уменьшает использование трафика ввода/вывода, а также улучшает масштабируемость транзакций, так как запросы, как правило, распределяются между несколькими экземплярами. Кроме того, (Z-axis scaling) улучшает изоляцию сбоев, поскольку отказ одного экземпляра оставляет часть данных доступной.
Функциональное масштабирование (Y-axis scaling) в отличии от (X-axis and Z-axis), которые состоят из нескольких, работающих идентичных копий приложения, последний тип масштабирования разбивает приложение на несколько разных услуг. Каждая служба несет ответственность за одну или несколько функций, взаимодествуя друг с другом. Есть несколько различных способов по функциональному разложения приложения, но эта уже тема отдельной статьи…
Комплексное применение всех трех типов масштабирования позволяет не только решить проблемы развития и увеличения сложности приложений, но и значительно улучшить производительность и эффективность использования вашей инфраструктуры.
Service Orchestration and Choreography
Технологии описывающие поведенческую модель взаимодействии сервисов, включающих в себя последовательность действий и взаимоотношений между различными видами услуг, которые определяют бизнес процесс. Есть два способа, чтобы построить этот процесс: оркестровка и хореография сервисов.
Оркестровка представляет собой единый централизованный исполняемый бизнес-процесс (Orchestrator), который координирует взаимодействие между различными службами. Orchestrator отвечает за вызов и объединения сервисов. Отношения между всеми участвующими службами описываются одной конечной точкой (composite service). Оркестровка включает в себя управление сделок между отдельными услугами. Orchestration использует централизованный подход к составу услуг.
Хореография описывает взаимодействие между несколькими службами, в то время как оркестровка представляет контроль с точки зрения одной из сторон. Хореография отличается от оркестровки расположением логики, которая контролирует взаимодействие между службами. Хореография является глобальным описанием участвующих услуг, который определяется путем обмена сообщениями, правил взаимодействия и соглашений между двумя или более услугами, и использует децентрализованный подход к составу услуг.
Комментарии (11)
valis
05.09.2016 13:07+1Имхо. В архитектуре микросервисов самое интересное начинается в моменты:
— Передача на сопровождение — необходимо построить централизованный каталог микросервисов с контролем версий и жизни каждого сервиса
— Модификация — с целью минимизировать доработки всего ландшафта и ошибок необходимо: грамотно делить функционал, обеспечивать обратную совместимость, контролировать выдержку архитектурных стилей при проектировании интерфейсов, планировать регрессионное тестирование и детально документировать!!!
Мне кажется что это основные аспекты данной архитектуры, которые часто заставляют разработчиков смотреть в сторону монолита.
Jackob
05.09.2016 17:04Полностью соглашусь с вами относительно первого пункта — необходимо средство формального описания микросервисов и протоколов их взаимодействия между собой, а также средство для моделирования этого взаимодействия.
И поспорю со вторым вашим утверждением, все перечисленное вами — всего лишь рабочие моменты, которые присущи и монолиту, с той разницей что микросервисы перераспределяют роли между программистом и архитектором в пользу последнего…
Yeah
05.09.2016 17:51По-моему самое интересное там начинается с вопроса: а как мы будем обеспечивать целостность?
oxidmod
05.09.2016 17:52целостность чего?
Yeah
05.09.2016 18:36Данных. Один микросервис заведует пользователями, второй фоточками. Как убедиться, что нет потерявшихся фоточек (юзера удалили) и фоточек с левыми user_id?
oxidmod
05.09.2016 22:32через события и менеджер очередей
Yeah
06.09.2016 02:19Это не дает целостности. Сервер очередей может упасть, сообщение не дойти (например в случае, если сервер очередей не будет справляться с потоком). Сервер БД тоже может упасть, но тогда не пройдет вся транзакция, а тут — частично. Что если "A" дергает "B", "C" и "D", на "С" все нормально, а "D" и "B" вернули ошибки? Как отменить транзакцию на "C"?
Я как-то интересовался микросервисами, гуглил, читал бложики, но все, что я смог найти: та ну ее эту целостность и транзакции! С таким подходом область применения микросервисов сильно сужается.
oxidmod
06.09.2016 07:12Смотрите на них как на отдельные приложения. Что вы делаете когда вызов стороннего апи падает?
valis
05.09.2016 18:02Ну вы меня перефразировали.
Все сводится к обеспечению архитектурной целостности продукта, а это можно достичь путем строгой выдержки принятых в группе разработки стандартов и жесткого контроля их выполнения.
gearbox
Где аспекты? рука дрогнула и недопереведенный текст зарелизили?
Jackob
Руки дрожат после выходных… Знакомая тема?
Хотя задекларированные аспекты освещенны, пожалуй кроме traffic engineering,
но это слишком обьемная тема, чтобы валить все в одну кучу…