This commit is contained in:
@@ -1,6 +1,7 @@
|
|||||||
---
|
---
|
||||||
aliases:
|
aliases:
|
||||||
- узкое место
|
- узкое место
|
||||||
|
- узкое горлышко
|
||||||
tags:
|
tags:
|
||||||
- maturity/🌱
|
- maturity/🌱
|
||||||
date: 2024-12-01
|
date: 2024-12-01
|
||||||
|
|||||||
57
dev/architecture/Infrastructure as a Service.md
Normal file
57
dev/architecture/Infrastructure as a Service.md
Normal file
@@ -0,0 +1,57 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- IaaS
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
**Infrastructure as a Service (IaaS)** — это модель доставки облачных вычислений, в которой пользователи получают доступ к виртуализированным вычислительным ресурсам через интернет. IaaS предоставляет базовую инфраструктуру, такую как серверы, хранилище, сети и операционные системы, что позволяет компаниям создавать и управлять своими приложениями без необходимости физического владения оборудованием.
|
||||||
|
|
||||||
|
**Основные компоненты IaaS**
|
||||||
|
- **Виртуальные серверы**: Вычислительные ресурсы, которые можно масштабировать по мере необходимости.
|
||||||
|
- **Хранилище данных**: Диски для хранения файлов, баз данных и резервных копий.
|
||||||
|
- **Сетевые ресурсы**: Виртуальные сети, балансировщики нагрузки, межсетевые экраны.
|
||||||
|
- **Поддержка операционных систем**: Возможность установки и настройки различных ОС.
|
||||||
|
|
||||||
|
**Особенности IaaS**
|
||||||
|
- **Гибкость**: Пользователи могут настраивать инфраструктуру под свои нужды.
|
||||||
|
- **Масштабируемость**: Ресурсы легко увеличиваются или уменьшаются в зависимости от текущих потребностей.
|
||||||
|
- **Оплата за использование**: Биллинг основан на потребленных ресурсах (CPU, RAM, трафик, хранилище).
|
||||||
|
- **Удалённый доступ**: Управление осуществляется через веб-интерфейсы или API.
|
||||||
|
|
||||||
|
**Преимущества IaaS**
|
||||||
|
- **Экономия затрат**: Нет необходимости инвестировать в физическое оборудование.
|
||||||
|
- **Быстрое развертывание**: Новые ресурсы можно запустить за считанные минуты.
|
||||||
|
- **Масштабируемость**: Удобно для приложений с переменной нагрузкой.
|
||||||
|
- **Глобальное покрытие**: Дата-центры провайдеров находятся по всему миру, что снижает задержки.
|
||||||
|
- **Резервирование**: Автоматическое создание бэкапов и управление отказоустойчивостью.
|
||||||
|
|
||||||
|
**Недостатки IaaS**
|
||||||
|
- **Сложность управления**: Пользователи сами отвечают за настройку и поддержку приложений.
|
||||||
|
- **Безопасность**: Необходимость контроля за безопасностью данных и приложений.
|
||||||
|
- **Зависимость от провайдера**: Зачастую сложно мигрировать между платформами.
|
||||||
|
|
||||||
|
**Примеры IaaS**
|
||||||
|
- **Amazon Web Services (AWS)**: EC2, S3, VPC.
|
||||||
|
- **Microsoft Azure**: Virtual Machines, Blob Storage, Virtual Network.
|
||||||
|
- **Google Cloud Platform (GCP)**: Compute Engine, Persistent Disk, Cloud Networking.
|
||||||
|
- **DigitalOcean**: Droplets, Spaces, Load Balancers.
|
||||||
|
|
||||||
|
**Когда использовать IaaS**
|
||||||
|
- Для разработки и тестирования: Быстрое развертывание инфраструктуры для новых проектов.
|
||||||
|
- Для хостинга приложений: Удобно для веб-приложений, микросервисов и API.
|
||||||
|
- Для хранения и обработки данных: Хранилища для больших объемов данных с гибкими параметрами доступа.
|
||||||
|
- Для обеспечения отказоустойчивости: Резервное копирование и масштабирование ресурсов.
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
|
||||||
|
**Родитель**:: [[Модель доставки программного обеспечения|Модель доставки программного обеспечения]]
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
93
dev/architecture/Multitenancy.md
Normal file
93
dev/architecture/Multitenancy.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
Multitenancy (мультиарендность) — это [[Архитектурный паттерн|архитектурный подход]] в разработке программного обеспечения, при котором одна инсталляция приложения обслуживает несколько независимых клиентов (арендаторов, **tenants**). Этот подход широко используется в облачных приложениях и [[Software as a Service|SaaS]], чтобы оптимизировать использование ресурсов и упростить управление системой.
|
||||||
|
|
||||||
|
**Основные аспекты Multitenancy**
|
||||||
|
1. **Tenant** — это отдельный клиент системы, который может представлять компанию, организацию или пользователя. Каждому арендатору предоставляется ощущение, что он работает с собственным приложением, хотя технически это один экземпляр.
|
||||||
|
2. **Изоляция данных** — данные каждого арендатора изолированы от других. Это может быть достигнуто разными способами, от использования отдельных баз данных до разделения данных в пределах одной таблицы.
|
||||||
|
3. **Общие ресурсы** — приложение, серверы, инфраструктура (например, база данных или сервер API) могут использоваться совместно всеми арендаторами, что снижает затраты на поддержку.
|
||||||
|
|
||||||
|
**Преимущества Multitenancy**
|
||||||
|
- **Экономия ресурсов**: Использование одной инстанции позволяет сократить затраты на серверы, обновления и управление.
|
||||||
|
- **Упрощенное обновление**: Обновление приложения на уровне всей системы вместо работы с каждой инстанцией отдельно.
|
||||||
|
- **Снижение времени на развертывание**: Новый арендатор может быть добавлен в систему быстро.
|
||||||
|
|
||||||
|
**Недостатки Multitenancy**
|
||||||
|
- **Сложность в реализации**: Разделение данных, обеспечение безопасности и настройка кастомизации требуют дополнительных усилий.
|
||||||
|
- **Риски утечек данных**: Неправильная конфигурация может привести к тому, что данные одного арендатора будут доступны другому.
|
||||||
|
- Ограничения [[Масштабирование информационной системы|масштабируемости]]: В некоторых сценариях одна инстанция может не справляться с нагрузкой.
|
||||||
|
|
||||||
|
**Варианты реализации Multitenancy**
|
||||||
|
- **Одна база данных, общая схема**:
|
||||||
|
- Все арендаторы используют одну базу данных и одну схему.
|
||||||
|
- Данные разделяются с помощью столбца, например tenant_id.
|
||||||
|
- **Плюсы**:
|
||||||
|
- Простая реализация и минимальные затраты на управление.
|
||||||
|
- Подходит для большого числа арендаторов.
|
||||||
|
- **Минусы**:
|
||||||
|
- Сложнее обеспечить безопасность и [[Масштабирование информационной системы|масштабируемость]].
|
||||||
|
- Риск потери производительности при большом объеме данных.
|
||||||
|
- **Одна база данных, несколько схем**:
|
||||||
|
- У каждого арендатора своя схема в базе данных.
|
||||||
|
- **Плюсы**:
|
||||||
|
- Лучшая изоляция данных.
|
||||||
|
- Упрощенная миграция данных между арендаторами.
|
||||||
|
- **Минусы**:
|
||||||
|
- Более сложное управление.
|
||||||
|
- Ограничения базы данных по количеству схем.
|
||||||
|
- **Отдельная база данных для каждого арендатора**:
|
||||||
|
- **Плюсы**:
|
||||||
|
- Максимальная изоляция данных и высокая безопасность.
|
||||||
|
- Упрощенная настройка бэкапов.
|
||||||
|
- **Минусы**:
|
||||||
|
- Увеличение затрат на управление и инфраструктуру.
|
||||||
|
- Сложнее масштабировать при большом числе арендаторов.
|
||||||
|
- **Выделенная инфраструктура**: У каждого арендатора не только своя база данных, но и свои серверы приложений.
|
||||||
|
- **Плюсы**: Абсолютная изоляция данных и производительности.
|
||||||
|
- **Минусы**: Высокие затраты на разработку и поддержку.
|
||||||
|
## О чем стоит подумать
|
||||||
|
Внедрение multitenancy — это задача, требующая продуманного подхода. Вот советы, которые помогут грамотно реализовать multitenancy:
|
||||||
|
|
||||||
|
**Определитесь с уровнем изоляции данных**. Первым шагом нужно решить, как данные будут изолироваться между арендаторами:
|
||||||
|
- **Одна база данных, общая схема**
|
||||||
|
- **Одна база данных, отдельные схемы для арендаторов**
|
||||||
|
- **Отдельная база данных для каждого арендатора**
|
||||||
|
|
||||||
|
**Разработайте механизм идентификации арендаторов**. Ваше приложение должно “знать”, с каким арендатором оно работает:
|
||||||
|
- Используйте **поддомен** (e.g., tenant1.crm.com), чтобы определять арендатора по URL.
|
||||||
|
- Передавайте идентификатор арендатора через **заголовки HTTP** или токены доступа (например, JWT с tenant_id).
|
||||||
|
- Подумайте о настройках “по умолчанию”, если арендатор не указан (например, демонстрационный режим).
|
||||||
|
|
||||||
|
**Реализуйте гибкость в настройках для арендаторов**. Система должна позволять кастомизацию для каждого арендатора:
|
||||||
|
- **UI/UX**: Логотип, цветовая схема, название компании.
|
||||||
|
- **Функциональность**: Включение/отключение модулей (например, модуль отчетности, интеграции).
|
||||||
|
- **Бизнес-логика**: Разные правила для обработки сделок, клиентов или аналитики.
|
||||||
|
|
||||||
|
**Позаботьтесь о безопасности**. Безопасность — один из ключевых факторов в multitenancy. Убедитесь, что:
|
||||||
|
- **Изоляция данных**: Каждый запрос фильтруется по tenant_id или привязан к отдельной схеме/базе.
|
||||||
|
- **Шифрование**:
|
||||||
|
- Данные должны быть зашифрованы в покое и при передаче.
|
||||||
|
- Используйте разные ключи шифрования для каждого арендатора.
|
||||||
|
- **Роли и доступы**: Гибкая система управления ролями, чтобы пользователи арендаторов видели только свои данные.
|
||||||
|
|
||||||
|
**Планируйте систему обновлений**
|
||||||
|
- Backward compatibility: Не ломайте существующий функционал для арендаторов при выпуске обновлений.
|
||||||
|
- Используйте feature toggles: Включайте новые функции для отдельных арендаторов постепенно.
|
||||||
|
- Тестируйте обновления на выделенной “песочнице”.
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
|
||||||
|
**Родитель**:: [[Архитектурный паттерн]]
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
60
dev/architecture/Platform as a Service.md
Normal file
60
dev/architecture/Platform as a Service.md
Normal file
@@ -0,0 +1,60 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- PaaS
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
**Platform as a Service (PaaS)** — это [[Модель доставки программного обеспечения|модель доставки]] облачных вычислений, предоставляющая разработчикам готовую платформу для разработки, тестирования, развертывания и управления приложениями. PaaS избавляет от необходимости управлять инфраструктурой, такой как серверы, базы данных и операционные системы, и позволяет сосредоточиться исключительно на разработке программного обеспечения.
|
||||||
|
|
||||||
|
**Основные компоненты PaaS**
|
||||||
|
- **Среда разработки**: Инструменты для написания и тестирования кода (IDE, CI/CD).
|
||||||
|
- **Инструменты для развертывания**: Механизмы автоматического деплоя приложений.
|
||||||
|
- **Управление данными**: Подключение к базам данных и хранилищам.
|
||||||
|
- **Масштабируемость**: Автоматическое масштабирование приложений в зависимости от нагрузки.
|
||||||
|
- **API и SDK**: Интерфейсы для взаимодействия с платформой и другими сервисами.
|
||||||
|
|
||||||
|
**Особенности PaaS**
|
||||||
|
- **Автоматизация инфраструктуры**: Пользователь управляет только приложением, а инфраструктура автоматизируется.
|
||||||
|
- **Гибкость**: Поддержка различных языков программирования, фреймворков и библиотек.
|
||||||
|
- **Интеграция**: Простая работа с базами данных, API и сторонними сервисами.
|
||||||
|
- **Мультиарендность (Multitenancy)**: Разделение ресурсов между несколькими пользователями с изоляцией данных.
|
||||||
|
|
||||||
|
**Преимущества PaaS**
|
||||||
|
- **Ускорение разработки**: Быстрый доступ к инструментам и средам разработки.
|
||||||
|
- **Снижение затрат**: Нет необходимости закупать и поддерживать оборудование.
|
||||||
|
- **Упрощённое развертывание**: Поддержка CI/CD и автоматизации.
|
||||||
|
- **Масштабируемость**: Платформа автоматически подстраивается под нагрузку приложения.
|
||||||
|
- **Готовые интеграции**: Доступ к базам данных, системам аналитики и другим сервисам без необходимости настройки.
|
||||||
|
|
||||||
|
**Недостатки PaaS**
|
||||||
|
- **Ограничения по кастомизации**: Возможности платформы могут быть ограничены для специфических нужд.
|
||||||
|
- **Зависимость от провайдера**: Трудности при миграции на другую платформу.
|
||||||
|
- **Стоимость**: При интенсивном использовании сервисов расходы могут вырасти.
|
||||||
|
- **Совместимость**: Некоторые платформы поддерживают не все языки и фреймворки.
|
||||||
|
|
||||||
|
**Примеры PaaS**
|
||||||
|
- **Heroku**: Простая платформа для развертывания и управления приложениями.
|
||||||
|
- **Google App Engine**: Облачная платформа от Google для масштабируемых приложений.
|
||||||
|
- **AWS Elastic Beanstalk**: Платформа от AWS с поддержкой множества языков.
|
||||||
|
- **Microsoft Azure App Service**: Платформа для создания веб- и мобильных приложений.
|
||||||
|
- **Red Hat OpenShift**: PaaS для контейнеризированных приложений.
|
||||||
|
|
||||||
|
**Когда использовать PaaS**
|
||||||
|
- **Стартапы**: Быстрый запуск MVP с минимальными затратами на инфраструктуру.
|
||||||
|
- **Разработка корпоративных приложений**: Ускорение цикла разработки и тестирования.
|
||||||
|
- **Мультиоблачная стратегия**: Разработка приложений, работающих в нескольких облаках.
|
||||||
|
- **Проекты с динамической нагрузкой**: Автоматическое масштабирование без сложной настройки.
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
|
||||||
|
**Родитель**:: [[Модель доставки программного обеспечения]]
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
@@ -8,6 +8,7 @@ aliases:
|
|||||||
- балансировке нагрузки
|
- балансировке нагрузки
|
||||||
- алгоритмами балансировки
|
- алгоритмами балансировки
|
||||||
- балансировкой нагрузки
|
- балансировкой нагрузки
|
||||||
|
- алгоритмы балансировки
|
||||||
tags:
|
tags:
|
||||||
- maturity/🌱
|
- maturity/🌱
|
||||||
date: 2024-06-13
|
date: 2024-06-13
|
||||||
@@ -15,9 +16,10 @@ date: 2024-06-13
|
|||||||
![[../../../meta/files/images/Pasted image 20241103021050.png]]
|
![[../../../meta/files/images/Pasted image 20241103021050.png]]
|
||||||
|
|
||||||
**Статические алгоритмы**
|
**Статические алгоритмы**
|
||||||
- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть [[../Stateless Service|stateless]] (не сохранять состояние между запросами).
|
- **Random.** Запросы от клиентов отправляются по разным экземплярам сервиса в случайном порядке.
|
||||||
|
- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть [[../Stateless Service|stateless]].
|
||||||
|
- **Weighted round-robin**. Администратор может задать вес для каждого сервиса. Сервисы с большим весом будут обрабатывать больше запросов, чем другие.
|
||||||
- **Sticky round-robin** Улучшенная версия алгоритма round robin. Если первый запрос от Алисы попал на сервис A, то и все последующие её запросы будут отправляться на этот же сервис A.
|
- **Sticky round-robin** Улучшенная версия алгоритма round robin. Если первый запрос от Алисы попал на сервис A, то и все последующие её запросы будут отправляться на этот же сервис A.
|
||||||
- **Weighted round-robin** Администратор может задать вес для каждого сервиса. Сервисы с большим весом будут обрабатывать больше запросов, чем другие.
|
|
||||||
- **Hash (Хеширование)** Этот алгоритм применяет хеш-функцию к IP-адресу или URL запроса. Запросы направляются на соответствующие экземпляры сервиса в зависимости от результата [[../../cryptography/Хеш-функция|хеш-функции]].
|
- **Hash (Хеширование)** Этот алгоритм применяет хеш-функцию к IP-адресу или URL запроса. Запросы направляются на соответствующие экземпляры сервиса в зависимости от результата [[../../cryptography/Хеш-функция|хеш-функции]].
|
||||||
- [[../Session Affinity|Session Affinity]]
|
- [[../Session Affinity|Session Affinity]]
|
||||||
|
|
||||||
|
|||||||
@@ -14,7 +14,7 @@ date:
|
|||||||
1. **Простота управления**: Управление одной машиной обычно проще, чем управление кластером машин, что упрощает администрирование и техническое обслуживание.
|
1. **Простота управления**: Управление одной машиной обычно проще, чем управление кластером машин, что упрощает администрирование и техническое обслуживание.
|
||||||
2. **Совместимость с приложениями**: Вертикальное масштабирование часто не требует изменений в архитектуре или конфигурации приложений, что делает его более простым в реализации для некоторых систем.
|
2. **Совместимость с приложениями**: Вертикальное масштабирование часто не требует изменений в архитектуре или конфигурации приложений, что делает его более простым в реализации для некоторых систем.
|
||||||
3. **Меньшая сложность**: Отсутствие необходимости в распределенной обработке данных упрощает архитектуру и может обеспечить более высокую производительность для определенных типов задач.
|
3. **Меньшая сложность**: Отсутствие необходимости в распределенной обработке данных упрощает архитектуру и может обеспечить более высокую производительность для определенных типов задач.
|
||||||
4. **Немедленное улучшение производительности**: Добавление ресурсов к существующему серверу может обеспечить немедленное улучшение производительности без необходимости перераспределения данных или изменения архитектуры системы.
|
4. **Немедленное улучшение производительности**: Добавление [[../../other/Ресурсы для работы приложений|ресурсов]] к существующему серверу может обеспечить немедленное улучшение производительности без необходимости перераспределения данных или изменения архитектуры системы.
|
||||||
- Самый простой способ масштабирования
|
- Самый простой способ масштабирования
|
||||||
|
|
||||||
**Проблемы:**
|
**Проблемы:**
|
||||||
|
|||||||
@@ -10,7 +10,7 @@ date:
|
|||||||
|
|
||||||
**Плюсы:**
|
**Плюсы:**
|
||||||
- **Масштабируемость**: Горизонтальное масштабирование позволяет системе легко масштабироваться в соответствии с увеличением нагрузки, добавляя больше машин в кластер. Теоретически бесконечно, но физически есть пределы.
|
- **Масштабируемость**: Горизонтальное масштабирование позволяет системе легко масштабироваться в соответствии с увеличением нагрузки, добавляя больше машин в кластер. Теоретически бесконечно, но физически есть пределы.
|
||||||
- **Гибкость**: Можно добавлять дополнительные ресурсы по мере необходимости, что позволяет лучше адаптироваться к изменяющимся требованиям без простоев.
|
- **Гибкость**: Можно добавлять дополнительные [[../../other/Ресурсы для работы приложений|ресурсы]] по мере необходимости, что позволяет лучше адаптироваться к изменяющимся требованиям без простоев.
|
||||||
- **Надежность и доступность**: Распределение нагрузки и данных между множеством узлов может улучшить общую надежность и доступность системы, так как отказ одного узла не приведет к сбою всей системы.
|
- **Надежность и доступность**: Распределение нагрузки и данных между множеством узлов может улучшить общую надежность и доступность системы, так как отказ одного узла не приведет к сбою всей системы.
|
||||||
- **Географическое распределение**: Узлы могут быть географически распределены, что помогает минимизировать задержки и улучшить производительность для пользователей в разных регионах.
|
- **Географическое распределение**: Узлы могут быть географически распределены, что помогает минимизировать задержки и улучшить производительность для пользователей в разных регионах.
|
||||||
|
|
||||||
|
|||||||
@@ -15,6 +15,7 @@ date: 2024-12-02
|
|||||||
|
|
||||||
- [[Event Sourcing]]
|
- [[Event Sourcing]]
|
||||||
- [[../../../../knowledge/dev/архитектура/паттерн/Command Query Responsibility Segregation|CQRS]]
|
- [[../../../../knowledge/dev/архитектура/паттерн/Command Query Responsibility Segregation|CQRS]]
|
||||||
|
- [[Multitenancy|Multitenancy]]
|
||||||
|
|
||||||
Миграция/синхронизация данных:
|
Миграция/синхронизация данных:
|
||||||
- [[Change Data Capture|Change Data Capture]]
|
- [[Change Data Capture|Change Data Capture]]
|
||||||
@@ -35,7 +36,7 @@ date: 2024-12-02
|
|||||||
- [[Serverless]]
|
- [[Serverless]]
|
||||||
- [[Монолитная архитектура]]
|
- [[Монолитная архитектура]]
|
||||||
- [[Событийно-ориентированная архитектура]]
|
- [[Событийно-ориентированная архитектура]]
|
||||||
- [[00 Микросервисная архитектура]]
|
|
||||||
- [[Command Query Responsibility Segregation]]
|
- [[Command Query Responsibility Segregation]]
|
||||||
|
- [[00 Микросервисная архитектура]]
|
||||||
<!-- SerializedQuery END -->
|
<!-- SerializedQuery END -->
|
||||||
|
|
||||||
|
|||||||
@@ -23,7 +23,7 @@ linked:
|
|||||||
|
|
||||||
|
|
||||||
## Почему простаивание потока — это проблема?
|
## Почему простаивание потока — это проблема?
|
||||||
Каждый поток нуждается в памяти для хранения своего стека вызовов и других связанных с ним структур данных. ==Когда поток простаивает, он продолжает потреблять ресурсы для поддержания своего состояния.==
|
Каждый поток нуждается в памяти для хранения своего стека вызовов и других связанных с ним структур данных. ==Когда поток простаивает, он продолжает потреблять [[../other/Ресурсы для работы приложений|ресурсы]] для поддержания своего состояния.==
|
||||||
|
|
||||||
Кроме того, процессорное время, которое выделяется неработающим потокам, могло бы быть использовано для других задач. Если большое количество потоков простаивает, это может привести к увеличению загрузки процессора и снижению производительности, так как операционная система будет тратить больше времени на [[../fundamental/Переключение контекста|переключение между потоками]].
|
Кроме того, процессорное время, которое выделяется неработающим потокам, могло бы быть использовано для других задач. Если большое количество потоков простаивает, это может привести к увеличению загрузки процессора и снижению производительности, так как операционная система будет тратить больше времени на [[../fundamental/Переключение контекста|переключение между потоками]].
|
||||||
|
|
||||||
|
|||||||
@@ -5,6 +5,7 @@ aliases:
|
|||||||
- бэкенда
|
- бэкенда
|
||||||
- бэкенду
|
- бэкенду
|
||||||
- Приложение
|
- Приложение
|
||||||
|
- приложения
|
||||||
tags:
|
tags:
|
||||||
- maturity/🌱
|
- maturity/🌱
|
||||||
date:
|
date:
|
||||||
|
|||||||
@@ -4,6 +4,7 @@ aliases:
|
|||||||
- гранулярность микросервисов
|
- гранулярность микросервисов
|
||||||
- декомпозиции на микросервисы
|
- декомпозиции на микросервисы
|
||||||
- декомпозиции системы
|
- декомпозиции системы
|
||||||
|
- гранулярности микросервисов
|
||||||
tags:
|
tags:
|
||||||
- maturity/🌱
|
- maturity/🌱
|
||||||
date: 2024-11-24
|
date: 2024-11-24
|
||||||
|
|||||||
@@ -3,6 +3,7 @@ aliases:
|
|||||||
- кэш
|
- кэш
|
||||||
- кэша
|
- кэша
|
||||||
- кеш
|
- кеш
|
||||||
|
- кешировать
|
||||||
tags:
|
tags:
|
||||||
- maturity/🌱
|
- maturity/🌱
|
||||||
date:
|
date:
|
||||||
|
|||||||
41
dev/architecture/Модель доставки программного обеспечения.md
Normal file
41
dev/architecture/Модель доставки программного обеспечения.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- модель доставки
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
**Модель доставки** — это способ предоставления программного обеспечения пользователю. Она определяет, как пользователи получают доступ к приложению, его функциональности, а также как распределяются и управляются ресурсы. Выбор модели доставки влияет на архитектуру приложения, его масштабируемость, стоимость и удобство использования.
|
||||||
|
|
||||||
|
Модели доставки являются основой для большинства современных IT-решений, особенно в области облачных технологий, где пользователи могут получить доступ к сервисам через интернет. Правильный выбор модели позволяет оптимально удовлетворить потребности бизнеса и конечных пользователей.
|
||||||
|
|
||||||
|
Наиболее распространенные модели доставки программного обеспечения:
|
||||||
|
- SaaS ([[Software as a Service]]): ПО как услуга.
|
||||||
|
- IaaS ([[Infrastructure as a Service]]): Инфраструктура как услуга.
|
||||||
|
- PaaS ([[Platform as a Service]]): Платформа как услуга.
|
||||||
|
- FaaS (Function as a Service): Функция как услуга ([[Serverless|serverless]]).
|
||||||
|
- CaaS (Container as a Service): Контейнеры как услуга.
|
||||||
|
- BaaS (Backend as a Service): Бэкенд как услуга.
|
||||||
|
- DaaS (Desktop as a Service): Рабочий стол как услуга.
|
||||||
|
- DBaaS (Database as a Service): База данных как услуга.
|
||||||
|
- AIaaS (Artificial Intelligence as a Service): Искусственный интеллект как услуга.
|
||||||
|
- XaaS (Everything as a Service): Всё как услуга.
|
||||||
|
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
|
||||||
|
**Родитель**::
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
- [[Software as a Service]]
|
||||||
|
- [[Infrastructure as a Service]]
|
||||||
|
- [[Platform as a Service]]
|
||||||
|
<!-- SerializedQuery END -->
|
||||||
|
|
||||||
26
dev/database/Isolation.md
Normal file
26
dev/database/Isolation.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date:
|
||||||
|
- - 2024-09-02
|
||||||
|
---
|
||||||
|
**Изолированность (isolation).** Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат.
|
||||||
|
|
||||||
|
- Защищает от [Race condition](../other/Race%20condition.md).
|
||||||
|
- [[../../../../_inbox/Согласованность транзакции БД (Сonsistency)|Согласованность транзакции БД (Сonsistency)]] без [Isolation](Isolation.md) не достижима.
|
||||||
|
|
||||||
|
При чтении решить проблему изоляции проще. Например, каждый участник читает свою версию данных. Но вовремя записи нет способа (с алгоритмической точки зрения) изолировать участников, которые обновляют одни и те же данные. Необходимо каким-то способом сигнализировать участникам, что одновременно кто-то еще работает с данными.
|
||||||
|
|
||||||
|
Основной способ обеспечить изоляцию это [Блокировка](../fundamental/Блокировка.md).
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Реляционная база данных|00 Реляционная база данных]]
|
||||||
|
**Родитель**:: [[Свойства транзакций БД]]
|
||||||
|
**Источник**::
|
||||||
|
**Автор**::
|
||||||
|
**Создана**:: [[2024-09-02]]
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
27
dev/database/Свойства транзакций БД.md
Normal file
27
dev/database/Свойства транзакций БД.md
Normal file
@@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- ACID
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-13
|
||||||
|
---
|
||||||
|
-
|
||||||
|
- [[Согласованность транзакции БД (Сonsistency)|Сonsistency]]
|
||||||
|
-
|
||||||
|
-
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Реляционная база данных|00 Реляционная база данных]]
|
||||||
|
**Родитель**::
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-13]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
- [[Согласованность транзакции БД (Сonsistency)]]
|
||||||
|
<!-- SerializedQuery END -->
|
||||||
|
|
||||||
@@ -7,7 +7,7 @@ date: 2023-11-02
|
|||||||
---
|
---
|
||||||
При создании VIEW в [[../../../../knowledge/dev/Liquibase|Liquibase]] возникают трудности с её поддержкой, особенно когда исходная таблица, меняется. Это становится ещё сложнее, если несколько VIEW ссылаются на одну таблицу. Когда происходят изменения, становится сложно быстро найти актуальный скрипт для создания VIEW, так как изменения могут быть разбросаны по нескольким файлам или версиям.
|
При создании VIEW в [[../../../../knowledge/dev/Liquibase|Liquibase]] возникают трудности с её поддержкой, особенно когда исходная таблица, меняется. Это становится ещё сложнее, если несколько VIEW ссылаются на одну таблицу. Когда происходят изменения, становится сложно быстро найти актуальный скрипт для создания VIEW, так как изменения могут быть разбросаны по нескольким файлам или версиям.
|
||||||
|
|
||||||
Для упрощения управления все VIEW выносятся в отдельный changeLog файл. Этот файл всегда указывается в конце основного master changeLog, поскольку VIEW создаются после создания всех таблиц, чтобы обеспечить корректность их работы.
|
Для упрощения управления все VIEW выносятся в отдельный changeLog файл. Этот файл всегда указывается в конце основного master changeLog. Он будет удалять VIEWs и создавать их заново. Таким образом у нас будет одно место в котором описаны скрипты создания VIEWs, и мы будем изменять их при необходимости, а не создавать новый changeSet.
|
||||||
|
|
||||||
Пример master changeLog файла:
|
Пример master changeLog файла:
|
||||||
```xml
|
```xml
|
||||||
|
|||||||
@@ -16,7 +16,7 @@ linked:
|
|||||||
- [Контейнерная виртуализация](Контейнерная%20виртуализация.md)
|
- [Контейнерная виртуализация](Контейнерная%20виртуализация.md)
|
||||||
- [Гипервизор](../../../../_inbox/Гипервизор.md)
|
- [Гипервизор](../../../../_inbox/Гипервизор.md)
|
||||||
|
|
||||||
Виртуализация помогает увеличить эффективность использования ресурсов, упрощает управление ИТ-инфраструктурой, повышает гибкость и масштабируемость систем, а также улучшает безопасность и изоляцию приложений.
|
Виртуализация помогает увеличить эффективность использования [[../other/Ресурсы для работы приложений|ресурсов]], упрощает управление ИТ-инфраструктурой, повышает гибкость и масштабируемость систем, а также улучшает безопасность и изоляцию приложений.
|
||||||
|
|
||||||
|
|
||||||
***
|
***
|
||||||
|
|||||||
49
dev/network/Client-Assisted Routing.md
Normal file
49
dev/network/Client-Assisted Routing.md
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- Клиент-ориентированная маршрутизация
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
Клиент-ориентированная маршрутизация (англ. Client-Assisted Routing) — это стратегия, которая сочетает традиционные сетевые технологии ([[Geo Base DNS|Geo DNS]], Anycast) с данными о производительности, собираемыми на клиентской стороне.
|
||||||
|
|
||||||
|
Вместо того, чтобы полагаться исключительно на географическое местоположение пользователя, система анализирует фактическую производительность подключения, такую как:
|
||||||
|
- [[../architecture/Latency|Задержки]] (latency);
|
||||||
|
- Пропускная способность (bandwidth);
|
||||||
|
- Надежность маршрутов.
|
||||||
|
|
||||||
|
Этот подход позволяет направлять запросы пользователей на действительно оптимальный сервер, а не только на ближайший.
|
||||||
|
|
||||||
|
## Пример Dropbox
|
||||||
|
Dropbox внедрил гибридную архитектуру, которая обходит ограничения стандартного Geo DNS и обеспечивает более точное определение оптимального сервера. Основные элементы решения:
|
||||||
|
|
||||||
|
1. **Тестирование производительности на клиентской стороне**
|
||||||
|
- Клиентские приложения Dropbox (например, настольные и мобильные клиенты) измеряют задержки до различных серверов компании.
|
||||||
|
- На основе полученных данных выбирается сервер с наилучшей производительностью, что позволяет избежать ошибок, связанных с неверным определением ближайшего сервера через Geo DNS.
|
||||||
|
2. **Использование Anycast**
|
||||||
|
- Anycast позволяет одному IP-адресу быть связанным с несколькими серверами по всему миру. Пользовательский запрос автоматически направляется к серверу с наиболее коротким сетевым маршрутом.
|
||||||
|
3. **Сбор аналитики в реальном времени**
|
||||||
|
- Dropbox анализирует данные о задержках, загруженности серверов и сетевых условиях, чтобы постоянно обновлять маршруты.
|
||||||
|
- Система адаптируется к изменениям в интернет-маршрутах и помогает справляться с пиковыми нагрузками.
|
||||||
|
4. **Гибридный подход**
|
||||||
|
- Geo DNS остается базовым уровнем маршрутизации, но результаты корректируются данными клиентских тестов и Anycast.
|
||||||
|
### Кто еще использует аналогичные подходы?
|
||||||
|
1. **Netflix** Использует клиент-ориентированную маршрутизацию для выбора оптимальных серверов своей CDN. Приложения Netflix тестируют доступность и производительность серверов в фоновом режиме.
|
||||||
|
2. **Cloudflare**. Их CDN объединяет Anycast и данные о сетевых условиях, чтобы минимизировать задержки для пользователей.
|
||||||
|
3. **Akamai**. Один из крупнейших провайдеров CDN, который активно использует данные о производительности на клиентской стороне для маршрутизации запросов.
|
||||||
|
4. **Valve (Steam)**. Steam измеряет задержки до серверов для оптимального скачивания игр и улучшения игрового опыта.
|
||||||
|
5. **Google**. Для таких сервисов, как YouTube, Google использует Anycast и адаптивные алгоритмы маршрутизации, ориентированные на данные о производительности.
|
||||||
|
6. **Amazon AWS**. Сервис Global Accelerator направляет трафик через оптимальные маршруты с учетом производительности и доступности серверов
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
|
||||||
|
**Родитель**::
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
@@ -48,6 +48,9 @@ date:
|
|||||||
6. Authoritative сервер возвращает нужную запись (например, IP-адрес).
|
6. Authoritative сервер возвращает нужную запись (например, IP-адрес).
|
||||||
7. Клиент получает IP-адрес и устанавливает соединение с сервером по этому адресу.
|
7. Клиент получает IP-адрес и устанавливает соединение с сервером по этому адресу.
|
||||||
|
|
||||||
|
Не рекурсивный поиск
|
||||||
|
![[../../meta/files/images/Pasted image 20250128133803.png]]
|
||||||
|
|
||||||
**Проблемы и угрозы DNS**
|
**Проблемы и угрозы DNS**
|
||||||
- **DNS Spoofing (подмена)**: Атака, при которой злоумышленники подменяют ответ DNS-сервера, перенаправляя пользователей на вредоносные сайты.
|
- **DNS Spoofing (подмена)**: Атака, при которой злоумышленники подменяют ответ DNS-сервера, перенаправляя пользователей на вредоносные сайты.
|
||||||
- **DDoS-атаки на DNS**: Направлены на перегрузку серверов, чтобы сделать их недоступными.
|
- **DDoS-атаки на DNS**: Направлены на перегрузку серверов, чтобы сделать их недоступными.
|
||||||
|
|||||||
49
dev/network/Geo Base DNS.md
Normal file
49
dev/network/Geo Base DNS.md
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- Geo DNS
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
Geo Base [[../garden/ru/dev/network/Domain Name System|DNS]] — это система, которая маршрутизирует запросы пользователей к серверу на основе их географического положения. Такая настройка позволяет:
|
||||||
|
- Уменьшить [[../garden/ru/dev/architecture/Latency|время отклика]], так как запросы направляются на сервер, находящийся ближе к пользователю.
|
||||||
|
- Обеспечить [[../garden/ru/dev/architecture/highload/Балансировка нагрузки|балансировку нагрузки]] между дата-центрами в разных регионах.
|
||||||
|
- Снизить вероятность перегрузки отдельных серверов.
|
||||||
|
|
||||||
|
Работа Geo Base DNS основывается на определении IP-адреса пользователя и его сопоставлении с географическим регионом. На основе этих данных система выбирает оптимальный сервер.
|
||||||
|
|
||||||
|
**Как это работает?**
|
||||||
|
1. **DNS-запрос**: Пользователь вводит адрес сайта в браузере, например, `example.com`. Запрос передается к DNS-серверу.
|
||||||
|
2. **Определение местоположения**: DNS-сервер использует базу данных геолокации IP-адресов, чтобы определить регион пользователя.
|
||||||
|
3. **Выбор сервера**: На основе местоположения пользователя система перенаправляет запрос на ближайший сервер.
|
||||||
|
4. **Ответ**: Ближайший сервер обрабатывает запрос, минимизируя задержки.
|
||||||
|
|
||||||
|
**Преимущества Geo Base DNS**
|
||||||
|
- **Скорость**: Уменьшение времени отклика благодаря использованию ближайшего сервера.
|
||||||
|
- **Надежность**: Если один из серверов становится недоступен, запросы перенаправляются на другие доступные серверы.
|
||||||
|
- Балансировка нагрузки: Обеспечивается равномерное распределение запросов между серверами в разных регионах.
|
||||||
|
- **Глобальное покрытие**: Пользователи из разных частей мира получают равномерный опыт работы с приложением или сайтом.
|
||||||
|
|
||||||
|
**Где применяется Geo Base DNS?**
|
||||||
|
1. [[../garden/ru/dev/architecture/highload/Content Delivery Network|CDN]]: Оптимизация доставки статического контента (изображений, видео, файлов) для пользователей.
|
||||||
|
2. **Игровые серверы**: Направление игроков на серверы с минимальной задержкой для улучшения игрового процесса.
|
||||||
|
3. **Глобальные веб-приложения**: Обеспечение высокого уровня обслуживания для пользователей в разных странах.
|
||||||
|
4. **Мультирегиональные компании**: Поддержка локальных серверов для офисов и клиентов в разных регионах.
|
||||||
|
|
||||||
|
**Ограничения**
|
||||||
|
- **Точность геолокации**: Иногда IP-адрес может быть неправильно сопоставлен с регионом.
|
||||||
|
- **Стоимость**: Использование географически распределенных систем может быть дорогостоящим.
|
||||||
|
- **Кеширование DNS**: Может приводить к задержкам в обновлении маршрутов.
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../garden/ru/meta/zero/00 Сети|00 Сети]]
|
||||||
|
**Родитель**:: [[../garden/ru/dev/network/Domain Name System|DNS]]
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
46
dev/network/Round Robin DNS.md
Normal file
46
dev/network/Round Robin DNS.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
**Round Robin DNS** — это метод распределения нагрузки на серверы, при котором [[Domain Name System|DNS]]-сервер возвращает IP-адреса серверов поочередно, в порядке очереди (round-robin). Это простой и эффективный способ балансировки нагрузки на уровне [[Domain Name System|DNS]].
|
||||||
|
|
||||||
|
**Как это работает:**
|
||||||
|
1. В DNS-записи (обычно типа A или AAAA) для домена указывается несколько IP-адресов серверов.
|
||||||
|
2. Когда клиент (например, браузер) отправляет запрос на получение IP-адреса для домена, DNS-сервер возвращает один из IP-адресов из списка.
|
||||||
|
3. При последующих запросах DNS-сервер возвращает следующий IP-адрес в списке, и так по кругу.
|
||||||
|
|
||||||
|
Пример DNS-записи:
|
||||||
|
```DNS
|
||||||
|
example.com. IN A 192.168.1.1
|
||||||
|
example.com. IN A 192.168.1.2
|
||||||
|
example.com. IN A 192.168.1.3
|
||||||
|
```
|
||||||
|
|
||||||
|
**Преимущества:**
|
||||||
|
- **Простота реализации.** Не требуется сложное оборудование или программное обеспечение.
|
||||||
|
- **Распределение нагрузки.** Запросы распределяются между серверами, уменьшая нагрузку на один конкретный сервер.
|
||||||
|
- [[Reliability|Отказоустойчивость]]. Если один из серверов выходит из строя, запросы продолжат отправляться на другие.
|
||||||
|
|
||||||
|
**Ограничения:**
|
||||||
|
- **Отсутствие учета нагрузки.** Round Robin DNS не знает, какой сервер в данный момент перегружен или не отвечает.
|
||||||
|
- **Зависимость от кеширования.** Некоторые клиенты или провайдеры DNS могут [[../architecture/Кэширование|кешировать]] ответы, игнорируя ротацию адресов.
|
||||||
|
- **Нет проверки доступности.** DNS-сервер не проверяет, активен ли сервер, перед возвратом его IP-адреса.
|
||||||
|
|
||||||
|
**Примеры использования:**
|
||||||
|
- **Веб-приложения:** Для распределения трафика между несколькими веб-серверами.
|
||||||
|
- [[../architecture/highload/Content Delivery Network|CDN]]: Для распределения пользователей между серверами в разных регионах.
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Сети|00 Сети]], [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
|
||||||
|
**Родитель**:: [[../architecture/highload/Балансировка нагрузки|Балансировка нагрузки]]
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
60
dev/other/Backward compatibility.md
Normal file
60
dev/other/Backward compatibility.md
Normal file
@@ -0,0 +1,60 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- обратная совместимость
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
## Тезисы
|
||||||
|
- **Backward compatibility (обратная совместимость)** — это способность системы взаимодействовать с предыдущими версиями API, данных или программного обеспечения.
|
||||||
|
- Поддержка обратной совместимости необходима для обеспечения плавного обновления, сохранения работы старых клиентов и уменьшения числа багов.
|
||||||
|
- Основные подходы к обеспечению совместимости:
|
||||||
|
- [[Семантическое версионирование|Семантическое версионирование]] (Semantic Versioning, SemVer).
|
||||||
|
- Контроль изменения контрактов API.
|
||||||
|
- Тестирование на совместимость с предыдущими версиями.
|
||||||
|
- Нарушение обратной совместимости возможено только с планированием и четкой коммуникацией с пользователями.
|
||||||
|
***
|
||||||
|
**Backward compatibility** (обратная совместимость) — это свойство системы, при котором она остается работоспособной при взаимодействии с устаревшими версиями компонентов, клиентами или данными. Например, новое обновление сервиса должно работать с клиентами, которые используют старую версию API.
|
||||||
|
|
||||||
|
Обратная совместимость важна в системах, где существует множество интеграций с внешними сервисами или клиентами, так как внезапные изменения могут привести к массовым сбоям.
|
||||||
|
|
||||||
|
Зачем нужна обратная совместимость:
|
||||||
|
- **Стабильность.** Поддержание совместимости уменьшает вероятность ошибок и отказов.
|
||||||
|
- **Пользовательский опыт.** Пользователи не должны обновлять свое ПО или менять код из-за изменения в API.
|
||||||
|
- **Долгосрочная стратегия.** Совместимость облегчает внедрение обновлений и снижает риски миграции.
|
||||||
|
|
||||||
|
**Основные принципы поддержки совместимости**
|
||||||
|
- [[Семантическое версионирование|Семантическое версионирование]] (SemVer).
|
||||||
|
- Четкое разделение изменений на major, minor и patch версии помогает пользователям понимать влияние обновления.
|
||||||
|
- Изменения, которые нарушают совместимость, должны быть явно обозначены в major-версии.
|
||||||
|
- [[../architecture/Контракт взаимодействия|Контракт]] API.
|
||||||
|
- Контракты API должны быть тщательно описаны (например, через OpenAPI или gRPC).
|
||||||
|
- Изменения в API должны быть обратимыми или изолированными (например, добавление новых полей, но не удаление старых).
|
||||||
|
- **Deprecated.**
|
||||||
|
- Устаревшие методы или эндпоинты должны помечаться как deprecated задолго до удаления.
|
||||||
|
- Пользователи должны быть уведомлены о сроках удаления.
|
||||||
|
- **Тестирование совместимости.**
|
||||||
|
- Регулярное тестирование взаимодействий между разными версиями клиента и сервера.
|
||||||
|
- Автоматизированные тесты для сценариев, затрагивающих старые версии API.
|
||||||
|
|
||||||
|
**В некоторых случаях отказ от совместимости неизбежен:**
|
||||||
|
- Рефакторинг системы, где устаревшая архитектура мешает дальнейшему развитию.
|
||||||
|
- Прекращение поддержки устаревших клиентов, которые больше не используются.
|
||||||
|
- Полный переход на новую технологию или формат данных.
|
||||||
|
**Однако отказ требует:**
|
||||||
|
- Предварительной коммуникации с пользователями (например, через документацию, уведомления и письма).
|
||||||
|
- Предоставления временного периода для миграции.
|
||||||
|
- Инструментов или инструкций для упрощения перехода (например, миграционных скриптов).
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
|
||||||
|
**Родитель**::
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
55
dev/other/Feature toggles.md
Normal file
55
dev/other/Feature toggles.md
Normal file
@@ -0,0 +1,55 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- фича-флаги
|
||||||
|
- фича-флаг
|
||||||
|
- флаги функций
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
Feature toggles — это паттерн в разработке, позволяющий включать или отключать функциональность в приложении с помощью конфигурации. Это достигается с помощью простых условий в коде (например, if/else) и внешнего управления их состоянием (через конфигурационные файлы, панели администрирования или сервисы).
|
||||||
|
|
||||||
|
Пример:
|
||||||
|
```java
|
||||||
|
if (featureToggleService.isEnabled("newFeature")) {
|
||||||
|
// Новая функциональность
|
||||||
|
} else {
|
||||||
|
// Старая функциональность
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Зачем нужны:**
|
||||||
|
- **Плавные релизы.** Разработчики могут выкатывать новые функции без необходимости мгновенного их активации для всех пользователей.
|
||||||
|
- **Тестирование.** Позволяют тестировать функциональность в production-среде на ограниченной аудитории (A/B-тестирование).
|
||||||
|
- **Миграции.** Облегчают переход между версиями или технологическими стеками, включая и отключая изменения поэтапно.
|
||||||
|
- **Управление рисками.** В случае возникновения проблем функция может быть быстро отключена без необходимости отката релиза.
|
||||||
|
|
||||||
|
**Основные виды:**
|
||||||
|
- **Release toggles.** Используются для плавного развертывания новых функций. После успешного запуска флаг обычно удаляется из кода.
|
||||||
|
- **Experiment toggles.** Применяются для проведения A/B-тестов и экспериментов, чтобы определить, какая версия функциональности более эффективна.
|
||||||
|
- **Ops toggles.** Предназначены для управления поведением системы на уровне операций. Например, для включения или отключения определённых интеграций.
|
||||||
|
- **Permission toggles.** Используются для управления доступом пользователей к определённым функциям (например, премиум-функционал).
|
||||||
|
|
||||||
|
**Полезные советы:**
|
||||||
|
- **Документация флагов.** Каждый флаг должен быть задокументирован, включая его цель и ожидаемый срок жизни.
|
||||||
|
- **Жизненный цикл флагов.** Флаги не должны оставаться в коде навсегда. После использования они должны быть удалены, чтобы избежать накопления технического долга.
|
||||||
|
- **Тестирование.** Необходимо тестировать приложение в обоих состояниях флага (включённом и выключенном).
|
||||||
|
- **Централизованное управление.** Используйте специальные библиотеки или сервисы для управления флагами (например, LaunchDarkly, Unleash).
|
||||||
|
|
||||||
|
**Проблемы:**
|
||||||
|
- **Усложнение кода.** Большое количество флагов может сделать кодовую базу сложной для понимания.
|
||||||
|
- **Технический долг.** Забытые или устаревшие флаги создают ненужные зависимости и усложняют сопровождение.
|
||||||
|
- **Конфликты.** Неправильное управление состоянием флагов может привести к непредсказуемому поведению системы.
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**::
|
||||||
|
**Родитель**::
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
39
dev/other/Ресурсы для работы приложений.md
Normal file
39
dev/other/Ресурсы для работы приложений.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
- ресурсы
|
||||||
|
- ресурсов
|
||||||
|
tags:
|
||||||
|
- maturity/🌱
|
||||||
|
date: 2025-01-28
|
||||||
|
---
|
||||||
|
**Ресурсы** — это вычислительные мощности ([[../fundamental/Центральный процессор|CPU]], память, дисковое пространство), необходимые для работы сервиса или [[../architecture/Бэкенд|приложения]]. Их распределение играет ключевую роль в обеспечении стабильной работы и производительности системы.
|
||||||
|
|
||||||
|
**Классификация**
|
||||||
|
- **Минимальные ресурсы**. Минимальный объем CPU и памяти, достаточный для работы приложения с ограниченной производительностью. Пример для Java-сервиса: CPU 200m, RAM 400Mi. Минимальные ресурсы не обеспечивают [[Reliability|отказоустойчивость]], что требует дополнительного выделения избыточных ресурсов.
|
||||||
|
- **Оптимальные ресурсы**. Обеспечивают стабильную работу с минимальными задержками и хорошей производительностью. Пример для Java-сервиса: CPU 500m, RAM 512Mi.
|
||||||
|
- **Избыточные ресурсы**. С запасом, чтобы гарантировать стабильность работы при всплесках нагрузки. Пример для Java-сервиса: CPU 1000m, RAM 1024Mi.
|
||||||
|
|
||||||
|
**Оптимизация использования ресурсов**
|
||||||
|
- [[../java/Нативные сборки в Java|Нативные сборки в Java]]:
|
||||||
|
- Плюсы: уменьшение потребления памяти.
|
||||||
|
- Минусы: увеличивает сложность CI/CD и требует доработки кода.
|
||||||
|
- Уменьшение [[../architecture/Декомпозиция на микросервисы|гранулярности микросервисов]]:
|
||||||
|
- Плюсы: снижение общего потребления ресурсов.
|
||||||
|
- Минусы: потеря изоляции микросервисов и усложнение управления.
|
||||||
|
- **Оптимизация кода**:
|
||||||
|
- Плюсы: снижение потребления CPU и памяти.
|
||||||
|
- Минусы: требует затрат на рефакторинг и может усложнить поддержку.
|
||||||
|
- [[../architecture/Multitenancy|Multitenancy]]
|
||||||
|
***
|
||||||
|
## Мета информация
|
||||||
|
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
|
||||||
|
**Родитель**::
|
||||||
|
**Источник**::
|
||||||
|
**Создана**:: [[2025-01-28]]
|
||||||
|
**Автор**::
|
||||||
|
### Дополнительные материалы
|
||||||
|
-
|
||||||
|
|
||||||
|
### Дочерние заметки
|
||||||
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||||||
|
|
||||||
BIN
meta/files/images/Pasted image 20250128133803.png
Normal file
BIN
meta/files/images/Pasted image 20250128133803.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
@@ -22,15 +22,15 @@ aliases:
|
|||||||
> Высокие нагрузки, [отказоустойчивость](Reliability.md) - это не про технологии, это про АРХИТЕКТУРУ!
|
> Высокие нагрузки, [отказоустойчивость](Reliability.md) - это не про технологии, это про АРХИТЕКТУРУ!
|
||||||
|
|
||||||
Основная логика увеличения производительности:
|
Основная логика увеличения производительности:
|
||||||
- Увеличиваем эффективность использования ресурсов
|
- Увеличиваем эффективность использования [[../../dev/other/Ресурсы для работы приложений|ресурсов]]
|
||||||
- Увеличиваем количество ресурсов
|
- Увеличиваем количество [[../../dev/other/Ресурсы для работы приложений|ресурсов]]
|
||||||
## Алгоритм проектирования
|
## Алгоритм проектирования
|
||||||
1. Первым делом необходимо провести [Анализ данных проекта](Анализ%20данных%20проекта.md).
|
1. Первым делом необходимо провести [Анализ данных проекта](Анализ%20данных%20проекта.md).
|
||||||
2. Для каждого использования подобрать архитектурный прием, разработать архитектуру.
|
2. Для каждого использования подобрать архитектурный прием, разработать архитектуру.
|
||||||
3. Для каждой архитектуры подобрать инструменты и технологии.
|
3. Для каждой архитектуры подобрать инструменты и технологии.
|
||||||
|
|
||||||
## Алгоритм диагностики существующего решения
|
## Алгоритм диагностики существующего решения
|
||||||
Что делать если решение уже разработано и его нужно переделать в highload-решение. Для начала необходимо поставить "диагноз". А именно понять где у системы узкое горлышко. На какие процессы тратится больше всего ресурсов.
|
Что делать если решение уже разработано и его нужно переделать в highload-решение. Для начала необходимо поставить "диагноз". А именно понять где у системы [[../../dev/architecture/Bottlneck|узкое горлышко]]. На какие процессы тратится больше всего ресурсов.
|
||||||
|
|
||||||
|
|
||||||
## Архитектурные паттерны
|
## Архитектурные паттерны
|
||||||
|
|||||||
Reference in New Issue
Block a user