на каком технологическом стеке реализуется микросервисная платформа

Микросервисная архитектура на современном стеке Java-технологий

Проект состоит из 5-и микросервисов: 3-х инфраструктурных (Config server, Service discovery server, UI gateway) и примеров front-end’а (Items UI) и back-end’а (Items service):

Все они будут последовательно рассмотрены далее. В «боевом» проекте, очевидно, будет значительно больше микросервисов, реализующих какую-либо бизнес-функциональность. Их добавление в подобную архитектуру технически выполняется аналогично Items UI и Items service.

Disclaimer

В статье не рассматриваются инструменты для контейнеризации и оркестрации, т. к. в настоящее время они не используются в проекте.

Config server

Для создания централизованного хранилища конфигураций приложений был использован Spring Cloud Config. Конфиги могут быть прочитаны из различных источников, например, отдельного git-репозитория; в этом проекте для простоты и наглядности они находятся в ресурсах приложения:

При этом конфиг самого Config server ( application.yml ) выглядит так:

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

Классы приложения и main-методы в остальных микросервисах имеют аналогичный вид.

Service discovery server

Service discovery — это паттерн микросервисной архитектуры, позволяющий упростить взаимодействие между приложениями в условиях возможного изменения числа их инстансов и сетевого расположения. Ключевым компонентом при таком подходе является Service registry — база данных микросервисов, их инстансов и сетевых расположений (подробнее здесь).

В этом проекте Service discovery реализован на основе Netflix Eureka, представляющего собой Client-side service discovery: Eureka server выполняет функцию Service registry, а Eureka client перед выполнением запроса к какому-либо микросервису обращается к Eureka server за списком инстансов вызываемого приложения и самостоятельно осуществляет балансировку нагрузки (используя Netflix Ribbon). Netflix Eureka, как и некоторые другие компоненты стека Netflix OSS (например, Hystrix и Ribbon) интегрируется с Spring Boot приложениями с помощью Spring Cloud Netflix.

В конфиге Service discovery server, находящемся в его ресурсах ( bootstrap.yml ), указывается только название приложения и параметр, определяющий, что запуск микросервиса будет прерван, если невозможно подключиться к Config server:

Оставшаяся часть конфига приложения располагается в файле eureka-server.yml в ресурсах Config server:

Eureka server использует порт 8761, что позволяет всем Eureka client’ам не указывать его, используя значение по умолчанию. Значение параметра register-with-eureka (указано для наглядности, т. к. оно же используется по умолчанию) говорит о том, что само приложение, как и другие микросервисы, будет зарегистрировано в Eureka server. Параметр fetch-registry определяет, будет ли Eureka client получать данные из Service registry.

Список зарегистрированных приложений и другая информация доступны по http://localhost:8761/ :

Альтернативными вариантами для реализации Service discovery являются Consul, Zookeeper и другие.

Items service

Это приложение представляет собой пример back-end с REST API, реализованным с использованием появившегося в Spring 5 фреймворка WebFlux (документация здесь), а точнее Kotlin DSL для него:

Рассмотрим один из способов отправки дополнительных метаданных на Eureka server:

Убедимся в получении Eureka server этих данных, зайдя на http://localhost:8761/eureka/apps/items-service через Postman:

Items UI

Этот микросервис, помимо того, что демонстрирует взаимодействие с UI gateway (будет показано в следующем разделе), выполняет функцию front-end для Items service, с REST API которого может взаимодействовать несколькими способами:

И используется таким образом:

И используется таким образом:

В том, что все три способа возвращают одинаковый результат, можно убедиться, зайдя на http://localhost:8081/example :

Я предпочитаю вариант с использованием OpenFeign, т. к. он даёт возможность разработать контракт на взаимодействие с вызываемым микросервисом, обязанности по имплементации которого берёт на себя Spring. Объект, реализующий этот контракт, инжектируется и используется, как обычный бин:

Для работы Feign-клиента требуется аннотировать класс приложения @EnableFeignClients :

Для работы Hystrix fallback в Feign-клиенте в конфиг приложения нужно внести:

UI gateway

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

В этом проекте для большей наглядности реализован UI gateway, то есть единая точка входа для различных UI; очевидно, что API gateway реализуется аналогично. Микросервис реализован на основе фреймворка Spring Cloud Gateway. Альтернативным вариантом является Netflix Zuul, входящий в Netflix OSS и интегрированный с Spring Boot с помощью Spring Cloud Netflix.
UI gateway работает на 443 порту, используя сгенерированный SSL-сертификат (находится в проекте). SSL и HTTPS сконфигурированы следующим образом:

Логины и пароли пользователей хранятся в Map-based имплементации специфичного для WebFlux интерфейса ReactiveUserDetailsService :

Параметры безопасности настроены таким образом:

Эта страница использует средства фреймворка Bootstrap, подключаемого к проекту с помощью Webjars, который даёт возможность управлять client-side библиотеками как обычными зависимостями. Для формирования HTML-страниц используется Thymeleaf. Доступ к странице логина конфигурируется с помощью WebFlux:

Маршрутизация средствами Spring Cloud Gateway может быть настроена в YAML- или java-конфиге. Роуты к микросервисам либо прописываются вручную, либо создаются автоматически на основе данных, полученных из Service registry. При достаточно большом количестве UI, к которым требуется осуществлять маршрутизацию, удобнее будет воспользоваться интеграцией с Service registry:

Значение параметра include-expression указывает, что роуты будут созданы только для микросервисов, названия которых оканчиваются на -UI, а значение параметра url-expression — что они доступны по HTTP протоколу, в отличие от самого UI gateway, работающего по HTTPS, и при обращении к ним будет использоваться клиентская балансировка нагрузки (реализуемая с помощью Netflix Ribbon).

Рассмотрим пример создания роутов в java-конфиге вручную (без интеграции с Service registry):

Первый роут осуществляет маршрутизацию на ранее показанную домашнюю страницу Eureka server ( http://localhost:8761 ), второй нужен для загрузки ресурсов этой страницы.

В нижележащих микросервисах может возникнуть необходимость получить доступ к логину и/или ролям пользователя, прошедшего аутентификацию в UI gateway. Для этого я создал фильтр, добавляющий в запрос соответствующие заголовки:

Spring Cloud Sleuth — это решение для трассировки запросов в распределённой системе. В заголовки запроса, проходящего через несколько микросервисов, добавляются Trace Id (сквозной идентификатор) и Span Id (идентификатор unit of work) (для более лёгкого восприятия я упростил схему; здесь более детальное объяснение):

Указав соответствующие настройки логирования, в консоли соответствующих микросервисов можно будет увидеть примерно следующее (после названия микросервиса выводятся Trace Id и Span Id):

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

Сборка

Учитывая возможность использования Gradle wrapper, нет необходимости в наличии установленного локально Gradle.

Сборка и последующий запуск успешно проходят на JDK 11.0.1. До этого проект работал на JDK 10, поэтому допускаю, что на этой версии проблем со сборкой и запуском не возникнет. По поводу более ранних версий JDK данных у меня нет. Кроме того, нужно учитывать, что используемый Gradle 5 требует как минимум JDK 8.

Запуск

Рекомендую стартовать приложения в порядке их описания в этой статье. Если вы используете Intellij IDEA с включённым Run Dashboard, то должно получиться примерно следующее:

Заключение

В статье был рассмотрен пример микросервисной архитектуры на актуальном в Java-мире стеке технологий, её основные компоненты и некоторые фичи. Надеюсь, для кого-то материал окажется полезным. Благодарю за внимание!

Источник

Микросервисы для начинающих

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

Чтобы понять, что такое микросервисы и в каких случаях их следует использовать, мы обратились к Джейме Буэльта (Jaime Buelta), автору книги «Hands-On Docker for Microservices with Python». Он рассказал о преимуществах этой архитектуры, а также поделился рекомендациями для разработчиков, планирующих перейти на нее с монолитов.

Преимущества и риски

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

Буэльта объясняет: «Микросервисная архитектура — это способ структурирования системы, при которой несколько независимых сервисов общаются друг с другом определенным образом (обычно это происходит с помощью web-сервисов RESTful). Ключевая особенность состоит в том, что каждый микросервис способен обновляться и развертываться независимо от остальных».
Архитектура микросервисов определяет не только то, как вы создаете свое приложение, но и то, как организована ваша команда.

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

На вопрос о рисках, связанных с микросервисами, Буэльта ответил: «Главная сложность при внедрении архитектуры (особенно при переходе с монолита) заключается в создании дизайна, в котором сервисы действительно будут независимыми. Если этого не удастся добиться, то межсервисные связи станут сложнее, что приведет к дополнительным расходам. Микросервисам нужны профессионалы, которые сформируют направления развития в долгосрочной перспективе. Я рекомендую организациям, которые хотят перейти на такую архитектуру, назначить кого-то ответственным за «общую картину». На микросервисы нужно смотреть более широко», — считает Джейме.

Переход от монолита к микросервисам

Мартин Фаулер, известный автор и консультант по программному обеспечению, советует придерживаться принципа «сначала — монолит». Это связано с тем, что использовать микросервисную архитектуру с самого начала разработки рискованно, поскольку в большинстве случаев она подходит только для сложных систем и больших команд разработчиков.
«Основной критерий, который должен побуждать вас к переходу на новую архитектуру — это численность вашей команды. Небольшим группам не стоит этого делать. В подобных условиях разработчики и так понимают все, что происходит с приложением, и всегда могут задать уточняющий вопрос коллеге. Монолит отлично работает в этих ситуациях, и поэтому практически каждая система начинается с него», — считает Джейме. Это подтверждает «правило двух пицц» Amazon, согласно которому команду, ответственную за один микросервис, можно прокормить двумя пиццами — иначе она слишком большая.

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

Рекомендации по переходу на микросервисы

Отвечая на вопрос о том, какие практические рекомендации могут использовать разработчики при переходе на микросервисы, Буэльта заявил: «Ключом к успешной архитектуре микросервисов является то, что каждый сервис должен быть максимально независим».
Возникает вопрос: «Как вы можете сделать сервисы независимыми?». Лучший способ обнаружить взаимозависимость системы — подумать о новых возможностях: «Если вы хотите добавить новую функцию, можно ли будет ее реализовать, изменив лишь один сервис? Какие виды функций потребуют координации нескольких микросервисов? Они будут использоваться часто или редко? Невозможно создать идеальный дизайн, но, по крайней мере, с его помощью можно принимать правильные и обоснованные решения», — объясняет Буэльта.

Джейме советует переходить на архитектуру правильно, чтобы потом все не переделывать. «После завершения перехода изменить границы микросервисов будет тяжелее. Стоит уделить побольше времени на начальную фазу проекта», — добавляет он.
Переход с одного шаблона проектирования на другой — это серьезный шаг. Мы спросили, с какими проблемами Джейме и его команда сталкивались во время миграции на микросервисы, на что он ответил:

«На деле основные трудности связаны с людьми. Эти проблемы, как правило, недооценивают, но переход на микросервисы фактически меняет способ работы разработчиков. Задача не из легких!». Он добавляет: «Я лично сталкивался с подобными проблемами. Например, мне приходилось обучать и давать советы разработчикам. Особенно важно объяснять, почему необходимы те или иные изменения. Это помогает людям понять причины внедрения всех нововведений, которые могут прийтись им не по душе.

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

Причины выбора Docker, Kubernetes и Python в качестве технологического стека

Мы спросили Буэльту, какие технологии он предпочитает для внедрения микросервисов. Касательно выбора языка ответ оказался прост: «Python для меня — лучший вариант. Это мой любимый язык программирования. Этот язык хорошо подходит для микросервисов. Его удобно читать и легко применять. Кроме того, Python обладает широким функционалом для веб-разработки и динамичной экосистемой сторонних модулей для любых потребностей. К этим потребностям относится подключение к другим системам, например, к базам данных, внешним API и т.д.».

Docker часто рекламируется как один из самых важных инструментов для микросервисов. Буэльта объяснил, почему:

«Docker позволяет инкапсулировать и копировать приложение в удобных стандартизированных пакетах. Это уменьшает неопределенность и сложность среды. Также это значительно упрощает переход от разработки к производству приложений. Вдобавок ко всему, уменьшается время использования оборудования. Вы можете разместить несколько контейнеров в разных средах (даже в разных операционных системах) в одной физической коробке или виртуальной машине».

«Kubernetes позволяет развертывать несколько контейнеров Docker, работающих скоординированным образом. Это заставляет разработчиков мыслить кластеризованно, помня о производственной среде. Также это позволяет определять кластер с помощью кода, чтобы новые развертывания или изменения конфигурации определялись в файлах. Все это делает возможными методы наподобие GitOps (о них я писал в своей книге), при этом сохраняя полную конфигурацию в системе управления версиями. Каждое изменение вносится определенным и обратимым образом, поскольку оно представляет из себя регулярное git-слияние. Благодаря этому можно очень легко восстанавливать или дублировать инфраструктуру».

«Придется потратить время, чтобы обучиться Docker и Kubernetes, но это того стоит. Оба инструмента очень мощные. К тому же, они поощряют вас работать таким образом, чтобы избежать проблем при производстве», — считает Буэльта.

Многоязычные микросервисы

При разработке микросервисов можно использовать разнообразные технологии, поскольку за каждый из них в идеале отвечает независимая команда. Буэльта поделился своим мнением о многоязычных микросервисах: «Многоязычные микросервисы — это здорово! Это одно из основных преимуществ архитектуры. Типичный пример многоязычного микросервиса — перенос устаревшего кода, написанного на одном языке, на новый. Микросервис может заменить собой любой другой, который предоставляет тот же внешний интерфейс. При этом его код будет совершенно иным. К примеру, я переходил со старых приложений PHP, заменяя их аналогами, написанными на Python». Джейме добавил: «Работа с двумя или более платформами одновременно поможет лучше разобраться в них и понимать, в каких случаях их лучше использовать».

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

Об авторе

Джейме Буэльта (Jaime Buelta) — профессиональный программист и Python-разработчик, который за свою многолетнюю карьеру познакомился со множеством различных технологий. Он разрабатывал программное обеспечение для различных областей и отраслей, включая аэрокосмическую, сетевую и коммуникационную, а также промышленные системы SCADA, онлайн-сервисы для видеоигр и финансовые сервисы.

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

Источник

Опыт построения инфраструктуры на микросервисной архитектуре

За последний год публикаций о микросервисах стало так много, что рассказывать что это и зачем нужно было бы пустой тратой времени, так что дальнейшее изложение будет сконцентрировано на вопросе — каким способом бы реализовали эту архитектуру и почему именно так и с какими проблемами столкнулись.

У нас в небольшом банке были большие проблемы: 3 python монолита связанных чудовищным количеством синхронных RPC взаимодействий с большим объемом legacy. Что бы хотя бы отчасти решить все возникающие при этом проблемы было принято решение перейти на микросервисную архитектуру. Но прежде чем решиться на такой шаг нужно ответить на 3 основных вопроса:

Собственно кратким ответам на эти вопросы и будет посвящена данная статья.

Как разбить монолит на микросервисы и какими критериями следует при этом руководствоваться.

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

Мы — банк, соответственно вся система крутиться вокруг операций с финансами и различными вспомогательными вещами. Перенести финансовые ACID транзакции на распределенную систему с сагами безусловно можно, но в общем случае крайне трудно. Таким образом мы выработали следующие правила:

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

Каким образом микросервисы будут взаимодействовать?

Вариантов множество, но в конечном итоге их всех можно абстрагировать простым «микросервисы обмениваются сообщениями», но если реализовать синхронный протокол (например RPC через REST) то большинство недостатков монолита сохранятся, а вот достоинств микросервисов почти не появится. Так что очевидным решением было взять любой брокер сообщений и начать работать. Выбирая между RabbitMQ и Кафкой остановились на последней и вот почему:

Очереди на кафке+асинхронность позволяют нам:

В качестве системы сериализации данных мы выбрали AVRO, почему — описано в отдельной статье.

Но вне зависимости от выбранного способа сериализации важно понимать как будет проходить обновление протокола. Хотя AVRO и поддерживает Schema Resolution мы этим не пользуемся и решаем чисто административно:

Сами же схемы AVRO мы храним в git-субмодулях и подключаем ко всем кафка-проектам. Централизованный реестр схем решили пока не внедрять.

Некоторые тонкости

Каждый подписчик получает все сообщения из топика

Это специфика модели взаимодействия Publish–subscribe — будучи подписаны на топик подписчик получит их все. В результате если сервису нужны лишь некоторые из сообщений — ему придется их отфильтровать. Если же это станет проблемой то можно будет сделать отдельный сервис-роутер, который будет раскладывать сообщения по нескольким разным топикам, тем самым реализовывать часть функционала RabbitMQ, отсутствующего в кафке. Сейчас у нас один подписчик на питоне в один поток обрабатывает примерно 7-5 тыс сообщений в секунду, если же запускать с через PyPy то скорость вырастает до 11-15 тыс/сек.

Ограничение времени жизни указателя в топике

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

Ограничение времени на подтверждение чтения

Если читатель кафки не подтверждает чтение за 30 сек (настраиваемый параметр) то брокер считает что что то пошло не так и при попытке подтвердить чтение возникает ошибка. Чтобы избежать этого мы при длительной обработке сообщения Отправляем подтверждения чтения без смещения указателя.

Граф связей получается трудным для восприятия

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

Как осуществлять мониторинг?

Ещё в рамках монолита у нас были логи в файлах и Sentry Но по мере перехода на взаимодействие через кафку и развертывания в k8s логи переместились в ElasticSearch и соответственно сначала мониторили читая логи подписчика в Эластике. Нет логов — нет работы.
За тем начали использовать Prometheus и kafka-exporter немного модифицировали его дашборд: https://github.com/kkirsanov/articles/blob/master/2019-habr-kafka/dashboard.json

В результате получаем вот такие картинки:

Срезу видно какой сервис какие сообщения перестал обрабатывать.

Дополнительно все сообщения из ключевых (платежные транзакции, нотификации от партнеров и т.п.) топиков копируются в InfluxDB, заведенную в ту же grafana. Так что мы можем не только фиксировать сам факт передачи сообщений, но делать разнообразные выборки по содержимому. Так что ответы на вопросы вида «каково среднее время задержки ответа от сервиса» или «Сильно ли отличается поток транзакций сегодня от вчерашнего по этому магазину» всегда под рукой.

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

В результате по мере прохождения сообщения через вычислительный граф сообщение обогащается информацией о пройденном на графе пути. Получается аналог zipkin/opentracing для MQ, позволяющий получив сообщение легко восстановить его путь на графе. Особую ценность это приобретает в тех случаях, когда на графе возникают циклы. Помните пример с маленьким сервисом, доля в платежах которого составляет всего 0.0001% Анализируя мета-информацию в сообщении он может определить — являлся ли они инициатором платежа, не обращаясь при этом в БД для сверки.

Источник