Микросервисы становятся все более популярным способом создания и поддержки сложных приложений. По сути, микросервисы — это набор небольших независимых сервисов или компонентов, которые совместно реализуют задачи большого приложения. Сегодня расскажем о полезных книгах для начинающих и опытных разработчиков микросервисных архитектур.
Привет, Хабр! Меня зовут Андрей Чернов, я 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 довольно проста (не входит в тему этой статьи). Но что же мы за программисты такие, если не хотим это дело как-то кастмизировать. Добавляем зависимости.
Привет! Недавно у нас в компании завершилось RnD по микрофронтендам, мы посмотрели подходы, протестировали некоторые идеи, и хотим поделиться с вами результатами. Если вы сейчас выбираете подход для использования микросервисов на фронтенде, этот пост может вам пригодиться как сводное сравнение особенностей, плюсов и минусов четырёх основных подходов.
Когда мы пытались понять потребности и присматривались к тому, какие решения в этой области есть у других, мы прошлись по компаниям, посмотрели, какие подходы в сфере микрофронтенда они используют. Несколько компаний приходили к нам и презентовали нам свои решения. Но так как большинство из этих решений были самописными, мы решили отказаться от рассмотрения данных концепций и посмотреть стандартные подходы.
И вот к чему мы пришли.
Мы выделили три основных потребности разработки на микрофронтенде.
1. разделить большие команды разработки фронтендов на несколько;
2. разрабатывать большие портальные приложения;
3. сократить порог входа в разработку для фронтенд‑разработчиков.
Подходов, которые мы рассмотрели, было четыре:
1. Single SPA,
2. Module Federation,
3. NPM modules,
4. Git Submodules.
Введение
У меня была задача «Собирать статистику постов в vk каждый час». Я не являюсь разработчиком или DevOps специалистом. Поэтому мой способ решения задачи сложился из поисковых запросов, личного опыта, советов друзей и коллег.
Решение я разбил на 2 части.
Нужен ли каждому разработчику свой dev-сервер? Многие компании, опасаясь лишних расходов и проблем, даже не пробуют внедрить такой подход.
CarPrice развернул свои dev-серверы еще в те далекие времена, когда все работало на монолите. А после монолита пилил собственный сервис для оркестрации dev-серверов на базе Docker, затем разворачивал их на Minikube и постепенно пришел к Kubernetes.
На связи ведущий инженер отдела DevOps CarPrice Михаил Чешуин. В этой статье я расскажу, как мы запускали dev-серверы в разные периоды — и как все работает сейчас
