Как проектировать микросервисы

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

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

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

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

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

#skills

Кеширование на бекенде

Вводная статья, посвященная кешированию на бекенде, затрагивающая много интересных моментов.

Автор проходится по основным концептам:
– Для чего нужно кеширование, что нужно кешировать, по каким метрикам оценивать работу кеша

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

– Всегда актуальный вопрос – стратегии инвалидации кеша. Jitter, чтобы не протухало всё разом. Схлопывание запросов в один, когда протухла запись, которую очень интенсивно используют

– Кеширование ошибок – полезный прием. Если знаем, что в бд нет определенных данных, так зачем каждый раз продолжать долбиться в бд. Можно закеширвать ошибку. Есть даже специальная схема атаки – cache miss attack

О кешировании у нас уже был пост Design distributed cache.

#skills

Пятничное развлекательное

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

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

После прочтения вы наверняка не начнете проводить "офигенно длинные собрания", но точно почерпнёте набор того, что важно для полезной, качественной встречи. Мне очень понравилась мысль, что на встрече должно быть минимально достаточное количество людей для принятия решения. Чтобы не приходилось с ним бегать наверх для одобрения. Кстати, о том как этого добиться, есть отдельная статья.

В статье хорошо демонстрируется важность единой терминологии. По сути — один из аспектов DDD, о котором писали раньше. Простой термин, но как он может по-разному интерпретироваться. Например, "наличие". Для закупки «есть в наличии» — это хотя бы один товар в любом одном магазине в России. Для розницы — есть в большинстве магазинов хотя бы один товар. Для организации акций — есть хотя бы 5 штук в большинстве магазинов.

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

#edu

Попробуйте HTMX

Если у вас несложный фронтенд и не хочется погружаться в дебри развесистых фронтенд фреймворков – посмотрите на htmx. Очень интересная штуковина. Никакого javascript и сложной логики на фронте. Берем в руки html и вперёд.

Обзорная статья, где автор делится позитивным опытом использования htmx.

А тут можно посмотреть примеры использования htmx с вашим любимым языком программирования. Питонистам будет интересен вот такой свежий проектик.

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

#skills #frontend

Нужен совет сообщества. У нас всё острее встаёт вопрос документирования сервисов. Конечно, у каждого сервиса есть свой сваггер, к методам написаны докстринги, в ридми есть описание работы сервиса и его архитектуры. Но всё это лежит в разных местах. Хочется красивенько и удобненько собрать всё вместе.

Из хотелок:
– для всего многообразия единый веб-интерфейс: архитектурные описания сервисов из readme, openapi спецификация, общее описание архитектуры из конфлюенса.
– было бы классно понимать пересечения http-ручек, когда в случае вызова одной по цепочке вызывается другая

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

Расскажите, как решаете вопрос с документацией, что документируете? Какие технологии стоит использовать?

Асинхронное взаимодействие сервисов с применением Kafka

Практическая статья, демонстрирующая, как организовать асинхронное взаимодействие сервисов на Python с использованием Kafka. Автор коротенько даёт вводные, описывает архитектуру и переходит к делу.

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

#python #procode

Пятничное развлекательное

Наверно, почти все слышали о замечательной книге "Вы, конечно, шутите, мистер Фейнман!", но она точно заслуживает ещё одного упоминания.

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

Эта книга вдохновляет и мотивирует на новые свершения.

Если еще не читали – обязательно прочтите.

#fun #books

TOAST – проблемы откуда не ждали

Для хранения длинных записей в Postgres используется механизм TOAST.

Колонки с длинными значениями не хранятся в самой таблице. Если значение больше 2 Кб, то данные разбиваются на чанки и отправляются в связные тост-таблицы, скрытые от пользователя. А в исходной таблице хранится специальный указатель на чанки в тост-таблице.

И нам этом можно было бы и закончить. Просто интересный факт, связанный с особенностью хранения данных.

Но есть нюансы. Отметим практически значимые.
– В тост-таблице не может быть больше, чем 2^32 значений, то есть можно просто упереться в верхнее значение
– TOAST не поддерживает UPDATE. То есть каждая операция обновления вашего большого JSON приводит к INSERT в тост-таблицу и её распуханию.
– Независимо сколько в вашей таблице колонок, тост-таблица всегда одна.

Но дело не только в количестве значений в тост-таблице. Сам механизм накладывает определенные издержки.
JSON в Postgres уже давно не в новинку и активно используется. И, как правило, обсуждения проблем TOAST крутятся именно вокруг JSON полей.

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

Во второй же рассказывают, как оптимизировали JSON, чтобы повысить его производительность и уменьшить влияние TOAST. Также дают пару советов: всегда использовать JSONB и никогда не хранить в нём ID.

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

#skills #database

Работа с памятью

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

Познавательная статья с очень качественной визуализацией, посвящённая основам работы с памятью.

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

#skills

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

Автор пишет много практических постов о разработке, например, пост о логировании или какие нюансики стоит знать, внедряя loguru. Периодически поток информации разбавляется юмором. А ещё узнал из этого канала об интересной такой утилите deptry.

Пятничное развлекательное

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

А кто хочет лёгкого и интересного чтения обратите внимание на его книгу о жизни и работе в Африке – Записки примата. Необычайная жизнь ученого среди павианов. Путешествия по континенту, исследование влияния стресса на другие биологические показатели, быт местных племен.

#fun #books

Backup: май

Архитектура проекта
1. Load balancing
2. Zero-Downtime Deployments with Docker Compose
3. Как проектировать микросервисы
4. Кеширование на бекенде
5. Асинхронное взаимодействие сервисов с применением Kafka

Копаем вглубь
1. Пагинируем по-всякому
2. Как работает ChatGPT
3. Попробуйте HTMX
4. Работа с памятью

Базы данных
1. О производительности Postgres
2. TOAST – проблемы откуда не ждали

Разное
1. Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло
2. Роберт Сапольски — Биология религиозности
3. Вы, конечно, шутите, мистер Фейнман!
4. Сравниваем лампы и батарейки

Если пропустили, то подборка за апрель.

#backup

Попробуйте ruff

Ранее мы рассказывали о целом наборе линтеров, которые постоянно применяем в своих проектах.

Недавно обратили внимание на достаточно молодой и интересный линтер для python – ruff. Он объединяет в себе правила многих других линтеров – по сути всех, которые используем.

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

Из плюсов:
– ощутимая скорость. Линтеры у нас прогоняются с помощью pre-commit на каждом коммите, поэтому скорость имеет значение. Пару раз даже ловил себя на мысли, что не делаю лишний коммит, чтобы не ждать прогона линтеров. А ruff отрабатывает практически моментально
– в pre-commit не нужно держать целый зоопарк линтеров. Достаточно один раз сконфигурировать и подключить ruff

Так что категорически рекомендую попробовать. У них, кстати, есть playground для этих целей.

#python

Управление данными в микросервисах

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

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

В статье автор рассказывает о способах управления данными в микросервисной архитектуре:
– Дублирование мастер-систем. Каждый сервис хранит и поддерживает данные независимо друг от друга
– API. Сервис, ответственный за данные, предоставляет доступ к данным по API другим сервисам
– DWH. Сервис, ответственный за данные, сливает их в единое хранилище, а другие сервисы имеют доступ к хранилищу
– Очереди. Сервис, ответственный за данные, публикует информацию обо всех изменениях в очередь. А другие сервисы, считывая данные из очереди, хранят на своей стороне и актуализируют.

По каждому способу автор рассказывает о достоинствах и недостатках. Подробнее останавливается на последнем, как на наиболее интересном, и рассказывает о нюансах реализации.

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

#systemdesign

За что мы любим командную строку

В повседневной деятельности мы активно применяем командную строку. Иногда слышим вопросы о том, зачем это вообще нужно, вроде и без неё все хорошо? Этот вопрос вполне логичен, если не погружался в эту тему, не пытался решать реальные задачи.

На хабре мы написали лёгкую статью, где на примерах рассказали, за что мы любим командную строку. Профессиональный навык работы с командной строкой – один из шагов к 10х программисту.

Зачем разработчику нужен Linux вообще и терминал в частности

Эта статья существует! Вчерашний анонс из-за путешествий во времени вышел не вовремя. Так зачем вам терминал?
– легко поставить софт
– легко автоматизировать процессы
– легко вспомнить
– легко настроить под себя

легко…(злобный закадровый смешок)

Покажем, чем терминал важен для разработчиков и не только на разных примерах.

#devfm #skills

Backup: подборка по базам

Экспертиза в базах данных – супер востребованный скилл среди разработчиков. У нас накопилось приличное количество постов, посвящённых базам данных. Собрали все в один пост, чтобы было удобно.

Практика
– Подробный гайд по работе с json в postgres
– Какой тип данных использовать для хранения строк в postgres
– Куда смотреть, если postgres начала тупить
– Базовые настройки Postgres
– Работа с NULL в Postgres
– Тестирование миграций alembic
– Сравниваем базы данных с помощью data-diff
– Временные интервалы в postgres
– Порядок имеет значение
– Утилита postgres_dba

Теория
– TOAST – проблемы откуда не ждали
– Индексы в PostgreSQL
– Буфферный кеш в PostgreSQL
– Этапы выполнения запросов в PostgreSQL
– ACID в PostgreSQL
–Понимаем EXPLAIN в PostgreSQL
– Миграции без даунтайма
– Храним данные по-разному, в зависимости от цели – создаем аналитическую базу
– Введение в Greenplum и пример реального использования
– Введение в Manticore и сравнение с Elastic
– Тернистый путь к ClickHouse
– Оптимизатор Join в Postgres
– Как мы боролись с Manticore
– Посмотрите на keydb
– TimescaleDB для хранения временных рядов

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

#backup

Типы кабелей

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

– силовые кабели
– витая пара и DAC-кабель. Какие категории кабелей бывают и как и что на это влияет: скорость передачи данных, экранирование
– оптика. Что за мода такая, что за сердцевина, какие бывают коннекторы

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

Путь от монолита к микросервисам

Лёгкая для понимания статья, проводящая грань между монолитом, микросервисным монолитом, микросервисами и так называемым оркестратором бизнес-сервисов (последнее – это какая-то ненаучная фантастика).

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

Статья мне понравилось ещё тем, что по пути автор даёт ссылки на интересные материалы для погружения в тему. Например, о CirquitBreaker от Мартина Фаулера.

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

#systemdesign

Пятничное развлекательное

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

#fun