Всем привет! Меня зовут Николай Первухин, я 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 Михаил Чугунов.
Из этой статьи даже начинающий разработчик поймёт, что такое микросервисы и в каких ситуациях они применяются. Денис и Михаил постарались ответить на все вопросы максимально доступным языком. Мы выделили несколько категорий вопросов:
Заранее обрадуем жаждущих именно услышать специалистов: каждый вопрос сопровождается ссылкой с вшитым тайм-кодом, так что долго искать ответы в записи вебкаста не придётся.
Хороший вопрос требует хорошего ответа. Приступим.
Микросервисы сейчас — это новый черный. Все больше и больше компаний переходят именно на микросервисную архитектуру. И при переходе ловят самые разные ошибки. Самая популярная происходит из-за того, что люди просто не готовы к тому, что их приложения начинают активно использовать сеть. Потому что IPC и RPC-запросы — это абсолютно разные вещи.
Я техлид в команде Авито в проекте SLA. Сегодня расскажу, как мы оптимизировали сетевые вызовы, чтобы избежать проблем с сетью при переходе в микросервисный мир. Разговор будет про оптимизацию CURL-запросов, деградацию сервисов и FAIL-FAST-подходы.
Доброго времени суток! Для начала, о чем будет статья? Статья является сжатым описанием опыта перехода от монолитного приложения к микросервисам. Коснемся плюсов такого перехода и затронем часть проблем, с которыми можно столкнуться в реальной разработке. Для кого может быть полезна статья? Для тех кто по каким-то причинам еще сомневается в эффективности микросервисных архитектур. Также отмечу, что статья не является учебным пособием. Она ставит целью коротко познакомить с практикой перехода от одной архитектуры к другой. Для тех кто хочет погрузиться в детали проектирования микросервисных архитектур, рекомендую почитать литературу, начать можно с книги Криса Ричардсона «Микросервисы. Паттерны разработки и рефакторинга.». Это даст неплохую основу для дальнейшего развития. Излагать материал буду на примере построения гипотетической системы регистрации и онбординга продавцов на некоторой торговой площадке.
После того, как я написал статью про паттерн CQRS, мне захотелось описать ещё один интересный шаблон для микросервисной архитектуры, а именно saga (он же повествование).
Будучи признанным техническим директором (CTO), имея частичную занятость в качестве технического директора в пяти разных компаниях, а также являясь бывшим техническим директором, работающим уже на полную ставку в трех разных стартапах, и, наконец, как человек, который в настоящий момент руководит агентством по разработке программного обеспечения и запускает свои собственные продукты, я могу с уверенностью сказать, что в течение первых 30 дней работы в качестве CTO у вас не будет времени на шутки.
Я расскажу вам, как извлечь максимум пользы за это время…
Весной в Технократию пришла задача: есть 1500 организаций по всей России, каждая должна уметь автоматически отслеживать активность пользователей. Организации присылают видео с площадки, а дальше дело за нами: принять, валидировать, вытащить нужные данные. Так начиналась эта история. Меня зовут Руслан Абдуллаев, я DevOps в Технократии, и сейчас расскажу, что мы с этим делали.
Привет! В следующий четверг, 9 декабря, мы проведём наш седьмой QIWI Server Party.
Обсудим оптимизацию приложений на MongoDB, поделимся опытом проведения интеграционного тестирования в условиях множества сторонних API. Кроме этого — рассмотрим проблему с распределенными транзакциями в микросервисной архитектуре и поговорим об автоматизации создания дашбордов. В этот раз — всё в формате онлайн-трансляции на нашем Youtube-канале.
Зарегистрироваться можно на этой странице.
Под катом — программа митапа.
Привет, Хабр!
Меня зовут Александр Красных, я тимлид команды ранжирования и рекомендаций в Циан. Мы сделали фичу, которая позволяет найти по фото похожие квартиры. Для этого нужно уметь быстро находить среди миллионов фотографий изображения, визуально похожие по стилю на входную картинку-запрос.
В статье поговорим о том, как мы решили задачу с помощью алгоритмов глубокого обучения, и расскажем, что там под капотом этой функции и как мы подружили EfficientNet с FAISS. В работе над статьей мне помогал Владимир Филипенко (@vovaf709): он изложил самые основы, чтобы текст мог понять и неспециалист.
Marlin – корпоративный архитектурный репозиторий и система автоматизации процессов жизненного цикла программного обеспечения, которая может сэкономить сотни часов менеджерам проектов и команде разработчиков. Под катом подробное описание процесса сборки, развертывания и тестирования приложения, а также создания зависимостей между другими корпоративными системами.
Привет! Меня зовут Алина, я работаю техническим писателем в компании Quadcode. В этой статье хочу поделиться опытом верхнеуровневого описания архитектуры системы с использованием структуры C4. Небольшая оговорка: предпринятые шаги включают в себя определенные отходы от канонической нотации в угоду удобству и особенностям системы.
Для справки:
HLD (high-level design) – верхнеуровневое описание архитектуры системы, где представлены основные компоненты и их взаимодействия.
LLD (low-level design) – низкоуровневое детальное описание каждого из компонентов системы.
Переходим к докладам по backend с IT-конференции ЮMoneyDay.
Первый кейс о том, как мы внедряли Contract-First. Описали процесс перехода от Сode-First к написанию OpenAPI-спецификаций и генерации кода по ним.
Во втором кейсе разбираем анатомию центра авторизаций. Рассказали, как организовать разработку и поддержку множества критичных процессов и спокойно спать по ночам.
Привет! Меня зовут Иван, я занимаюсь бэкенд-разработкой в Ozon: пишу микросервисы на Go для личного кабинета продавца. В прошлом году мы запустили новый процесс регистрации продавцов, в котором задействовано сразу несколько микросервисов. В нём стало больше шагов, при этом каждый из них выполняется в разных микросервисах. Поэтому мы задались вопросом: «А что будет, если один из шагов упадёт?».
В микросервисной архитектуре давно известен инструмент решения подобных проблем — это паттерн Saga. Мы решили взять его на вооружение и немного упростить под нашу задачу. Я расскажу о том, как мы это сделали, и покажу, что Saga может быть простой. Так что если вы давно хотели попробовать реализовать Saga, но вам казалось, что это сложно — читайте дальше.
Проектирование и работа с REST-сервисами стали повседневными задачами для многих аналитиков. Однако мы часто встречаемся на работе с различными или даже противоречащими друг другу трактовками таких понятий, как REST, RESTful-сервис, RESTAPI.
Сегодня мы разберём, какие принципы вложил в парадигму REST её автор и как они могут помочь нам при проектировании систем.
Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.
Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.
Эта статья является переводом материала «Untangling Microservices, or Balancing Complexity in Distributed Systems».
Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].
Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?
В этом посте я хочу ответить на эти вопросы. Вы узнаете об общих проблемах проектирования, которые превращают микросервисы в распределенные большие комки грязи (distributed big balls of mud), и, конечно же, о том, как их избежать.
