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

Представьте, что вам нужно ускорить работу огромной легаси-системы с 50 микросервисами, нагрузка на которую выросла в 2000 раз. При этом она обрабатывает затратные по времени операции, которые зависят друг от друга в плане данных. 

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

Привет Хабр! Меня зовут Евгений Лабутин, я фронтенд-разработчик в МТС Digital. Расскажу вам о том, как мы приручили микросервисы на нашем проекте МТС Твой бизнес, зачем они нам вообще понадобились и какую выгоду мы от этого получили. Интересно? Добро пожаловать под кат!

Была у меня мечта - писать backend на C++. А вот разбираться в unix socket'ах, TCP, многопоточной/асинхронной обработке запросов и во многом другом совсем не хотелось. Не верил я, что до сих пор нет каких-то минималистичных фреймворков. И сегодня я вам расскажу, как можно просто сделать HTTP API микросервис на C++ с помощью фреймворка Drogon.

Сервис Google - Maps Timeline позволял пользователям легко посмотреть историю своих перемещений на Гугл картах, с привязкой к посещённым местам, сделанным фотографиям.

Сегодня Гугл убил его, а вместе с ним и историю моих путешествий за последние несколько лет...

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

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

Всем привет. Меня зовут Алексей. Сейчас я работаю frontend-разработчиком в компании Ozon. В свободное время мне нравится читать про новые технологии, фреймворки, а учитывая то, с какой скоростью развивается frontend, я никогда не скучаю. В этой статье пойдет речь о микрофронтах. В частности, мы посмотрим, как их реализовать на самом базовом уровне, разберемся, когда они нужны, а когда даже не стоит смотреть в их сторону. 

Привет, Хабр! Меня зовут Артём Шубский, я техлид в компании AGIMA. Заметили, что на Хабре и на конференциях часто рассказывают, как перешли с монолита на микросервисы. Мы тоже всем сердцем любим микросервисы, но в этой статье я расскажу об обратном примере: как и почему на одном из проектов шли от микросервисов к монолиту. Это поучительная история о том, почему не страшно поменять архитектуру, даже когда кажется, что поздно.

Привет, меня зовут Ваня. Я решаю архитектурные задачи на фронтенде в Тинькофф Бизнесе и сейчас расскажу вам про одну из них.

Несколько лет назад у нас было большое монолитное приложение, которое со временем превратилось в десяток поменьше. В этой статье я поведаю, какие проблемы у нас возникали на регулярной основе в монолите, как мы их решили и стоит ли «распиливать» свой фронтенд.

Как то вечером, придя домой с работы, я решил немного позаниматься домашним проектом. Я сделал несколько правок и сразу захотел поэкспериментировать с ними. Но до экспериментов мне пришлось заходить на VPS, пулить изменения, пересобирать контейнер и запускать его. Тут я и решил, что пора разобраться с непрерывной доставкой.

Вступление

Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.

Код доступен для ознакомления на гитхабе. Образы опубликованы на докерхабе, весь зоопарк стартует одной командой.

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

В Сравни у нас много продуктов, включая сервисы подбора и покупки полиса ОСАГО, подбора кредита, образовательных курсов, онлайн-оформления ипотеки. Информация о пользователях хранится и обрабатывается в специальном центральном сервисе (Profile Service). На текущий момент сервис содержит миллионы объектов пользователей, а нагрузка в пиковые моменты там до 180 запросов в секунду.

Исходная реализация Profile Service была построена на микросервисах и, как казалось нам ранее, полностью покрывала наши потребности: в плане гибкости взаимодействия с продуктами и работы с существующей нагрузкой. Изменения назрели под конец прошлого года, когда продуктовые команды стали настойчиво обращаться в команду сервиса для решения срочных задач. Здесь им регулярно требовалась помощь разработчиков — и команда Profile Service около месяца занималась только обработкой продуктовых запросов.

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

Мартышка и АйТи: Парадокс сложной эффективности

Вы когда-нибудь задумывались, почему в IT всё циклично? Почему старые методы и технологии, которые когда-то были на пике популярности, возвращаются на сцену?

Давайте разберёмся, что такое Парадокс сложной эффективности на простом примере, а также посмотрим, как это работает в IT последние 30 лет.