Прочитав некоторые статьи, посвященные преимуществам и недостаткам микросервисной архитектуры (micro service architecture MSA), я хотел бы осветить иные аспекты, которые она представляет для гибкой оркестровки, контроля масштабирования инфраструктуры облака, хореографии — описывающей взаимодействие между несколькими службами и динамическим управлением трафиком (traffic engineering).
Термин «Microservice Architecture» возник в течение последних нескольких лет, чтобы описать особый способ разработки программных приложений разрабатываемых и развертываемых независимо друг от друга. В то время как нет четкого определения этого архитектурного стиля, есть определенные общие характеристики ему присущие: автоматизированное развертывание и децентрализованное управление его компонентов и данных.
Короче говоря, этот архитектурный стиль представляет собой подход к разработке единого приложение как набора небольших сервисов, каждое из которых работает в своем собственном процессе и общается с сервисами, часто используя HTTP REST API. Существует абсолютный минимум централизованного управления этими услугами, которые могут быть написаны на разных языках программирования и использовать различные технологии хранения данных.
Монолитные приложения могут быть весьма успешными, хотя все больше людей чувствуют себя крайне разочароваными, особенно когда эти приложения развернуты в облаке. После внесенния в небольшой части приложения изменения, требуется пересобрать весь монолит и заново развернуть его в облаке. Со временем часто бывает трудно сохранить хорошую модульную структуру приложения, после изменения, которые должны затрагивать лишь только один модуль, что повышает накладные расходы на сопровождение продукта.
Горизонтальное масштабирование (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), которые состоят из нескольких, работающих идентичных копий приложения, последний тип масштабирования разбивает приложение на несколько разных услуг. Каждая служба несет ответственность за одну или несколько функций, взаимодествуя друг с другом. Есть несколько различных способов по функциональному разложения приложения, но эта уже тема отдельной статьи…
Комплексное применение всех трех типов масштабирования позволяет не только решить проблемы развития и увеличения сложности приложений, но и значительно улучшить производительность и эффективность использования вашей инфраструктуры.
Технологии описывающие поведенческую модель взаимодействии сервисов, включающих в себя последовательность действий и взаимоотношений между различными видами услуг, которые определяют бизнес процесс. Есть два способа, чтобы построить этот процесс: оркестровка и хореография сервисов.
Оркестровка представляет собой единый централизованный исполняемый бизнес-процесс (Orchestrator), который координирует взаимодействие между различными службами. Orchestrator отвечает за вызов и объединения сервисов. Отношения между всеми участвующими службами описываются одной конечной точкой (composite service). Оркестровка включает в себя управление сделок между отдельными услугами. Orchestration использует централизованный подход к составу услуг.
Хореография описывает взаимодействие между несколькими службами, в то время как оркестровка представляет контроль с точки зрения одной из сторон. Хореография отличается от оркестровки расположением логики, которая контролирует взаимодействие между службами. Хореография является глобальным описанием участвующих услуг, который определяется путем обмена сообщениями, правил взаимодействия и соглашений между двумя или более услугами, и использует децентрализованный подход к составу услуг.
Термин «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 использует централизованный подход к составу услуг.
Хореография описывает взаимодействие между несколькими службами, в то время как оркестровка представляет контроль с точки зрения одной из сторон. Хореография отличается от оркестровки расположением логики, которая контролирует взаимодействие между службами. Хореография является глобальным описанием участвующих услуг, который определяется путем обмена сообщениями, правил взаимодействия и соглашений между двумя или более услугами, и использует децентрализованный подход к составу услуг.