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

Чего от разработки ПО хотят разработчики, продакты и владельцы бизнеса?

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

Вы слышали о Red Hat OpenShift и VMWare Tanzu? Мы сделали российскую альтернативу этих продуктов. Сегодня я хочу поделиться, как мы с командой собираем комплект баз данных, которые можно использовать для запуска микросервисных приложений.

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

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

Привет! Меня зовут Саша Сусиков. Я проверяю клавиатуры на прочность около 10 лет из  них последние 2 года с помощью Go. Сейчас я участвую в разработке платформы СберМаркета, где создаю инструменты, которые упрощают жизнь разработчикам. Эта статья для тех, кому предстоит настроить процесс взаимодействия сервисов в компании и вы ищете, как не наломать дров.

На этой неделе мы выпустили Squadus — единое цифровое рабочее пространство, которое позволяет компаниям удобно и гибко структурировать коммуникации. На создание этого on-premise решения ушло порядка трех лет; для ускорения разработки Squadus мы скомбинировали наши технологии и компоненты СПО.

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

В новом цикле статей рассказываем, как Squadus развивался с технической точки зрения. Начнем с бэкенда: поговорим сегодня о переходе от монолитной архитектуры к микросервисной, о том, какие проблемы и как мы решали, и что нам это дало.

Именно так я решил назвать эту статью, чтобы описать свои эмоции на прожаривании кода спонтанном публичном код-ревью моего open-source Portal от участников Go-чата, в котором я активно участвую. Главным ревьюером был Глеб Яльчик, что делало ситуацию ещё более волнительной для меня. Расскажу, как я на это решился, что мы обсудили, к чему пришли и какой эффект это дало. А внедрять Portal мы будем на примере мини-приложения по мотивам (всеми любимой) мобы Dota.

Примечание: это приложение будет что-то делать только в учебных целях, чтобы понять, как Portal сможет нам помочь передавать данные. Логика в нём будет достаточно простой, без ряда проверок и, возможно, с багами. Если станет достаточно интересно, то можем обсудить и его в комментариях!

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

Привет, Хабр! Меня зовут Андрей Чернов, я Java-архитектор микросервисов в СберТехе — компании, которая создала цифровую облачную платформу Platform V для разработки бизнес-приложений. Наша команда развивает продукт Platform V SessionsData — высокопроизводительное распределённое in-memory-хранилище для общего контекста сессионных и key-value-запросов, которое СберБанк Онлайн использует в качестве микросервиса на своей серверной стороне. Продукт актуален не только для решения задач СберБанка Онлайн: он доступен рынку и может использоваться для аналогичных целей в любых отраслях.

В статье расскажу, почему мы решили создать собственный микросервис, чем он нам помогает, а также как мы справлялись с нагрузкой СберБанка Онлайн. У статьи будет продолжение. Во второй части поговорим о том, как мы достигаем высокой доступности сервиса, а в третьей — какие доработки нужны нам, чтобы развивать Platform V SessionsData.

С помощью Apache Kafka мы в Авито гарантируем соблюдение контрактов публикуемых событий. Рассказываем, как мы переработали архитектуру и сделали работу с Kafka удобнее и надёжнее.

Мы можем пережить даже полный отказ дата-центра. Почему — тоже расскажем в этой статье.

Привет, Хабр! Прежде чем погружаться в проблемы, давайте я расскажу, как у нас устроена микросервисная архитектура и куда мы идём. К сожалению или к счастью, в сегменте B2B в банковском и околобанковском обслуживании клиенты чаще пользуются веб-версиями приложений. Большие списки, зарплатные ведомости, работа с документами — всё это проще делать на большом экране. Постепенный переход в мобильную среду начинается только сейчас. 

В этом посте я расскажу о том, как мы используем DDD в Augury и наши уникальные бизнес-требования для создания руководства по архитектуре микросервисов, сосредоточившись на трех общих паттернах. Мы используем это руководство и определения, чтобы решить, когда создавать новый микросервис и как распределить нашу доменную логику по этим сервисам.

Привет! С вами снова Максим. Во второй части будет о том, что мы придумали.

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

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

Дорогой читатель, это мой первый туториал и если я что-то упустил или не объяснил, хотя стоило бы, напиши пожалуйста комментарий и я обновлю статью.

TL;DR

Весь код для микросервисов и e2e теста тут

Рекомендую быстро пробежаться по коду перед прочтением статьи т к в самой статье я объясню только неочевидные моменты реализации e2e тестирования.

Вашему вниманию представлена квинтэссенция подготовленной мной серии докладов под названием «Распределенное понимание распределенных систем» (“Distributed Distributed Systems unDerstanding”), посвященной определению и оптимизации микросервисных архитектур. Эта серия основана на книгах «Основы архитектуры программного обеспечения: инженерный подход» и «Архитектура программного обеспечения: сложные моменты».

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

Напомню, что текст рассчитан в первую очередь на разработчиков, которые имеют мало практического опыта работы в конкурентной и/или микросервисной среде, поэтому многие вещи я объясню на пальцах. Для тех, кто захочет ознакомиться с более строгими формулировками, сразу скажу, что здесь будут затронуты упрощённые идеи паттернов Transactional Outbox и Saga.

Finagle — библиотека от разработчиков Twitter. Ее используют для организации межсервисного RPC и построения mesh-микросервисной архитектуры. У библиотеки богатая функциональность по тонкой настройке и интроспекции, но сегодня мы рассмотрим клиентскую балансировку.

Привет, Хабр! Сейчас мы, команда СберБанка Онлайн, проводим очень масштабную работу по миграции на микросервисную архитектуру. Проект стартовал много месяцев назад, и сейчас уже можно поделиться некоторыми результатами и соображениями. Так мы и решили поступить — делимся нюансами этой работы в статье, которая написана по мотивам выступления Артёма Арюткина, исполнительного директора и руководителя проектного офиса. Подробности нашей трансформации — под катом.

Я вас категорически приветствую, дорогие хабравчане! В этой статье я хотел бы поглубже разобрать такую штуку как Spring Security, а в частности Security фильтры, как они работают в целом и как объединяются в цепочку ApplicationFilterChain.

Скажу сразу, эта статья является скорее финальной точкой моего ночного дебагинга кишочков Spring Security, а также одной из основных целей этой статьи является закрепление знаний, которые я получил. Но это не отменяет тот факт, что статья кому-то (и я уверен что многим) будет полезна. Поехали.

Проблема

Для начала я обозначу проблему, с появлением которой я и начал столь интересный путь по стектрейсу в дебаггере. На проекте, над которым сейчас мы с командой работаем понадобилось прикрутить сервис авторизации. Не долго думая и собрав в кучу все требования, было принято решение поднять сервис, поддерживающий OAuth2 стандарт, а именно Keycloak. Этот сервис довольно популярен и по его настройке скопилось немало экспертизы. А также у коллег из других команд был опыт по развертыванию и настройке Keycloak. В общем, остановились на нем. Как гласит документация, в Keycloak поддерживается интеграция со Spring Security, поэтому проблем возникнуть не должно, НО…

После поднятия самого Keycloak сервера и конфигурирования Realm’a, Client’a юзеров и т. д., мы начали прикручивать авторизацию в наши микросервисы. Исходя из мануала, настройка Keycloak довольно проста (не входит в тему этой статьи). Но что же мы за программисты такие, если не хотим это дело как-то кастмизировать. Добавляем зависимости.