Обновление

dev/architecture/Latency.md

@@ -2,6 +2,7 @@
 aliases:
   - задержка
   - время отклика
+  - задержки
 tags:
   - maturity/🌱
 date:

dev/architecture/Single point of failure.md

@@ -0,0 +1,42 @@
+---
+aliases:
+  - SPOF
+  - точка отказа
+  - единственная точка отказа
+tags:
+  - maturity/🌱
+date: 2024-12-08
+---
+**Single Point of Failure (SPOF)** — это любой компонент [[../../../../_inbox/Информационная система|системы]], отказ которого приводит к её недоступности или снижению работоспособности. Такие компоненты являются критически важными для функционирования системы, и их выход из строя может иметь катастрофические последствия.
+
+SPOF часто встречается в системах с центральным узлом, на который приходится вся нагрузка или от которого зависит доступность других компонентов.
+
+**Примеры Single Point of Failure:**
+- **Единственный сервер**. Если сервер, обрабатывающий запросы, выходит из строя, система перестает отвечать.
+- База данных без [[highload/Репликация|репликации]]. При отказе центральной базы данных все операции, зависящие от неё, останавливаются.
+- **Сетевой маршрутизатор или коммутатор**. Если устройство выходит из строя, теряется связь между частями системы.
+- [[Централизованный сервис|Централизованный сервис]]. Например, единственная точка авторизации (Auth Service) может остановить работу всей системы при её отказе.
+- **Единый источник питания**. Если отсутствует резервное питание, система будет недоступна при отключении электричества.
+
+**Методы устранения Single Point of Failure**
+- [[highload/Репликация|Репликация]]. Создание копий компонентов (например, баз данных, серверов) для обеспечения их доступности при отказе одного из них.
+- **Резервирование**. Установка резервного оборудования или программного обеспечения, которое автоматически включается в работу при отказе основного.
+- **Распределение нагрузки**. Использование балансировщиков нагрузки для равномерного распределения запросов между несколькими серверами или сервисами.
+- **Отказоустойчивые архитектуры**. Проектирование системы так, чтобы она могла продолжать работу, даже если один из компонентов выйдет из строя.
+- [[Масштабирование информационной системы|Масштабирование]].
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-12-08]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- 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) -->
+- [[Централизованный сервис]]
+<!-- SerializedQuery END -->
+

dev/architecture/Масштабирование информационной системы.md

@@ -2,6 +2,7 @@
 aliases:
   - масштабирование
   - масштабировании
+  - масштабируемости
 tags:
   - maturity/🌱
 date: 2024-12-03
@@ -37,5 +38,6 @@ date: 2024-12-03
 <!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 - [[Вертикальное масштабирование]]
 - [[Горизонтальное масштабирование]]
+- [[Масштабирование по осям X, Y и Z]]
 <!-- SerializedQuery END -->
 

dev/architecture/Межсервисное взаимодействие.md

@@ -9,6 +9,10 @@ date: 2024-11-27
 Чем больше вызовов нужно сделать, тем меньшую [[Reliability|отказоустойчивость]] получаем.
 
 ![[../../../../meta/files/Pasted image 20241127200019.png]]
+
+Взаиможействие бывает двух основных видов:
+- Асинхронные вызовы
+- Синхронные вызовы
 ***
 ## Мета информация
 **Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]

dev/architecture/Объединение данных из разных микросервисов.md

@@ -0,0 +1,34 @@
+---
+aliases:
+  - объединять данные из разных микросервисов
+tags:
+  - maturity/🌱
+date: 2024-12-02
+---
+При проектировании микросервисной архитектуры ключевой задачей является правильная [[Декомпозиция на микросервисы]]. Однако в процессе разработки может возникнуть ситуация, когда данные, необходимые для выполнения одного бизнес-процесса, распределяются между несколькими сервисами. Это усложняет обработку данных, увеличивает [[Latency|время отклика]] системы и создает дополнительные точки отказа.
+
+Объединение данных между сервисами становится необходимым, когда:
+- Один бизнес-процесс требует данных из нескольких микросервисов.
+- Логика обработки данных не соответствует границам ответственности сервисов.
+- Архитектурные решения не учитывают изначально взаимосвязанные данные.
+
+![[../../meta/files/images/Pasted image 20241202191611.png]]
+
+Если в системе часто возникают ситуации, требующие объединения данных, это может быть сигналом неправильного выбора границ микросервисов. Основные признаки:
+- Частые запросы между сервисами для синхронизации данных.
+- Высокая сложность реализации бизнес-логики из-за разрозненности данных.
+- Замедление работы системы из-за межсервисного взаимодействия.
+
+***
+## Мета информация
+**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
+**Родитель**:: [[Декомпозиция на микросервисы|Декомпозиция на микросервисы]]
+**Источник**:: 
+**Создана**:: [[2024-12-02]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Централизованный сервис.md

@@ -0,0 +1,47 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-12-08
+---
+Централизованный сервис — это компонент [[../../../../_inbox/Информационная система|системы]], выполняющий одну или несколько ключевых функций, таких как аутентификация, управление конфигурацией, обработка данных или логирование. Все или большинство других компонентов системы зависят от работы этого сервиса, что делает его важным элементом архитектуры.
+
+Централизованные сервисы часто встречаются в монолитных приложениях или в [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисной архитектуре]], где определённый микросервис выполняет критическую роль.
+
+**Примеры централизованных сервисов**
+- **Auth Service** — централизованная аутентификация и авторизация пользователей.
+- **Configuration Server** — единый источник конфигурационных данных для системы.
+- **Message Broker** — посредник для обмена данными между микросервисами (например, Kafka, RabbitMQ).
+- **Logging Service** — агрегатор логов из разных частей системы.
+- **Data Store** — единый источник данных, например, основная база данных.
+
+**Преимущества централизованного сервиса**
+- **Упрощённая логика**. Все компоненты обращаются к единому сервису, что делает логику работы системы понятной и предсказуемой.
+- **Централизованное управление**. Легче внедрять изменения, поскольку обновление логики происходит в одном месте.
+- **Консистентность данных**. Использование одного источника данных или логики исключает дублирование и расхождения.
+- **Удобство мониторинга**. Проще отслеживать состояние системы, когда ключевые функции реализованы в одном месте.
+
+**Недостатки централизованного сервиса**
+- [[Single point of failure|Единственная точка отказа]] (SPOF). При отказе централизованного сервиса вся система может оказаться недоступной.
+- [[Bottlneck|Узкое место]]. Высокая нагрузка на сервис может привести к деградации производительности всей системы.
+- Риски [[Масштабирование информационной системы|масштабируемости]]. Централизованные сервисы сложнее масштабировать, особенно если они обрабатывают большие объемы данных.
+- [[Latency|Задержки]]. В распределённых системах время отклика может увеличиваться из-за необходимости обращения к централизованному компоненту.
+
+**Как минимизировать риски централизованных сервисов?**
+- [[highload/Репликация|Репликация]] и кластеризация. Развёртывание нескольких экземпляров сервиса с балансировкой нагрузки между ними.
+- **Распределение ответственности**. Разделение функциональности на несколько сервисов, чтобы уменьшить нагрузку на каждый из них.
+- [[Кэширование]]
+- **Децентрализация**. Внедрение распределённых механизмов, которые уменьшают зависимость от одного сервиса. Пример: использование JWT для авторизации вместо постоянных запросов к Auth Service.
+***
+## Мета информация
+**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
+**Родитель**:: [[Single point of failure|Single point of failure]]
+**Источник**:: 
+**Создана**:: [[2024-12-08]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+