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

Введение

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

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

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

Самое начало

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

Недавно мной был создан самодостаточный пример совместной работы компонентов Symfony Messenger и Symfony Console, подробно описанный в статье https://habr.com/ru/articles/817425/.

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

Мой внутренний перфекционист :-) сильно против этого возражал и говорил «а вот бы все эти консоли-терминалы запускались одной командой, в нужном количестве, сразу с Worker’ами, а если какой Worker упадёт, то заново запускались в нужном количестве».

Возражать своему внутреннему перфекционисту я не стал и создал ещё один пример работы Symfony Messenger, который запускается Worker’ами из PHP фреймворка Workerman. При этом Symfony Console вообще не используется.

Привет, Хабр! Меня зовут Александр Митин, я работаю в Т1 на проектах одного крупного банка. Занимаюсь развитием продкутовых сервисов компании (проект по обслуживанию и проведению ЧДП/ПДП клиентов). Опыт разработки 13 лет, последние 5 лет — в финтехе.

Сегодня микросервисная архитектура используется во многих проектах. Зачастую в таких системах применяют журналирование, авторизацию и прочие служебные сервисы, общие для всех приложений. А при разработке возникает огромное желание не дублировать одну и ту же логику, а вынести её в отдельную библиотеку, тем самым переиспользовав код. Что мы имеем в итоге? В лучшем случае одну библиотеку «common», которая разрастается до огромных размеров и становится ядром распределённого монолита. В дальнейшем новые версии этой библиотеки теряют обратную совместимость, а каждое её обновление в проектах сильно осложняет поддержку. Более того, становится невозможным разобраться, где и какие классы используются, что делает архитектуру хрупкой и уязвимой.

Пришёл и мой черёд асинхронно и многопоточно средствами PHP кое-что пообрабатывать… И я, естественно, вспомнил про компонент Messenger фреймворка Symfony.

Ранее я никогда Symfony Messenger не использовал.
Чтобы понять, как с ним работать, я пытался найти какой-то простой, законченный и самодостаточный пример, понятный даже чайнику, но мне это не удалось...

Всё, что находилось, было либо слишком сложным, либо это были какие-то отдельные куски кода, понятные только тем, кто уже работал с Symfony Messenger. К тому же всё, что находилось, в основном было "заточено" либо под Redis, либо под RabbitMQ. установка которых как-то немного перебор для учебного примера…

В-общем, я создал и выложил на GitHub такой простой, законченный и самодостаточный пример работы Symfony Messenger совместно с Symfony Console.

Привет Хабр!

Меня зовут Алексей Пушкарёв, я – архитектор продуктовых решений компании ELMA. Наша команда разрабатывает одноименную Low-code платформу.  В этой статье я расскажу, почему мы выбрали микросервисную архитектуру для Low-code системы вместо классической монолитной, которой до этого занимались много лет. Поясню, почему использовали именно такие технологии и решения, с какими недостатками сами столкнулись. Поговорим, как такая архитектура сказалась на Low-code разработчиках.

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

Добро пожаловать под кат!

Всем привет!

Меня зовут Сергей Максимов и я руковожу разработкой в Центре Управления Процессами (ЦУП) Московской Биржи. В статье я хочу рассказать о нашем опыте автоматизации бизнес-процессов (БП), когда система должна быть не только удобной бизнес-пользователям снаружи, но и надежной внутри.

Бизнес Биржи, с одной стороны, похож на обычный банковский финтех, но имеет ряд важных особенностей. Чтобы лучше представить специфику нашей работы, я приведу метафору. Представьте, что каждое утро с вашего корпоративного космодрома в космос отправляется ракета. В течение дня космический корабль автономно выполняет работу на орбите, а вечером возвращается на базу. В полёте связь с кораблем очень ограничена и успех его полёта на 99% определяется качественной подготовкой. Всё должно отработать точно и в срок. Досрочный спуск корабля с орбиты технически возможен, но влечет за собой огромные репутационные потери с отчетом регулятору и новостями в федеральных СМИ.

Продолжаем рецензии на книги по ИТ‑тематике с промокодом от нашего блога. Сегодня это перевод известной книги «Building Micro‑Frontends» O'REILLY по микросервисам, вышедший в издательстве БХВ‑Петербург весной 2024г. Книга рассчитана на широкий круг веб‑разработчиков, архитекторов и руководителей команд, работающих с веб‑приложениями. А в целом, полезна всем, кто столкнулся с проблемами масштабируемости, параллельной разработки и организации кодовой базы при создании сложных фронтенд‑приложений.

• сильно оптимизировали работу фреймворка и обогнали основных конкурентов в бенчмарках высокопроизводительных фреймворков;
• значительно упростили конфигурирование;
• обзавелись install, докер-образами, Yandex Cloud-образом и DEB-пакетами;
• обросли новой функциональностью, включая серверные мидлвари для HTTP, и YDB-драйвером;
• перешли на новую ежемесячную схему релизов и упростили версионирование.

Всем привет, меня зовут Антон Малафеев, я руководитель группы инженеров IT‑инфраструктуры в СберМаркете. Моя команда вот уже больше 3-х лет занимается разработкой деплоя для PaaS и сопутствующих инструментов.

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

Но сначала немного цифр. Ниже на рисунке — наша статистика использования канареечного деплоя. На момент написания статьи у нас в проде 200+ сервисов, 5300 подов PaaS, ежемесячно мы делаем 2 тысячи деплоев в продакшн и 11 тысяч деплоев в стейдж, которые проходят через канарейку.

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

Компактная книга "Node.js: разработка приложений в микросервисной архитектуре с нуля" Юлии Поповой — выпущена в апреле 2024 г. как практическое руководство для разработчиков уровня джун и выше. Описан процесс создания микросервисов на Node.js с использованием фреймворка NestJS и других популярных технологий. Хотя в заголовке есть фраза «с нуля», книга рассчитана на читателей, уже имеющих опыт работы с JavaScript, TypeScript и NestJS. Автор не углубляется в теоретические основы, а дает практические аспекты построения масштабируемых приложений на базе микросервисной архитектуры. Заглянем внутрь :-)

Привет, Хабр! Сегодня расскажем о кейсе по внедрению NoSQL базы данных Clickhouse в платформу контейнеризации.

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

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

Для обслуживания каждого инстанса web-приложения компания «СберАвто» использует кластерную пару веб-серверов Nginx, которые выполняют функции балансировки нагрузки, маршрутизации запросов и обработки HTTP-запросов от клиентов. Поэтому, при выборе межсетевого экрана уровня приложения (WAF) было важно обеспечить непрерывную интеграцию с существующей инфраструктурой на базе Nginx.

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

Гибкость в выборе вариантов установки ноды WAF как на балансировщики нагрузки, так и в контейнер рядом с конкретным приложением, обеспечила возможность защитить  в том числе и сервисы, расположенные внутри инфраструктуры. Развертывание доступно с использованием playbook Ansible или Terraform, что существенно упрощает процесс установки и обслуживания.

Платформа «Вебмониторэкс» имеет большие возможности обеспечения наблюдаемости и защиты API. В частности, для наблюдения за API, построения OAS и мониторинга изменений API был использован модуль «Структура API» (рис.1), более подробно про данный модуль можно прочитать в нашей документации.

Cosmos представляет собой новейшее поколение медиа-обработчика на Netflix, интегрирующее архитектуру на основе микросервисов, асинхронные рабочие процессы и функционал без привязки к серверам. Эта платформа нацелена на оптимизацию медиа-процессов внутри Netflix, повышая их гибкость и производительность, а также способствуя более продуктивной работе разработчиков. За последние годы команда Encoding Technologies (ET) усердно трудилась над модернизацией видео-конвейера с использованием платформы Cosmos.

Обновлённый конвейер состоит из множества микросервисов, каждый из которых выполняет строго определённые функции. Один из таких сервисов – Video Encoding Service (VES), который играет ключевую роль в процессе кодирования видео, преобразуя исходные медиа-файлы в форматы, подходящие для стриминга на Netflix или других студийных задач. VES сталкивается с рядом требований, связанных с обработкой контента:

• Необходимость поддержки множества форматов, разрешений и качества изображения для разнообразных устройств пользователей, от мобильных телефонов до смарт-телевизоров;

• Обязательность чанковой кодировки для соответствия требованиям задержек, с учётом различной чувствительности к ним;

• Важность непрерывного выпуска обновлений для ускорения инноваций в стриминговых и студийных направлениях;

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

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

Приятного прочтения!

Привет, Хабр!

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

В статье рассмотрим два языка программирования, которые выделяются своим функциональным подходом и широким применением в микросервисной архитектуре: Scala и Erlang.

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

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

Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет.

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

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

Можно ли исправить ситуацию коренным образом?

Привет, Хабр! Меня зовут Салахутдинов Дмитрий, я принципал инженер в СберМаркете. Занимаюсь развитием Ruby-платформы и масштабированием системы через декомпозицию монолита на сервисы.

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

Привет, Хабр! Меня зовут Миша Трифонов, я head of frontend в компании Cloud.ru и основатель сообщества TeamSnack. Поделюсь опытом, кейсами, решениями за 3,5 года работы в направлении микрофронтов.

Статья будет полезна как для тех, кто мало пользовался микрофронтами, так и для гуру микрофронтов. Расскажу, что это такое, покажу преимущества их внедрения и научу продавать ценность этого процесса бизнесу. Еще расскажу про трудности: технология требует ресурсов и усилий.