Классная мини книга про вебсокеты.

• История и проблематика
• Детали работы протокола
• Масштабирование и отказоустойчивость

#интеграция

#интеграция #архитектура

На фоне стабильной тенденции к переходу из аналитиков в архитектуру не менее стабильно возникает вопрос: “А как это делать вообще?”

Есть минимум два варианта:

— закопаться в книгах по архитектуре и штурмовать вакансии архитектора

— понять, что уже есть для нужной роли, и постепенно двигаться к ней, отбирая у кого-нибудь подходящие задачи

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

Сначала копнем в работу сетей и инфры, чтобы понять влияние на выбор технологий. Здесь же разберемся, как и почему работает балансировка. Дальше начинаем думать о надежности, и учимся использовать circuit breaker’ы, адаптивные ретраи и другие паттерны отказоустойчивости. Где-то рядом придется задуматься о производительности и кэшировании, а там и выборе технологии под кэш. А потом потребуют развесистый бизнес-процесс реализовать на несколько сервисов, и вот вам проектирование распределенной системы с транзакциями.

Таким образом получаем трек: локальные интеграции -> интеграционная архитектура -> полноценный сисдизайн. Останется еще с хранилищами попрактиковаться.

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

#интеграция

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

Рега тут

Эти выхи буду на WAW. Кто еще там? Го чай пить и знакомиться.
А завтра утром веду воркшоп по сисдизайну - заходите, чтобы посмотреть, чем мы в нашей архсекте занимаемся.

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

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

Категорически рекомендую как нанимающим лидам, так и кандидатам.

У меня лишь один вопрос остался: если вот это все делает аналитик, то чем вообще занимается разработка?

WAW 2025

На выхах добрался до WAW, который оставил неожиданно приятные впечатления. За счет небольших размеров получилось очень лампово и душевно, было время обсудить интересное. Только 1,5 дня мало((

Выделялись три основных темы: сисдизайн, лидерско-манагерское, AI. Трек сисдизайна получился особо удачно, спасибо Ане Вичуговой, Зое Степчевой и скромному мне. Надеюсь, никого не упустил?

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

Я же делал воркшоп по сисдизайну, где разбирали кейс доставки карты в сокращенном виде. Прошло бодро и активно, 5 из 6 команд дошли до конца, все довели решение до рабочей версии.

Несколько закономерностей, которые заметил еще в рамках нашего кейс-клуба:

Реализация НФТ
Характерное поведение аналитика: определить требования к нагрузке, доступности, масштабированию… и забыть про них. Не происходит валидации, как мы реализовали требования на уровне архитектуры, основное внимание уделяется бизнес сценариям. Не надо так;)

Легаси системы
Когда мы используем существующий ландшафт (т.е. почти всегда), нужно не забыть про характеристики и ограничения легаси систем. Иначе весь наш хайлоад рассыпется на какой-нибудь вендорской коробке.

Масштабирование
Нагруженные сервисы, стоит запускать в нескольких экземплярах. Если нет данных, чтобы оценить нагрузку и ресурсы, можно начинать с двух в качестве дефолтного варианта. Дальше будем смотреть, сколько нужно добавить. Ну и не забыть о балансировке.

На другие секции удалось только мельком заглянуть, ничего конкретного не скажу.
Спасибо оргам и всем участникам за конфу, встретимся через год ❤‍🔥

#конференции

Отправка событий от бека к фронту

Лень монтажить вебинар, пока вынесу с него интересный вопрос:

- Если WebSockets, HTTP/2, SSE позволяют слать сообщения с бека на фронт, то почему в основном говорят о WebSockets для двухстороннего взаимодействия?

Server Sent Events
Чтобы получать события с сервера клиент кидает GET-запрос с указанием в заголовках, что хочет сохранить соединение и получать события. Если сервер так умеет, то создается длительное соединение, и он начинает слать сообщения клиенту, пока кто-нибудь соединение не закроет.
Работает SSE поверх HTTP/1.1 и выше.

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

Если честно, я даже не знаком с людьми, которые использовали SSE. Нашел пару примеров:
⁃ В SuperJob их юзают просто чтобы не заморачиваться, как я понял.
⁃ Тут их используют для реализации subnoscriptions в GraphQL. Ну ок, есть логика

У вас был такой опыт? Поделитесь в комментах, плз.

HTTP/2
Взаимодействия между клиентам и сервером делятся на стримы. Каждый стрим состоит из одного request-сообщения и одного response-сообщения. Каждое сообщение может состоять из одного и более фреймов.

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

Получается, что внутри стрима мы можем слать фреймы в двух направлениях. НО - создать стрим может только клиент. Т.е. парадигма request-response в протоколе сохраняется.

В теории так сделать можно, но разрабы нас за это сожгут, так мы предлагаем ручками лезть в потроха протокола. Так можно и сразу с TCP напрямую работать. Или кто-нибудь знает готовые либы под это?

На практике проще сразу брать gRPC, который использует эту механику. Но это новый стек, новые проблемы.
Либо заюзать те же SSE.

Почитать: Хардкорный разбор HTTP/2

WebSockets
Полнодуплексный протокол, в котором мы устанавливаем соединение, клиент кидает GET запрос с нужными заголовками и вместе с сервером переключается на общение поверх вебсокетов. Клиент и сервер могут в произвольном порядке слать друг другу сообщения, пока кто-нибудь не закроет соединение
Работает поверх TCP.

Позволяет слать события только в обе стороны: сервер <—> клиент.
Сложнее в реализации, чем SSE, т.к. многие не умеют его готовить, нужно затаскивать новый протокол и тулинг в проект.

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

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

#интеграция

#манагерское

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

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

Как продакту, мне интересно делать идеальные продукты с совершенным UX и мегафичами, кастдевить пользователей и получать восторженный фидбек. И чтобы все было аналитикой обвешано - тестить дерзкие гипотезы и дизраптить рынок. Потому что это мегакруто. Правда еще выручку растить нужно, и чтобы экономика сходилась, иначе инвесторы денег не дадут. А тут эти технари с нытьем про техдолг и костыли.

Как предприниматель (у мен одного ощущение, что слово “бизнесмен” сейчас воспринимают как пошлый атавизм из 90х?) в гробу я видал всю эту вашу итшечку и смузи-фичи. Каждое утро я просыпаюсь и думаю, как бы вообще ничего не делать и побольше заработать. Вчера продал пару новых проектов крупным партнерам и собрал концепт нового стратегического направления. Нужно быстро запустить все за пару недель, максимум месяц. В смысле, какой проект важнее? Все важно, они издеваются что ли?! Даже сроки внятные назвать не могут.

Ну и что?
Чтобы заниматься наиболее интересными для себя вещами, придется понять и принять интересы других. И будет это ой как непросто. А задача манагера на разных уровнях - развивать это принятие и понимание в обе стороны.

#архитектура

Есть академические штуки, о которых много говорят, но непонятно, как их применять на практике.

Например, CAP-PACELC теорема. Она рассматривает синхронизацию между нодами хранилища и задает нам два простых вопроса:

— Если сбой, что важнее: консистентость или доступность?

— Если штатно, что важнее: консистентность или скорость отклика?

Круто, и что мне с этим делать? Я архитектуру кафки и постгри проектировать не собираюсь. Чтобы кто-то садился и задавался вопросом: “Какую же модель мне выбрать для сервиса заявок: CP или AP??” - тоже никогда не встречал. Тогда зачем мне это кроме шаблонных собесов?

А если посмотреть шире?
Наш сервис-система-компания - это миллионы-миллиарды объектов, которые постоянно меняют свое состояние. Меняют в рамках определенных правил, ограничений, процессов, которые ведут к бизнес-цели. Фактически, мы занимаемся непрерывной синхронизацией состояний этих объектов.

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

Есть пара: процессинг заказов и платежный сервис, что критичнее
— консистетность или доступность?
— консистентность или время отклика?

А для пары процессинг заказов и бухгалтерия?

Из ответов следует выбор модели strong / eventually consistency. А из этого следует, как будем управлять распределенными транзакциями: оркестрация, хореография, воркфлоу и т.д. А из этого, где нам нужны будут ретраи с идемпотентностью, а где события будем кидать.

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

Часто фундаментальные концепции из computer science не дают конкретные рекомендации для локальных задач, но позволяют расширить сознание, чтобы более системно и целостно подходить к проектированию.

#архитектура

Выложили записи докладов с ArchDays’2024.

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

Работа Кафки просто и наглядно

Шикарная визуализация работы Кафки: https://softwaremill.com/kafka-visualisation

И менее шикарная, но тоже пригодится: https://evoura.com/kafka-traffic-visualizer

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

Разбираемся с основами, начинаем здесь:

1. Установите: 1 брокер, 1 консьюмер группа, 1 консьюмер, 2 партиции. Посмотрите, как сообщения распределяются между партициями.

2. Добавьте второго консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.

3. Добавьте третьего консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.

4. Перенесите третьего консьюмера в отдельную консьюмер группу. Сравните потребление сообщений в двух консьюмер группах.

Теперь понаблюдаем за работой с ключами, переключитесь сюда:

5. Установите 2 партиции, key range = 4. Посмотрите как сообщения с одинаковым ключом распределяются между партициями

6. Установите 3 партиции, потом 4.

7. Установите 6 партиций. Что изменилось? Почему так происходит?

Возвращаемся в основной симулятор:

8. Установите: 2 брокера, фактор репликации - 2, 1 консьюмер группа, 1 консьюмер. Посмотрите, где и как реплицируются партиции и сообщения.

9. Установите: 3 брокера, фактор репликации = 2. Посмотрите, как теперь работает репликация.

10. Установите: фактор репликации = 1. Посмотрите, как теперь работает репликация.

11. Установите: фактор репликации = 3. Обратите внимание, как распределяются между брокерами мастер-партиции (яркие) и их реплики (блеклые)

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

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

#брокеры

#брокеры

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

Нашелся репозиторий вида "все про интеграцию": технологии, паттерны, протоколы. Не знаю, как использовать, но может вам полезно будет: https://github.com/stn1slv/awesome-integration

#манагерское #книжное

Уже писал, что "требований" как вещи-в-себе не существует.

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

Заказная разработка
Подкладываем портянку "требований" к договору, по которому происходит оплата с приемкой. Спасает не всегда - с крупными клиентами можете остаться без денег или попасть в блеклист.

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

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

Мне в этом плане нравится книга The Mom Test / Спросите вашу маму

Кратко суть:
 • все люди врут
 • люди врут потому, что вы их провоцируете постановкой вопросов
 • как разговаривать с людьми, чтобы извлечь полезную инфу

Кому стоит прочитать:

 • Продакту и заказчику - чтобы понять контекст и проблемы клиентов / пользователей

 • Аналитику и тимлиду - чтобы понять, зачем эта фича нужна заказчику

 • Разрабу и QA - чтобы понять, зачем аналитик запихал этот метод в апи

 • Владельцу внутренней платформы типа ESB, CI/CD и т.п. - чтобы заранее планировать развитие ваших сервисов

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

#конференции

Программа NextConf сухими цифрами:
- 3 практических воркшопа
- 4 доклада формата методички бери-и-делай
- 3 доклада про архитектурные подходы
- 3 карьерные активности, включая обзор рынка и круглый стол

У меня все. Встречаемся завтра.

Недавно выкладывал задание в симуляторе Кафки. Добавил шаги по работе с ключами и перераспределением партиций при падении брокера.

Забирайте и проходите, если еще не. Штука не только полезная, но и залипательная - успокаивает лучше рыбок.

Ультимативный гайд по софтам

Делюсь сакральным знанием о коммуникациях, оставленным атлантами в недрах Тибета. Использовать на коллегах, руководителях, партнерах.

1. Не давайте коммитов, пока полностью не поймете задачу. Если не понимаете - сообщите об этом и задайте вопросы.

2. Когда начинаете работать над задачей, дайте знать об этом заинтересованной стороне.

3. Если не можете взять задачу сразу или в оговоренные сроки - сразу сообщите об этом.

4. Если вы столкнулись с проблемой, и не можете ее решить - сообщите об этом.

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

6. Если понимаете, что не успеете в сроки - сообщите об этом сразу. Это никому не понравится, но отрулить будет на порядок проще, чем в последний момент.

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

8. Если на встрече у вас нет ответа на вопрос, так и скажите: пока не могу ответить, беру в работу. Буллшит-импровизации и попытки увильнуть видны почти всегда.

Поздравляю! Вы адекватнее ~83,57% людей на рынке.

#коммуникации #манагерское

#интеграция #API

Пережили конфу, в субботу начнем десятый поток курса по проектированию API.

С одной стороны, это Yet Another REST API Course для джунов-миддлов, чего вы там не видели? Люди знакомятся c HTTP, учатся делать типичный REST API, тестить и документировать сервиcы.

С другой - все чаще вижу на занятиях сеньоров и лидов. Зачем им это?

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

“Делать правильно” никому не нужно. Важно спроектировать API, которое не превратится через полгода в нечитаемое месиво, а под каждую доработку не нужно будет втыкать костыли на каждой стороне. Для этого мы разбираем уровни зрелости REST API, их границы применения, и когда стоит использовать RPC API.

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

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

Так что приходите за обязательной базой или расширением горизонтов. 5-23 апреля, рега тут.