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

Всем привет, меня зовут Абай. Я являюсь Back-End разработчиком в 13LAB.

После прочтения интересной статьи со сравнением NodeJS и FastAPI, у меня появилось желание высказать свое личное мнение об удобстве разработки бэкенда на Python и фреймворке FastAPI.

FastAPI - является легковесным асинхронным фреймворком для Python, который используют преимущественно для разработки API-сервисов. Фреймворк довольно молодой и существует всего лишь 5 лет. До 2021 года не имел большой популярности по сравнению с Flask и Django, но на данный момент уже стал намного востребованнее, что его стали использовать в МAANG компаниях, к примеру...

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

Реализацией RPC запросов поверх брокеров сообщений никого не удивишь: очередь для запроса, очередь для ответа — ничего сложного.

Тот же RabbitMQ имеет пример в официальной документации. Других примеров там нет, поэтому создается впечатление, что отправка ответных сообщений в другую очередь — единственный возможный способ реализации RPC.

Этот сценарий отлично работает когда у нас есть непрерывный поток сообщений и непрерывный поток ответов на них. Однако, данный подход не применим в случаях, когда нам нужно отправить только одно сообщение и получить ответ именно на него. Мы сразу же попадаем в какой-то ад с фильтрацией ответов по correlation_id.

На самом деле, в RabbitMQ есть механизм и для такого сценария. Но он спрятан в недрах документации и о нем почти нет информации в интернете (особенно рабочих примеров кода).

Вот это недоразумение мы сейчас и исправим.

Обычно мы подключаем сбор метрик в prometheus к нашим web‑приложениям с помощью каких‑то клиентских библиотек, которые отдают метрики на /metrics. В этой статье я хочу рассказать как визуализировать Latency с помощью Histogram метрики.

Будет полезно тем, кто еще не строил метрики из Prometheus, а так же тем, кто хочет понять как их интерпретировать.

Хорошо быть умелым разработчиком и самому закрывать все задачи по запуску микросервисных приложений. Но как быть, если команда разработчиков тратит все время на управление микросервисными приложениями, настройку систем безопасности, аутентификации, мониторинга, логирования? Можно писать код и самостоятельно запускать каждый компонент, а можно нажать несколько кнопок и развернуть микросервис. Именно для этого мы создали консоль в платформе контейнеризации dBrain.cloud. В этой статье хотим подробнее рассказать, зачем и кому она будет полезна.

Около десяти лет назад мы в CUSTIS реализовали систему распределения товара для «Спортмастера». Со времени ее запуска изменилось многое: корректировались цели заказчика, менялись возможности и потребности рынка, появились новые способы автоматизации. Но на протяжении всех этих лет система дорабатывалась, поддерживалась и настраивалась нами, чтобы оставаться максимально удобной и эффективной для заказчика.

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

Привет, Хабр! С вами Андрей Чернов — Java-архитектор микросервисов в СберТехе.

Это третья часть материала про то, как мы развиваем Platform V SessionsData — высокопроизводительное распределённое in-memory хранилище для общего контекста сессионных запросов key-value. В первой части я рассказал, почему мы решили создать собственный микросервис, а во второй — как нам удаётся достигать высокой доступности сервиса. Сегодня поговорим о том, какие наработки помогут нам и дальше развивать Platform V SessionsData.

В этой статье будут рассмотрены инструменты наблюдения за сетевой инфраструктурой Kubernetes и основные составляющие Observability/Наблюдаемости – мониторинг, журналы событий, метрики, распределенная трассировка и оповещения. Обсудим, как эти инструменты могут помочь обеспечить надежную и эффективную работу кластеров Kubernetes и запущенных на них микросервисах, а также какие преимущества и недостатки существуют при использовании этих решений.

Эта статья для DevOps, Kubernetes administrators и SRE инженеров, которым важно и интересно разобраться в том, как устроена сетевая инфраструктура Kubernetes, какое взаимодействие происходит на уровне ядра Linux и различных приложений (Go, Java, Python и т.п.); изучить две обширные технологии eBPF и OpenTelemetry, активно продвигаемые CNCF сообществом. А главное при помощи каких инструментов можно упростить принятие решений инженерам при использовании Kubernetes в своих проектах и продуктах.

Всем привет! Продолжаем наш цикл статей о внедрении подхода Design API First на проектах нашей компании. Ранее мы рассмотрели использование этого подхода, описали плюсы и минусы, узнали, как на практике выглядит проектирование API на примере сервиса аутентификации. Сегодня расскажем о том, как мы встраиваем Design API First в наш конвейер разработки, подробно остановимся на инструментах, помогающих с технической точки зрения организовать этот процесс. Объясним, как реагировать на изменения требований и обеспечивать версионность, а также что использовать для мокирования данных. Рассмотрим различные варианты применения: для нового проекта, для существующего проекта (где изначально был Code First).

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn

Предметно-ориентированный подход (DDD, Domain-Driven Design) в проектировании программного обеспечения является наиболее эффективным способом моделирования бизнес-процессов. Сегодня мы поговорим о стратегическом и тактическом проектировании, после чего рассмотрим инструмент ускорения проектирования под названием «событийный штурм» (event storming).

Твёрдо и чётко. Это цитата из доклада Алексея Курзякова на Alfa LevelUp Day  в Екатеринбурга, где мы открыли новый IT-хаб. А это значит — самое время провести в новом офисе новый митап в новом формате с докладами и воркшопом. На двух параллельных треках провели оффлайн-воркшоп и поговорили о новых фичах, инновациях и росте: как создать фреймворк, как из мидла вырасти в тимлида, как в кратчайшие сроки создать новую фичу и не словить аварию, как в кризисных условиях создавать сервисы и как упаковывать тяжелые монолиты в удобный интерфейс.

Под катом краткая выжимка докладов, ссылки на видеозаписи и фотоотчёт.

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

Один из признанных ИТ-сообществом ответов - это, так называемый Saga паттерн. О том, что это такое, написано достаточно много, а мы займёмся его реализацией. 

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

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

Это история о том, как мое любопытство превратило небольшую задачу в настоящий квест длиной в 5 спринтов. Надеюсь, мой пример поможет вам меньше бояться подобных задач, и даст мотивацию копать глубже. А в конце статьи я расскажу, как правильно закреплять результаты, чтобы такая масштабная работа не была проделана впустую. Но сначала немножко контекста.

Привет! Сегодня поговорим про один из множества проектов, реализуемых на базе Единой информационной системы жилищного строительства ДОМ.РФ (ЕИСЖС) - конструктор государственных региональных программ поддержки. Я, главный специалист Артём Емельянов, расскажу, что это такое, какая связь между государственными региональными ипотечными программами поддержки и зачем нужен конструктор.  

Государственные региональные ипотечные программы поддержки помогают улучшить жилищные условие за счет разных льгот при покупке жилья. Они могут быть направлены на поддержку определенных категорий населения, таких как молодые семьи, ветераны, многодетные семьи, или на общую поддержку жилищного строительства и рынка недвижимости. Более детально со списком государственных региональных ипотечных программ поддержки можно ознакомиться в нашем консультационном центре ДОМ.РФ.  

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

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

Здравствуйте, меня зовут Дмитрий Марков. Я архитектор направления в Альфа-Банке. В этой статье мы поговорим об архитектуре, как ни странно. Без космических «прорывов» и «аналоговнет». Всё жизненно. 

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

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

Тут у нас с вами будет про условия/проблемы, про концептуальное решение со сменой технического стека, про аутентификацию, авторизацию, API-шлюз и, конечно же, немного про микро- и макросервисы, куда ж без них.

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