Фреймворки разработки для приложений на основе микросервисов: оценка и сравнение

АННОТАЦИЯ

Микросервисный архитектурный стиль недавно привлек большое внимание как академических кругов, так и промышленности как новый способ проектирования, разработки и развертывания облачно-нативных приложений. Эта концепция поощряет декомпозицию монолита на множество независимо развертываемых единиц. Типичное приложение на основе микросервисов формируется из двух типов сервисов: функциональные сервисы, которые предоставляют основную бизнес-логику, и инфраструктурные сервисы, которые предоставляют основные функциональные возможности для экосистемы микросервисов. Чтобы повысить производительность разработчиков, было разработано множество программных фреймворков для предоставления этих повторно используемых инфраструктурных сервисов, позволяющих программистам сосредоточиться на реализации микросервисов произвольными способами. В этой работе мы использовали четыре фреймворка с открытым исходным кодом для разработки облачного приложения, чтобы сравнить и оценить их удобство использования и практичность. Хотя все выбранные фреймворки в целом продвигают асинхронный дизайн микросервисов, существуют различия в способах реализации сервисов каждым из них. Это приводит к проблемам совместимости, таким как соглашение об именовании топиков сообщений. Кроме того, ключевым выводом являются долгое время запуска сервисов на основе JVM, что может снизить устойчивость и переносимость приложения. Некоторые другие преимущества проистекают непосредственно из языка программирования, такие как способность Go генерировать нативные исполняемые файлы, что приводит к очень маленьким и компактным образам Docker (до 78% меньше по сравнению с другими языками).

1. ВВЕДЕНИЕ

Микросервисный архитектурный стиль возник из архитектурных шаблонов Сервис-ориентированной архитектуры и Предметно-ориентированного проектирования с сильным акцентом на практики DevOps [15]. Он не только был успешно принят в компаниях с многомиллионными пользователями, таких как Netflix или Amazon, но и получил значительное внимание со стороны академических кругов как надежный и масштабируемый метод построения облачных приложений. Короче говоря, микросервисная архитектура пропагандирует новый дизайн программного обеспечения, в котором приложение структурировано в сервисы. Эти сервисы независимо разрабатываются, обновляются и развертываются, что значительно улучшает гибкость приложения. Аналогично, общая масштабируемость и отказоустойчивость приложения улучшаются. Однако эти преимущества также имеют свою цену. Приложения становятся более сложными, а задержки увеличиваются, потому что канал связи более подвержен сетевым задержкам.

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

1. Обзор различных подходов к реализации микросервисов, который демонстрируется в четырех выбранных микросервисных фреймворках.
2. Модель сравнения для фреймворков микросервисов, основанная на трех основных критериях: функциональные возможности, шаблоны проектирования и производительность.
3. Последствия принятия фреймворка при разработке микросервисов.

В остальной части этой статьи Раздел 2 дает краткий отчет об оценках и сравнениях, проведенных до сих пор для микросервисов. Затем мы представляем мотивирующий пример использования и архитектуру прототипа системы взимания платы в Разделе 3. Раздел 5 представляет сравнение по характеристикам, а Раздел 6 показывает практические результаты производительности. Мы обсуждаем результаты в Разделе 7, делаем общий вывод в Разделе 8 и перечисляем будущие направления исследований в Разделе 9.

2. СОПУТСТВУЮЩИЕ РАБОТЫ

Одно из самых известных определений программного фреймворка, предложенное Джонсоном, описывает его как «переиспользуемый дизайн всей или части системы, который представлен набором абстрактных классов и способом взаимодействия их экземпляров» или «скелет приложения, который может быть настроен разработчиком приложения» [12]. С программным фреймворком разработчики могут переиспользовать как дизайн, так и код, чтобы сосредоточиться на решении специфических бизнес-потребностей [13]. Следовательно, разработка программного обеспечения на основе фреймворков может рассматриваться как деятельность по модификации и расширению фреймворка [19]. Кроме того, фреймворк может улучшить производительность программиста и повысить качество, производительность, надежность и совместимость программного обеспечения [7, 13, 17]. Однако программный фреймворк также может привести к удлинению времени разработки, поскольку разработчики должны изучать и знакомиться с фреймворком [23]. Также принятие фреймворка может привести к более сложной структуре кода и большему объему программного обеспечения.

Поскольку фреймворки обычно разрабатываются для решения узкого набора проблем, нацеливаясь на определенный тип приложений [8], существует все больше и больше фреймворков, специализированных для облегчения, ускорения и улучшения разработки приложений с микросервисным архитектурным дизайном. Было несколько работ, изучающих производительность микросервисов [2, 25]. Другие предлагают критерии для оценки микросервисов, такие как [1, 24]. Однако, насколько нам известно, нет ни одной исследовательской статьи, которая сравнивает производительность и подходы, используя разные языки программирования и фреймворки для построения одного и того же приложения. Эта статья решает именно этот пробел, чтобы сравнить и оценить различные подходы к разработке на основе фреймворков для микросервисов.

3. МОТИВАЦИОННЫЙ ПРИМЕР ИСПОЛЬЗОВАНИЯ

Одной из самых больших проблем в городских районах является снижение качества воздуха, которое вызывает \(4.2\) миллиона преждевременных смертей каждый год, согласно недавнему отчету Всемирной организации здравоохранения (ВОЗ) [20]. В том же отчете мобильность человека была определена как основной источник загрязнения наружного воздуха, включая сжигание ископаемого топлива автомобилями.

Во многих странах политики ввели различные регулирования для решения этих проблем, одним из них является внедрение платы за загрязнение. Однако текущие схемы взимания платы взимают фиксированные сборы на основе статических критериев, таких как тип транспортного средства или зона взимания платы [26]. В этой работе, вдохновленные [10], мы предлагаем новую детализированную систему для расчета платы за проезд пропорционально уровню загрязнения каждой области. Это означает, что чем более загрязнена область, тем выше плата за пройденный километр применяется для всех транспортных средств в этой области. Одним очевидным преимуществом этого подхода является то, что эта система позволяет динамическую ставку платы на основе уровня загрязнения воздуха в реальном времени. Кроме того, это очень масштабируемо, поскольку она использует только данные о местоположении транспортного средства в короткие интервалы для расчета платы за проезд. Справедливость этой системы может быть дополнительно улучшена добавлением информации о модели транспортного средства и скорости (оцененной из данных о местоположении).

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

Рис. 1 иллюстрирует архитектуру, в которой стрелки между микросервисами - это не прямое общение, а скорее косвенное общение через брокер сообщений. Конвейер обработки объяснен подробно ниже:

• Транспортные средства обновляют информацию о своих GPS-координатах, отправляя сообщения на основе JSON через брокер сообщений.
• Сервис сопоставления карт (Map Matcher Service) подписывается на Сообщения обновления местоположения от транспортных средств. Затем он использует API, предоставляемые локальным экземпляром OSRM (Open Source Routing Machine) [11], чтобы сопоставить сообщенные координаты с маршрутом на улицах. Затем пройденный маршрут будет отправлен в брокер сообщений в Сообщениях о маршруте (Route Messages).
• Сервис сопоставления загрязнения (Pollution Matcher Service) получает Сообщения о маршруте и сравнивает их с базой данных о загрязнении воздуха. В этой базе данных PostGIS загрязненные области хранятся как полигоны с соответствующими уровнями загрязнения. Полученный маршрут сопоставляется с этими полигонами, и в случае, если маршрут пересекает несколько областей с разными уровнями загрязнения, он будет разбит на несколько сегментов. Эти сегменты вместе с соответствующими уровнями загрязнения отправляются Сервисом сопоставления загрязнения в брокер сообщений через Сообщения о сегментах (Segment Messages).
• Сервис расчета платы (Toll Calculator Service) рассчитывает плату за проезд для каждого транспортного средства на основе Сообщений о сегментах. Он вычисляет расстояние пути каждого сегмента и, на основе уровня загрязнения, возвращает совокупную плату за проезд для каждого транспортного средства. Эти значения отправляются в брокер сообщений как Сообщения о плате (Toll Messages).
• При получении Сообщений о плате Панель управления (Dashboard) отображает совокупную плату за проезд для каждого автомобиля и визуализирует маршрут каждого транспортного средства на интерактивной карте.

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

4. ФРЕЙМВОРКИ

Существует большое количество фреймворков для разных языков программирования. Для реализации системы взимания платы мы выбрали четыре различных фреймворка микросервисов: Go Micro (Go), Molecular (JavaScript с Node.js), Lagom (Scala) и Spring Boot/Spring Cloud (Java). Они выбраны, чтобы отразить разнообразие инструментов, которые могут быть использованы для разработки микросервисов. Что касается языков программирования, Java считается «старым» языком, в то время как Scala и Go были представлены в последнее десятилетие, и Node.js - это новая среда выполнения для JavaScript. С точки зрения философии дизайна фреймворка, хотя Spring Boot широко используется для микросервисов, он не разработан специально для таких приложений, как другие три. Каждый фреймворк предоставляет различный подход к построению приложений на основе микросервисов. В этом разделе мы кратко обсуждаем основные различия.

Go Micro предоставляет абстракцию для разработки распределенных систем с использованием Удаленного вызова процедур (RPC) и событийно-ориентированной коммуникации, написанную на Go. Этот опинионизированный фреймворк предоставляется как набор подключаемых строительных блоков, которые могут быть включены или исключены в проекте в зависимости от специфических требований приложения. Этот дизайн снижает сложность в разработке. Они охватывают широкий спектр функциональностей, от синхронной/асинхронной передачи сообщений, кодирования сообщений, обнаружения сервисов, до динамической конфигурации. Чтобы определить микросервис с Go Micro, фреймворк поощряет разработчиков сначала определить интерфейсы (по умолчанию через ProtoBuf), а затем реализовать их. После этого сервис может быть инициализирован и зарегистрирован во встроенном реестре сервисов.

Lagom - это еще один опинионизированный микросервисный фреймворк для построения реактивных микросервисов на Scala или Java. Разработанный и поддерживаемый той же компанией, что стоит за Akka и Play Framework, Lagom построен для легкой интеграции в эти две технологии. Lagom поддерживает и поощряет использование Поиска источников событий (Event sourcing) и Разделения ответственности команд и запросов (CQRS) для сохранения данных. Lagom рекомендует разработчикам разделять интерфейс сервиса и реализацию сервиса, которые организованы как подпроекты в пределах одной сборки. В то время как первый содержит описания интерфейсов вместе с моделями данных, второй реализует логику сервиса.

Molecular - это микросервисный фреймворк для JavaScript, использующий среду выполнения Node.js, построенную на движке V8 JavaScript от Chrome. Основная философия дизайна этого фреймворка - создание приложений с низкой задержкой, управляемых событиями. Molecular также предоставляет подключаемые модули для различных функций, таких как шлюзы, база данных, сериализация и т.д. Фреймворк состоит из трех основных компонентов: транспортер, сервис и брокер сервисов. В то время как сервис определяет общую структуру для каждого микросервиса, транспортер - это абстракция для шины связи, а брокер сервисов связывает сервис с транспортером.

Spring Boot & Spring Cloud - это два проекта из экосистемы Spring. В то время как Spring Boot - это опинионизированный способ построения автономных Spring-приложений, Spring Cloud предоставляет набор инструментов для быстрого построения нескольких общих шаблонов в распределенных системах, таких как обнаружение сервисов, управление конфигурацией и т.д. Это означает, что Spring Boot не разработан специально для разработки микросервисов, а скорее как среда разработки полного стека. Spring Boot должен полагаться на Spring Cloud для возможностей, специфичных для микросервисов.

5. СРАВНЕНИЕ ХАРАКТЕРИСТИК

В этом разделе мы предоставляем обширную оценку этих фреймворков относительно 2 основных критериев: функциональные возможности и шаблоны проектирования. Для первого мы дополнительно подкатегоризируем его на (1) Зрелость, (2) Поддержка разработки микросервисов и (3) Встроенные функции. Все эти детали будут суммированы в Таблице 1 и Таблице 2. Обратите внимание, что «N/A» не обязательно означает, что фреймворку не хватает определенной функции, а скорее, что функция требует внешних библиотек, которые еще не были официально интегрированы во фреймворк.

5.1 Основные функции и философия дизайна

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

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

5.2 Зрелость

Чтобы количественно оценить зрелость фреймворка с открытым исходным кодом, мы смотрим на цикл выпуска и метрики с сайтов открытого исходного кода для хостинга кода, таких как GitHub, как использовалось в предыдущих исследованиях [6, 18].

Учитывая, что Spring Boot был первоначально выпущен в 2014 году, в то время как первый выпуск Lagom был в 2016 году, а Go Micro и Molecular - в 2017 году, Spring Boot стал одним из самых зрелых фреймворков. Это также объясняет, как количество выпусков от Spring превосходит другие в два раза, как видно в Таблице 1. Однако, поскольку Spring Boot также является популярным фреймворком для построения общих Java-приложений, это может не полностью отражать зрелость Spring в разработке микросервисов конкретно.

5.3 Поддержка разработки микросервисов

Учитывая разницу в зрелости среди выбранных фреймворков, можно ожидать разных уровней поддержки и кривых обучения. Действительно, документация Spring Boot очень обширна по сравнению с другими. С огромным сообществом и долгим существованием на рынке легко найти поддержку от сообществ разработчиков, таких как StackOverflow. Кроме того, Spring и Lagom поддерживаются Pivotal и Lightbend соответственно, поэтому они могут предложить коммерческую поддержку для крупных организаций, в то время как Molecular и Go Micro должны полагаться на сообщественную поддержку. Инструменты сборки и решения управления зависимостями играют важную роль для значительного улучшения производительности. Шаблонные коды для новых микросервисов могут быть быстро сгенерированы по определенным шаблонам, однако каждый фреймворк поддерживает разный уровень настройки. Например, Lagom и Molecular позволяют только настроить имя проекта и имя сервиса, в то время как другие два позволяют указывать пакеты зависимостей. Кроме того, функции, такие как горячая перезагрузка или интерактивная консоль разработки, могут дополнительно сократить циклы разработки, поскольку они помогают разработчикам немедленно видеть эффекты нового кода во время выполнения.

5.4 Шаблоны проектирования

Для достижения надежности в микросервисах есть определенные рекомендации, которым нужно следовать, такие как минимизация зависимостей сервисов или разделение хранилища данных [21]. Эти нефункциональные свойства материализуются в разных шаблонах проектирования. Чтобы понять, как философия дизайна каждого выбранного фреймворка отличается друг от друга, мы кратко обсуждаем их в этом разделе и предоставляем сводку в Таблице 2.

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

Другим шаблоном проектирования, пропагандируемым всеми фреймворками, является шаблон проектирования База данных на сервис. Дизайн микросервисов помогает

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

В среде с множеством сервисов, независимо развернутых, крайне важно для операторов иметь обзор приложения и понимание основных операций [3]. Поэтому все четыре фреймворка предоставляют обширную интеграцию с различными инструментами логирования. Однако, когда дело доходит до сбора метрик, в то время как Molecular имеет встроенный модуль, собирающий и публикующий метрики в различные выходы, Spring Boot и Go Micro предоставляют сборщик метрик как подключаемый модуль; Lagom должен полагаться на облачную платформу Lightbend для этих возможностей. Это потому, что Lagom был разработан для упрощения разработки и развертывания приложений микросервисов на текущем предложении Lightbend в облачной платформе.

Аналогично, техника, используемая для мониторинга и анализа распределенных систем, называемая Распределенная трассировка (Distributed Tracing), также поддерживается всеми фреймворками. В этой технике, когда запрос проходит через систему, добавляется уникальный идентификатор, позволяющий детали о пути, времени, проведенном в каждом сервисе, быть центрально захваченными и визуализированными. Хотя ни один фреймворк не предоставляет свою собственную реализацию сервиса мониторинга, поддерживающего Распределенную трассировку, Spring Boot, Molecular и Go Micro полностью интегрированы с внешними решениями, такими как Prometheus. В противоположность этому, микросервисы Lagom снова должны полагаться на платформу Lightbend.

С недавним ростом контейнерных облачных платформ, Docker и оркестрационные платформы на основе Docker, такие как Kubernetes, Mesosphere DC/OS, OpenShift и т.д., стали де-факто стандартом. Все фреймворки имеют поддержку для развертывания Docker, кроме поддержки Molecular для Kubernetes все еще отсутствует. И Spring Boot, и Lagom могут строить исполняемые файлы, которые могут быть развернуты на Heroku, Azure и т.д.

Что касается шаблонов коммуникации между микросервисами, все фреймворки поощряют использование асинхронной передачи сообщений как основного способа обмена информацией. Асинхронная передача сообщений может разделить сервисы, минимизируя зависимости и улучшая отказоустойчивость приложения в целом [22]. Фактически, способность работать асинхронно - это один из критериев дизайна, чтобы получить максимальную отдачу от микросервисного архитектурного стиля [9]. В то время как большинство широко используемых протоколов, таких как AMQP, MQTT, полностью поддерживаются всеми, каждый фреймворк реализует канал связи по-разному: Spring, Lagom и Go Micro предоставляют разные модули интеграции для брокеров сообщений, в то время как Molecular различает два типа коммуникации. Локальные сервисы используют внутрипамятную локальную шину для обмена сообщениями. Удаленные сервисы полагаются на слой абстракции, называемый Транспортер (Transporter), который может доставлять события, запросы и ответы. По умолчанию NATS используется как брокер, однако другие реализации не могут быть добавлены напрямую, потому что Molecular автоматически добавляет префиксы к топикам сообщений.

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

Таблица 1. Характеристики фреймворков микросервисов.

Таблица 2. Шаблоны проектирования фреймворков микросервисов.

6. ОЦЕНКА ПРОИЗВОДИТЕЛЬНОСТИ

6.1 Тестовая установка

Мы реализовали конвейер, как описано в разделе 3, с каждым фреймворком. Для оценочного теста использовались следующие версии инструментов и фреймворков: Spring Boot 2.2.4 (Java 1.8), Go Micro 1.18.0, (Go 1.13), Molecular 0.13.0 (Node.js 13.1.4), Lagom 1.6.0 (Scala 2.12.8), NATS 2.1.2. Чтобы обеспечить согласованность входных данных по тестам, мы построили Симулятор трафика (Traffic Simulator) для симуляции транспортных средств. Этот компонент основан на Simulation of Urban MObility (SUMO) [4] и предоставляет симуляцию трафика в европейском городе, используя данные из OpenStreetMap. Из Панели управления симуляция может быть настроена по количеству симулируемых транспортных средств и частоте обновления. Результаты, представленные в этой статье, получены из симуляций с 10 транспортными средствами, и они обновляют свое местоположение каждые 5 секунд.

Машина, на которой проводились тесты, имеет процессор Intel Core i5 и 16 ГБ ОЗУ. Все микросервисы контейнеризованы с использованием Docker и развернуты с использованием Docker Compose, так как это популярный выбор для достижения платформенно-независимой стратегии развертывания [25]. Мы рассматривали задержку и потребление ресурсов как ключевые критерии для измерения производительности разных фреймворков. Другой метрикой ресурсов является объем приложения, заданный размером образов Docker.

Выбранный пример использования представляет некоторые типичные типы микросервисов, которые должны быть приняты во внимание при оценке приложения. Сопоставитель карт (Map Matcher) изображает сервис, который потребляет внешний API, Сопоставитель загрязнения (Pollution Matcher) постоянно обменивается данными с внешней базой данных, в то время как Калькулятор платы (Toll Calculator) выполняет все вычисления внутренне.

6.2 Медленный старт реализаций на основе JVM

Мы заметили длинные задержки в первых сообщениях, обработанных в реализациях Spring Boot и Lagom, по сравнению с последующими запросами, как проиллюстрировано на Рис. 2.

Причина такого странного поведения, которое не найдено в других реализациях, лежит в фазе прогрева Java Virtual Machine (JVM) [16]. В этом тесте, чтобы уменьшить эффекты фазы прогрева, мы оцениваем производительность фреймворка только после пяти итераций сообщений, т.е. пропуская первые 50 сообщений.

Рисунок 2: Длинная задержка для первых сообщений в Lagom.

6.3 Сквозная производительность задержки

Рис. 3 суммирует сквозную задержку каждого фреймворка. Все четыре реализации показывают схожее поведение в отношении задержки,

хотя и в разной степени. Есть еще некоторые заметные паттерны, общие для всех реализаций. Например, самым медленным микросервисом всегда является Сопоставитель загрязнения (Pollution Matcher), который должен обращаться к базе данных PostGIS, он составляет от 73.27% в Lagom до 90.59% от общего времени в реализации Go Micro. В противоположность этому, Калькулятор платы (Toll Calculator) имеет минимальный вклад в общее сквозное время, поскольку он может выполнять все процессы внутренне. Из результатов ясно, что доступ к базе данных очень медленный по сравнению с другими задачами, связанными с вводом-выводом. Это иллюстрирует трудности в управлении состоянием сервиса, в котором они должны быть экстернализированы в базу данных, чтобы создать полностью без状态的ные сервисы. Во многих дизайнах микросервисы вынуждены следовать принципу 12-факторного приложения, т.е. быть без状态ными, но вообще либо очень трудно, либо не оптимизировано строить приложения исключительно из без状态ных микросервисов.

Накладные расходы на коммуникацию более рассеяны для Lagom и Spring, в то время как Go Micro и Molecular имеют более последовательную задержку. Даже с более медленной коммуникацией, Lagom в общем performs лучше, чем Go Micro.

Рисунок 3: Сравнение производительности задержки.

6.4 Потребление ресурсов

6.4.1 Размер образов Docker

Мы оценили размер образов Docker, произведенных каждым фреймворком, так как меньшие образы могут быть развернуты и созданы быстро, приводя к более быстрым циклам обновления [14]. В этой установке мы использовали образы на основе Alpine: Spring использует openjdk-8-jre-alpine, Lagom использует openjdk-8-jre-alpine, Molecular использует mhart/alpine-node:10, и Go Micro использует базовый образ golang как образ сборки и scratch как контейнер развертывания.

Результаты суммированы на Рис. 4. Поскольку приложения Go могут быть собраны как бинарные файлы, они могут использовать scratch - минимальный пустой образ Docker. Поэтому сервисы, разработанные на этом языке, очень компактны по сравнению с другими, например, Сопоставитель загрязнения, написанный на Go Micro, на 78% меньше реализации с Lagom (33.6 МБ против 156 МБ). Molecular также имеет способность создавать меньшие докеризированные сервисы по сравнению с Lagom или Spring Boot, так как эти два фреймворка требуют JVM для запуска исходного кода.

Рисунок 4: Сравнение размеров образов Docker.

6.4.2 Использование CPU и памяти

Как видно на Рис. 5, Lagom и Spring дают гораздо более высокое потребление ресурсов, чем два других фреймворка. Интересно, что в то время как Lagom имеет более высокое использование CPU на сервисе Map Matcher, чем Spring, и ниже, чем для Pollution Matcher, в случае использования памяти результаты обратные. Смотря снова на Рис. 3, задержка для Map Matcher самая низкая с Spring, но этот фреймворк также показывает самую высокую задержку в Pollution Matcher. Lagom получает немного более низкую общую сквозную задержку, чем Go Micro, но с гораздо более высоким потреблением ресурсов, поэтому важно смотреть на оба аспекта при решении о фреймворке.

Более низкое потребление CPU и памяти и маленький размер образов сервисов Go Micro делают его самым эффективным фреймворком в использовании ресурсов из четырех.

Рисунок 5: Потребление CPU и памяти микросервисов, реализованных разными фреймворками.

7. ОБСУЖДЕНИЕ

Три из четырех фреймворков, изученных в этой работе (Lagom, Molecular и Go Micro), поощряют разработчиков структурировать протокол связи перед разработкой фактических микросервисов. В противоположность этому, Spring Boot не заставляет разработчиков следовать определенному стилю кода для определения API приложения. Одна из возможных причин - то, что Spring Boot - это фреймворк общего назначения, не разработанный специально для микросервисов. Этот факт подчеркивает важность шаблона коммуникации в распределенных системах в целом и в микросервисах в частности.

В теории, разделение сервисов описывается как одна из самых важных особенностей микросервисов. Однако в реальности есть несколько вызовов для реализации полной независимости между микросервисами. Например, общие библиотеки между микросервисами улучшают производительность разработчиков, но также создают зависимости. В нашей реализации JSON выбран как формат сообщений, обмениваемых между сервисами, потому что он не создает специфических требований для микросервисов в сериализации/десериализации. Если вместо этого используется Protocol Buffer, это заставляет каждый микросервис использовать ProtoBuf. Однако, учитывая, что реализации ProtoBuf доступны для многих языков программирования, разработчики все еще имеют много опций для разработки своих сервисов. В другом крайнем случае, использование некоторых платформенно-специфических протоколов, таких как Spring HTTP Invoker, заставляет и сервер, и клиент быть написанными на языке JVM.

Для облачно-нативной архитектуры, такой как микросервисы, совместимость становится более значимой, чем когда-либо. Принятие микросервисного фреймворка, использующего стандарты или популярные инструменты, может быть гораздо более выгодным для организации в долгосрочной перспективе. В этом отношении, как один из самых популярных программных фреймворков, Spring Boot/Spring Cloud предоставляет разработчикам четкое преимущество для построения микросервисов, так как этот фреймворк имеет обширный уровень поддержки и интеграции, доступной. И Go Micro, и Molecular предоставляют менее опинионизированный подход к построению микросервисов. Lagom сильно полагается на платформу Lightbend и Akka, так что это может потребовать дополнительных усилий для развертывания на других платформах.

Разработка микросервисов в частности, или облачно-нативных приложений в общем, полагается на много разных уровней абстракции, которые могут значительно ухудшить производительность. Архитекторы программного обеспечения и разработчики также должны держать это в уме при выборе технологического стека для приложения. Например, наши результаты показывают, что Molecular может достичь хорошей сквозной производительности задержки, но при развертывании с использованием Docker, Go Micro может производить гораздо меньшие образы, что может быть выгодно на ограниченных ресурсах. Аналогично, языки на основе JVM могут привести к большим образам Docker и более высокому потреблению ресурсов. Вместе с проблемой прогрева JVM, это может быть не лучшим выбором для чувствительных к задержке приложений.

8. ЗАКЛЮЧЕНИЕ

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

Из результатов, представленных в этой работе, ясно, что нет универсального решения при выборе фреймворка микросервисов. Это сильно зависит от специфических функциональных и нефункциональных требований приложения. Все фреймворки, упомянутые в этой статье, так же как и большинство других доступных опций, могут предоставить абстракцию и шаблонный код, чтобы помочь разработчикам иметь дело со сложностями, обычно найденными в распределенных системах, таких как микросервисы. Как показано в разделе оценки, совместимость - один из самых важных критериев для максимизации гибкости в выборе инструментов. Например, тот факт, что Lagom разработан, чтобы сильно полагаться на Akka и платформу Lightbend, или Molecular использует пользовательское соглашение об именовании для очередей сообщений, может вызвать проблемы интеграции с другими микросервисами. Относительно шаблонов проектирования, все фреймворки следуют асинхронной, событийно-ориентированной архитектуре с поддержкой других возможностей, таких как распределенная трассировка или отказоустойчивость. Когда дело доходит до сравнения производительности, наши результаты показывают, как использование языков на основе JVM может привести к более тяжелым образам Docker и более высокому потреблению ресурсов.

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

9. БУДУЩАЯ РАБОТА

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

10. БЛАГОДАРНОСТИ

Эта работа получила финансирование от Федерального министерства экономики и энергетики (BMWi), Германия, по гранту № 01MA17008, проект Industrial Communication for Factories (IC4F).