Проектирование и рефакторинг *

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

Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

Здравствуйте.

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

Первая часть этой истории находится тут. Там можно почерпнуть некоторую информацию о том, что из себя представляет описываемая мной система.  Хотя бы в части устройства базы данных.  А база это наше все!

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

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

Статья — технический разбор моей попытки построить сеть каналов‑барахолок в Telegram, которая включала бы в себя все объявления уже существующих и устранила фактор хаоса (спам, коммерция, мусорные сообщения). А так же поверх — бота с подпиской на объявления по ключевыем словам.

Представьте, что ваша компания — это город. Сначала это посёлок с одной улицей, где все знают друг друга и работают сообща. Но когда посёлок превращается в мегаполис, старые правила перестают работать: дороги забиты, свет отключается, а жители бунтуют. То же происходит с IT-платформами: на старте монолит кажется простым решением, но с ростом он душит развитие. Team Topologies предлагает альтернативу — превратить платформу в сеть «умных посёлков», где каждый сервис развивается автономно, но по общим правилам. В статье разберём базу как это работает и посмотрим на примере реальной компаний. 

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

Теорема CAP (дословно: Consistency (согласованность), Availability (доступность), Partition Tolerance (устойчивость к разделению)), предложенная Эриком Брюером в 2000 году, объясняет, почему невозможно одновременно обеспечить все три этих свойства.

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

Да, многие могут сказать, что это больше стезя архитектора. Но грань между аналитиком и архитектором в текущих реалиях очень смазана. Хороший системный аналитик фактически является lite версией архитектора. Поэтому щас выскажусь!)))

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

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

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

Здравствуйте.

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

Хочу рассказать об одной самописной системе, которую мы используем уже очень давно. И о ее развитии (в другой статье).

Что станет с вашим замечательным проектом в перспективе, если построить его на чужих технологиях? Многие подозревают, некоторые догадываются а я рассказываю. Из первых рук и на личном опыте.

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

В течение последнего полугода команда Discord по обслуживанию медиа-инфраструктуры модернизировала конвейер обработки изображений, добавив поддержку анимированных форматов WebP и AVIF. Теперь на платформе можно делиться анимированными картинками WebP и AVIF как в виде прикреплённых файлов, так и в виде вставок. При этом все эмодзи выдаются в виде анимированных WebP — и бесшовно отображаются на любой платформе Discord. Эти изменения были реализованы для того, чтобы повысить качество анимации и воспроизведения роликов на всех платформах. При этом одновременно резко уменьшается размер файлов, и поэтому их загрузка ускоряется!

Любой программист, вне зависимости от уровня, когда‑то сталкивался с этим. Ты садишься за проект, полный планов и идей, предвкушаешь, как создашь нечто совершенное, но... проходит час, второй, а на экране только десяток папок, пара заглушек и файл README.md. И вот уже начинаешь возвращаться к документации в поисках «правильной» структуры проекта или подсматриваешь, как сделали другие.

Примерно то же самое происходит, когда ты работаешь в команде: собрания перетекают в бесконечное обсуждение архитектуры, абстракций и фреймворков. Идеи летят кометами, все соглашаются, что «всё должно быть как надо», но реальная работа — застопорилась. Потому что команда вместе с тобой подсознательно ждет чего‑то: идеального старта.

Синдром идеального старта — не просто миф, а настоящая преграда для продуктивной разработки. В этой статье мы поговорим о том, почему ждать «идеальности» — значит тормозить, как такой подход мешает развитию, и что с этим можно сделать.

Зачем мы ждём идеального старта?

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

Проблема в том, что идеальное, как правило, недостижимо. Вот почему:

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

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

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

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

Сегодня я хотел бы рассказать о том, как можно реализовать оптимистичную блокировку в Hibernate если вы используете DDD, а точнее агрегаты. Если кто-то не в курсе что такое оптимистичная блокировка, то советую сначала почитать это. 

Проблема:

Думаю, многим известно что, в целом, реализация оптимистичной блокировки в Hibernate проще некуда - всё что нужно сделать это добавить поле version с аннотацией @Version в вашу энтити. Bот так:

Вы задумали создать платформу, но не знаете, с чего начать? Сегодня «платформой» называют всё — от облачных сервисов до экосистем вроде Apple. Но чтобы не потратить годы и миллионы впустую, важно выбрать тип, который решит ваши задачи, а не будет данью моде. Как не запутаться? Давайте разберёмся.

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

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

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

Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎

У вас никогда не вызывало недоумения, что связанность и прочность (или связность) — это про примерно одно и то же (и то, и другое — это некая связь), но одно — хорошо, а другое — почему-то плохо? 🙂
Но давайте по порядку.

Всем привет! Меня зовут Кирилл Якименко, я – BIM-эксперт компании КРОК, работаю с BIM-технологиями уже около 6 лет, входил даже в клуб Autodesk Expert Elite. В КРОК я занимаюсь тем, что внедряю BIM технологии, развиваю и поддерживаю их применение.

Сегодня я вам расскажу о том, какой путь прошел КРОК в эволюции автоматизации процессов в Revit, как большой и тяжелый проект нам помогал в этом, а не мешал.

Один из самых вредоносных принципов в разработке, когда-либо получивших широкую известность — YAGNI. Его озвучил Рон Джеффрис в 1998, а спустя более двадцати лет — еще и Кармак подлил керосин в огонь со своим: «Неопытным разработчикам трудно оценить, как редко разработка архитектуры с учетом будущих требований приводит к успеху».

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

— Давай предусмотрим передачу конфигурационных параметров в эту функцию? — YAGNI.
— Инъекция зависимости здесь уместнее приколоченной гвоздями реализации хранилища. — YAGNI.
— Черный кофе без сахара, пожалуйста. — YAGNI!