Что такое микросервис java
Перейти к содержимому

Что такое микросервис java

  • автор:

Разработка микросервисов на GO и Java: в чем преимущества распределенной архитектуры

Согласно Statista, больше 80% организаций со штатом от 5,000 сотрудников используют микросервисную архитектуру, или микросервисы. Разработка микросервисов помогает бизнесу масштабироваться, делают приложения надежнее и упрощают кодовую базу. Но подходят они не всем.

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

Микросервисная архитектура — что это

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

Такой подход — противоположность монолитной архитектуры. Монолит — это когда все сервисы объединены в одну кодовую базу.

Микросервисы и монолит — чем они отличаются

Рассмотрим в чём разница между микросервисной и монолитной архитектурой на таблице:

В чем преимущества микросервисов

Рассмотрим основные преимущества микросервисной архитектуры:

  • Быстрый запуск. Микросервис можно запустить гораздо быстрее, чем монолит. Причина кроется в том, что микросервис выполняет одну функцию, в то время как монолит включает в себя множество взаимосвязанных функций, обусловленных бизнес логикой приложения.
  • Масштабируемость. Можно масштабировать сервисы независимо. Например, если поиск по приложению нагружен слабо — ему хватит одного сервера. Если нагрузка вырастет, его архитектуру можно будет масштабировать как горизонтально так и вертикально. Существуют сервисы, которые автоматически выделяют ресурсы по потребности, например, Amazon EC2 Auto Scaling, Kubernetes, и Google Cloud Run.
  • Упрощение кодовой базы. Для поддержки микросервиса программистам не нужно знать весь код всего продукта. Специалист может работать над одним локальным микросервисом, не влияя на остальные. В монолитах всё наоборот — программисты тратят много времени на чтение кода, который им фактически не нужен.
  • Независимое развертывание. Разработчики могут частично обновлять сервер, делать канареечные релизы (осторожно внедрять новую версию приложения в продакшн) и проверять нововведения без резких переходов к новой версии (сине-зелёное развертывание). Всё это упрощает процесс разработки.
  • Гибкость. При создании микросервисов для проекта вы можете использовать столько языков программирования, фреймворков и инструментов, сколько захотите. Например, можно выбрать Go как основной язык бизнес логики, а в ML модулях использовать более подходящий для таких задач Python. В монолитах это невозможно, поэтому программисты тратят своё время на «борьбу с кодом», а не на поиск лучших решений для бизнеса.

Кому подойдёт разработка микросервисов

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

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

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

Кому лучше не использовать микросервисы? Микросервисы плохо подходят для небольших команд из за сложности управления, локальной разработки и тестирования.

Go и Java для разработки микросервисов — почемы мы используем эти языки программирования

Микросервис можно написать на любом языке, но есть технологии, которые лучше заточены под эту архитектуру. В Surf мы часто используем Go, также известный как Golang, и Java. Вот основные преимущества этих языков:

  • GolangиJavaподдерживают многопоточность. Golang — это очень быстрый язык благодаря «горутинам» — технологии, которая обеспечивает еще более высокую скорость, чем традиционные потоки.
  • Безопасность: оба этих языка обладают сильной типизацией и автоматическим управлением памятью. Это помогает предотвращать ошибки и упрощает отладку кода.
  • GolangиJavaхорошо работают с технологиями контейнеризации, такими как Docker и Kubernetes. Эти технологии используются для развертывания и управления распределенными архитектурами. Например, Golang позволяет легко упаковать приложения в контейнеры и управлять ими на уровне микросервисов.

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

Golang, Java или Kotlin — при работе с нами у вас в команде будут опытные middle+ разработчики

Разработка микросервисного бэкенда для ERP системы — кейс KFC

KFC обратились к нам для разработки кастомной Enterprise Resource Management (ERP) системы — клиенту нужно было перевести документооборот внутри ресторанов KFC из бумажного в цифровой формат и частично автоматизировать операционное управление. Для этого требовался сложный бекенд.

Мы выбрали Kotlin как основной язык. Kotlin основан на Java — благодаря многопоточности это высокопроизводительный язык, но при этом он требует мало шаблонного кода. Благодаря этому разработка микросервиса ускоряется.

В качестве платформы использовали Spring Boot — фреймворк, который упрощает создание и управление автономными веб-приложениями. Для распределения ресурсов остановились на Kubernetes. Всего мы написали 7 микросервисов, которые разбиты по тематике.

Как микросервисная архитектура помогает команде KFC

Легко масштабировать сервисы. Если какой-то сервис становится бутылочным горлышком, а остальные справляются, ему выделяется больше ресурсов. У KFC более 900 ресторанов и поддерживать распределенную систему на этом масштабе значительно дешевле, чем централизованную.

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

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

Подводя итог

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

  • Но у микросервисов есть и недостатки. Например, необходимость в использовании нескольких баз данных, сложность тестирования и управления.
  • Микросервисы успешно используются как стартапами, так и крупными компаниями. Банк Monzo построил более 1600 микросервисов, включая те, которые работают на Go, а Netflix использует более 1000 микросервисов. Обе компании довольны своим выбором: они достигли желаемых результатов.

В Surf мы разрабатываем бэкенд решения на основе микросервисов и монолитов уже 12 лет. Наши клиенты — это крупные банки, foodtech и ecommerce проекты и быстро растущие стартапы. Для нас нет стандартных решений — мы подбираем техстек под бизнес требования каждого клиента.

Микросервисная архитектура от А до Я

Вряд ли можно найти хоть одного разработчика, который не слышал бы о микросервисах. Но если вы делаете первые шаги в освоении микросервисной архитектуры, нужно начинать с основ. Вы знаете, например, в чем разница между SOA и микросервисами? Микросервисы облегчат вам жизнь или нанесут ущерб тщательно разработанным приложениям? И как правильно создавать микросервисы? В этой статье мы расставим все точки над i.

Мы дадим определение микросервисной архитектуре, обсудим фреймворки, контейнеры, технологию нативного образа, а также особенности написания и поддержки микросервисов на Java™. Вы узнаете, как разбить приложение на микросервисы. Заинтригованы? Тогда приступим!

Предпочитаете живое общение? Свяжитесь с нами, и наши инженеры расскажут вам о микросервисной архитектуре и при необходимости помогут с миграцией вашего приложения.

Что из себя представляют микросервисы?

Микросервисная архитектура ー это метод построения легковесных приложений. При таком подходе приложение делится на множество независимых и слабосвязанных модулей (сервисов). Микросервисы поддерживают независимое развертывание и могут быть созданы на разных языках программирования и с применением разных технологий хранения данных. Микросервисы являются альтернативой монолитам.

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

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

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

Микросервисы ー это вариант SOA. Данный вид сервисов был разработан во избежание риска разбухания ПО. Размер микросервисов меньше, коммуникация между ними осуществляется по сети через произвольные протоколы, такие как API. Разработчики более свободны в выборе инструментального ПО без привязки к ESB (сервисным шинам предприятия), другим сервисам или межсервисным соединениям. Со временем, благодаря контейнеризации и маленьким контейнерам на Alpine Linux, микросервисы стали еще более независимыми друг от друга. Теперь бизнес-компоненты приложения можно запускать одновременно на одном оборудовании и при этом контролировать их по отдельности. Как итог, микросервисы в контейнерах открывают путь к облачно-нативным разработкам и созданию масштабируемых приложений.

Как работает микросервисная архитектура

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

Ниже описаны инструменты, позволяющие создать микросервисную архитектуру на Java™.

Контексты и внедрение зависимостей

В Java™ EE контексты и внедрение зависимостей ー это функция, позволяющая контролировать жизненный цикл объектов, имеющих внутреннее состояние, с помощью домен-специфических контекстов, а также интегрировать различные компоненты в клиентские объекты в типобезопасном режиме.

Аннотации или разные методы внешней конфигурации позволяют задействовать поля простых классов. Контейнеры или фреймворки, контролирующие жизненный цикл класса/бина, могут внедрять необходимые поля после их создания. Исходный код не увидит эту сложность и не заметит замену, выполненную с целью тестирования или изменения способа коммуникации. Таким образом, команда может писать и тестировать небольшие компоненты и в результате создавать более гибкие и надежные микросервисы. Подобная архитектура основана на принципе инверсии управления (IoC).

Динамические прокси

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

В Java™ можно создать фасадный экземпляр класса, перехватывающий вызовы метода интерфейса. Данный паттерн проектирования основан на динамических прокси и реализуется с помощью java.lang.reflect.Proxy и java.lang.reflect.InvocationHandler . Это встроенный API-механизм рефлексии, который широко применяется в CDI-контейнерах, например, в Spring.

Веб-сервер

Фреймворки обеспечивают подключение настраиваемых компонентов на высоком уровне. Но при этом существуют протоколы низкоуровневой коммуникации, например, HTTP, требующие наличия промежуточного звена между сетевыми соединениями и бизнес-логикой. Также необходимо обеспечить управление некоторыми состояниями (контекстами), ресурсами и безопасностью. Этим занимаются веб-сервисы. Каждый микросервис соединяется со своим экземпляром сервера, сконфигурированным в централизованном порядке с помощью фреймворка, например, Embedded Tomcat.

Роль JVM

JVM и библиотека базовых классов служат фундаментом для веб-сервера, библиотек и бизнес-логики. Рантайм проверяет и исполняет байт-код разработчика. Код также можно проанализировать с помощью стандартных инструментов диагностики, например, Mission Control.

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

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

Фреймворки

Фреймворки обеспечивают реализацию многих рутинных задач в микросервисах. На рынке присутствует большое количество фреймворков: Spring, MicroProfile, Quarkus и многие другие. Некоторые имеют общие API. Также они часто поддерживают несколько API, что позволяет портировать существующий код в неизменном виде или с незначительными изменениями.

Контейнеризация

Итак, мы определили все компоненты микросервисов, выбрали целевую ОС, системные пакеты и оборудование. Теперь нужно запустить систему микросервисов целиком.

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

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

alt_text

Слои микросервиса в контейнере

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

Наконец, существуют системы оркестрации, такие как Kubernetes и Marathon, которые позволяют распределять контейнеры в кластере машин. В данном случае остатки кода на Java™ и JVM исчезают, а строительные блоки превращаются в конфигурированные контейнеры, развернутые в парке серверов. Они могут сосуществовать с компонентами SaaS, доступными в облаке.

Плюсы и минусы микросервисов

Преимущества микросервисной архитектуры

  1. Масштабируемость. Микросервисы идеально вам подходят, если вы планируете горизонтальное (посредством узлов, десктопов, серверов) или вертикальное (увеличение количества CPU или объема памяти / хранилища) масштабирование вашего приложения. Такая гибкость возможна благодаря независимости каждого микросервиса. Кроме того, приложение можно изменить динамически, включая или выключая компоненты для балансировки вычислительной нагрузки. Вертикальное или горизонтальное масштабирование в случае монолитов ー трудная задача. Их, конечно, можно масштабировать вертикально, скопировав приложение и запустив несколько копий. Но каждый экземпляр будет иметь доступ ко всем данным и ресурсам, что увеличит входящий / выходящий трафик и потребление памяти и снизит эффективность кэширования. Некоторые узлы используют CPU и хранилище данных в разных объемах, что замедляет работу всей системы. В таких условиях монолитные приложения утрачивают присущую им стабильность.
  2. Облачно-нативные приложения. Микросервисы хорошо сочетаются с Docker-контейнерами, где они упаковываются вместе с рантаймом, фреймворками, библиотеками и даже операционной системой. В результате каждая бизнес-функция отделяется и поддерживается и развертывается в облаке как единое целое.
  3. Простота обслуживания. Микросервисы проще тестировать и отлаживать. Предположим, компания поддерживает монолитное приложение на тысячах копий: последствия обновления одного сегмента непредсказуемы. Микросервисная архитектура более прямолинейна: вот интерфейс, вот реализация, а вот определенное количество сервисов. Замените некоторые из них и не трогайте остальные. В сочетании с непрерывным развертыванием эта модель проектирования облегчает создание и поставку надежного продукта.
  4. Высокая устойчивость. Поскольку приложение разбивают на независимые микросервисы, оно более устойчиво к ошибкам. Баг в одной части кода не приведет к падению всей системы. Вместо этого команде нужно устранить неисправности всего в одном сервисе.
  5. Общая экономия. Трехкомпонентное преимущество:
    • Благодаря тому, что приложение поделено на микросервисы, цикл релизов сокращается. Компании не нужно полностью перепроектировать приложение, чтобы обновить один сервис. Она использует механизмы непрерывного развертывания и универсальные команды разработчиков и развертывает сервисы независимо друг от друга.
    • Контейнерные образы с микросервисами используют файловые системы, такие как UnionFS, AuFS, OverlayFS. Они создают слои с описанием того, как нужно воспроизводить действия с базовым образом. В результате увеличивается только количество обновлений слоя, поэтому контейнеры остаются легкими, что экономит ресурсы и сокращает издержки компании.
    • Благодаря независимости функций на каждую из них можно назначить отдельную команду. Разработчикам даже не нужно находиться в одном месте. Использование мощных и дорогих машин тоже необязательно. Ваши инженеры смогут разворачивать микросервисы на самый простых устройствах (т.е. x86 32 bit).
  6. Широкий выбор инструментов. Микросервисная архитектура устраняет привязку к поставщику. Если компоненты не зависят друг от друга, они могут работать на разных фреймворках или использовать несколько библиотек. Разработчики также могут писать код одного приложения на разных языках.
  7. Независимость от базы данных. Микросервисы отделены от системы, а это значит, что можно забыть о связях с базой данных благодаря унифицированному интерфейсу. Можно вносить изменения в данные или полностью заменить базу данных.

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

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

Недостатки микросервисной архитектуры

В случае традиционных монолитов приложения находятся в одном пространстве виртуальной памяти, а запросы посылаются на физический сервер. Микросервисы взаимодействуют при помощи протоколов (HTTP/HTTPS, AMQP, REST, TCP). Это влечет за собой определенные последствия:

  • Постоянное передвижение трафика по сети;
  • Сбои запросов и другие ошибки, связанные с сетью;
  • Возможно, потребуется зашифровать и упаковать данные в другие формы.

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

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

И все же преимущества микросервисной архитектуры перевешивают недостатки. И даже последние можно с легкостью устранить. Сейчас расскажем, как.

Как сделать микросервисы быстрыми и эффективными

Микросервисная система может быстро выйти из-под контроля ввиду своей сложности и превратиться в клубок, распутать который не по силам будет даже старшим разработчикам. Как решить эту проблему? Разделите микросервисы с помощью систем управления потоковыми данными (Kafka, Kinesis, Spark Streaming), упростите коммуникацию между сервисами посредством сервисной сетки (Istio, OSM на Kubernetes) или перепроектируйте систему. В идеале, ваша цель ー избежать этого:

alt_text

Пример спагетти-кода

и прийти к этому:

alt_text

Микросервисы на системе управления потоковыми данными

Заметьте, что на первой схеме отсутствует связь между очередями сообщений (представлены цилиндрами MQ) и базами данных.

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

alt_text

Первый уровень микросервисной архитектуры

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

alt_text

Микросервисы с сервисной сеткой

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

Но даже когда мы запустим, сконфигурируем и распределим наши микросервисы, нужно будет решить еще одну проблему. Как свести к минимуму потребление памяти и время запуска?

Во время работы над проектом можно попробовать улучшить следующие показатели:

  1. Размер Docker-образа;
  2. Объем потребляемой памяти;
  3. Время запуска.

Контейнеризированному проекту требуется доступ к среде исполнения Java™. Но вот в чем загвоздка: нельзя поместить Oracle JDK в Docker-контейнер без лицензии. Вместо этого вы можете использовать базовые образы БЕЛЛСОФТ размером всего 107 MB. Есть еще вариант размером 43,5 MB для CLI-подобных приложений. Это самый маленький контейнер на рынке.

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

alt_text

Результаты эксперимента с проектом в разных конфигурациях

Загрузка классов оказывает значительное влияние на время запуска. Благодаря thin jar и AppCDS скорость запуска выросла почти в 2,5 раза.

В итоге мы получаем легковесный контейнерный образ, потребляющий всего 128 MB памяти и запускающийся за 8 секунд. По сравнению с изначальными результатами время запуска сократилось с 20 с до 8 с, а потребление памяти уменьшилось в 6 раз.

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

Повысьте эффективность микросервисной архитектуры с помощью нативного образа

При сборке в нативном образе приложение занимает 35 MB оперативной памяти и запускается за 0,111 секунды! При этом сам нативный образ весит 89 MB.

Как работает нативный образ? Разработчики меняют двоичный файл сервиса на нативный исполняемый файл с помощью технологии нативного образа GraalVM. Сочетание компилятора Graal в режиме AOT и виртуальной машины SubstrateVM обеспечивает мгновенный запуск, минимальное потребление памяти, экономию оперативной памяти и высокую производительность. Для использования этого инструмента нужно добавить несколько зависимостей на этапе сборки, а затем расширить сборочные скрипты с помощью команды:

gradlew nativeImage 

Вы также можете воспользоваться инструментом, разработанным БЕЛЛСОФТ, Native Image Kit (NIK). NIK преобразует Java приложение в предварительно скомпилированный исполняемый файл, который потребляет минимальное количество ресурсов и запускается почти мгновенно. NIK идеально подходит для проектирования микросервисов, так как он поддерживает разные языки программирование и широкий диапазон платформ.

Микросервисы на Java™ на основе нативного образа работают в соответствии с предположением о замкнутости мира. Базовый контейнер должен обладать минимальной функциональностью (в отсутствие JDK), то есть он может быть scratch-образом. Он будет работать в том случае, если приложение содержит все свои зависимости. Например, нативный образ можно статически слинковать со стандартной библиотекой C.

Как правило, нативному образу требуются некоторые базовые артефакты: сертификаты, библиотеки SSL, а также динамически загружаемая библиотека C. В этом случае двоичный файл можно слинковать по-другому, а базовый образ будет так называемым distroless-образом, т.е. без дистрибутива. Базовый distroless-образ без libc в gcr.io весит всего 2 MB, что немного меньше, чем размер минимального образа Alpine Linux, но при этом с glibc базовый образ будет весить уже 17 MB.

Запуск микросервисов на Java™ с применением технологии нативного образа позволяет добиться высокой производительности и скорости. Но разработчики не всегда могут гарантировать корректную работу приложения из-за определенных ограничений. Кроме того, Graal VM с оптимизациями и другие полезные инструменты не бесплатны. А развертывание контейнерного образа с тонким слоем thin jar возможно, только если у нас есть jar-файлы, то есть с обычной средой исполнения.

В целом, выбор рантайма или нативного образа при построении микросервисной архитектуры зависит от текущих задач, бизнес-среды, состояния, в котором находится ваша компания, и многих других факторов.

Заключение

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

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

Что такое микросервисы: определение, архитектура и примеры

img

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

Термин «микро» относится к размеру микросервиса – он должен быть удобным в управлении одной командой разработчиков (5-10 специалистов). В данной методологии большие приложения делятся на крошечные независимые блоки.

Что такое монолитная архитектура?

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

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

Монолитная архитектура приложения для электронной торговли

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

Что такое микросервисная архитектура?

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

Давайте рассмотрим пример приложения для онлайн-торговли с микросервисной архитектурой. В данном примере каждый микросервис отвечает за одну бизнес-возможность. У «Поиска», «Оплаты», «Рейтинга и Отзывов» есть свои экземпляры (сервер), которые взаимодействуют между собой.

Микросервисная архитектура

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

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

Микросервисы и монолитная архитектура: сравнение

Микросервисы

Монолитная архитектура

Каждый блок данных создается для решения определенной задачи; его размер должен быть предельно малым

Единая база кода для всех бизнес-целей

Запуск сервиса происходит сравнительно быстро

На запуск сервиса требуется больше времени

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

Локализовать ошибки сложно. Если какая-то определенная функция не перестает работать, то ломается вся система. Чтобы решить проблему, придется заново собирать, тестировать и развертывать приложение.

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

Монолитная архитектура тесно связана. Изменения в одному модуле кода влияет на другой

Компании могут выделять больше ресурсов на самые рентабельные сервисы

Сервисы не изолированы; выделение ресурсов на отдельные сервисы невозможно

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

Масштабирование приложения – задача сложная и экономически не выгодная

Микросервисы всегда остаются постоянными и доступными

Большая нагрузка на инструменты для разработки, поскольку процесс необходимо запускать с нуля

Федеративный доступ к данным, благодаря чему под отдельные микросервисы можно подбирать наиболее подходящую модель данных

Небольшие целевые команды. Параллельная и ускоренная разработка

Большая команда; требуется серьезная работа по управлению командой

Изменения в модели данных одного микросервиса никак не сказывается на других микросервисах

Изменения в модели данных влияют на всю базу данных

Четко прописанный интерфейс позволяет микросервисам эффективно взаимодействовать между собой

Микросервисы делают акцент на продуктах (модулях), а не проектах

Сосредоточены на проекте в целом

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

Одна функция или программа зависит от другой

Сложности в работе с микросервисами

  • Микросервисы полагаются друг на друга, поэтому необходимо выстроить коммуникацию между ними.
  • В микросервисах создается больше модулей, чем в монолитных системах. Эти модули пишутся на разных языках, и их необходимо поддерживать.
  • Микросервисы – это распределенная система, так что, по сути, мы имеем дело со сложной системой.
  • В разных сервисах используются свои механизмы; для неструктурированных данных требуется больший объем памяти.
  • Для предотвращения каскадных сбоев необходимо эффективное управление и слаженная командная работа.
  • Трудно воспроизвести ошибку, если она пропадает в одной версии и вновь появляется в другой.
  • Независимое развертывание и микросервисы – вещи слабо совместимые.
  • Микросервисная архитектура требует большего количества операций.
  • Сложно управлять приложением, когда в систему добавляются новые сервисы.
  • Для поддержки всевозможных распределенных сервисов требуется большая команда опытных специалистов.
  • Микросервисы считаются дорогостоящими решениями, поскольку для разных задач создаются и поддерживаются разные серверные пространства.

Сервис-ориентированная архитектура (СОА) или микросервисы

СОА-сервисы (SOA — Service-oriented architecture) поддерживаются через реестр, который считается перечнем файлов каталога. Приложения должны найти сервис в реестре и вызвать его.

Иначе говоря, СОА похож оркестр: каждый музыкант играет на своем инструменте, а всеми артистами управляет дирижер.

Микросервисы – это разновидность СОА-стиля. Приложения создаются в виде набора небольших сервисов, а не цельной программы.

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

Теперь давайте поговорим о различиях между СОА и микросервисах.

Параметр

СОА

Микросервисы

В СОА компоненты приложения открыты для внешнего мира; они доступны в виде сервисов

Микросервисы – это часть СОА. Такая архитектура считается реализацией СОА

Они не зависят друг от друга

Размер приложения больше, чем у обычных программ

Размер приложения всегда небольшой

Стек технологий ниже, чем у микросервисов

Стек технологий очень большой

Независимость и ориентированность

СОА-приложения создаются для выполнения множества бизнес-задач

Создаются для выполнения одной бизнес-задачи

Процесс развертывания растянут по времени

Несложное развертывание, на которое тратится меньше времени

Меньше, чем у микросервисов

Компоненты бизнес-логики хранятся внутри одного сервисного домена. Простые проводные протоколы (HTTP с XML JSON).
API управляется с помощью SDK/клиентов

Бизнес-логика распределена между разными корпоративными доменами

Микросервисные инструменты

Wiremock – тестирование микросервисов

WireMock – это гибкая библиотека для создания заглушек и сервисов-имитаций. В ней можно настроить ответ, который HTTP API вернет при получении определенного запроса. Также может использоваться для тестирования микросервисов.

Docker

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

Hystrix

Hystrix – это отказоустойчивая Java-библиотека. Данный инструмент предназначен для разделения точек доступа к удаленным сервисам, системам и сторонним библиотекам в распределенной среде (микросервисах). Библиотека улучшает всю систему в целом, изолируя неисправные сервисы и предотвращая каскадный эффект от сбоев.

Лучшие примеры использования микросервисной архитектуры

  • Отдельное хранение данных для каждого микросервиса.
  • Поддержание кода на едином уровне зрелости
  • Отдельная сборка для каждого микросервиса.

Заключение

  • Микросервисы – это СОА-шаблон, в котором приложения создаются как набор малых и независимых серверных единиц.
  • Микросервисная архитектура относится к стилям разработки архитектуры, позволяющим создавать приложение в виде небольших и автономных сервисов для определенных предметных областей.
  • Монолитная архитектура похожа на большой контейнер, в котором все компоненты приложения собраны в один пакет.
  • Каждый блок приложения в микросервисе имеет предельно малый размер и выполняет определенную функцию.
  • Большая база кода в монолитной архитектуре замедляет процесс разработки. Выход новых версий может растянуться на месяцы. Поддерживать такую базу кода довольно сложно.
  • Существует 2 типа микросервисов: Stateless (без сохранения состояния) и Stateful (с отслеживанием состояния)
  • Микросервисы на Java полагаются друг на друга; они должны взаимодействовать между собой. Микросервисы позволяют в большей степени сконцентрироваться на определенных функциях или потребностях бизнеса.
  • Сервисно-ориентированная архитектура, или СОА, – это усовершенствованные распределенные вычисления, основанные на проектной модели запроса/ответа в синхронных или асинхронных приложениях.
  • Компоненты приложения в СОА открыты для внешнего мира и представлены в виде сервисов; микросервисы считаются частью СОА. Это реализация СОА.
  • К популярным микросервисным инструментам относятся Wiremock, Docker и Hystrix.

Что такое микросервисы: особенности архитектуры, примеры использования, инструменты

Аватарка пользователя theartofdevel

Видео про микросервисы с простым объяснением архитектуры и отличий от монолита, а также примерами инструментов.

Архитектурный стиль микросервисов — это подход, при котором система строится как набор независимых и слабосвязанных сервисов, которые можно создавать, используя различные языки программирования и технологии хранения данных. Концепция микросервисов позволяет поддерживать слабую связанность сервисов в процессе работы над системой, что определяют паттерны Low Coupling и High Cohesion.

Подробности — в видео и текстовой расшифровке ниже.

Монолит vs микросервисы

При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.

В случае с микросервисной архитектурой обновляется только изменённый сервис. Если изменения затрагивают интерфейс сервиса, это потребует координации всех его клиентов. Цель хорошей микросервисной архитектуры — максимально уменьшить необходимость координации сервисов.

Что такое контракт

Контракт — это формализация возможностей взаимодействия с микросервисом. В случае с REST API эндпоинты сервиса и схема данных являются контрактом. Первоначальная разработка архитектуры — это декомпозиция системы на слабосвязанные сервисы, создание интерфейсов и связей между ними, поддержка целостности данных без потери производительности. Помочь с решением данной задачи могут шаблоны Tolerant Reader и Consumer-Driven Contracts.

Микросервисная команда

Команда не должна включать в себя больше людей, чем можно насытить двумя пиццами. Такое правило использовала компания Amazon при распиливания своего монолита в 2002 году. Вполне допустимо и правило developer per service, то есть один разработчик на один микросервис.

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

«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»

Микросервисный подход предполагает разбиение системы на сервисы по бизнес-требованиям. Сервисы включают в себя полный набор технологий: UI, storage, backend. Это приводит к созданию кросс-функциональных команд, имеющих достаточно компетенций для реализации всех необходимых сервисов, покрывающих 100% бизнес-функционала. Команды должны отвечать за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7. В таком случае возможность проснуться от звонка в 3 часа ночи — это очень сильный стимул писать хороший код.

Насколько большим должен быть микросервис

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

  • Node.js — для простых страничек с отчетами.
  • С++ — для real-time приложений.
  • Python —для анализа данных.
  • Golang — для высоконагруженного сервиса.
  • Java — для интеграции с энтерпрайзом.

Архитектура микросервиса даёт полную свободу в выборе технологий и инструменария.

Инструментарий для реализации микросервисов

В процессе реализации микросервисной архитектуры существенным упрощением будет использование систем CI/CD, системы оркестрации, Service Discovering, мониторинга и сбора логов.

  • Для CI/CD сейчас активно используются GitLab CI, TeamCity, Jenkins, Github Action, Circle CI.
  • В качестве системы оркестрации можно попробовать Nomad или Apache Mesos, а если вы используете Docker, то Kubernetes и Docker Swarm.
  • Для Service Discovering можно взять Consul, Eureka или Zookeeper.
  • Для мониторинга и сбора логов можно выбрать стек ELK или TICK, а также построить свою систему мониторинга из отдельных продуктов, включая Prometheus, Grafana и Graphite.

Необходимо быть уверенным в том, что приложение работает правильно. Для этого запускаются автоматические тесты, при этом система разворачивается в отдельной среде (Automated Deployment).

Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *