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

Как-то в конторе появилась мысль, что надо бы продумать как нам распараллелить работу над одни микриком, так чтобы команды не пересекались друг с другом. Есть некоторые 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.

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

Всем привет! Меня зовут Марсель Абдрахманов, я фронтлид в Банки.ру. В статье хочу поделиться нашей историей ухода от монолита к микрофронтендам. У нас в Банки.ру большой отдел веб-разработки, за последнее время мы сильно выросли, ежедневно катим десятки релизов на прод. Расскажу, как мы относительно быстро внедрили микрофронтенды и перешли на архитектуру, которая позволила сократить время доставки обновлений на прод с двух дней до нескольких часов.

Одна из сложнейших задач этого года — адаптация под новые условия работы с зарубежными вендорами и с open-source сообществом в целом. Open-source не решает все проблемы; в некоторых случаях он их только создает. При этом в российской разработке есть особенности, связанные с импортозамещением. Все вместе это наложило отпечаток на большинство классических программных платформ и языков программирования.

В 2023 году ЕДИНЫЙ ЦУПИС перевел информационные сервисы на отечественную платформу Java с поддержкой ее поставщика. Сейчас в качестве среды разработки и исполнения Java в ЕДИНОМ ЦУПИС используется Axiom JDK Pro. Давайте посмотрим на проблемы этого года глазами разработчиков Java-платформы, а поможет нам в этом Олег Чирухин, деврел в команде этого дистрибутива.

Привет! Меня зовут Денис, я - разработчик ПО SEDMAX. Это промышленное ПО для сбора и визуализации данных в энергетике. Как и у всех, у нас бывают баги. Мне бы хотелось поделиться опытом в поиске таких багов, а так же порассуждать на тему того, что необходимо было сделать, чтобы баг не появился. У нас серверная часть написана на go в виде некоторого множества сервисов, поэтому специфика большинства багов будет асинхронное взаимодействие, а код примеров представлен на go.

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