From ae7be232947ff62d04c64e9ebfadbe4a048f724a Mon Sep 17 00:00:00 2001 From: Struchkov Mark Date: Fri, 17 Jan 2025 16:55:52 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D0=B8=D0=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dev/Universal Unique IDentifier.md | 2 +- dev/architecture/CAP теорема.md | 3 +- dev/architecture/Session Affinity.md | 44 +++++++++++ dev/architecture/Stateless Service.md | 32 ++++++++ .../highload/Балансировка нагрузки.md | 10 ++- dev/architecture/Кэширование.md | 2 +- .../Масштабирование информационной системы.md | 1 + dev/architecture/Монолитная архитектура.md | 2 +- dev/architecture/Распределённая система.md | 48 ++++++++++++ dev/architecture/Согласованность данных.md | 4 +- dev/network/Domain Name System.md | 74 +++++++++++++++++++ 11 files changed, 215 insertions(+), 7 deletions(-) create mode 100644 dev/architecture/Session Affinity.md create mode 100644 dev/architecture/Stateless Service.md create mode 100644 dev/architecture/Распределённая система.md create mode 100644 dev/network/Domain Name System.md diff --git a/dev/Universal Unique IDentifier.md b/dev/Universal Unique IDentifier.md index 211814b8..a4c55ec2 100644 --- a/dev/Universal Unique IDentifier.md +++ b/dev/Universal Unique IDentifier.md @@ -41,7 +41,7 @@ UUID версии 1 использует текущее время по григ UUID версии 3 (V3) — это идентификатор, основанный на алгоритме хеширования [[cryptography/MD5|MD5]]. В отличие от UUID версии 1, который использует текущее время, UUID V3 генерируется на основе имени (строки) и пространства имен (namespace). Основная идея заключается в том, что при использовании одинаковых имени и пространства имен результатом всегда будет один и тот же UUID. -**Пример использования:** Когда нужно сгенерировать уникальный идентификатор для имени домена в сети, применяется UUID V3 с пространством имен **DNS** и строкой, содержащей доменное имя. Например: +**Пример использования:** Когда нужно сгенерировать уникальный идентификатор для имени домена в сети, применяется UUID V3 с пространством имен [[network/Domain Name System|DNS]] и строкой, содержащей доменное имя. Например: ``` UUID(DNS, "example.com") → 5df41881-3aed-3515-88a7-2f4a814cf09e diff --git a/dev/architecture/CAP теорема.md b/dev/architecture/CAP теорема.md index 33ceb3b5..10809835 100644 --- a/dev/architecture/CAP теорема.md +++ b/dev/architecture/CAP теорема.md @@ -1,5 +1,6 @@ --- -aliases: +aliases: + - CAP-теорема tags: - maturity/🌱 date: diff --git a/dev/architecture/Session Affinity.md b/dev/architecture/Session Affinity.md new file mode 100644 index 00000000..21c9463e --- /dev/null +++ b/dev/architecture/Session Affinity.md @@ -0,0 +1,44 @@ +--- +aliases: + - Sticky Sessions +tags: + - maturity/🌱 +date: 2025-01-17 +--- +**Session Affinity** (или **Sticky Sessions**) — это подход в [[highload/Балансировка нагрузки|балансировке нагрузки]], при котором запросы от одного клиента всегда направляются на один и тот же сервер в течение всей сессии. Это обеспечивает сохранение состояния клиента на конкретном сервере и делает взаимодействие более последовательным. + +**Преимущества** +- **Сохранение состояния**: Не требует сложной реализации хранения состояния между серверами. +- **Простота для разработчиков**: Упрощает работу с приложениями, которые не являются [[Stateless Service|stateless]]. + +**Недостатки** +- **Риски перегрузки**: Сервер, привязанный к большому количеству клиентов, может стать перегруженным. +- **Уязвимость к сбоям**: Если сервер выходит из строя, сессии клиентов теряются. +- Меньшая гибкость [[Масштабирование информационной системы|масштабирования]]: Динамическое добавление или удаление серверов затруднено. + +**Методы реализации** +- **По IP-адресу клиента**: + - Сервер выбирается на основе IP-адреса клиента. + - Простая реализация, но уязвима к использованию прокси-серверов и NAT. +- **По cookie**: + - Балансировщик устанавливает [[../network/Cookie|cookie]] на клиенте, где хранится информация о назначенном сервере. + - Наиболее популярный метод благодаря своей гибкости. +- **На основе токена**: + - Клиент предоставляет токен (например, JWT), который указывает на сервер, обрабатывающий сессию. + - Токен может быть частью механизма аутентификации. +- **Hash-Based (Хеширование)**: + - Сервер определяется через хеширование идентификатора клиента (например, IP, ID пользователя или URL). + - Эффективен для систем с большим количеством пользователей. +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]] +**Родитель**:: [[highload/Балансировка нагрузки|Балансировка нагрузки]] +**Источник**:: +**Создана**:: [[2025-01-17]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Stateless Service.md b/dev/architecture/Stateless Service.md new file mode 100644 index 00000000..1d5bd022 --- /dev/null +++ b/dev/architecture/Stateless Service.md @@ -0,0 +1,32 @@ +--- +aliases: + - Stateless + - Stateless-сервисы +tags: + - maturity/🌱 +date: 2025-01-17 +--- +**Stateless-приложения** — это приложения или сервисы, которые обрабатывают каждый запрос как независимое событие, не полагаясь на сохранение данных между запросами. Вся необходимая информация для выполнения запроса должна передаваться в рамках самого запроса. + +**Преимущества:** +- [[Масштабирование информационной системы|Масштабируемость]]: Простота [[highload/Горизонтальное масштабирование|горизонтального масштабирования]] за счет отсутствия необходимости синхронизации состояния между серверами. +- **Отказоустойчивость**: Выход из строя одного сервера не влияет на другие. Пользователь может обратиться к любому серверу в кластере, и запрос будет обработан корректно. +- **Упрощенное управление**: Легче деплоить и управлять, так как не требуется репликация состояния. +- Совместимость с [[highload/Балансировка нагрузки|балансировкой нагрузки]]: Подход хорошо интегрируется с алгоритмами балансировки, такими как Round Robin или Least Connections. + +**Недостатки** +- **Необходимость внешнего хранилища**: Для хранения состояния используются базы данных, кэши (Redis, Memcached) или другие системы. Это может увеличить задержки при доступе к данным. +- **Более сложные запросы**: Поскольку сервер не помнит пользователя, клиент должен передавать всю необходимую информацию в каждом запросе (например, токены аутентификации, данные контекста). +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]] +**Родитель**:: +**Источник**:: +**Создана**:: [[2025-01-17]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/highload/Балансировка нагрузки.md b/dev/architecture/highload/Балансировка нагрузки.md index 1ac4bbd6..a1b3c984 100644 --- a/dev/architecture/highload/Балансировка нагрузки.md +++ b/dev/architecture/highload/Балансировка нагрузки.md @@ -5,6 +5,9 @@ aliases: - балансировщики нагрузки - балансировщиком нагрузки - балансировщиком + - балансировке нагрузки + - алгоритмами балансировки + - балансировкой нагрузки tags: - maturity/🌱 date: 2024-06-13 @@ -12,14 +15,16 @@ date: 2024-06-13 ![[../../../meta/files/images/Pasted image 20241103021050.png]] **Статические алгоритмы** -- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть stateless (не сохранять состояние между запросами). +- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть [[../Stateless Service|stateless]] (не сохранять состояние между запросами). - **Sticky round-robin** Улучшенная версия алгоритма round robin. Если первый запрос от Алисы попал на сервис A, то и все последующие её запросы будут отправляться на этот же сервис A. - **Weighted round-robin** Администратор может задать вес для каждого сервиса. Сервисы с большим весом будут обрабатывать больше запросов, чем другие. - **Hash (Хеширование)** Этот алгоритм применяет хеш-функцию к IP-адресу или URL запроса. Запросы направляются на соответствующие экземпляры сервиса в зависимости от результата [[../../cryptography/Хеш-функция|хеш-функции]]. +- [[../Session Affinity|Session Affinity]] **Динамические алгоритмы** - **Least connections**. Новый запрос отправляется экземпляру сервиса с наименьшим числом текущих соединений. - **Least response time.** Новый запрос отправляется на экземпляр сервиса с самым быстрым временем отклика. +- **Adaptive Load Balancing**. Использует мониторинг серверов и их текущей нагрузки (CPU, RAM, сетевые ресурсы). Запрос направляется на наиболее “свободный” сервер. *** ## Мета информация @@ -32,3 +37,6 @@ date: 2024-06-13 - ### Дочерние заметки + +- [[Session Affinity]] + diff --git a/dev/architecture/Кэширование.md b/dev/architecture/Кэширование.md index 16bc2687..43f20c79 100644 --- a/dev/architecture/Кэширование.md +++ b/dev/architecture/Кэширование.md @@ -33,7 +33,7 @@ linked: - [Кэширование на стороне браузера](highload/Кэширование%20на%20стороне%20браузера.md). Ответы HTTP могут кэшироваться браузером. При первом запросе данных по HTTP они возвращаются с политикой истечения срока действия в заголовке HTTP. При повторном запросе данных клиентское приложение сначала пытается получить их из кэша браузера. - [Кэширование на стороне Nginx](../devops/nginx/Кэширование%20на%20стороне%20Nginx.md) - [Content Delivery Network](highload/Content%20Delivery%20Network.md). CDN кэширует статические веб-ресурсы. Клиенты могут получать данные с ближайшего узла CDN. -- **Балансировщик нагрузки**: Балансировщик также может кэшировать ресурсы. +- [[highload/Балансировка нагрузки|Балансировщик нагрузки]]: Балансировщик также может кэшировать ресурсы. - [Кэширование в приложении](Кэширование%20в%20приложении.md). В сервисах есть несколько уровней кэша. Если данные не находятся в кэше процессора, сервис пытается получить их из памяти. Иногда в сервисе есть вторичный уровень кэша для хранения данных на диске. - **Распределённый кэш**: Распределённые кэши, такие как Redis, хранят пары ключ-значение в памяти для множества сервисов. Это обеспечивает значительно лучшую производительность чтения и записи по сравнению с базой данных. - **База данных**: Даже в базе данных есть различные уровни кэша diff --git a/dev/architecture/Масштабирование информационной системы.md b/dev/architecture/Масштабирование информационной системы.md index c8bb5210..bdbcda3f 100644 --- a/dev/architecture/Масштабирование информационной системы.md +++ b/dev/architecture/Масштабирование информационной системы.md @@ -4,6 +4,7 @@ aliases: - масштабировании - масштабируемости - масштабируемость + - масштабирования tags: - maturity/🌱 date: 2024-12-03 diff --git a/dev/architecture/Монолитная архитектура.md b/dev/architecture/Монолитная архитектура.md index 3a82a71c..7fbf014e 100644 --- a/dev/architecture/Монолитная архитектура.md +++ b/dev/architecture/Монолитная архитектура.md @@ -15,7 +15,7 @@ date: 2024-04-04 - **Лёгкость внесения радикальных изменений**. В монолитной архитектуре вы можете одновременно менять код и структуру базы данных. После этого достаточно пересобрать и развернуть новое приложение. - **Простота тестирования**. Сквозное тестирование охватывает всю систему сразу. Инструменты, такие как Selenium, позволяют тестировать пользовательский интерфейс, API и внутреннюю логику в одном процессе. - **Упрощённое развертывание**. Разработчику достаточно скопировать один WAR-файл (или аналог) на сервер с установленным приложением, например Tomcat. -- **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за балансировщиком нагрузки, распределяя трафик между ними. +- **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за [[highload/Балансировка нагрузки|балансировщиком нагрузки]], распределяя трафик между ними. Несмотря на простоту, монолитный подход имеет **ряд ограничений**, которые могут стать критическими при увеличении размера приложения или масштабировании бизнеса: - **Трудности с масштабированием**. Программные модули конкурируют за ресурсы. Например, модуль обработки изображений, нагружающий CPU, может негативно влиять на стабильность других модулей. diff --git a/dev/architecture/Распределённая система.md b/dev/architecture/Распределённая система.md new file mode 100644 index 00000000..e2ec307b --- /dev/null +++ b/dev/architecture/Распределённая система.md @@ -0,0 +1,48 @@ +--- +aliases: + - распределенная система +tags: + - maturity/🌱 +date: 2025-01-17 +--- +Распределённая система — это группа независимых компьютеров, которые взаимодействуют через сеть для выполнения общей задачи. Для пользователя такая [[Информационная система|система]] выглядит как единое целое. + +Примеры: кластеры серверов, системы хранения данных (например, Hadoop, [[Cassandra]]), платформы потоковой обработки ([[00 Kafka|Kafka]], Flink) и блокчейн-сети. + +**Основные характеристики:** +- **Отсутствие общего состояния:** Каждый узел работает независимо, состояние хранится локально или реплицируется между узлами. +- **Прозрачность распределения:** Система должна скрывать сложность распределения от пользователя, обеспечивая: + - **Доступ**: пользователю не нужно знать, на каком узле хранятся данные. + - **Расположение**: данные могут быть перемещены между узлами. + - **Сопряжённость**: система должна справляться с частичными сбоями. +- [[Масштабирование информационной системы|Масштабируемость]]: Возможность увеличивать производительность системы за счёт добавления новых узлов. +- [[Reliability|Отказоустойчивость]]: Система продолжает работать даже при сбое отдельных компонентов. +- [[Согласованность данных|Согласованность данных]]: Обеспечение актуальности данных на всех узлах в условиях асинхронных операций. + +**Проблемы распределённых систем** +- Согласованность данных ([[CAP теорема|CAP-теорема]]): + - Система не может одновременно обеспечивать все три свойства: + - **Согласованность (Consistency):** Все узлы возвращают одинаковые данные. + - **Доступность (Availability):** Каждый запрос получает ответ, даже при сбоях. + - **Устойчивость к разделению (Partition Tolerance):** Система работает при разделении сети. +- **Управление отказами:** Определение, какие узлы вышли из строя, и их восстановление. +- **Сложность разработки:** Необходимость учитывать сетевые [[Latency|задержки]], частичные сбои и распределённое состояние. +- **Производительность:** Распределённые операции могут быть медленнее из-за необходимости синхронизации данных. + +**Модели взаимодействия** +- **Клиент-сервер:** Клиенты отправляют запросы, серверы обрабатывают их. +- **Peer-to-Peer (P2P):** Все узлы равны и взаимодействуют напрямую. Пример: BitTorrent, блокчейн. +- **Публикация-подписка (Pub/Sub):** Узлы подписываются на определённые темы и получают уведомления о новых событиях. Пример: [[../../../../_inbox/00 Kafka|Kafka]], [[../../../../_inbox/00 RabbitMQ|RabbitMQ]]. +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]] +**Родитель**:: [[Информационная система]] +**Источник**:: +**Создана**:: [[2025-01-17]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Согласованность данных.md b/dev/architecture/Согласованность данных.md index e0077096..3b26db75 100644 --- a/dev/architecture/Согласованность данных.md +++ b/dev/architecture/Согласованность данных.md @@ -23,7 +23,7 @@ date: 2025-01-15 - [[highload/Монотонное чтение|Монотонное чтение]] (Monotonic Read Consistency): - Если пользователь прочитал определённое значение данных, последующие чтения не вернут более старое состояние. - [[Еventual consistency|Конечная согласованность]] (Eventual Consistency): Узлы системы со временем синхронизируются, но в краткосрочной перспективе данные могут быть несогласованными. - - Пример: Системы репликации данных, такие как [[../../../../knowledge/dev/network/DNS|DNS]]. + - Пример: Системы репликации данных, такие как [[../network/Domain Name System|Domain Name System]]. **Методы обеспечения согласованности** - **Консенсусные алгоритмы**: @@ -49,7 +49,7 @@ date: 2025-01-15 ### Дочерние заметки -- [[Еventual consistency]] - [[Согласованность транзакции БД (Сonsistency)]] +- [[Еventual consistency]] diff --git a/dev/network/Domain Name System.md b/dev/network/Domain Name System.md new file mode 100644 index 00000000..62c04510 --- /dev/null +++ b/dev/network/Domain Name System.md @@ -0,0 +1,74 @@ +--- +aliases: + - DNS +tags: + - maturity/🌱 +date: + - - 2024-01-13 +--- +## Тезисы +- **DNS (Domain Name System)** — это система, которая преобразует доменные имена в IP-адреса и наоборот. +- DNS — это распределенная база данных, состоящая из множества серверов, которые хранят и предоставляют информацию о доменах. +- Основные компоненты DNS: клиент (resolving), серверы (root, TLD, authoritative), зоны и записи (A, AAAA, CNAME и другие). +- Процесс DNS-запроса включает несколько этапов, начиная от локального кэша до root-серверов и серверов имен. +*** +**DNS (Domain Name System)** — это [[../architecture/Распределённая система|распределенная система]], которая позволяет пользователям использовать удобные доменные имена (например, `example.com`) вместо сложных для запоминания [[../../../../knowledge/dev/network/Internet Protocol v4|IP]]-адресов (например, `192.0.2.1`). + +По умолчанию DNS сервер работает на 53 порту. + +**Компоненты DNS** +- **DNS-клиенты (Resolvers)** + - Это программы или устройства, которые инициализируют DNS-запрос для преобразования доменного имени в IP-адрес. + - Пример: ваш браузер или операционная система. +- **DNS-серверы**: + - **Root-серверы**: + - Основной уровень в иерархии DNS. + - Направляют запросы к серверам TLD (Top-Level Domain). + - Существует 13 логических групп root-серверов (например, `a.root-servers.net`). + - **TLD-серверы**: Обрабатывают запросы для доменов верхнего уровня (например, `.com`, `.org`, `.ru`). + - **Authoritative Name Servers**: Хранят окончательную информацию о домене, включая IP-адреса, записи MX и другие. +- **DNS-зоны**: + - Фрагменты пространства имен, управляемые конкретным сервером. + - Пример: зона для `example.com` может включать записи для `www.example.com` и `mail.example.com`. +- **DNS-записи**: + - **A**: IPv4-адрес. + - **AAAA**: IPv6-адрес. + - **CNAME**: каноническое имя (псевдоним для другого домена). + - **MX**: почтовые серверы для домена. + - **TXT**: текстовые данные, используемые для SPF, DKIM, подтверждения владения. + - **NS**: серверы, обслуживающие зону. + - **PTR**: обратное преобразование IP в доменное имя. + +**Как работает DNS?** +1. **Пользователь вводит доменное имя в браузере.** +2. **Клиент (resolver)** проверяет локальный кэш. Если запись найдена, используется она. +3. Если записи нет, запрос отправляется на root-сервер. +4. Root-сервер перенаправляет запрос на сервер TLD (например, `.com`). +5. TLD-сервер перенаправляет запрос на authoritative сервер для конкретного домена. +6. Authoritative сервер возвращает нужную запись (например, IP-адрес). +7. Клиент получает IP-адрес и устанавливает соединение с сервером по этому адресу. + +**Проблемы и угрозы DNS** +- **DNS Spoofing (подмена)**: Атака, при которой злоумышленники подменяют ответ DNS-сервера, перенаправляя пользователей на вредоносные сайты. +- **DDoS-атаки на DNS**: Направлены на перегрузку серверов, чтобы сделать их недоступными. +- **Кэш-поизонинг**: Внедрение ложной информации в кэш DNS. +- **Проблемы с конфиденциальностью**: DNS-запросы могут быть видны третьим сторонам, что создает риски слежки. + +**Современные улучшения DNS** +- **DNSSEC (DNS Security Extensions)**: Добавляет цифровую подпись для проверки подлинности записей. +- **DoH (DNS over HTTPS)** и **DoT (DNS over TLS)**: Шифруют DNS-запросы, повышая конфиденциальность и защищенность. +- **Anycast**: Используется для распределения запросов на ближайший DNS-сервер, улучшая производительность и устойчивость. + +## Заметки +- По умолчанию работает по протоколу [UDP](UDP.md), переходит на [TCP](TCP.md) если размер ответа больше 500 байт. +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Сети|00 Сети]] +**Родитель**:: +**Источник**:: +**Автор**:: +**Создана**:: [[2024-01-13]] +### Дополнительные материалы +- +### Дочерние заметки +