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

Хорошо быть умелым разработчиком и самому закрывать все задачи по запуску микросервисных приложений. Но как быть, если команда разработчиков тратит все время на управление микросервисными приложениями, настройку систем безопасности, аутентификации, мониторинга, логирования? Можно писать код и самостоятельно запускать каждый компонент, а можно нажать несколько кнопок и развернуть микросервис. Именно для этого мы создали консоль в платформе контейнеризации 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-шлюз и, конечно же, немного про микро- и макросервисы, куда ж без них.

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

За окном 2023 год, а среди разработчиков только и разговоров, что про микросервисы да API First. Несмотря на то, что эти темы не новы, похоже, что их актуальность даже набирает обороты.

Про микросервисы уже много написано и теоретического и практического. Есть у этого подхода и свои евангелисты (Microservice Architecture) :) В целом это тема достаточно холиварная, особенно при крайних точках зрения. Сегодня мы ее отложим, но обязательно вернемся в контексте темы этой статьи. Конечно, это будет не менее обсуждаемая история, посвященная методологии API First и программным интерфейсам (прежде всего, web, но не только) при проектировании и разработке современных информационных систем :)

Меня зовут Антон, я руководитель Архитектурного комитета в компании SimbirSoft. Мы используем подход API First для проектов самой разной направленности, где есть несколько команд разработки (как минимум Backend и Frontend), а также при высокой неопределенности на этапе реализации (быстроменяющиеся требования и цели, параллельные процессы проектирования и реализации, высокие запросы к TTM и так далее).

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

Этот материал открывает цикл статей, посвященных практическому внедрению методологии API First в разработку наших команд. Если быть точным, то мы отдаем предпочтение «младшему брату» API First, практикующему  проектирование (design), — известному как Design API First. Чтобы избежать путаницы, далее термин «API First» будет обозначать подход к разработке ПО, а термины «Design API First» и «Design First» – проектирование ПО в рамках подхода API First.

2 часть: Как мы внедряли Design API First. Показываем на примере сервиса аутентификации

3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт

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

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

Привет, с вами команда разработки dBrain.cloud! Хотим поделиться историей миграции с Elasticsearch Beats Kibana (EBK) на Grafana Loki. Предпосылок перехода было немало: замена EBK лицензии Apache 2.0 на ограниченную SSPL 1.0, растущее потребление ресурсов, объемы требуемого места в хранилище и др. Сегодня покажем, как из грамотно подобранных и поселенных под одной крышей продуктов получилось собрать единый стек логирования и мониторинга.

В данной статье будет описано, как создать простой kafka producer и kafka consumer, а затем протестировать их.

Уверен, что многие, кто интересовался подходами к разработке микросервисной архитектуры, знакомы с трудами Криса Ричардсона на эту тему и уже встречали transactional outbox pattern. А для тех, кто не знаком, кратко расскажу основную идею:

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

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

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