7. Async Processing (асинхронная обработка)
* суть: отделение обработки задач от основного потока выполнения для повышения производительности и масштабируемости;
* архитектура:
* Server (сервер) — принимает запросы и помещает задачи в очередь;
* Workers (воркеры) — отдельные процессы/контейнеры, которые обрабатывают задачи из очереди;
* компоненты:
* очередь задач (Task Queue) — промежуточное хранилище для задач (например, RabbitMQ, Kafka);
* воркеры — обрабатывают задачи параллельно;
* преимущества:
* снижение нагрузки на основной сервер;
* возможность масштабирования обработки (добавление воркеров при росте нагрузки);
* устойчивость к пикам нагрузки (задачи накапливаются в очереди и обрабатываются постепенно).
* примеры: обработка платежей, отправка уведомлений, ETL-процессы.
Эти паттерны можно комбинировать для достижения оптимальной масштабируемости. Например, использовать горизонтальное масштабирование и балансировку нагрузки для сервисов, кэширование для ускорения доступа к данным, шардирование и репликацию для масштабирования базы данных, а асинхронную обработку для ресурсоёмких задач. Выбор паттерна зависит от конкретных требований системы: характера нагрузки, типа данных, требований к доступности и консистентности.
* суть: отделение обработки задач от основного потока выполнения для повышения производительности и масштабируемости;
* архитектура:
* Server (сервер) — принимает запросы и помещает задачи в очередь;
* Workers (воркеры) — отдельные процессы/контейнеры, которые обрабатывают задачи из очереди;
* компоненты:
* очередь задач (Task Queue) — промежуточное хранилище для задач (например, RabbitMQ, Kafka);
* воркеры — обрабатывают задачи параллельно;
* преимущества:
* снижение нагрузки на основной сервер;
* возможность масштабирования обработки (добавление воркеров при росте нагрузки);
* устойчивость к пикам нагрузки (задачи накапливаются в очереди и обрабатываются постепенно).
* примеры: обработка платежей, отправка уведомлений, ETL-процессы.
Эти паттерны можно комбинировать для достижения оптимальной масштабируемости. Например, использовать горизонтальное масштабирование и балансировку нагрузки для сервисов, кэширование для ускорения доступа к данным, шардирование и репликацию для масштабирования базы данных, а асинхронную обработку для ресурсоёмких задач. Выбор паттерна зависит от конкретных требований системы: характера нагрузки, типа данных, требований к доступности и консистентности.
Telegram
METANIT.COM
Стратегии масштабирования распределённых систем
(продолжение в следующем посте)
(продолжение в следующем посте)
❤5🔥3👍2🤮1
Ключевые Архитектурные паттерны
(продолжение предыдущего поста)
1. Client-Server Architecture (Клиент-серверная архитектура)
- Суть: задачи распределены между клиентами и серверами. Клиенты отправляют запросы, серверы обрабатывают их и возвращают результаты.
- Компоненты:
- Клиент (Client) — инициирует запросы (например, веб-браузер, мобильное приложение).
- Интернет (Internet) — канал передачи данных.
- Load Balancer (балансировщик нагрузки) — распределяет запросы между серверами для оптимизации производительности.
- Сервис (Service) — обрабатывает запросы и взаимодействует с базой данных.
- CDN (Content Delivery Network) — ускоряет доставку статического контента, снижая нагрузку на сервер.
- Преимущества: масштабируемость, централизованное управление, надёжность.
- Недостатки: зависимость от сервера, затраты на инфраструктуру, необходимость постоянного подключения к сети.
- Примеры: веб-сайты, электронная почта, онлайн-игры
2. Async Task Execution with Queues (Асинхронное выполнение задач с очередями)
- Суть: задачи выполняются асинхронно через очереди, что позволяет контролировать параллелизм и порядок выполнения.
- Компоненты:
- Presentation Layer (уровень представления) — взаимодействует с пользователем.
- Business Logic Layer (уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (уровень доступа к данным) — работает с базой данных.
- Очереди — хранят задачи для асинхронной обработки.
- Преимущества: предотвращение перегрузки системы, управление ресурсами, последовательное выполнение задач (например, финансовые транзакции).
- Примеры использования: обработка больших объёмов запросов, фоновые задачи (отправка писем, обработка изображений)
3. Serverless Architecture (Бессерверная архитектура)
- Суть: разработчики не управляют серверами, а фокусируются на написании функций, которые запускаются по требованию облачным провайдером.
- Компоненты:
- Lambda Function — основная функция, обрабатывающая события.
- Lambda Worker — исполнители задач, запускаемые по мере необходимости.
- Особенности: модель Functions as a Service (FaaS) — код загружается в облако, провайдер управляет ресурсами.
- Преимущества: масштабируемость, снижение затрат, ускорение разработки, автоматическое управление инфраструктурой.
- Недостатки: ограниченный контроль над средой выполнения, сложности с отладкой, потенциальные проблемы с безопасностью.
- Примеры: AWS Lambda, Google Cloud Functions
4. Pipes and Filters (Каналы и фильтры)
- Суть: процесс обработки данных разбивается на шаги, каждый из которых выполняется отдельным обработчиком (фильтром). Данные передаются через каналы.
- Компоненты:
- Data Source (источник данных) — начальная точка потока данных.
- Filters (Filter 1, Filter 2, Filter 3) — обрабатывают данные, трансформируя их.
- Data Sink (потребитель данных) — конечная точка потока.
- Преимущества: модульность, возможность параллельной обработки, лёгкость замены и перестановки фильтров.
- Недостатки: фильтры могут тратить больше времени на преобразование данных, чем на их обработку.
- Примеры: оболочка UNIX Shell, архитектура компилятора (лексер, парсер, семантический анализатор, генератор кода)
5. Event-Driven Architecture (Событийно-ориентированная архитектура)
- Суть: компоненты системы реагируют на события (изменения состояния кода, действия пользователя). Взаимодействие асинхронное.
- Компоненты:
- Producer (производитель) — генерирует события.
- Consumers (потребители) — обрабатывают события.
- Особенности: события передаются по каналам (TCP/IP, файлы JSON/XML), брокеры обеспечивают сохранность событий при сбоях.
- Преимущества: высокая масштабируемость, гибкость, бесшовная интеграция, быстрая реакция на события.
- Недостатки: сложность проектирования, обеспечение согласованности событий в распределённых системах.
- Примеры: обработка заказов в интернет-магазинах, системы IoT, платформы Uber, Netflix
(продолжение предыдущего поста)
1. Client-Server Architecture (Клиент-серверная архитектура)
- Суть: задачи распределены между клиентами и серверами. Клиенты отправляют запросы, серверы обрабатывают их и возвращают результаты.
- Компоненты:
- Клиент (Client) — инициирует запросы (например, веб-браузер, мобильное приложение).
- Интернет (Internet) — канал передачи данных.
- Load Balancer (балансировщик нагрузки) — распределяет запросы между серверами для оптимизации производительности.
- Сервис (Service) — обрабатывает запросы и взаимодействует с базой данных.
- CDN (Content Delivery Network) — ускоряет доставку статического контента, снижая нагрузку на сервер.
- Преимущества: масштабируемость, централизованное управление, надёжность.
- Недостатки: зависимость от сервера, затраты на инфраструктуру, необходимость постоянного подключения к сети.
- Примеры: веб-сайты, электронная почта, онлайн-игры
2. Async Task Execution with Queues (Асинхронное выполнение задач с очередями)
- Суть: задачи выполняются асинхронно через очереди, что позволяет контролировать параллелизм и порядок выполнения.
- Компоненты:
- Presentation Layer (уровень представления) — взаимодействует с пользователем.
- Business Logic Layer (уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (уровень доступа к данным) — работает с базой данных.
- Очереди — хранят задачи для асинхронной обработки.
- Преимущества: предотвращение перегрузки системы, управление ресурсами, последовательное выполнение задач (например, финансовые транзакции).
- Примеры использования: обработка больших объёмов запросов, фоновые задачи (отправка писем, обработка изображений)
3. Serverless Architecture (Бессерверная архитектура)
- Суть: разработчики не управляют серверами, а фокусируются на написании функций, которые запускаются по требованию облачным провайдером.
- Компоненты:
- Lambda Function — основная функция, обрабатывающая события.
- Lambda Worker — исполнители задач, запускаемые по мере необходимости.
- Особенности: модель Functions as a Service (FaaS) — код загружается в облако, провайдер управляет ресурсами.
- Преимущества: масштабируемость, снижение затрат, ускорение разработки, автоматическое управление инфраструктурой.
- Недостатки: ограниченный контроль над средой выполнения, сложности с отладкой, потенциальные проблемы с безопасностью.
- Примеры: AWS Lambda, Google Cloud Functions
4. Pipes and Filters (Каналы и фильтры)
- Суть: процесс обработки данных разбивается на шаги, каждый из которых выполняется отдельным обработчиком (фильтром). Данные передаются через каналы.
- Компоненты:
- Data Source (источник данных) — начальная точка потока данных.
- Filters (Filter 1, Filter 2, Filter 3) — обрабатывают данные, трансформируя их.
- Data Sink (потребитель данных) — конечная точка потока.
- Преимущества: модульность, возможность параллельной обработки, лёгкость замены и перестановки фильтров.
- Недостатки: фильтры могут тратить больше времени на преобразование данных, чем на их обработку.
- Примеры: оболочка UNIX Shell, архитектура компилятора (лексер, парсер, семантический анализатор, генератор кода)
5. Event-Driven Architecture (Событийно-ориентированная архитектура)
- Суть: компоненты системы реагируют на события (изменения состояния кода, действия пользователя). Взаимодействие асинхронное.
- Компоненты:
- Producer (производитель) — генерирует события.
- Consumers (потребители) — обрабатывают события.
- Особенности: события передаются по каналам (TCP/IP, файлы JSON/XML), брокеры обеспечивают сохранность событий при сбоях.
- Преимущества: высокая масштабируемость, гибкость, бесшовная интеграция, быстрая реакция на события.
- Недостатки: сложность проектирования, обеспечение согласованности событий в распределённых системах.
- Примеры: обработка заказов в интернет-магазинах, системы IoT, платформы Uber, Netflix
❤2👍2🤝2
6. Microservices Architecture (Микросервисная архитектура)
- Суть: приложение разбивается на небольшие независимые сервисы, которые взаимодействуют через API.
- Компоненты:
- Service — отдельный микросервис, выполняющий конкретную функцию.
- Базы данных — каждая служба может иметь свою базу данных.
- Преимущества: лёгкость масштабирования, независимость развёртывания, возможность использования разных технологий для разных сервисов.
- Недостатки: сложность тестирования, накладные расходы на обмен данными между сервисами, необходимость синхронизации.
- Примеры: крупные веб-приложения, системы с высокой нагрузкой (например, Amazon, Netflix)
7. Monolithic Architecture (Монолитная архитектура)
- Суть: все компоненты приложения объединены в единую кодовую базу и развёртываются как единое целое.
- Компоненты:
- Web Layer (веб-слой) — взаимодействует с пользователем.
- Components (Component A, B, C) — модули приложения, выполняющие различные функции.
- Shared DB (общая база данных) — хранит данные для всех компонентов.
- Преимущества: простота разработки и развёртывания, низкая сложность взаимодействия между компонентами.
- Недостатки: сложность масштабирования, зависимость компонентов друг от друга, трудности с внедрением новых технологий.
- Примеры: традиционные корпоративные приложения, небольшие веб-сайты
- Суть: приложение разбивается на небольшие независимые сервисы, которые взаимодействуют через API.
- Компоненты:
- Service — отдельный микросервис, выполняющий конкретную функцию.
- Базы данных — каждая служба может иметь свою базу данных.
- Преимущества: лёгкость масштабирования, независимость развёртывания, возможность использования разных технологий для разных сервисов.
- Недостатки: сложность тестирования, накладные расходы на обмен данными между сервисами, необходимость синхронизации.
- Примеры: крупные веб-приложения, системы с высокой нагрузкой (например, Amazon, Netflix)
7. Monolithic Architecture (Монолитная архитектура)
- Суть: все компоненты приложения объединены в единую кодовую базу и развёртываются как единое целое.
- Компоненты:
- Web Layer (веб-слой) — взаимодействует с пользователем.
- Components (Component A, B, C) — модули приложения, выполняющие различные функции.
- Shared DB (общая база данных) — хранит данные для всех компонентов.
- Преимущества: простота разработки и развёртывания, низкая сложность взаимодействия между компонентами.
- Недостатки: сложность масштабирования, зависимость компонентов друг от друга, трудности с внедрением новых технологий.
- Примеры: традиционные корпоративные приложения, небольшие веб-сайты
Telegram
METANIT.COM
Ключевые Архитектурные паттерны
(продолжение в следующем посте)
(продолжение в следующем посте)
❤2👍2🔥2
Как внедрение нейросетей выходит бизнесу боком
Предприниматели по всему миру с энтузиазмом внедряют ИИ, хотя помощь компьютера далеко не всегда идет им на пользу.
Владелец небольшого онлайн-магазина из Великобритании завел чат-бота, чтобы тот отвечал на вопросы клиентов с 18:00 до 9:00, когда бизнесмен отдыхает. Полгода все шло отлично, пока в начале февраля не попался хитрый покупатель. Вместо того чтобы расспрашивать помощника о товарах, он принялся выпрашивать скидку. Сначала ИИ согласился скинуть 25%, а через час дошел и до 80%.
Стартап Hello Patient поручил ИИ проводить онлайн-собеседования с кандидатами на работу. Все шло прекрасно, пока один из соискателей не поленился и не отправил вместо себя другой ИИ. Два бота вступили в переписку и быстро нашли общий язык. По итогам разговора ИИ дал кандидату высшую оценку.
В ноябре прошлого года руководство одной фирмы доверило ИИ анализировать весь ее бизнес. Искусственный разум покорил начальство, мгновенно выдавая подробные отчеты, снабженные красивыми графиками. Более 2 месяцев на основе этих данных принимались важнейшие решения вроде расширения географии продаж, а также готовились финансовые презентации для совета директоров и инвесторов. Судя по отчетам, бизнес компании стремительно шел в гору – пока кто-то не попросил перепроверить одну из цифр, упомянутых ИИ. Однако этого показателя нигде не нашлось. Инцидент стал поводом для масштабного аудита, который выявил множество расхождений отчетов нейросети с реальностью.
ИИ путал данные про разные продукты и придумывал нужные цифры, лишь бы отчет получался красивым. Теперь компания пересматривает все решения за IV квартал, принятые на основе сгенерированной ИИ информации.
В декабре 2025 г. у облачного сервиса Amazon Web Services произошел сбой, на устранение которого ушло около 13 часов. Как узнала Financial Times, инженеры разрешили ИИ-инструменту Kiro внести изменения в систему. Алгоритм решил, что проще всего будет стереть весь код и переписать его заново. В самой компании отрицают причастность ИИ к проблеме. К ошибке привели некорректные действия одного из пользователей. Сбой затронул только один сервис в одном из двух регионов материкового Китая, уверяют там.
https://www.vedomosti.ru/technology/articles/2026/02/28/1179513-iskusstvennaya-pomosch
Предприниматели по всему миру с энтузиазмом внедряют ИИ, хотя помощь компьютера далеко не всегда идет им на пользу.
Владелец небольшого онлайн-магазина из Великобритании завел чат-бота, чтобы тот отвечал на вопросы клиентов с 18:00 до 9:00, когда бизнесмен отдыхает. Полгода все шло отлично, пока в начале февраля не попался хитрый покупатель. Вместо того чтобы расспрашивать помощника о товарах, он принялся выпрашивать скидку. Сначала ИИ согласился скинуть 25%, а через час дошел и до 80%.
Стартап Hello Patient поручил ИИ проводить онлайн-собеседования с кандидатами на работу. Все шло прекрасно, пока один из соискателей не поленился и не отправил вместо себя другой ИИ. Два бота вступили в переписку и быстро нашли общий язык. По итогам разговора ИИ дал кандидату высшую оценку.
В ноябре прошлого года руководство одной фирмы доверило ИИ анализировать весь ее бизнес. Искусственный разум покорил начальство, мгновенно выдавая подробные отчеты, снабженные красивыми графиками. Более 2 месяцев на основе этих данных принимались важнейшие решения вроде расширения географии продаж, а также готовились финансовые презентации для совета директоров и инвесторов. Судя по отчетам, бизнес компании стремительно шел в гору – пока кто-то не попросил перепроверить одну из цифр, упомянутых ИИ. Однако этого показателя нигде не нашлось. Инцидент стал поводом для масштабного аудита, который выявил множество расхождений отчетов нейросети с реальностью.
ИИ путал данные про разные продукты и придумывал нужные цифры, лишь бы отчет получался красивым. Теперь компания пересматривает все решения за IV квартал, принятые на основе сгенерированной ИИ информации.
В декабре 2025 г. у облачного сервиса Amazon Web Services произошел сбой, на устранение которого ушло около 13 часов. Как узнала Financial Times, инженеры разрешили ИИ-инструменту Kiro внести изменения в систему. Алгоритм решил, что проще всего будет стереть весь код и переписать его заново. В самой компании отрицают причастность ИИ к проблеме. К ошибке привели некорректные действия одного из пользователей. Сбой затронул только один сервис в одном из двух регионов материкового Китая, уверяют там.
https://www.vedomosti.ru/technology/articles/2026/02/28/1179513-iskusstvennaya-pomosch
Ведомости
Искусственная помощь: как внедрение нейросетей выходит бизнесу боком
Компьютерный разум не всегда может заменить человеческий
🤣20🔥4👀4👾4❤1
Cокеты и вообще сетевые возможности .NET на Linux получат прирост производительности – они перерабатываются для использования API io_uring (io_uring – это интерфейс системного вызова для Linux, он нужен для асинхронных операций ввода-вывода)
Один из разработчиков .NET - Бен Адамс (Ben Adams) подтвердил существенное улучшение производительности сокетов Linux .NET благодаря переходу на API io_uring.
По его словам, обновление снизит нагрузку на центральный процессор на 15-40% при каждом запросе HTTP/1.1. Пропускная способность на одно соединение HTTP/2 улучшится на 5-15%. Кроме того, обновление снизит нагрузку на оперативную память для неактивных соединений на 30-50%; снизит задержки на 10-20% на запрос для кратковременных соединений при исходящих запросах HttpClient (между микросервисами), уменьшит задержки на 5-15% на каждый запрос при работе с драйверами баз данных (Npgsql, MySQL Connector, Redis)
https://www.neowin.net/news/linux-about-to-get-big-performance-boost-from-a-native-feature-windows-11-already-borrowed/
Один из разработчиков .NET - Бен Адамс (Ben Adams) подтвердил существенное улучшение производительности сокетов Linux .NET благодаря переходу на API io_uring.
По его словам, обновление снизит нагрузку на центральный процессор на 15-40% при каждом запросе HTTP/1.1. Пропускная способность на одно соединение HTTP/2 улучшится на 5-15%. Кроме того, обновление снизит нагрузку на оперативную память для неактивных соединений на 30-50%; снизит задержки на 10-20% на запрос для кратковременных соединений при исходящих запросах HttpClient (между микросервисами), уменьшит задержки на 5-15% на каждый запрос при работе с драйверами баз данных (Npgsql, MySQL Connector, Redis)
https://www.neowin.net/news/linux-about-to-get-big-performance-boost-from-a-native-feature-windows-11-already-borrowed/
Neowin
Linux about to get big performance boost from a native feature Windows 11 already borrowed
Linux is about to get some big performance gains soon from a native feature it already has. Interestingly, Microsoft borrowed it earlier for Windows 11.
❤13👍11🤝2
Эффект стратегий масштабирования
(продолжение предыдущего поста)
Стратегии масштабирования можно разделить на две категории: с ограниченным воздействием и с высокой эффективностью.
Стратегии масштабирования с ограниченным воздействием проще реализовать, они требуют меньше времени и обычно предполагают минимальные изменения в текущей системе. Они идеально подходят для обеспечения немедленного или умеренного роста.
Стратегии с высокой эффективностью обеспечивают более значительные долгосрочные преимущества, но требуют существенных изменений в архитектуре системы.
Разберем четыре простых примера:
1. Вертикальное масштабирование
Вертикальное масштабирование подразумевает модернизацию ресурсов существующего сервера — увеличение мощности процессора, добавление оперативной памяти или расширение хранилища — для обработки повышенной нагрузки.
Когда использовать: идеально подходит для быстрого решения текущих проблем с производительностью без внесения изменений в приложение.
Плюсы:
* Быстрота и простота реализации, не требуется вносить изменения в приложение.
* Низкая сложность и минимальные операционные издержки.
Минусы:
* Ограниченная масштабируемость — в конечном итоге достигаются аппаратные ограничения.
* Единый сервер означает единую точку отказа.
* Значительный рост затрат на оборудование при достижении высоких уровней нагрузки.
2. Горизонтальное дублирование
Запуск нескольких копий приложения на отдельных серверах с распределением трафика через балансировщик нагрузки.
Когда использовать: полезно, когда требуется обеспечить надёжность и простой поэтапный рост.
Плюсы:
* Высокая доступность и отказоустойчивость.
* Простое масштабирование за счёт добавления новых экземпляров.
Минусы:
* Усложнение управления системой.
* Возможные проблемы с поддержанием согласованного состояния данных на разных экземплярах.
3. Разбиение данных (шардинг)
Разбиение данных предполагает разделение данных на несколько баз данных на основе определённых критериев — например, диапазонов идентификаторов пользователей, географического положения или категорий товаров. При этом каждая база данных обрабатывает часть общей нагрузки.
Когда использовать: когда база данных достигает пределов ёмкости или начинает работать медленнее, разбиение помогает распределить нагрузку и справиться со значительным ростом объёма данных.
Плюсы:
* Высокая масштабируемость за счёт распределения данных.
* Эффективное использование ресурсов.
Минусы:
* Сложная реализация и необходимость постоянного обслуживания.
* Трудности при выполнении запросов, затрагивающих несколько разделов данных.
4. Функциональная декомпозиция (микросервисы)
Функциональная декомпозиция подразумевает разбиение монолитного приложения на более мелкие, независимо развёртываемые микросервисы, каждый из которых отвечает за определённый бизнес‑процесс (например, заказы, клиенты, складские запасы).
Когда использовать: когда приложение становится слишком сложным для поддержки и масштабирования, микросервисы позволяют масштабировать отдельные компоненты независимо и упрощают обслуживание.
Плюсы:
* Максимальная масштабируемость и гибкость.
* Независимые сервисы могут развиваться отдельно друг от друга.
* Лучшая изоляция сбоев.
Минусы:
* Сложная архитектура, требующая тщательной координации.
* Усложняются обеспечение согласованности данных и взаимодействие между сервисами.
* Вероятно, потребуется увеличить штат сотрудников.
(продолжение предыдущего поста)
Стратегии масштабирования можно разделить на две категории: с ограниченным воздействием и с высокой эффективностью.
Стратегии масштабирования с ограниченным воздействием проще реализовать, они требуют меньше времени и обычно предполагают минимальные изменения в текущей системе. Они идеально подходят для обеспечения немедленного или умеренного роста.
Стратегии с высокой эффективностью обеспечивают более значительные долгосрочные преимущества, но требуют существенных изменений в архитектуре системы.
Разберем четыре простых примера:
1. Вертикальное масштабирование
Вертикальное масштабирование подразумевает модернизацию ресурсов существующего сервера — увеличение мощности процессора, добавление оперативной памяти или расширение хранилища — для обработки повышенной нагрузки.
Когда использовать: идеально подходит для быстрого решения текущих проблем с производительностью без внесения изменений в приложение.
Плюсы:
* Быстрота и простота реализации, не требуется вносить изменения в приложение.
* Низкая сложность и минимальные операционные издержки.
Минусы:
* Ограниченная масштабируемость — в конечном итоге достигаются аппаратные ограничения.
* Единый сервер означает единую точку отказа.
* Значительный рост затрат на оборудование при достижении высоких уровней нагрузки.
2. Горизонтальное дублирование
Запуск нескольких копий приложения на отдельных серверах с распределением трафика через балансировщик нагрузки.
Когда использовать: полезно, когда требуется обеспечить надёжность и простой поэтапный рост.
Плюсы:
* Высокая доступность и отказоустойчивость.
* Простое масштабирование за счёт добавления новых экземпляров.
Минусы:
* Усложнение управления системой.
* Возможные проблемы с поддержанием согласованного состояния данных на разных экземплярах.
3. Разбиение данных (шардинг)
Разбиение данных предполагает разделение данных на несколько баз данных на основе определённых критериев — например, диапазонов идентификаторов пользователей, географического положения или категорий товаров. При этом каждая база данных обрабатывает часть общей нагрузки.
Когда использовать: когда база данных достигает пределов ёмкости или начинает работать медленнее, разбиение помогает распределить нагрузку и справиться со значительным ростом объёма данных.
Плюсы:
* Высокая масштабируемость за счёт распределения данных.
* Эффективное использование ресурсов.
Минусы:
* Сложная реализация и необходимость постоянного обслуживания.
* Трудности при выполнении запросов, затрагивающих несколько разделов данных.
4. Функциональная декомпозиция (микросервисы)
Функциональная декомпозиция подразумевает разбиение монолитного приложения на более мелкие, независимо развёртываемые микросервисы, каждый из которых отвечает за определённый бизнес‑процесс (например, заказы, клиенты, складские запасы).
Когда использовать: когда приложение становится слишком сложным для поддержки и масштабирования, микросервисы позволяют масштабировать отдельные компоненты независимо и упрощают обслуживание.
Плюсы:
* Максимальная масштабируемость и гибкость.
* Независимые сервисы могут развиваться отдельно друг от друга.
* Лучшая изоляция сбоев.
Минусы:
* Сложная архитектура, требующая тщательной координации.
* Усложняются обеспечение согласованности данных и взаимодействие между сервисами.
* Вероятно, потребуется увеличить штат сотрудников.
Telegram
METANIT.COM
Эффект стратегий масштабирования
(продолжение в следующем посте)
(продолжение в следующем посте)
❤6👍2🤝2
РКН опроверг информацию о закрытии прямого подключения к иностранным VPN
Роскомнадзор опроверг информацию о закрытии возможности прямого подключения к иностранным VPN-серверам, заявили в ведомстве.
Ранее в понедельник Telegram-каналы написали, что Роскомнадзор закрыл возможность прямого подключения к иностранным серверам: теперь специальная нейросеть Роскомнадзора отслеживает поведение сетей в поисках характерных признаков VPN-протоколов, а затем перекрывает их узлы.
"Информация о закрытии возможности прямого подключения к иностранным серверам, сформулированная в вашем запросе, не соответствует действительности. Настоятельно рекомендуем проверять публикуемые данные, напоминаем о недопустимости распространения недостоверной информации", - заявили в Роскомнадзоре.
https://ria.ru/20260302/vpn-2077991897.html
Роскомнадзор опроверг информацию о закрытии возможности прямого подключения к иностранным VPN-серверам, заявили в ведомстве.
Ранее в понедельник Telegram-каналы написали, что Роскомнадзор закрыл возможность прямого подключения к иностранным серверам: теперь специальная нейросеть Роскомнадзора отслеживает поведение сетей в поисках характерных признаков VPN-протоколов, а затем перекрывает их узлы.
"Информация о закрытии возможности прямого подключения к иностранным серверам, сформулированная в вашем запросе, не соответствует действительности. Настоятельно рекомендуем проверять публикуемые данные, напоминаем о недопустимости распространения недостоверной информации", - заявили в Роскомнадзоре.
https://ria.ru/20260302/vpn-2077991897.html
РИА Новости
РКН опроверг информацию о закрытии подключения к иностранным VPN
Роскомнадзор опроверг информацию о закрытии возможности прямого подключения к иностранным VPN-серверам, заявили РИА Новости в ведомстве. РИА Новости, 02.03.2026
🤡19🍌8🥴3😁2😭1
Сервис по подбору персонала Хедхантер выкатил свежую статистику по состоянию рынка труда за прошедший февраль. И несмотря на то, что почти весь предыдущий год ситуация в сфере найма в ИТ постепенно ухудшалась, в феврале есть некоторые улучшения.
Прежде всего увеличились предлагаемые зарплаты - с 94 442 до 100 000 и по этому показателю сравнялись с ожидаемыми зарплатами.
hh-индекс (соотношение количества активных резюме к количеству активных вакансий на рынке) также улучшилсz - с 21.3 до 19.6. Хотя и это значение очень высокое.
Количество вакансий по отношению к прошлому месяцу снова стало рости - количество вакансий увеличилось на 18%. Количество резюме выросло лишь на 8%.
Несмотря на некоторое улучшение, это может быть вызвано сезонностью - предыдущим январем с его длинными выходными, так как прошлый февраль была похожая динамика
https://stats.hh.ru/?countrySalaryDynamicChartProfArea=information_technology&hhIndexProfArea=information_technology&vacanciesProfArea=information_technology
Прежде всего увеличились предлагаемые зарплаты - с 94 442 до 100 000 и по этому показателю сравнялись с ожидаемыми зарплатами.
hh-индекс (соотношение количества активных резюме к количеству активных вакансий на рынке) также улучшилсz - с 21.3 до 19.6. Хотя и это значение очень высокое.
Количество вакансий по отношению к прошлому месяцу снова стало рости - количество вакансий увеличилось на 18%. Количество резюме выросло лишь на 8%.
Несмотря на некоторое улучшение, это может быть вызвано сезонностью - предыдущим январем с его длинными выходными, так как прошлый февраль была похожая динамика
https://stats.hh.ru/?countrySalaryDynamicChartProfArea=information_technology&hhIndexProfArea=information_technology&vacanciesProfArea=information_technology
🤔7🤡3
Шаблон конкурирующих потребителей
(продолжение предыдущего поста)
Суть паттерна:
Шаблон конкурирующих потребителей (Competing Consumer Pattern) — это архитектурный шаблон, позволяющий нескольким потребителям (consumers) параллельно обрабатывать сообщения (задачи) из общей очереди. Цель — эффективно распределить нагрузку и повысить пропускную способность системы, обеспечив её отказоустойчивость
Компоненты на схеме:
1. Producers (производители) — генерируют задачи (сообщения), которые помещаются в очередь. На схеме это Admin API, отправляющие данные в хранилище (Storage) и очередь (Queue)
2. Queue (очередь) — централизованное хранилище сообщений, ожидающих обработки. Служит буфером между производителями и потребителями
3. File Processors Pool (пул процессоров файлов) — группа независимых потребителей (File processor), которые «соревнуются» за обработку сообщений из очереди. Каждый процессор обрабатывает только одно сообщение за раз
4. Consumers (потребители) — конечные сервисы, получающие результаты обработки (например, Products API на схеме)
5. Storage (хранилище) — место временного хранения данных (файлов), которые нужно обработать
Как работает паттерн (по схеме):
1. Producers отправляют задачи (например, файлы) в Storage и ставят сообщения о задачах в Queue.
2. File Processors Pool подписывается на очередь и «соревнуется» за сообщения: как только сообщение появляется в Queue, процессоры пытаются его «захватить».
3. Как только File processor получает сообщение, он:
- извлекает задачу (например, файл из Storage);
- обрабатывает её (например, преобразует или анализирует файл);
- отправляет результат в Consumers (Products API).
4. После успешной обработки процессор подтверждает получение сообщения — оно удаляется из очереди
5. Параллельная работа нескольких File processor обеспечивает увеличение пропускной способности (указано на схеме: «Parallel work to boost throughput»)
Ключевые особенности:
- Конкуренция: потребители «соревнуются» за сообщения — каждое сообщение обрабатывается только одним потребителем
- Параллелизм: несколько процессоров работают одновременно, что ускоряет обработку
- Отказоустойчивость: если один процессор выходит из строя, другие продолжают обработку
- Масштабируемость: можно добавлять процессоры для увеличения нагрузки
- Асинхронность: производители не ждут завершения обработки — задачи помещаются в очередь и обрабатываются позже
Пример из схемы:
- Admin API (производители) отправляют файлы в Storage и уведомляют Queue.
- File processor (из пула) забирает уведомление, читает файл из Storage, обрабатывает его и передаёт результат в Products API (потребители).
- Другие File processor параллельно обрабатывают другие файлы, конкурируя за сообщения в Queue.
Преимущества:
- оптимизация пропускной способности;
- балансировка нагрузки;
- устойчивость к сбоям отдельных потребителей;
- возможность горизонтального масштабирования (добавление процессоров)
Возможные проблемы:
- дублирование сообщений (требуется идемпотентная обработка);
- неравномерное распределение нагрузки;
- переполнение очереди при высокой нагрузке;
- «ядовитые сообщения» (poison messages), которые невозможно обработать
Шаблон конкурирующих потребителей идеально подходит для систем с переменной нагрузкой, где задачи независимы и могут выполняться параллельно — например, обработка изображений, отправка писем, анализ логов. Схема наглядно демонстрирует распределение ролей и взаимодействие компонентов в этом паттерне.
(продолжение предыдущего поста)
Суть паттерна:
Шаблон конкурирующих потребителей (Competing Consumer Pattern) — это архитектурный шаблон, позволяющий нескольким потребителям (consumers) параллельно обрабатывать сообщения (задачи) из общей очереди. Цель — эффективно распределить нагрузку и повысить пропускную способность системы, обеспечив её отказоустойчивость
Компоненты на схеме:
1. Producers (производители) — генерируют задачи (сообщения), которые помещаются в очередь. На схеме это Admin API, отправляющие данные в хранилище (Storage) и очередь (Queue)
2. Queue (очередь) — централизованное хранилище сообщений, ожидающих обработки. Служит буфером между производителями и потребителями
3. File Processors Pool (пул процессоров файлов) — группа независимых потребителей (File processor), которые «соревнуются» за обработку сообщений из очереди. Каждый процессор обрабатывает только одно сообщение за раз
4. Consumers (потребители) — конечные сервисы, получающие результаты обработки (например, Products API на схеме)
5. Storage (хранилище) — место временного хранения данных (файлов), которые нужно обработать
Как работает паттерн (по схеме):
1. Producers отправляют задачи (например, файлы) в Storage и ставят сообщения о задачах в Queue.
2. File Processors Pool подписывается на очередь и «соревнуется» за сообщения: как только сообщение появляется в Queue, процессоры пытаются его «захватить».
3. Как только File processor получает сообщение, он:
- извлекает задачу (например, файл из Storage);
- обрабатывает её (например, преобразует или анализирует файл);
- отправляет результат в Consumers (Products API).
4. После успешной обработки процессор подтверждает получение сообщения — оно удаляется из очереди
5. Параллельная работа нескольких File processor обеспечивает увеличение пропускной способности (указано на схеме: «Parallel work to boost throughput»)
Ключевые особенности:
- Конкуренция: потребители «соревнуются» за сообщения — каждое сообщение обрабатывается только одним потребителем
- Параллелизм: несколько процессоров работают одновременно, что ускоряет обработку
- Отказоустойчивость: если один процессор выходит из строя, другие продолжают обработку
- Масштабируемость: можно добавлять процессоры для увеличения нагрузки
- Асинхронность: производители не ждут завершения обработки — задачи помещаются в очередь и обрабатываются позже
Пример из схемы:
- Admin API (производители) отправляют файлы в Storage и уведомляют Queue.
- File processor (из пула) забирает уведомление, читает файл из Storage, обрабатывает его и передаёт результат в Products API (потребители).
- Другие File processor параллельно обрабатывают другие файлы, конкурируя за сообщения в Queue.
Преимущества:
- оптимизация пропускной способности;
- балансировка нагрузки;
- устойчивость к сбоям отдельных потребителей;
- возможность горизонтального масштабирования (добавление процессоров)
Возможные проблемы:
- дублирование сообщений (требуется идемпотентная обработка);
- неравномерное распределение нагрузки;
- переполнение очереди при высокой нагрузке;
- «ядовитые сообщения» (poison messages), которые невозможно обработать
Шаблон конкурирующих потребителей идеально подходит для систем с переменной нагрузкой, где задачи независимы и могут выполняться параллельно — например, обработка изображений, отправка писем, анализ логов. Схема наглядно демонстрирует распределение ролей и взаимодействие компонентов в этом паттерне.
Telegram
METANIT.COM
Шаблон конкурирующих потребителей
(продолжение в следующем посте)
(продолжение в следующем посте)
❤5👍3🤝2
Индустрия видеоигр стоимостью 200 миллиардов долларов раздирается разногласиями по поводу того, как интегрировать ИИ в творческие процессы. Некоторые называют эту новую технологию следующей большой революцией, другие же критикуют как угрозу, подавляющую человеческую креативность и снижающую качество
Некоторые студии ожидают повышения производительности ИИ на 30-50% при выполнении базовых задач, таких как генерация изображений, но по-настоящему революционные изменения, такие как новые стили игр или человекоподобные персонажи, произойдут еще через несколько лет из-за сложной, междисциплинарной природы разработки игр
Вместе с этим разработчики игр теряют уверенность в потенциале ИИ. Почти половина ожидает, что использование ИИ ухудшит качество игр в следующем году. Так, около 47% разработчиков, опрошенных исследовательской компанией Omdia в прошлом году, заявили, что ожидают снижения качества игр из-за использования генеративного ИИ, что является негативным явлением по сравнению с предыдущим годом.
При этом количество тех, кто считает, что ИИ улучшит качество игр - около 15%
Кроме того, сами игроки становятся всё менее терпимыми к ошибкам искусственного интеллекта. Геймеры жалуются на роботизированные диалоги, повторяющиеся ошибки и классические проблемы генеративного ИИ, включая шестипалые кисти рук или странные глаза персонажей. Многие игроки считают, что ИИ лишает игры души и человеческого творчества.
https://www.bloomberg.com/news/articles/2026-02-25/ai-mistakes-are-infuriating-gamers-as-developers-seek-savings
Некоторые студии ожидают повышения производительности ИИ на 30-50% при выполнении базовых задач, таких как генерация изображений, но по-настоящему революционные изменения, такие как новые стили игр или человекоподобные персонажи, произойдут еще через несколько лет из-за сложной, междисциплинарной природы разработки игр
Вместе с этим разработчики игр теряют уверенность в потенциале ИИ. Почти половина ожидает, что использование ИИ ухудшит качество игр в следующем году. Так, около 47% разработчиков, опрошенных исследовательской компанией Omdia в прошлом году, заявили, что ожидают снижения качества игр из-за использования генеративного ИИ, что является негативным явлением по сравнению с предыдущим годом.
При этом количество тех, кто считает, что ИИ улучшит качество игр - около 15%
Кроме того, сами игроки становятся всё менее терпимыми к ошибкам искусственного интеллекта. Геймеры жалуются на роботизированные диалоги, повторяющиеся ошибки и классические проблемы генеративного ИИ, включая шестипалые кисти рук или странные глаза персонажей. Многие игроки считают, что ИИ лишает игры души и человеческого творчества.
https://www.bloomberg.com/news/articles/2026-02-25/ai-mistakes-are-infuriating-gamers-as-developers-seek-savings
Bloomberg.com
AI Mistakes Are Infuriating Gamers as Developers Seek Savings
Games and AI, seemingly a perfect match, are off to a rocky start
💯16❤5🤔4🤮1
В Max твердо и четко опровергли данные о распространении вируса
Специалисты центра безопасности мессенджера в проактивном режиме блокируют вредоносное программное обеспечение
Информация о распространении вируса в национальном мессенджере Max не соответствует действительности, специалисты центра безопасности платформы в проактивном режиме блокируют вредоносное программное обеспечение (ПО). Об этом сообщили в пресс-службе платформы.
Ранее в СМИ и соцсетях появилась информация, что в мессенджере Max якобы зафиксирован резкий всплеск активности киберпреступников, распространяющих опасный Android-вирус "Мамонт", который ворует деньги со смартфонов. "Информация о распространении вируса в Max не соответствует действительности. Специалисты центра безопасности проактивно выявляют и блокируют вредоносное ПО", - рассказали в пресс-службе. Там также подчеркнули, что все данные пользователей надежно защищены.
https://tass.ru/ekonomika/26630155
Специалисты центра безопасности мессенджера в проактивном режиме блокируют вредоносное программное обеспечение
Информация о распространении вируса в национальном мессенджере Max не соответствует действительности, специалисты центра безопасности платформы в проактивном режиме блокируют вредоносное программное обеспечение (ПО). Об этом сообщили в пресс-службе платформы.
Ранее в СМИ и соцсетях появилась информация, что в мессенджере Max якобы зафиксирован резкий всплеск активности киберпреступников, распространяющих опасный Android-вирус "Мамонт", который ворует деньги со смартфонов. "Информация о распространении вируса в Max не соответствует действительности. Специалисты центра безопасности проактивно выявляют и блокируют вредоносное ПО", - рассказали в пресс-службе. Там также подчеркнули, что все данные пользователей надежно защищены.
https://tass.ru/ekonomika/26630155
TACC
В Max опровергли данные о распространении вируса
Специалисты центра безопасности мессенджера в проактивном режиме блокируют вредоносное программное обеспечение
🤡60🤣10👍4
Для работы Windows 12 потребуется NPU с поддержкой ИИ и производительностью 40 TOPS
Согласно источникам, для работы Windows 12 потребуется выделенный NPU-чип с вычислительной мощностью не менее 40 TOPS.
Выпуск ОС с кодовым названием «Hudson Valley Next» запланирован на 2026 год, что совпадёт с окончанием поддержки Windows 10 в октябре. Окно выпуска соответствует схеме Microsoft по запуску крупных версий Windows каждые несколько лет, при этом Windows 11 продолжает получать поддержку и обновления.
Партнёры по аппаратному обеспечению Intel и AMD уже позиционируют процессоры со встроенным ускорением ИИ, а производители оборудования маркируют новые системы как «готовые к Windows 12».
Ожидается, что новая ОС представит модульную архитектуру CorePC, которая коренным образом изменит её структуру. Компоненты Windows станут более изолированными друг от друга, что позволит осуществлять поэтапные обновления и масштабируемые версии для различных категорий устройств, от планшетов до высокопроизводительных рабочих станций.
Наиболее значительным изменением станет интеграция ИИ. В отличие от помощника Copilot в Windows 11, в Windows 12 ИИ станет центральной системой управления. Контекстно-зависимые рекомендации задач, сводки контента в реальном времени, автоматическая категоризация документов и семантический поиск будут работать на уровне всей системы, а не как отдельные функции.
Windows 12 также получит плавающую панель задач со скруглёнными углами, которая отсоединяется от нижней части экрана, прозрачные стеклянные элементы по всему интерфейсу и системные индикаторы в верхнем правом углу. В верхней части экрана по центру расположится строка поиска с прямой интеграцией с Copilot.
Таким образом, устройства без NPU достаточной мощности могут не поддерживать некоторые функции ИИ, либо же им полностью заблокируют возможность обновления до Windows 12.
Судя по коду, Windows 12 сохранит традиционную разовую лицензию для базовой версии Home, но добавит элементы подписки для премиальных функций ИИ. Эта гибридная модель может предложить дополнительные вычислительные мощности в облаке и эксклюзивные возможности ИИ через среду Windows 365.
https://tbreak.com/windows-12-leaked-2026-ai-npu-requirement/
Согласно источникам, для работы Windows 12 потребуется выделенный NPU-чип с вычислительной мощностью не менее 40 TOPS.
Выпуск ОС с кодовым названием «Hudson Valley Next» запланирован на 2026 год, что совпадёт с окончанием поддержки Windows 10 в октябре. Окно выпуска соответствует схеме Microsoft по запуску крупных версий Windows каждые несколько лет, при этом Windows 11 продолжает получать поддержку и обновления.
Партнёры по аппаратному обеспечению Intel и AMD уже позиционируют процессоры со встроенным ускорением ИИ, а производители оборудования маркируют новые системы как «готовые к Windows 12».
Ожидается, что новая ОС представит модульную архитектуру CorePC, которая коренным образом изменит её структуру. Компоненты Windows станут более изолированными друг от друга, что позволит осуществлять поэтапные обновления и масштабируемые версии для различных категорий устройств, от планшетов до высокопроизводительных рабочих станций.
Наиболее значительным изменением станет интеграция ИИ. В отличие от помощника Copilot в Windows 11, в Windows 12 ИИ станет центральной системой управления. Контекстно-зависимые рекомендации задач, сводки контента в реальном времени, автоматическая категоризация документов и семантический поиск будут работать на уровне всей системы, а не как отдельные функции.
Windows 12 также получит плавающую панель задач со скруглёнными углами, которая отсоединяется от нижней части экрана, прозрачные стеклянные элементы по всему интерфейсу и системные индикаторы в верхнем правом углу. В верхней части экрана по центру расположится строка поиска с прямой интеграцией с Copilot.
Таким образом, устройства без NPU достаточной мощности могут не поддерживать некоторые функции ИИ, либо же им полностью заблокируют возможность обновления до Windows 12.
Судя по коду, Windows 12 сохранит традиционную разовую лицензию для базовой версии Home, но добавит элементы подписки для премиальных функций ИИ. Эта гибридная модель может предложить дополнительные вычислительные мощности в облаке и эксклюзивные возможности ИИ через среду Windows 365.
https://tbreak.com/windows-12-leaked-2026-ai-npu-requirement/
Tbreak Media
Windows 12 leaked: 2026 release needs AI NPU chip | tbreak
Microsoft's next OS demands 40 TOPS NPU chips and launches when Windows 10 support ends in 2026. The leaked 'Hudson Valley Next' features floating taskbars, system-wide AI, and potential subscription models for premium features.
🤡54🥴5❤2🤔2💩2⚡1🖕1
OpenAI работает над альтернативой GitHub
OpenAI приступила к созданию собственной альтернативы популярной платформе для размещения кода GitHub. Проект призван снизить зависимость компании от Microsoft. Новый сервис находится на ранней стадии и используется как внутренняя альтернатива GitHub, но компания уже обсуждает возможность продавать его существующим клиентам.
Как полагают эксперты, создание собственной платформы поможет снизить зависимость от Microsoft. Кроме того, решение может быть вызвано серией серьёзных сбоев на GitHub, которые наблюдались с октября 2025 года.
https://www.theinformation.com/articles/openai-developing-alternative-microsofts-github
OpenAI приступила к созданию собственной альтернативы популярной платформе для размещения кода GitHub. Проект призван снизить зависимость компании от Microsoft. Новый сервис находится на ранней стадии и используется как внутренняя альтернатива GitHub, но компания уже обсуждает возможность продавать его существующим клиентам.
Как полагают эксперты, создание собственной платформы поможет снизить зависимость от Microsoft. Кроме того, решение может быть вызвано серией серьёзных сбоев на GitHub, которые наблюдались с октября 2025 года.
https://www.theinformation.com/articles/openai-developing-alternative-microsofts-github
The Information
OpenAI Is Developing an Internal Alternative to Microsoft’s GitHub
OpenAI is developing an alternative to GitHub, Microsoft’s popular code repository that lets software engineers store, share and collaborate on computer code, according to a person with knowledge of the project. The decision to embark on the new product came…
🤔11🖕9👀1