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

Привет, Хабр! Если вы работаете с микросервисами, то знаете, что они имеют свойство образовывать некоторую связанность. Хорошо, когда связи между микросервисами однонаправленные, но всё становится сложнее, если возникают циклические зависимости.

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

Меня зовут ​​Сергей Прохоров, я техлид бэкенд-разработки в Ak Bars Digital, и давайте вместе рассмотрим, как реализовать такую изоляцию на примере микросервиса веб-API ASP.NET Core. Метод изоляции основан на использовании feature toggles, или переключателей функциональности, о которых и пойдёт речь в двух частях статьи.

Лично я сталкивался с тем, как крупные компании распиливают монолит на микросервисы, но потом не переиспользуют их. Они так и остаются жить в одной системе.

Здесь мы делаем микросервисы, не ради микросервисов, а пилим наши монолиты работоспособными частями. То есть, зарефакторили кусок, и производство с ним работает. На каждый - около 3 месяцев. Правда, с таким подходом есть риск улететь в ситуацию, когда микросервисы получаются AS IS, а не в общей идее архитектуры. В поддержке потом их совокупность не лучше монолита.

В общем, расскажу, как на практике распиливаются монолиты огромных размеров, которые управляют всем производственным циклом. А размеры ещё те: НЛМК — гигант. Мы делаем 20% стали России и входим в TOP-20 по производству в мире.

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

Всем привет, меня зовут Алена Коваленко, я Java-разработчица одной из команд направления Warehouse Management System (WMS) компании Lamoda. Наша команда занимается автоматизацией складской системы и реализацией новых фич для улучшения работы сотрудников склада. В том числе мы занимаемся техническими импрувментами системы, такими как вынесение из монолита функциональности, связанной с идентификацией товара и приемкой возвратов, в отдельный сервис — Inbound Service.

После релиза Inbound Service на проде склад заметил долгий отклик системы. В процессе исследования проблемы мы обнаружили утечку памяти, связанную с конфигурацией приложения, в том числе внутренних очередей в ActiveMQ Artemis.

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

Неотъемлемым атрибутом таких компаний, как Uber, Twitter и LinkedIn, являются обновления в режиме реального времени: уведомления, сопровождающие вашу поездку, в Uber, твиты друзей и полезные советы отраслевых экспертов можно, которые получить и переслать в течении нескольких секунд. Как только информация попадает в сеть, она сразу становится доступной для всех вокруг. Пользователям всегда будет нравится эта простая и быстрая доступность информации - они всегда находятся в поиске подобных улучшений качества их жизни.

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

Всем привет! Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. В последнее время я активно занимаюсь BPM-системами Camunda и Zeebe (основа Camunda-cloud). Если вы, как и я, с ходу не можете ответить на вопрос, кто быстрее — Camunda или Zeebe, насколько, и в каких случаях они могут тормозить, то добро пожаловать под кат.

В настоящее время информационные технологии достигли высочайшей степени автоматизации разработки программного обеспечения. Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами. У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы. Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему. По большей части. Можем, когда хотим.

Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно? Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.

Привет! Меня зовут Ренат Шафиев, я с 2008 года работаю в банковской сфере и сейчас занимаюсь нефинансовыми сервисами для мобильного приложения и интернет-банка ВТБ Онлайн. Недавно мы запустили сервис по оформлению билетов на «ВТБ Арену» — он позволяет смотреть афишу мероприятий и оформлять билеты без ввода реквизитов карты, а для прохода на стадион достаточно показать QR-код билета. Хотим поделиться, с какими задачами мы столкнулись, в том числе по клиентскому пути и архитектуре.

Сталкивались ли вы с задачей построить Enterprise-grade-приложение из десятков приложений, слабо связанных друг с другом, разрабатываемых разными командами, с разными моделями релиза?

Мы хотим поделиться опытом, как решили эту задачу в Netcracker. Как в этом помогла концепция Service Mesh и идея применить «микросервисную модель» и к структуре Service Mesh. Мы реализовали Non Uniform Service Mesh (NUM), который представляет собой продукт и набор паттернов его применения.

Сама статья основана на расшифровке выступления на SaintHighload 2021 в Питере Алексея Ефимова, системного архитектора Netcracker и руководителя отдела Cloud Core. Ссылка на запись — в конце статьи.

Переехать в микросервисы можно двумя способами. Можно построить платформу — это надежно, но очень сложно. Или можно поднять Kubernetes и начать в него коммитить новые сервисы. Переезд проходит быстро и легко, но редко получается то, на что вы рассчитываете. Например, вместо микросервисной структуры вы можете обнаружить распределенный монолит.

Многие при этом не задумываются, правильно ли они пилят микросервисы. Как в синдроме утенка: увиденное самым первым становится единственно верным решением.

Меня зовут Олег Федоткин, я Head of PaaS СберМаркет, мы занимаемся той самой платформой, которая помогает разработчикам лучше, удобнее и быстрее писать микросервисы. Мы стандартизируем всю разработку, стараясь снизить Time to Market для новых фич. Но это всё равно очень сложно. Поэтому сегодня я разберу самые распространенные микросервисные проблемы.

Удивительно, сколько полезностей можно узнать за один хабрамитап Хабр ПРО. Например, какая судьба ждёт монолит при переходе на микросервисы и кто отвечает за общий код между двумя микросервисами.

Эти и другие вопросы обсуждались 25 ноября в выпуске «Хабрамитап про микросервисы: отвечаем на вопросы с Хабр Q&A». Вебкаст посетил наш сотрудник — руководитель направления автоматизации в Россельхозбанке (РСХБ) Денис Рылеев.

На протяжении эфира Денис отвечал на вопросы о микросервисах, которые задавал ведущий хабрамитапа Андрей Аврамчук, подобравший самые интересные топики от зрителей вебкаста и пользователей бывшего Тостера — нынешнего Хабр Q&A. Кроме Дениса выступал ещё один эксперт — системный инженер компании EPAM Михаил Чугунов.

Из этой статьи даже начинающий разработчик поймёт, что такое микросервисы и в каких ситуациях они применяются. Денис и Михаил постарались ответить на все вопросы максимально доступным языком. Мы выделили несколько категорий вопросов:

• Введение в микросервисы
• Серебряная пуля Фредерика Брукса
• Архитектура, разворачивание и API Gateway
• Какую литературу советуют почитать профессионалы

Заранее обрадуем жаждущих именно услышать специалистов: каждый вопрос сопровождается ссылкой с вшитым тайм-кодом, так что долго искать ответы в записи вебкаста не придётся.

Хороший вопрос требует хорошего ответа. Приступим.

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

Я техлид в команде Авито в проекте SLA. Сегодня расскажу, как мы оптимизировали сетевые вызовы, чтобы избежать проблем с сетью при переходе в микросервисный мир. Разговор будет про оптимизацию CURL-запросов, деградацию сервисов и FAIL-FAST-подходы.

Доброго времени суток! Для начала, о чем будет статья? Статья является сжатым описанием опыта перехода от монолитного приложения к микросервисам. Коснемся плюсов такого перехода и затронем часть проблем, с которыми можно столкнуться в реальной разработке. Для кого может быть полезна статья? Для тех кто по каким-то причинам еще сомневается в эффективности микросервисных архитектур. Также отмечу, что статья не является учебным пособием. Она ставит целью коротко познакомить с практикой перехода от одной архитектуры к другой. Для тех кто хочет погрузиться в детали проектирования микросервисных архитектур, рекомендую почитать литературу, начать можно с книги Криса Ричардсона «Микросервисы. Паттерны разработки и рефакторинга.». Это даст неплохую основу для дальнейшего развития. Излагать материал буду на примере построения гипотетической системы регистрации и онбординга продавцов на некоторой торговой площадке.

После того, как я написал статью про паттерн CQRS, мне захотелось описать ещё один интересный шаблон для микросервисной архитектуры, а именно saga (он же повествование).

Будучи признанным техническим директором (CTO), имея частичную занятость в качестве технического директора в пяти разных компаниях, а также являясь бывшим техническим директором, работающим уже на полную ставку в трех разных стартапах, и, наконец, как человек, который в настоящий момент руководит агентством по разработке программного обеспечения и запускает свои собственные продукты, я могу с уверенностью сказать, что в течение первых 30 дней работы в качестве CTO у вас не будет времени на шутки.

Я расскажу вам, как извлечь максимум пользы за это время…

Весной в Технократию пришла задача: есть 1500 организаций по всей России, каждая должна уметь автоматически отслеживать активность пользователей. Организации присылают видео с площадки, а дальше дело за нами: принять, валидировать, вытащить нужные данные. Так начиналась эта история. Меня зовут Руслан Абдуллаев, я DevOps в Технократии, и сейчас расскажу, что мы с этим делали.

Привет! В следующий четверг, 9 декабря, мы проведём наш седьмой QIWI Server Party.

Обсудим оптимизацию приложений на MongoDB, поделимся опытом проведения интеграционного тестирования в условиях множества сторонних API. Кроме этого — рассмотрим проблему с распределенными транзакциями в микросервисной архитектуре и поговорим об автоматизации создания дашбордов. В этот раз — всё в формате онлайн-трансляции на нашем Youtube-канале.

Зарегистрироваться можно на этой странице.

Под катом — программа митапа.

Привет, Хабр!

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

В статье поговорим о том, как мы решили задачу с помощью алгоритмов глубокого обучения, и расскажем, что там под капотом этой функции и как мы подружили EfficientNet с FAISS. В работе над статьей мне помогал Владимир Филипенко (@vovaf709): он изложил самые основы, чтобы текст мог понять и неспециалист.

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