Микросервисы против Монолитов

Микросервисы против Монолитов
(описание к предыдущему посту)

### Что такое Монолит?

Монолитная архитектура — это единое, целостное приложение, где все компоненты (пользовательский интерфейс, бизнес-логика, доступ к базе данных) тесно связаны между собой и работают как единое целое.

### Характеристики Монолитов

* Единая кодовая база и процесс развертывания
* Все функции и модули взаимосвязаны
* Проще начать разработку и развертывание на начальном этапе

### Преимущества Монолитов

* Простота разработки и тестирования на ранних этапах
* Простой процесс развертывания
* Производительность может быть выше для небольших приложений, так как всё работает вместе

### Недостатки Монолитов

* Сложность масштабирования по мере роста системы
* Малое изменение может потребовать повторного развертывания всего приложения
* Большим командам сложно работать независимо и без конфликтов.
* Ошибка в одном модуле может повлиять на всю систему

### Что такое Микросервисы?

Архитектура микросервисов разбивает приложение на небольшие независимые сервисы, которые взаимодействуют через API (часто HTTP/REST или очереди сообщений). Каждый сервис отвечает за определённую бизнес-функцию.

### Характеристики Микросервисов

* Множество небольших сервисов, каждый со своей кодовой базой
* Сервисы взаимодействуют через API или обмен сообщениями
* Независимое развёртывание и масштабирование каждого сервиса

### Преимущества Микросервисов

* Проще масштабировать отдельные части системы
* Команды могут независимо работать над разными сервисами
* Технологическая гибкость (разные сервисы могут использовать различные языки программирования или базы данных)
* Сбои в одном сервисе реже приводят к отказу всей системы

### Недостатки Микросервисов

* Более сложная разработка и управление
* Требуется надёжное отслеживание и взаимодействие между сервисами
* Усложнение процессов развёртывания и DevOps

### Сравнение Монолита и Микросервисов

* Монолит: Единое целое, простота, но малая гибкость и слабая адаптируемость
* Микросервисы: Распределённая система, гибкая, но сложная
* Монолит: Лучше подходит для небольших и средних приложений или ранних этапов разработки
* Микросервисы: Лучше подходит для крупных, сложных и быстро развивающихся систем

В июле компания Fastly опросила 791 профессионального программиста с позицией Senior Developer (с опытом работы более 10 лет) об использовании инструментов ИИ.
По его результатам оказалось, что около трети опрошенных сгенерировали более половины своего кода. Это почти в два с половиной раза больше, чем у младших разработчиков (с опытом работы от 0 до 2 лет), а именно 13%», — отметили в Fastly.

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

Старшие разработчики также чаще признавали, что тратят время на исправление кода, сгенерированного ИИ. Чуть менее 30% из них сообщили, что редактируют результаты ИИ в достаточной степени, чтобы компенсировать большую часть экономии времени. У младших разработчиков этот показатель составляет 17%. Тем не менее, 59% сениоров утверждают, что инструменты ИИ помогают им в целом быстрее выпускать код. У джуниоров этот показатель составляет 49%, а чуть более 50% из них отмечают, что ИИ делает их работу умеренно быстрее. Среди сениоров этот показатель составляет 39%.

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

Почти каждый третий разработчик (28%) говорит, что ему часто приходится исправлять или редактировать код, сгенерированный ИИ, а это сводит на нет эффект экономии времени. Только 14% говорят, что им редко приходится вносить изменения. И всё же более половины разработчиков по-прежнему чувствуют себя быстрее с инструментами ИИ.

https://www.fastly.com/blog/senior-developers-ship-more-ai-code

Кто-нибудь знает или помнит, что у нас есть «Большая российская энциклопедия» - аналог Википедии, точнее была...

Так вот правительство России направит 303 млн рублей на ликвидацию автономного некоммерческого общества (АНО) «Большая российская энциклопедия». Соответствующее распоряжение опубликовано на портале правовой информации. АНО занималось созданием портала, позиционирующимся как аналог «Википедии». Однако, в отличие от «Википедии», на статьи портала можно было ссылаться в научных и студенческих учебных работах, эти работы индексировались в Российском индексе научного цитирования.

Финансы выделят в 2025 году из резервного фонда кабинета министров РФ. Эти средства пойдут на погашение задолженности по заработной плате, выплаты при увольнении сотрудников и расчёты по обязательствам организации. Контролировать использование средств будет Минцифры РФ. Ведомство представит отчёт о проведённых мероприятиях до 1 марта 2026 года.
https://www.rbc.ru/rbcfreenews/68b94e179a794743f7649ffa

9 основных паттернов для создания отказоустойчивых приложений
(продолжение в следующем посте)

9 основных паттернов для создания отказоустойчивых приложений
(продолжение предыдущего поста)

### 1. Предохранитель (Circuit Breaker)

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

Основные состояния предохранителя:
* Закрыто: запросы пропускаются.
* Открыто: запросы немедленно отклоняются с ошибкой.

Эффективен для защиты от каскадных сбоев и изоляции проблемных сервисов.

### 2. Повтор запроса (Retry)

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

### 3. Таймаут (Timeout)

* Устанавливает максимальное время ожидания для запроса.
* Если ответ не получен в течение заданного периода, запрос считается неудачным.

### 4. Переборка (Bulkhead)

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

### 5. Ограничение скорости (Rate Limiting)

* Контролирует частоту входящих запросов для защиты системы от перегрузки.
* Защищает от атак типа «отказ в обслуживании», обеспечивает справедливое использование и помогает поддерживать стабильность системы.

### 6. Запасной вариант (Fallback)

* Предоставляет альтернативный (часто менее оптимальный) ответ или действие при сбое основного.
* Повышает доступность системы и улучшает пользовательский опыт, обеспечивая определённый уровень сервиса даже при недоступности основной функции.

### 7. Хеджирование (Hedging)

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

### 8. Сброс нагрузки (Load Shedding)

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

### 9. Обратное давление (Backpressure)

* Имеет некоторое сходство с другими паттернами отказоустойчивости.

Основной механизм обратного давления — это петля обратной связи между отправителем (производителем данных) и получателем (потребителем данных).

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

Существует несколько стратегий обратного давления:
* Реактивный запрос — потребитель явно запрашивает данные у производителя, получая их в своём темпе.
* Ограничение скорости — производитель ограничивает скорость вывода данных на основе обратной связи от потребителя.
* Буферизация — используется буфер для временного хранения данных, когда потребитель работает медленно.

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

Среди прочего, вредоносные обновления были выпущены для пакетов debug, chalk, ansi-styles, color-convert, wrap-ansi, supports-color и ansi-regex, имеющих более 200 млн загрузок за последнюю неделю. Отдельно выделяются пакеты chalk и debug, у которых имеется 129286 и 55289 зависимостей. Пакеты были скомпрометированы из-за утечки параметров учётной записи Джоша Джунона (Josh Junon), который является сопровождающим debug-js, chalk и множества библиотек для консольных приложений.

https://www.opennet.ru/opennews/art.shtml?num=63845

Проблема N+1 запросов
(продолжение в следующем посте)

Проблема N+1 запросов
(продолжение к предущему посту)

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

Пример (псевдокод):

// 1 запрос
users = db.query('SELECT * FROM users');

// ...что приводит к N дополнительным запросам
for (const user of users) {
  posts = db.query(`
      SELECT * FROM posts 
      WHERE user_id = user->id`);
  user.posts = posts;
}
// Теперь можно вернуть результат запрашивающей стороне

Вместо этого можно переписать код как один запрос с JOIN, чтобы получить все данные за одно обращение к БД:

results = await db.query(
  `SELECT u.*, p.* 
    FROM users u 
    LEFT JOIN posts p 
    ON u->id = p->user_id`);

Для некоторых запросов влияние N+1 может быть минимальным. Если N — небольшое число, всё может казаться «быстрым», если БД хорошо настроена и находится рядом с серверами приложений. Но при N=100 начинают проявляться замедления, и БД загружается сильнее, чем необходимо. Устранение таких проблем улучшает пользовательский опыт и снижает нагрузку на БД.

Шпаргалка по интервью по API
(описание в следующем посте)

Шпаргалка по интервью по API
(продолжение предыдущего поста)

Основы API

*Что такое API?*
API — это программное обеспечение, которое действует как посредник между приложениями, помогая им взаимодействовать друг с другом с помощью HTTP-запросов.

*Типы API*
* Открытые API
* Закрытые API
* Партнерские API
* Композитные API

Тестирование API

*Что такое тестирование API?*
Тестирование API — это стратегия тестирования программного обеспечения, которая гарантирует, что API стабильны, функциональны, надежны и безопасны.

*Преимущества тестирования API*
* Удобство
* Лучше, чем тестирование GUI
* Независимость от языка
* Гибкость в выборе языка программирования

REST vs SOAP

*REST*
* Использует XML или JSON
* Поддерживает HTTP
* Быстрее, чем SOAP
* Поддерживает кэширование

*SOAP*
* Использует только XML
* Поддерживает HTTP и HTTPS
* Более безопасен, чем REST
* Не поддерживает кэширование

API Testing vs Unit Testing

*Тестирование API*
* Использует тестирование «черного ящика»
* Проверяет функциональность

*Юнит-тестирование*
* Использует тестирование «белого ящика»
* Проверяет отдельные блоки кода

CRUD
Эта аббревиатура представляет четыре основные операции, распространенные в реляционных базах данных: создание, чтение, обновление и удаление.

Архитектура REST API
Схема показывает взаимодействие между клиентом и сервером через REST API, включая запросы и ответы.

Дополнительные вопросы об API

*Что такое аутентификация API?*
Аутентификация API — это процесс проверки прав доступа пользователя к данным и ресурсам, которые он запрашивает.

*Что такое Runscope?*
Runscope — это веб-приложение, используемое для мониторинга, отладки и тестирования производительности веб-сервисов API.

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

#### Аутентификация и авторизация (OAuth, JWT, сессии)
(описание в следующем посте)

#### Аутентификация и авторизация (OAuth, JWT, сессии)
(продолжение предыдущего поста)

##### Что такое аутентификация?

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

→ Пример: Вход в систему с использованием имени пользователя и пароля.

##### Что такое авторизация?

Авторизация определяет, какие действия аутентифицированному пользователю разрешено выполнять в системе. Она устанавливает разрешения и уровни доступа.

→ Пример: Обычный пользователь может просматривать контент, в то время как администратор может добавлять или удалять контент.

##### OAuth (Open Authorization)

→ Стандартный протокол для аутентификации и авторизации на основе токенов.
→ Позволяет пользователям входить в систему через сторонних провайдеров, таких как Google, Facebook или GitHub.
→ Пример: Кнопка «Войти через Google» на веб-сайтах.

##### JWT (JSON Web Token)

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

##### Сессии

→ Метод, при котором сервер временно хранит данные аутентификации пользователя.
→ Идентификатор сессии сохраняется в браузере клиента (cookie) и сопоставляется с данными на стороне сервера.
→ Пример: Традиционные веб-приложения, где пользователь остаётся авторизованным до истечения сессии или до выхода из системы.

##### Ключевые различия

→ OAuth: Передаёт аутентификацию внешним провайдерам.
→ JWT: Аутентификация без сохранения состояния, токены хранятся на клиенте.
→ Сессии: Аутентификация с сохранением состояния, данные хранятся на сервере.

Как работает Big O

* Big O показывает, насколько медленнее становится код при увеличении входных данных.

* Для конкретного алгоритма существуют три случая: наилучший, средний и наихудший.

* Кроме того, существуют оценки Big O для эффективности использования времени, памяти и хранилища.

* Big O помогает понять, какие структуры данных или алгоритмы демонстрируют лучшую производительность.

* Big O показывает скорость роста, а не фактическую скорость выполнения. Поэтому важно тестировать входные данные на практике.


Сложность Big-O

* O(1) — Доступ к значению в хеш-таблице по ключу.
* O(n!) — Добавление вложенного цикла для каждого ввода.
* O(2^n) — Наивное рекурсивное вычисление последовательности Фибоначчи.
* O(log n) — Алгоритмы «разделяй и властвуй».
* O(n) — Проход по списку.
* O(n log n) — Итерации, использующие «разделяй и властвуй».
* O(n^2) — Вложенный цикл на одном и том же вводе.

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

«В последнее время (особенно в контексте запуска мессенджера Max) обсуждение разрешений, требуемых современным мессенджерам, идёт особенно горячо. Давайте сравним разрешения, запрашиваемые тремя самыми актуальными для российских пользователей мессенджерами под Android: Telegram, WhatsApp и Max», — рассказали в «Лаборатории Касперского».

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

https://www.kaspersky.ru/blog/messengers-threats-and-countermeasures/40451/

На SQL теперь тоже пишут игры.

Проект DOOMQL развивает вариант игры DOOM на SQL и способный выполняться внутри СУБД CedarDB, частично совместимой с PostgreSQL. Игра поддерживает многопользовательский режим и выполняет отрисовку при помощи ASCII-графики.

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

Игровой цикл для обработки и обновления игрового состояния запускается с помощью 20-строчного shell-скрипта, который 30 раз в секунду выполняет SQL-код для расчёта траектории выстрелов, анализа столкновений, обработки ввода и возрождения игроков

3D-рендер на SQL поддерживает трассировку лучей, проекцию спрайтов на 3D-сцену, обработку перекрытия объектов и HUD-интерфейс. Вся логика рендеринга реализована при помощи представлений. Синхронизация состояния игроков осуществляется при помощи таблиц и представлений

https://github.com/cedardb/DOOMQL