
Нагрузка на базы данных растет с каждым днем. Как быстро масштабировать ресурсы, расширять базы данных и следить за их состоянием в UI, не вникая в подкапотные движения Kubernetes? Приводим кейсы.
Микросервисная архитектура и все что с ней связано
Нагрузка на базы данных растет с каждым днем. Как быстро масштабировать ресурсы, расширять базы данных и следить за их состоянием в UI, не вникая в подкапотные движения Kubernetes? Приводим кейсы.
Привет, хабр!
Меня зовут Кирилл, и на протяжении последних двух лет я мечтал научиться проходить System Design интервью. Но только недавно взялся за дело всерьёз.
Изучив различные хранилища данных, я наконец-то смог систематизировать свои знания. И хочу поделиться этой структурой с вами, чтобы рассказать, какие бывают хранилища данных и в каких случаях их лучше всего использовать.
Мне кажется, что уже есть сотни разных статей на эту тему, но каждый раз мне чего-то не хватало. Поэтому я решил написать свою статью, в которой покажу, как я реализую авторизацию и аутентификацию в своих проектах. Это именно гайд: вы можете взять готовый код и адаптировать его под свои нужды. В рамках статьи будут использоваться Ory Hydra и Ory Kratos, Apache APISIX в качестве API Gateway и несколько микросервисов на Golang. Всё это будет работать в Docker, чтобы вы могли легко запустить и поиграться.
Kubernetes давно стал стандартом для масштабируемого управления микросервисами, но использование его возможностей не всегда так очевидно, как кажется.
В этой статье мы рассмотрим, как расширение функционала K8s с помощью пользовательских ресурсов помогает решать инфраструктурные задачи, позволяя разработчикам быстро запускать и масштабировать сервисы без лишних хлопот. Однако с этим подходом приходят и свои проблемы, такие как ограничения в хранении больших объёмов данных. Разберемся, что стоит за этими вызовами, и почему HariKube — перспективное решение для эффективного распределения данных в Kubernetes.
Проектирование и поддержка высоконагруженной платформы для букмекерской конторы almsports.net потребовало особого подхода к обеспечению стабильности, отказоустойчивости и производительности. Мы, как команда разработчиков, ставили перед собой цель обеспечить не только стабильную работу, но и гибкость для масштабирования, отвечая на растущий трафик. В этом посте я поделюсь опытом того, как с использованием DevOps практик и CI/CD процессов мы смогли достичь 99.99% аптайма и эффективно обслуживать миллионы запросов в день на платформе almsports.
Привет, хабровчане! Я Алиса, тимлид в e-commerce агентстве KISLOROD.
Сегодня расскажу, как мы вырвались из цепких лап монолита с помощью Headless и API-First архитектуры, ускорили разработку и дали бизнесу крылья. Это не просто про технологии, а про то, как не сойти с ума от бесконечных правок и при этом ускорить запуск фич. Мы все еще на PHP, под капотом Bitrix, но перестали латать шаблоны и начали строить настоящую платформу. Погнали разбираться: что это, зачем и как не облажаться.
Расскажу про Python-библиотеку для гибкого чтения конфигураций с возможность переиспользования и переопределения элементов
Я ненавижу руками создавать бойлерплейты. Любые. Нет, LLM-ки тут тоже не помогут: им надо писать промпты (а потом ещё проверять, что оно там нагенерировало). Мне всегда хотелось, чтобы остов приложения задавался конфигурацией, а я бы только добавлял бизнес-логику. Буквально, в уже сгенерированные для неё места.
Именно в такой парадигме написана моя библиотека finitomata, в которой конфигурация конечных автоматов задаётся текстовым представлением (PlantUML/Mermaid), а бизнес-логика просто распихивается по колбэкам переходов. Но мне этого оказалось мало, и я решил обернуть в такие же абстракции хранение и подписку на изменения.
Так родилась библиотека (пока не опубликована, доступна только в исходниках) persistomata
.
Микросервисы перевернули игру в разработке приложений. Они сулят гибкость, отличную масштабируемость, командам — больше независимости. Но вот переход на них принес с собой и новые головные боли. Особенно когда дело доходит до развертывания. Управлять кучей мелких, отдельно выкатываемых кусочков — задачка та еще. Старые приемы тут часто пасуют. Нужны свежие идеи, другие инструменты, а главное — по‑другому смотреть на вещи.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
Привет, Хабр! Я Иван Попов, ведущий инженер ЦК платформенных и интеграционных решений РСХБ-Интех. Java — мой самый любимый язык программирования, я всю жизнь работал только на нём. Сейчас я работаю в банке и хочу разрушить стереотип о том, что в банках все работают на Vegas. На java мы очень много работаем, тем более если видим, что новая технология позволяет нам оптимизировать процессы разработки (а количество интеграций огромное).
Расскажу о новой фиче виртуальных потоков в Java 21, которая призвана повысить эффективность многопоточного кода.
Как обеспечить эффективное разделение ресурсов и зон ответственности в крупном проекте? Как гарантировать, что каждое подразделение имеет собственные настройки и не зависит от сбоев в других частях системы? Ответ - мультитенантность. В этой статье мы расскажем, как реализовали такой подход в платформе контейнеризации dBrain.cloud, какие преимущества это дало и почему мы отказались от готовых решений.
Привет, Хабр! Меня зовут Евгений Кермас, я главный эксперт по технологиям в Управлении развития технологий модельного риска в Сбере.
В этой статье я попробую ответить на вопрос: «Что делать, если вы, как архитектор, пришли на существующий проблемный проект в качестве кризисного-менеджера?» Расскажу о нескольких подходах и дам советы, которые могут помочь в принятии решений в создании архитектуры и планировании проекта. Для этого разберём один пример с максимальным количеством проблем. На входе у нас есть монолит с запутанным кодом, на legacy-инфраструктуре, с нецелевым техстеком и большим грузом проблем, как технологических, так и организационных.
В настоящее время резко возрос спрос на контейнеры, используемые в продакшене для эксплуатации больших энтерпрайз-приложений. Как правило, они развёртываются в Docker. Docker де-факто стал основной технологией для работы с контейнеризованными приложениями. Но на основе чего он построен? Как он контейнеризует приложения? В данной статье постараемся ответить на эти вопросы.
Приложения тормозят. Пользователи уходят. Бизнес недоволен. Знакомая картина? Часто корень зла – медленный доступ к данным. Кеширование может стать спасательным кругом. Но это не серебряная пуля. Неправильно настроенный кеш – источник новых проблем, иногда похуже старых.
Привет, Хабр! Меня зовут Дмитрий Ханин, я работаю в Сбере и участвую в разработке Платформы ЦА — системы на базе блокчейн, занимающейся привлечением средств юридических и физических лиц. Сегодня хотелось бы рассказать про тот путь, который мы прошли за несколько лет, как организовали взаимодействие между разными приложениями и чем нам это помогло.
Рассказ разделён на две части. В первой рассмотрим путь проекта и проблемы, с которыми сталкивались, а во второй разберём, как мы решали часть этих проблем.
Привет! Меня зовут Геннадий, я руковожу командой разработки системы учета товаров в Ozon. Мы активно используем Kafka как основной инструмент для асинхронного взаимодействия между нашими сервисами. Для нас Kafka — это не просто очередь сообщений, а один из ключевых компонентов всей архитектуры. Поэтому мы постоянно погружаемся в его тонкости и нюансы, чтобы грамотно настраивать и использовать его возможности. Думаю, многие из вас сталкиваются с тем же — когда Kafka становится критически важной частью вашего решения.
Хотя информации о ребалансировке Kafka достаточно, она часто либо слишком разрозненная и техническая, либо наоборот — поверхностная и без акцента на важные детали. Я собрал для вас самое важное и объясню это простым и понятным языком.
Привет, меня зовут Александр. Я более двух лет работаю backend разработчиком над микросервисами компании. Микросервисная архитектура стала очень популярной в больших проектах, ее используют большинство команд на разном стеке технологий. Сегодня разберемся как наша команда создает высоконагруженные сервисы с процентом надежности и устойчивости стремительно приближающимся к 99,99.