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

Микросервисы. Ваш следующий выбор

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

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

Что такое микросервисы?

Слово «микро» в микросервисах подразумевает, что это небольшие приложения. Их размер позволяет выполнить одну задачу или решить конкретную проблему. Эта проблема должна быть концептуальной, а не технической. По выражению Microsoft, «микросервисы должны быть разработаны вокруг бизнес-возможностей».

Внутренняя функциональность отдельного микросервиса может быть изменена или радикально модернизирована без влияния на остальную систему. Еще одним преимуществом использования микросервисов является простота развертывания. Каждый отдельный сервис можно развернуть быстро и независимо от остальной системы, используя стандартные механизмы CI/CD. Кроме того, четко определенные API делают микросервисы удобными для автотестирования.

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

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

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

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

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

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

Микросервисы vs сервис-ориентированная архитектура vs веб-сервисы

Идея совместной работы небольших отдельных программ может напомнить вам о SOA (сервис-ориентированной архитектуре) и веб-сервисах — двух ключевых словах, появившихся в 2000-х годах, когда Web 2.0 был в самом разгаре. Между этими концепциями и микросервисами есть важные различия:

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

Микросервисы, Java, Spring Boot и Spring Cloud

Некоторые из первых работ в области микросервисов возникли в сообществе Java. На конференции по Java в Польше в 2012 году была представлена одна из самых важных ранних презентаций на эту тему, озаглавленная «Микросервисы — Java, путь Unix». В ней рекомендовалось применять принципы, которыми руководствовались при разработке первых приложений Unix в 1970-х годах («Пишите программы, которые делают одно дело и делают его хорошо. Пишите программы для совместной работы»).

В результате этой истории появилось множество Java-фреймворков, позволяющих создавать микросервисы. Одним из самых популярных является Spring Boot, который специально разработан для микросервисов; Boot дополнен Spring Cloud, который, как следует из названия, позволяет развертывать эти сервисы в облаке.

Микросервисы и контейнеры: Docker, Kubernetes и не только

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

Каждый отдельный микросервис может работать в собственном контейнере, что значительно сокращает расходы на управление сервисами. Существует несколько вариантов реализации концепции контейнеров, но самым популярным является Docker, который обычно используется в паре с Kubernetes в качестве платформы оркестровки.

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

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

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

• Service Registry: для подключения клиентов к доступным экземплярам микросервисов.
• Circuit Breaker: для предотвращения повторного вызова отказавших служб.
• Fallback: для обеспечения альтернативы отказавшему сервису.
• Sidecar: для обеспечения вспомогательного сервиса для основного контейнера, например, для ведения логов, синхронизации сервисов или мониторинга.
• Adapter: для стандартизации или нормализации интерфейса между основным контейнером и внешним миром.
• Ambassador: для подключения основного контейнера к внешнему миру, например, для проксирования соединений локального хоста на внешние соединения.

Микросервисы и облако: AWS и Azure

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

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

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

Архитектурный стиль микросервисов — это подход, при котором система строится как набор независимых и слабосвязанных сервисов, которые можно создавать, используя различные языки программирования и технологии хранения данных. Концепция микросервисов позволяет поддерживать слабую связанность сервисов в процессе работы над системой, что определяют паттерны 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.

В чем разница между SOA и микросервисами?

Сервис-ориентированная архитектура (SOA) – это метод разработки программного обеспечения, который использует программные компоненты, называемые сервисами, для создания бизнес-приложений. Каждый сервис предоставляет бизнес-возможности. Они также могут общаться друг с другом на разных платформах и языках. Разработчики применяют SOA для многократного использования сервисов в различных системах или объединения нескольких независимых сервисов для выполнения сложных задач. Архитектура микросервисов – это эволюция архитектурного стиля SOA. Хотя каждый сервис SOA представляет собой полноценную бизнес-возможность, каждый микросервис представляет собой гораздо меньший программный компонент, специализирующийся только на одной задаче. Микросервисы устраняют недостатки SOA и делают программное обеспечение более совместимым с современными облачными корпоративными средами.

Какие ограничения монолитной архитектуры позволяет устранить архитектура SOA?

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

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

Монолитные архитектуры также обеспечивают централизацию ответственности и команд разработчиков, отвечающих за все приложение. Из-за размера и сложности архитектур они сталкиваются с проблемами, связанными с непрерывной доставкой и практикой DevOps.

С помощью SOA разработчики разбивают функциональные возможности программного обеспечения на уровни поставщиков и потребителей сервисов. Эти уровни взаимодействуют и обмениваются данными по корпоративной сервисной шине (ESB). Разработчики используют SOA для упрощения сложных приложений в несколько повторно используемых сервисов.

Какие ограничения архитектуры SOA позволяет устранить архитектура микросервисов?

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

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

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

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

Архитектурные различия: SOA и микросервисы

Сервисно-ориентированная архитектура (SOA) охватывает более широкую сферу деятельности предприятия. Различные бизнес-подразделения эффективно взаимодействуют на единой платформе обмена данными. Напротив, микросервисы относятся к более узкой сфере.

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

Реализация

Внедрение SOA включает интеграцию различных типов сервисов в приложение. Это решение использует корпоративную сервисную шину для подключения таких типов услуг, как:

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

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

Связь

Для доступа к удаленным сервисам архитектура SOA использует централизованную корпоративную сервисную шину (ESB) для подключения различных сервисов к нескольким протоколам обмена сообщениями. Некоторые из этих протоколов включают SOAP, расширенный протокол очереди сообщений (AMQP) и очередь сообщений Microsoft (MSMQ). Если ESB выйдет из строя, это повлияет на все сервисы SOA.

В то же время в архитектурах микросервисов используются более простые системы обмена сообщениями, такие как API-интерфейсы RESTful, служба сообщений Java (JMS) или потоковая передача событий «издатель-подписчик» (pub/sub). Эти методы не требуют, чтобы микросервисы поддерживали активное соединение при обмене данными.

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

Хранилище данных

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

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

Развертывание

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

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

Ключевые преимущества: микросервисы и SOA

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

Возможность повторного использования

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

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

Скорость

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

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

Гибкость управления

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

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

Когда использовать SOA или микросервисы

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

SOA

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

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

Архитектура микросервисов – лучший вариант для поддержки гибких команд разработчиков. Разработчики могут быстро и постепенно вносить изменения в код, не влияя на стабильность приложения, используя инструменты непрерывной интеграции и непрерывной доставки (CI/CD). Лучше использовать микросервисы, когда разработчики ставят перед собой следующие цели:

• Использование различных языков программирования, библиотек или фреймворков для создания одного приложения
• Объединение отдельных сервисов, построенных с использованием различных программных фреймворков
• Предоставление вычислительных ресурсов и масштабирование отдельных сервисов в режиме реального времени

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

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

Создание простого проекта, который будет состоять из следующих функциональных сервисов:

• catalog-service: он предоставляет REST API для предоставления каталожной информации, такой как продукты.
• inventory-service: он предоставляет REST API для управления товарными запасами.

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

Приложение будет использовать MySQL базу данных. База может быть развернута в Docker или может быть локальной.

1. Описание проекта
2. Создание сервисов для проекта
3. Добавление Spring Cloud Config
4. Добавление Spring Cloud Eureka
5. Подключение RestTemplate. Теперь сервис умеет отправлять запросы из catalog-service в inventory-service.
6. Натсройки (application properties)
7. Spring cloud bus — настраиваем приложение так, что бы можно было менять настройки (properties) без перезагрузки самого приложения
8. Меняем Rest-Tamplate на hystrix . Подключаем Hystrix Dashboard
9. строим “ворота” чхода для микросервисов — Spring Cloud Zuul
10. Логирование Spring Cloud Sleuth
11. Переносим все микросервисы в один проект каке модули. Избавляемся от дубликатов в pom проектов.

Дальше мы перейдем для работы в другой репозиорий. Нам осталось настроить безопасность наших микросервисов, дописать правильное логирование Построить CI_CD и наконец — загнать это все в Docker и научиться запускать “одной кнопкой”