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

На последней кибербитве Standoff 12, которая проходила в ноябре 2023 года, впервые был представлен вымышленный финтех — Global Digital Bank, максимально автоматизированный, с облачными приложениями на основе микросервисов «под капотом». Задачей команд атаки (red team) было реализовать недопустимые события, в случае с финтехом — остановить работу банка, выкрасть базу данных клиентов, взломать новостной портал. Назначение PT Container Security — защитить контейнерные среды и помочь синим командам отследить действия атакующих. Что из этого получилось? Рассказываем!

Приветствую всех новичков и гуру фронтенда, а также всех, кто работает с интерфейсами. Я Никита Борцов, создаю красоту на фронте первой в России FinOps-платформы для управления облачными затратами “Инферит Клаудмастер”.

В этой статье вы узнаете о:

• факторах, сформировавших тренд на уход фронтенд-разработки от монолита к микрофронтенду,
• процессах со стороны команды разработки при переходе на микрофронтенд,
• кейсе платформы “Инферит Кладумастер”: почему для нашей команды микрофронтенд с плагином Module Federation стал полезным решением,
• признаках того, что пора переходить на микрофронтенд.

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

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

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

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

Nameko, как фреймворк для Python, предлагает удобные абстракции и инструменты для создания микросервисов, ориентированных на сообщения и события.

С Nameko можно получить не только инструмент для создания микросервисов, но и платформу для реализации распределенных систем с поддержкой Dependency Injection, позволяющей легко интегрировать различные компоненты приложения.

Как-то в конторе появилась мысль, что надо бы продумать как нам распараллелить работу над одни микриком, так чтобы команды не пересекались друг с другом. Есть некоторые API над которыми работают несколько команд. Каждая работает над своей фичей локально и пишет тесты, а вот при деплое на стэнд получается столпотворение потому, что нужно изменения слить в одну ветку аля develop и её закинуть на тест. При этом могут быть конфликты при мерже кода или измениться проперти, которые не совместимы между разными ветка.

Мобильный банк сейчас обслуживает 450+ микриков. Над которыми работают более 90 команд. Так как у нас в проекте нет code ownership, то каждая команда вносит изменения в нужные им микрики. Чтобы избежать различного рода сложностей, которые приводят к увеличению времени time to market, нужно было развести разработку отдельных команд так, чтобы они не влияли друг на друга и могли работать параллельно.

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

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

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.

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

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

Первым шагом dBrain.cloud на пути к построению кластеров большого объема стало разделение etcd. Далее мы взялись за controller-manager.

Эта статья строится на двух простых идеях:

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

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

Вы наверняка слышали термин «MACH-архитектура», которая включает в себя Микросервисы, API-First дизайн, Cloud-Native инфраструктуру и Headless фронтенд. На Хабре тема MACH архитектуры практически не поднимается ввиду как сложности полной реализации и того факта, что MACH обычно ассоциируют только с E-Commerce уровня enterprise. Настораживает, что вокруг МАСН много пиара, но очень мало кейсов внедрений. Собственно, данный обзор — об этом.

Антон Губарев, инженер в Avito PaaS, рассказал, как реализовать межсервисную авторизацию на 2500 сервисов и ничего не сломать.

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

Салют, Хабр!

Go Kit предоставляет стандартизированный способ создания сервисов, с ее помощью можно легко реализовать совместимость сервисов. С его помощью можно легко интегрировать различные транспортные протоколы, такие как HTTP, RPC, gRPC, и многое другое, а также реализовывать общие паттерны: логирование, метрики, трассировка. В общем, Go Kit хорошо подходит для разработки микросервисов на go.

Мотивацию создания этой либы разработчики описали так:

Go стал языком сервера, но он по-прежнему недостаточно представлен в так называемых «современных корпоративных» компаниях, таких как Facebook, Twitter, Netflix и SoundCloud. Многие из этих организаций обратились к стекам на основе JVM для создания своей бизнес-логики, во многом благодаря библиотекам и экосистемам, которые напрямую поддерживают их микросервисные архитектуры.

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

Привет, Хабр, меня зовут Светлана Уварова, я — ведущий системный архитектор в МТС.

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

Микросервисная архитектура предполагает декомпозицию монолитного приложения на несколько полностью независимо развёртываемых и масштабируемых сервисов. За пределами этого базового определения, то, что представляет собой микросервис, может быть несколько субъективным. Хотя есть несколько проверенных в бою практик, принятых такими гигантами, как Netflix и Uber, которые всегда следует принимать во внимание. И я расскажу о некоторых из них. 

Аннотация. В статье анализируются технические требования, предъявляемые к электрозаправочным станциям с точки зрения определения возможности и особенностей проектирования информационной системы по их обслуживанию. Показаны основные особенности работы электрозаправочных станций, согласно стандартам, принятым в Европе, США и Китае. Рассмотрены их функциональные характеристики и специфика работы для удаленного управления с помощью информационной системы.

Сформулированы требования к информационной системе, которая может быть создана на основе микросервисной архитектуры. Показано, что для обеспечения взаимодействия между отдельными частями информационной системы должна быть обеспечена стабильность ее работы в режиме 24/7.

В ходе исследования определено, что:

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

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

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

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

Когда эволюция платформы dBrain.cloud дошла до заявленных и считающихся нормальными в публичных облаках пределов, справляться с возникшими при росте объемов кластеров проблемами пришлось самостоятельно. Ведь компании-гиганты, эксплуатирующие Kubernetes, эти тайны не раскрывают.

Здравствуйте, меня зовут Александр, я backend-разработчик. В данной публикации хочу поделиться опытом настройки мониторинга NATS JetStream. Рассказать для чего в принципе это может понадобиться. А также  привести пример необходимого стека сервисов поднятых в docker для мониторинга. В статье не рассматриваются настройки dashboards в Grafana, принципы и особенности работы NATS.

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