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

Прим. перев.: в конце прошлого года 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 столкнулись адепты этих архитектур, которые в формате баттла искали ответы на самые актуальные вопросы. Избыточны ли ресурсы на каждый микросервис? Есть ли необходимость в постоянном рефакторинге? И как грамотно организовать рабочее место?

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

В октябре прошлого года мои коллеги представили на EnvoyCon доклад "Построение гибкой подсистемы компрессии в Envoy". Вот он ниже

Судя по статистике сегодняшней статьи от SergeAx, тема компрессии сетевого трафика оказалась интересной многим. В связи с чем я немедленно возжелал вселенской славы и решил кратко пересказать содержание доклада. Тем более, что он не только о компрессии, но и том, как можно упростить сопровождение сетевой подсистемы как backend'а, так и мобильного frontend'а.

Присказка

Привет, коллеги!

В феврале необязательно доставать чернила и плакать — можно и радоваться. 

Во-первых, Grafana заапрувила новую версию нашего плагина для мониторинга Kubernetes: KubeGraf v.1.5.0 доступен для инсталляции.

Во-вторых, оказалось, что за полтора года с момента выхода первой версии плагин скачали четверть миллиона раз!

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