User
Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.
Код доступен для ознакомления на гитхабе. Образы опубликованы на докерхабе, весь зоопарк стартует одной командой.
Привет, Хабр!
Каждая секунда простоя может стоить компании целое состояние, важно иметь надежные механизмы защиты от сбоев. Здесь и приходит на помощь паттерн Circuit Breaker.
Представьте себе обычный автоматический выключатель в вашем доме. Когда происходит перегрузка, он "выбивается", предотвращая возможные повреждения. Точно так же работает и Circuit Breaker в микросервисах. Он мониторит вызовы к внешнему сервису и при обнаружении слишком большого количества неудачных попыток временно "отключает" вызов, предотвращая тем самым падение всей системы.
Этот паттерн основывается на трех основных состояниях: закрытое, открытое и полуоткрытое.
Моя любимая рубрика — «статьи со дна Хабра». Это когда человек вроде бы хотел поделиться болью, но случайно выставил на обозрение своё эго. Недавняя статья «В айти нет денег и повышений» — как раз из таких. Автор переборщил с надрывом и слегка обижен на мир. Поэтому и отхватил. Но посыл был хороший — и меня статья зацепила.
Если коротко:
Автор работает в IT с 18 лет. Сейчас ему 24. И он пишет, как несправедлив этот мир, потому что его потолок — 400k. Видимо, за умение слепить форму или написать CRUD’ы должны платить миллионы.
Он жалуется, что ему ни разу в жизни не давали повышения. Утверждает, что это бывает только в фантастических рассказах. При этом он сменил 7 компаний — то есть в каждой работает в среднем меньше года. Удивительно, почему его не хотят закидывать деньгами.
Итог статьи и её автора — печален. Мы наблюдали нелепый акт самовыпила с Хабра. Сначала автор улетел в минуса, потом в read-only. После чего создал второй аккаунт, чтобы в последний путь бряцнуть своим дипломом бакалавра.
Перевод статьи Ben Burwell, инженера FlightAware, в которой описан довольно солидный список ложных предположений, которые программист может выдвинуть об авиации при разработке софта. Например, вы знали, что бывают сегменты в авиаперелетах, которые длятся одну минуту, чтобы переместиться из одного аэропорта в другой, хотя физически самолет никуда не летит? А вот инженерам из авиа-отросли такие уникальные случаи нужно учитывать.
У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырех языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жесткие требования по latency, тонна SLA и желание сделать гибкую систему аутентификации и авторизации для сервисов. Не то, чтобы все это было категорически необходимо для начала этой истории, но если уж начал рассказывать про асинхронные взаимодействия, то иди в этом до конца.
Единственное, что меня беспокоило — это авторизация. В мире нет ничего более желанного для ИБ и ненавистного разработчиками, чем контроль доступа. И я знал, что довольно скоро мы доберёмся и до этого вопроса.
Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».
Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».
Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.
Привет, Хабр! Меня зовут Иван Глинкин, я занимаюсь инфраструктурным тестированием и аппаратным хакингом в Бастионе. Недавно наткнулся на интересное предложение на российских маркетплейсах — роутеры с предустановленным «пожизненным» VPN. Звучит заманчиво: купил, включил и сразу получаешь безлимитный доступ к виртуальной частной сети, причем без подписки.
Но как говорится, бесплатный сыр бывает только в мышеловке. Я решил разобраться, что на самом деле скрывается за красивыми обещаниями продавцов. Приобрел три роутера из разных ценовых категорий — от бюджетного Cudy за 3000 рублей до топового Xiaomi за 7000. Спойлер: если вы ожидали хеппи-энд, то вы зашли не в тот блог.
В процессе исследования обнаружил несегментированные сети, где можно получить доступ к устройствам других покупателей, пароли admin:admin, хранящиеся в открытом виде, и SSH-доступ для продавцов. А еще выяснил, что «пожизненные» серверы работают на дешевом хостинге за 2,5 доллара.
В этой статье расскажу, какие угрозы скрываются за яркой рекламой и почему экономия на сетевой безопасности может обойтись слишком дорого.
Моим первым языком программирования был ActionScript. Написание кода для Macromedia Flash максимально далеко от голого железа, и эта специфика работы глубоко засела в моём сознании. В результате меня интересовали преимущественно высокоуровневые языки для веб-программирования. Низкоуровневые же казались непостижимыми. Со временем я постепенно из разных источников узнавал о них всё больше, но это моё убеждение оставалось прежним. Низкоуровневые языки пугают, и машинный код подтверждал это наглядно. Когда я обращался к Google с запросом «понятный машинный код», то результат выдачи чаще представлял нечто пугающее и отталкивающее, нежели полезное для обучения.
В конечном итоге я решил, что для достижения поставленных целей мне этот страх необходимо преодолеть. И результат приложенных усилий оказался для меня неожиданным.
Машинный код вовсе не страшен. Если вы можете обеспечить, чтобы документ JSON соответствовал схеме JSON, то без проблем сможете писать машинный код.
Многие помнят позапрошлогодний инцидент с Man-in-the-Middle атакой на XMPP-сервис jabber.ru. Эта история наделала много шума, но, как мне кажется, главный вывод из неё так и не был усвоен широкой аудиторией. А зря. Потому что эта атака вскрыла системную уязвимость в процессе выдачи TLS сертификатов, которая напрямую касается миллионов сайтов, особенно тех, кто доверяет свою безопасность Cloudflare.
В этой статье я расскажу вам о самой уязвимости и как вы можете быть ей подвержены.
Глава 1: мой коллега, программист
Пустая оболочка человека. Он больше похож на попугая, чем на личность. Мой начальник, искренне верящий в священнодействие Парного Программирования, сковал цепью меня и этого коллегу-«программиста», как сиамских близнецов с разных планет. Общей была наша клавиатура, но не мышление. Боже, как же он был далёк от этого.
«Постой-ка. У меня появилась идея. Дай мне клавиатуру.»
Идея. Ага. Как у младенца появляется «идея» засунуть вилку в розетку. Я почти доделал нечто прекрасное; стройную, изящную логику, пронзающую сложность подобно ножу, режущему масло. И тут появился он — бьёт по клавиатуре, как будто она ему деньги должна, копипастит код-франкенштейн из комментария на StackOverflow, написанный последователем Дяди Боба в 2014 году.
Знает ли он, что делает наша система? Нет.
Прочитал ли он тикет? Разумеется, нет.
Ощущает ли он уверенность, когда безрассудно корёжит глобальное состояние? Разумеется, да.
Итак, вы решили использовать Angie как замену Nginx. С чего начать процесс? Какие аспекты нужно учитывать при переходе? Разберёмся со всем по порядку.
Напомню, что Angie является форком Nginx. Это значительно упрощает процесс переезда с Nginx на Angie, так как Angie поддерживает все возможности и директивы конфигурации, что и Nginx. Обратный переход с Angie на Nginx может быть уже не таким простым, если мы начинаем использовать уникальные возможности Angie (например, возможности проксирования или балансировки).
Начнём с подготовки системы к миграции.
Приветствую, дорогой читатель!
С момента появления в нашем любимом веб-сервере Angie замечательной функции ACME-челленджа через DNS прошло уже достаточно времени, чтобы оценить все преимущества этого решения. Эта поистине революционная фича подарила нам долгожданную возможность получать wildcard‑сертификаты буквально в несколько кликов.
Однако, как это часто бывает с новыми технологиями, до сих пор у многих пользователей, особенно только начинающих свое знакомство с Angie, возникают вполне закономерные вопросы вроде: «Как правильно это настроить?» или «Как это вообще работает под капотом?». Именно для таких случаев, дорогие друзья, и была задумана эта подробная статья — максимально простыми и понятными словами описать весь процесс настройки от начала и до конца.
Если вы всё ещё используете IP-геолокацию для выбора отображаемого языка, то хватит заниматься ерундой. Это ошибочное допущение, замаскированное под фичу.
IP сообщает, откуда пришёл запрос, и на этом всё. Он не сообщает, какой язык нужен пользователю, на каком языке он говорит и какой язык понимает. Подобная система постоянно ломается — VPN, путешествия, эмиграция, страны с несколькими официальными языками. Это не умное, а раздражающее решение.
Салют, Хабр! Я думаю, каждый из вас знаком или, по крайней мере, слышал о такой прекрасной утилите как GoodbyeDPI (большое спасибо @ValdikSS!). Сегодня я хочу представить вам (почти) свою разработку - аналог GoodbyeDPI.
Около полугода назад в своей статье Обвиваем YouTube змеем, или как смотреть и скачивать видео с YouTube без VPN на чистом Python-е. Часть 1 (заблокирована по требованию РКН) я рассказывал о том, как скачивать видео с YouTube на Python, а так как YouTube у нас "деградировал", я поделился инструментом, с помощью которого можно исправить этот вопиющий недостаток. Инструмент тогда выглядел достаточно сыро, и несмотря на то, что он выполнял свою задачу, требовал серьезных улучшений. Увидев интерес общественности, я решил допилить его, и вот, спустя полгода, после немалой работы, я рад представить вам NoDPI - проект, который явно не понравится РКН (и он опять меня заблокирует).
В этой статье я хочу рассказать о его возможностях, внутреннем устройстве, отличии от аналогов. Надеюсь, статья будет вам полезна и интересна. Поехали!
Много было сказано про Serverless в нагрузках без сохранения состояния. Действительно, когда у вас есть контейнеры или функции их легко почти мгновенно масштабировать и нет большой разницы, на какой именно машине это делать.
Но данные имеют очень конкретную привязку к диску, на котором размещены. Что создает немало сложностей к самой концепции бессерверных вычислений.
В этой статье я хочу показать, где бессерверная архитектура может быть применима, и рассмотрю несколько новых, и весьма перспективных решений в этой области, таких как Neon, Warpstream и TiDB.
После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.
Архитектура программного обеспечения — основа, от которой зависят качество, производительность и масштабируемость систем. В статье шаблон от экспертов в области архитектуры программного обеспечения с типовыми описаниями и примерами архитектурных представлений. Шаблон доступен для скачивания.
Ещё пару лет назад вопрос «Какой ChatGPT лучше?» сводился к простому выбору: что за версию использовать — «тройку» или «четвёрку»? Теперь всё сложнее, и не всегда с ходу понятно, чем одна модель отличается от другой. OpenAI больше не делает ставку на одну универсальную, а предлагает линейки моделей, где каждая специализируется на чём‑то своём: одни лучше рассуждают, другими удобнее писать код, третьи идеально подходят для повседневных задач (генераций и др.).
В этом обзоре я расскажу, какая модель ChatGPT лучше для своих областей, то есть как выбрать ту, которая будет решать вашу задачу лучше остальных. Спойлер: для разных предназначений мы выберем всего три‑четыре модели, чтобы закрыть максимальное число вопросов наиболее способными нейросетями.