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

Active Directory использует большинство наших заказчиков, так что необходимость интегрироваться с ней появляется практически в каждом проекте. Чтобы командам не приходилось каждый раз решать эту задачу заново, разработчики True Engineering создали сервис, который мы теперь можем в готовом виде встраивать в другие продукты. Делимся опытом.

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

Эту часть работы мы сейчас и автоматизировали в рамках отдельного микросервиса AReS – от Account Registration Service. Он умеет заводить в AD новых пользователей, отправлять им письма с регистрационной информацией, напоминать о необходимости придумать пароль. Это законченный компонент, и его можно копировать практически в любой продукт.

Архитектура процесса

Когда пользователь регистрируется в системе, его данные поступают в RabbitMQ, откуда их подхватывает AReS. В пакете вся информация, которая нужна для создания учётной записи:

Микросервис — это структурная единица, в которой все данные и функции, относящиеся к какой-нибудь одной конкретной бизнес-цели, объединены в один сервис.

Что ж, это достаточно общее понимание микросервиса, но что мы на самом деле под ним подразумеваем?

Для примера мы можем взять конструктор Lego, да, вы не ослышались, Lego.

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

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

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

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

При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.

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

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

Для разработчиков не секрет, что создание нового сервиса влечет за собой немало рутиной настройки: билд скрипты, зависимости, тесты, docker, k8s дескрипторы. Раз мы выполняем эту работу, значит текущих шаблонов IDE недосточно. Под катом мои попытки автоматизировать все до одной кроссплатформенной кнопки "сделать хорошо" сопровождаемые кодом, примерами и финальным результатом.

Если перспективы создания сервисов в один клик с последующим автоматическим деплоем в Digital Ocean звучат заманчиво, значит эта статья для вас.

Прим. перев.: в конце прошлого года Anne LoVerso — инженер из VMware Pivotal Labs — опубликовала развернутое сравнение Kubernetes с… океанариумом. Эта небольшая статья с наглядными иллюстрациями и аналогиями ориентирована на тех, кто впервые знакомится с K8s, и призвана упростить их самое первое погружение в дебри океана… оркестратора.

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

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

Скорость разработки и производительность программистов могут отличаться в зависимости от их уровня и используемых в проектах технологиях. Для проектирования ПО нет стандартов и ГОСТов, только вы выбираете, как будете разрабатывать свою программу. Один из лучших способов повысить эффективность работы — применить шаблон проектирования CQRS. 

Существует три вида паттерна CQRS: Regular, Progressive и Deluxe. В этой статье я расскажу о первом — классическом паттерне Regular CQRS, который мы используем в DD Planet в рамках разработки онлайн-сервиса «Выберу.ру». Progressive и Deluxe — более сложные архитектуры и влекут за собой использование обширного набора абстракций.

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

Наши команды практикуют подход Trunk Based Development – новый код сразу добавляется в мастер-ветку, сторонние ветки живут максимум несколько дней. А чтобы коммиты не мешали друг другу, разработчики используют фича-флаги (Feature Flags) – переключатели в коде, которые запускают и останавливают работу его компонентов.

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

Если вы стремитесь сокращать Time-to-Market, это недопустимо долго. Чем раньше вы получите обратную связь от пользователей, тем скорее вы исправите ошибки, тем меньше времени вы тратите на неудачные идеи, тем больше ресурсов можете уделить идеям удачным.

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

Проблемы долгоживущих веток

Данная статья будет полезна тем, кто никогда прежде не экспериментировал с Raspberry, но считает, что этому самое время.

Привет, Хабр! Тенденция приписывать любому техническому устройству эпитет «умный» достигла, кажется, своего апогея (по количеству употребления, разумеется). К тому же, большинство моих знакомых не из IT-сферы до сих пор наивно полагают, что каждый уважающий себя программист живет в самом «умном» доме во всём квартале, у которого вместо стен — серверные стенды исполинских размеров, а в свободное от работы время этот же человек-программист выгуливает «умную» собаку из Boston Dynamics. Дабы не отставать от этих современных стандартов, мы с товарищем решили собственноручно создать что-то «умное», но несложное, поскольку в школе схемотехника и конструирование роботов обошли нас стороной.

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

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

1. Можно выбрать неудачный микросервис для копирования - с недостающими элементами, некорректными настройками и т.д.

2. Если у разработчиков нет эталона, повышается риск дополнительных ошибок. Значит, кому-то придётся потратить лишнее время, чтобы их исправить.

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

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

Что даёт шаблон микросервиса

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

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

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

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

Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?

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

Слово «микросервисы» на слуху последние несколько лет. Технология активно развивается, на онлайн-конференциях о ней говорят, да и сами мы пишем их каждый день. Когда-то новый подход уже стал рутиной. Но мне как Java-архитектору интересно то, каким код был раньше, как он менялся, какие способы исполнения популярны сейчас и будут использоваться в 2021 году: асинхронность, контейнеры, FaaS. 

Так родился этот пост в двух частях, который я подготовил для Хабра на основе своих статей в блоге компании BellSoft и круглого стола Joker 2020, где мы обсуждали будущее джавы. Актуальное сегодня улучшение экосистемы для бэкендов не может существовать без понимания того, как создавать микросервисы: писать с нуля или вырезать скальпелем из монолитов? Предлагаю в первой части поговорить об их сущности, а во второй — разложить микросервисный контейнер на слои и посмотреть на вклад каждого слоя.

Часто в проектах возникает необходимость выполнения отложенных задач, таких как отправка email, push и других специфических задач, свойственных доменной области вашего приложения. Сложности начинаются, когда обычного crontab уже не достаточно, когда пакетная обработка не подходит и когда у каждой единицы задачи свое время выполнения или оно назначается динамически.

Для решения такой задачи было создано очередное решение под названием Trigger Hook. Принципиальная схема работы показана на рисунке 1. На схеме показано, что происходит с заданиями в течения всего их жизненного цикла. Смена цвета означает смену статуса задачи.

В одном из проектов возникла необходимость перевести процессы импорта данных сторонних систем на микросервисную архитектуру. В качестве инструмента выбран Apache NiFi. В качестве первого подопытного выбран импорт ЕГРЮЛ ФНС.

В предыдущей статье был описан способ преобразования XML в JSON с использованием AVRO schema.

В данной статье описан способ преобразования JSON с помощью JOLT спецификации.

KubeGraf — это плагин для Grafana, который собирает данные с кластера Kubernetes и приложений внутри него, а затем показывает их на красивых и понятных графиках. В феврале этого года вышел релиз 1.5, и стало известно, что предыдущие версии скачали более 250 тысяч раз! Мы расспросили Сергея Спорышева, создателя плагина и директора направления DevOps-продуктов в ITSumma, об истории создания плагина, факапах и причинах популярности.

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

Огромных зарплат в те времена не было, компании по разработке ПО создавались романтиками в съемных комнатушках-офисах, в которых часто приходилось и ночевать. Кто-то не выдерживал и сдавался, кто-то создавал шедевры и богател, но в те времена никто не говорил, что люди получают зарплату просто так. Те времена подарили нам кучу программ, часть из которых остаются самыми популярными в своей сфере и по сей день (Например, MS Excel. Страшно думать, но до сих пор большинство инвестиционных банкиров используют для своих моделей именно MS Excel). Те времена подарили нам таких людей как Питер Нортон и Андерс Хейлсберг или Джон Кармак с Сидом Майером, если игры вам ближе.

Монолитная и микросервисная архитектуры — два диаметрально разных подхода. Во время круглого стола на конференции DevOps Live 2020 столкнулись адепты этих архитектур, которые в формате баттла искали ответы на самые актуальные вопросы. Избыточны ли ресурсы на каждый микросервис? Есть ли необходимость в постоянном рефакторинге? И как грамотно организовать рабочее место?