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

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

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

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

Вы наверняка слышали термин «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, которые всегда следует принимать во внимание. И я расскажу о некоторых из них. 

Микросервисная архитектура предполагает декомпозицию монолитного приложения на несколько полностью независимо развёртываемых и масштабируемых сервисов. За пределами этого базового определения, то, что представляет собой микросервис, может быть несколько субъективным. Хотя есть несколько проверенных в бою практик, принятых такими гигантами, как 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.

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

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

После анализа различных вариантов, мы остановились на WebSocket в связке с RSocket.

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

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

Поэтому, когда мы закончили проект, то решили восполнить (или попытаться) этот пробел в русскоязычной среде на реальном примере. Надеемся, что эта статья поможет вам разобраться в применении RSocket over WebSocket и сократит время на погружение :) 

Если у вас есть большая система, состоящая из множества микросервисов, то вы наверняка задавались вопросом: «Что сделать, чтобы архитектурная схема всей системы была всегда на 100% актуальной?».

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

Чтобы решить проблему мы автоматизировали отрисовку схем опираясь на метаданные IT-систем. Мы создали отдельный микросервис, который этим занимается и назвали его «Architect». О том как это происходит и как работает Architect я расскажу в этой статье, а также дам несколько советов, которые помогут внедрить то же самое у вас в компании.

Привет, Хабр! Меня зовут Иван Вербов, я UI/UX дизайнер команды разработки платформы контейнеризации dBrain.cloud. В разработке дизайна интерфейсов я стремлюсь к балансу между двумя противоположными подходами: строгость и стабильность - легкость и игра.

Хочу поделиться топ-5 фишек, созданных для консоли dBrain, чтобы превратить рутинную работу инженера по обслуживанию кластера в творческую.