Обновление

dev/architecture/Event Sourcing.md

@@ -0,0 +1,43 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-12-02
+---
+Event Sourcing — это [[архитектурный паттерн]], при котором состояние системы не сохраняется напрямую, а восстанавливается путем воспроизведения последовательности событий. Каждое событие отражает изменение в системе и сохраняется в неизменяемом журнале событий (event log).
+
+**Принципы:**
+- **Неизменяемость событий**. Каждое событие записывается единожды и не подлежит изменению.
+- **Воспроизведение событий**. Текущее состояние объекта вычисляется путем последовательного применения событий, начиная с исходного состояния.
+- **Хранилище событий**. Все события хранятся в базе данных, которая может быть оптимизирована для их последовательной записи.
+
+**Преимущества:**
+- **Аудит и прозрачность**. Хранилище событий предоставляет полный лог изменений, что упрощает аудит и диагностику.
+- **Производительность и масштабирование**. Увеличение производительности за счет использования хранилища событий и построения проекций для чтения.
+- **Восстановление состояния**. Легкость восстановления системы после сбоя путем проигрывания всех событий.
+- **Возможности для анализа**. Хранилище событий может использоваться для ретроспективного анализа данных.
+
+**Ограничения:**
+- **Усложнение системы**. Требуется дополнительная логика для обработки событий, создания проекций и управления хранилищем событий.
+- **Версионирование событий**. Необходимость в управлении версиями событий при изменении их структуры.
+- **Увеличение объема данных**. Хранение всех событий может привести к быстрому росту объема данных.
+- **Задержка восстановления состояния**. При большом числе событий восстановление состояния может занимать много времени.
+
+**Применение:**
+1. **Финансовые системы**. Для учета транзакций и обеспечения полного логирования операций.
+2. **E-commerce**. Хранение всех изменений корзины пользователя или заказов.
+3. **IoT**. Сохранение событий от датчиков для анализа в реальном времени или ретроспективы.
+4. Паттерн [[../../../../knowledge/dev/архитектура/паттерн/CQRS|CQRS]]. Часто используется совместно с Event Sourcing для разделения операций чтения и записи.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Архитектурный паттерн]]
+**Источник**:: 
+**Создана**:: [[2024-12-02]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Throughput.md

@@ -1,6 +1,7 @@
 ---
 aliases:
   - пропускная способность
+  - пропускной способности
 tags:
   - maturity/🌱
 date:
@@ -8,7 +9,7 @@ date:
 zero-link:
   - "[[../../meta/zero/00 HighLoad|00 HighLoad]]"
 parents: 
-linked: []
+linked:
 ---
 Throughput - пропускная способность системы, то есть количество работы, которое система или процесс может выполнить в единицу времени.
 

dev/architecture/highload/Балансировка нагрузки.md

@@ -3,6 +3,8 @@ aliases:
   - балансировку нагрузки
   - Балансировщик нагрузки
   - балансировщики нагрузки
+  - балансировщиком нагрузки
+  - балансировщиком
 tags:
   - maturity/🌱
 date: 2024-06-13

dev/architecture/highload/Вертикальное масштабирование.md

@@ -2,15 +2,11 @@
 aliases:
   - вертикальном масштабировании
   - вертикальному масштабированию
+  - scale-up
 tags:
   - maturity/🌱
 date:
   - - 2024-03-12
-zero-link:
-  - "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
-parents: 
-linked:
-  - "[[Горизонтальное масштабирование]]"
 ---
 Вертикальное масштабирование представляет собой увеличение мощности существующей машины или сервера путем добавления более мощных процессоров, большего объема оперативной памяти, большей емкости хранения данных и так далее, без добавления дополнительных машин в систему. Это противоположность [горизонтального масштабирования](Горизонтальное%20масштабирование.md), при котором мощность системы увеличивается за счет добавления дополнительных узлов.
 
@@ -29,7 +25,7 @@ linked:
 ***
 ## Мета информация
 **Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
-**Родитель**:: 
+**Родитель**:: [[../Масштабирование информационной системы|Масштабирование информационной системы]]
 **Источник**:: 
 **Автор**:: 
 **Создана**:: [[2024-03-12]]

dev/architecture/highload/Горизонтальное масштабирование.md

@@ -5,11 +5,6 @@ tags:
   - maturity/🌱
 date:
   - - 2024-03-12
-zero-link:
-  - "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
-parents: 
-linked:
-  - "[[Вертикальное масштабирование]]"
 ---
 Горизонтальное масштабирование это процесс увеличения мощности системы за счет добавления дополнительных узлов в распределенную сеть, а не за счет увеличения мощности уже существующих узлов (как это происходит при [вертикальном масштабировании](Вертикальное%20масштабирование.md)).
 
@@ -30,7 +25,7 @@ linked:
 ***
 ## Мета информация
 **Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
-**Родитель**:: 
+**Родитель**:: [[../Масштабирование информационной системы|Масштабирование информационной системы]]
 **Источник**:: 
 **Автор**:: 
 **Создана**:: [[2024-03-12]]
@@ -39,6 +34,6 @@ linked:
 ### Дочерние заметки
 <!-- 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) -->
-- [[garden/ru/dev/architecture/highload/Репликация.md|Репликация]]
+- [[Репликация]]
 - [[Проблема горизонтального масштабирования Websocket]]
 <!-- SerializedQuery END -->

dev/architecture/Архитектурная концепция.md

@@ -9,17 +9,11 @@ date: 2024-10-01
 **Цель**:
 - Определить базовые принципы, которые будут направлять разработку всей системы.
 - Решать проблемы на уровне системы, а не отдельных компонентов.
-
 ## Классификация
-На уровне системы:
+- [[Архитектурный паттерн]]
-- [[../../../../wiki/zero/00 Микросервисная архитектура|Микросервисная архитектура]]
-- [[Монолитная архитектура]]
-- [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированное программирование]]
-- [[Асинхронное программирование]]
-- [[Реактивное программирование|Реактивное программирование]]
-
-На уровне компонентов системы:
 - [[Паттерн проектирования]]
+
+Прочие концепции:
 - [[Inversion of Control]]
 - [[Один клиент — один поток]]
 - [[Много клиентов — один поток]]
@@ -38,10 +32,9 @@ date: 2024-10-01
 <!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 - [[Событийно-ориентированное программирование]]
 - [[Inversion of Control]]
-- [[Асинхронное программирование]]
+- [[Большой комок грязи]]
 - [[Много клиентов — один поток]]
 - [[Один клиент — один поток]]
 - [[Паттерн проектирования]]
-- [[Реактивное программирование]]
+- [[Архитектурный паттерн]]
-- [[00 Микросервисная архитектура]]
 <!-- SerializedQuery END -->

dev/architecture/Архитектурный паттерн.md

@@ -0,0 +1,31 @@
+---
+aliases:
+  - архитектурный шаблон
+  - Architectural Pattern
+tags:
+  - maturity/🌱
+date: 2024-12-02
+---
+Архитектуры:
+- [[../../../../wiki/zero/00 Микросервисная архитектура|Микросервисная архитектура]]
+- [[Монолитная архитектура]]
+
+- [[Event Sourcing]]
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Архитектурная концепция]]
+**Источник**:: 
+**Создана**:: [[2024-12-02]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- 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) -->
+- [[Event Sourcing]]
+- [[Монолитная архитектура]]
+- [[00 Микросервисная архитектура]]
+<!-- SerializedQuery END -->
+

dev/architecture/Асинхронное программирование.md

@@ -10,7 +10,7 @@ date: 2024-10-08
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
-**Родитель**:: [[../architecture/Архитектурная концепция|Архитектурная концепция]]
+**Родитель**:: [[../Парадигма разработки|Парадигма разработки]]
 **Источник**:: 
 **Создана**:: [[2024-10-08]]
 **Автор**:: 

dev/architecture/Гранулярность микросервисов.md

@@ -1,47 +0,0 @@
----
-aliases:
-  - размер микросервиса
-  - гранулярность микросервисов
-tags:
-  - maturity/🌱
-date: 2024-11-24
----
-Гранулярность микросервисов — это один из ключевых вопросов при проектировании распределённых систем. От неё зависит многое: гибкость архитектуры, масштабируемость, время разработки и стоимость поддержки. Однако определение оптимального размера каждого сервиса — задача не из лёгких.
-
-Гранулярность в контексте микросервисной архитектуры — это уровень разделения логики системы на отдельные сервисы. Слишком крупные сервисы рискуют превратиться в [[Монолитная архитектура|монолиты]], теряя преимущества микросервисного подхода. Слишком мелкие, наоборот, создают сложности в управлении и коммуникации, что приводит к росту накладных расходов.
-
-Основной вызов заключается в нахождении оптимального баланса. Микросервисы должны быть достаточно маленькими, чтобы можно было легко управлять их жизненным циклом и развивать независимо от других компонентов. В то же время они должны оставаться самодостаточными и функциональными.
-
-**Принципы определения гранулярности**
-1. **Бизнес-ориентированность**. Микросервис должен отражать конкретный бизнес-процесс или функциональную область. Если сервис охватывает слишком много бизнес-логики, его стоит разделить на более специализированные компоненты. Например, в системе для интернет-магазина логика управления заказами и обработка платежей должны быть разделены на два сервиса.
-2. Правило [[Single Responsibility Principle|единственной ответственности]]. Каждый микросервис должен выполнять одну задачу и делать это хорошо. Если сервис отвечает за множество разнородных функций, вероятно, его стоит разделить. Например, сервис, отвечающий и за авторизацию, и за управление профилем пользователя, нарушает принцип единственной ответственности.
-3. Слабая [[связанность]] и высокая [[Связность|связность]]. Сервисы должны быть слабо связаны друг с другом, чтобы изменения в одном не требовали изменений в других. В то же время внутренняя логика сервиса должна быть максимально когерентной — все функции должны быть тесно связаны и иметь смысл как единое целое.
-4. **Коммуникационные накладные расходы**. При излишнем разделении микросервисов коммуникация между ними может стать значительной проблемой. Каждое взаимодействие требует сетевых запросов, которые увеличивают время отклика и усложняют тестирование. Избежать этого можно, объединяя сервисы, которые часто взаимодействуют друг с другом.
-5. **Масштабируемость и независимость деплоя**. Один из ключевых факторов в пользу микросервисов — возможность масштабировать и развертывать сервисы независимо друг от друга. При этом важно помнить, что слишком мелкие микросервисы могут превратиться в головную боль для команды DevOps из-за увеличения количества деплоя и инфраструктурных задач.
-
-**Подходы к выбору гранулярности**
-- Разбиение по [[Доменная область|доменным областям]]. Этот подход предполагает разделение микросервисов по бизнес-доменам. Например, в системе для электронной коммерции могут существовать отдельные сервисы для управления каталогом товаров, работы с корзиной и обработкой платежей.
-- **Использование событий**. [[../../../../_inbox/Событийно-ориентированное программирование|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы.
-- **Практика "Strangler Fig"**. Этот метод подразумевает постепенное выделение функциональности из монолита в микросервисы. Это помогает определить оптимальную гранулярность, анализируя, какие части системы требуют частых изменений и могут быть разделены без излишних коммуникационных накладных расходов.
-
-**Ошибки, которых следует избегать**
-1. **Слишком крупные сервисы (микромонолиты)**. Они теряют преимущество независимости и приводят к тому, что разработчики вновь оказываются в рамках монолита, но с более сложной архитектурой деплоя и управления.
-2. **Излишняя гранулярность**. Чрезмерное разделение приводит к лавине коммуникаций и делает систему неуправляемой. Это может также вызвать рост сложности в управлении транзакциями и согласованностью данных.
-3. **Игнорирование бизнес-логики**. Определение границ микросервисов только на основе технических аспектов, без учёта бизнес-логики, приводит к нарушению когезии и снижению эффективности разработки.
-
-**Практические рекомендации**
-- **Начинайте с более крупных сервисов** и постепенно выделяйте их части, когда возникает потребность в независимом развитии и деплое. Это поможет избежать излишней сложности на начальных этапах.
-- **Анализируйте связи между сервисами**. Регулярный анализ зависимостей и коммуникационных потоков поможет понять, не стали ли отдельные сервисы слишком тесно связаны и не следует ли их объединить.
-***
-## Мета информация
-**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
-**Родитель**:: [[Микросервис]]
-**Источник**:: 
-**Создана**:: [[2024-11-24]]
-**Автор**:: 
-### Дополнительные материалы
-- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-

dev/architecture/Декомпозиция на микросервисы.md

@@ -1,21 +1,53 @@
 ---
 aliases:
-  - декомпозиции сервисов
+  - размер микросервиса
+  - гранулярность микросервисов
+  - декомпозиции на микросервисы
+  - декомпозиции системы
 tags:
   - maturity/🌱
-date: 2024-11-27
+date: 2024-11-24
 ---
+Гранулярность микросервисов — это один из ключевых вопросов при проектировании распределённых систем. От неё зависит многое: гибкость архитектуры, масштабируемость, время разработки и стоимость поддержки. Однако определение оптимального размера каждого сервиса — задача не из лёгких.
+
+Гранулярность в контексте микросервисной архитектуры — это уровень разделения логики системы на отдельные сервисы. Слишком крупные сервисы рискуют превратиться в [[Монолитная архитектура|монолиты]], теряя преимущества микросервисного подхода. Слишком мелкие, наоборот, создают сложности в управлении и коммуникации, что приводит к росту накладных расходов.
+
+Основной вызов заключается в нахождении оптимального баланса. Микросервисы должны быть достаточно маленькими, чтобы можно было легко управлять их жизненным циклом и развивать независимо от других компонентов. В то же время они должны оставаться самодостаточными и функциональными.
+
+**Принципы определения гранулярности**
+1. **Бизнес-ориентированность**. Микросервис должен отражать конкретный бизнес-процесс или функциональную область. Если сервис охватывает слишком много бизнес-логики, его стоит разделить на более специализированные компоненты. Например, в системе для интернет-магазина логика управления заказами и обработка платежей должны быть разделены на два сервиса.
+2. Правило [[Single Responsibility Principle|единственной ответственности]]. Каждый микросервис должен выполнять одну задачу и делать это хорошо. Если сервис отвечает за множество разнородных функций, вероятно, его стоит разделить. Например, сервис, отвечающий и за авторизацию, и за управление профилем пользователя, нарушает принцип единственной ответственности.
+3. Слабая [[связанность]] и высокая [[Связность|связность]]. Сервисы должны быть слабо связаны друг с другом, чтобы изменения в одном не требовали изменений в других. В то же время внутренняя логика сервиса должна быть максимально когерентной — все функции должны быть тесно связаны и иметь смысл как единое целое.
+4. **Коммуникационные накладные расходы**. При излишнем разделении микросервисов коммуникация между ними может стать значительной проблемой. Каждое взаимодействие требует сетевых запросов, которые увеличивают время отклика и усложняют тестирование. Избежать этого можно, объединяя сервисы, которые часто взаимодействуют друг с другом.
+5. **Масштабируемость и независимость деплоя**. Один из ключевых факторов в пользу микросервисов — возможность масштабировать и развертывать сервисы независимо друг от друга. При этом важно помнить, что слишком мелкие микросервисы могут превратиться в головную боль для команды DevOps из-за увеличения количества деплоя и инфраструктурных задач.
+
+**Подходы к выбору гранулярности**
+- Разбиение по [[Доменная область|доменным областям]]. Этот подход предполагает разделение микросервисов по бизнес-доменам. Например, в системе для электронной коммерции могут существовать отдельные сервисы для управления каталогом товаров, работы с корзиной и обработкой платежей.
+- **Использование событий**. [[../../../../_inbox/Событийно-ориентированное программирование|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы.
+- **Практика "Strangler Fig"**. Этот метод подразумевает постепенное выделение функциональности из монолита в микросервисы. Это помогает определить оптимальную гранулярность, анализируя, какие части системы требуют частых изменений и могут быть разделены без излишних коммуникационных накладных расходов.
+
+**Ошибки, которых следует избегать**
+1. **Слишком крупные сервисы (микромонолиты)**. Они теряют преимущество независимости и приводят к тому, что разработчики вновь оказываются в рамках монолита, но с более сложной архитектурой деплоя и управления.
+2. **Излишняя гранулярность**. Чрезмерное разделение приводит к лавине коммуникаций и делает систему неуправляемой. Это может также вызвать рост сложности в управлении транзакциями и согласованностью данных.
+3. **Игнорирование бизнес-логики**. Определение границ микросервисов только на основе технических аспектов, без учёта бизнес-логики, приводит к нарушению когезии и снижению эффективности разработки.
+
+**Практические рекомендации**
+- **Начинайте с более крупных сервисов** и постепенно выделяйте их части, когда возникает потребность в независимом развитии и деплое. Это поможет избежать излишней сложности на начальных этапах.
+- **Анализируйте связи между сервисами**. Регулярный анализ зависимостей и коммуникационных потоков поможет понять, не стали ли отдельные сервисы слишком тесно связаны и не следует ли их объединить.
 
 ***
 ## Мета информация
 **Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
 **Родитель**:: [[Микросервис]]
 **Источник**:: 
-**Создана**:: [[2024-11-27]]
+**Создана**:: [[2024-11-24]]
 **Автор**:: 
 ### Дополнительные материалы
 - 
 
 ### Дочерние заметки
 <!-- 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

@@ -0,0 +1,41 @@
+---
+aliases:
+  - масштабирование
+  - масштабировании
+tags:
+  - maturity/🌱
+date: 2024-12-03
+---
+**Масштабирование информационных систем** — это процесс увеличения [[Throughput|пропускной способности]] [[../../../../_inbox/Информационная система|информационной системы]] для обработки растущих объемов данных, запросов или пользователей. Этот процесс позволяет системе сохранять стабильность и производительность при росте нагрузки.
+
+Существует три ключевых подхода к масштабированию:
+1. [[highload/Вертикальное масштабирование|Вертикальное масштабирование]] (scale-up). Увеличение ресурсов одного узла, например, за счет добавления памяти или замены процессора на более мощный. Этот подход прост в реализации, но ограничен возможностями оборудования.
+2. [[highload/Горизонтальное масштабирование|Горизонтальное масштабирование]] (scale-out). Добавление новых узлов в систему для распределения нагрузки. Этот способ требует дополнительной настройки архитектуры, но обеспечивает практически неограниченное расширение.
+3. [[Масштабирование по осям X, Y и Z|Куб масштабирования приложений]] (cube scaling). Совмещение вертикального и горизонтального масштабирования с учетом сетевой архитектуры, контейнеризации и других современных технологий.
+
+**Когда нужно задуматься над масштабированием:**
+- **Растущая нагрузка**: Увеличение числа пользователей или объема обрабатываемых данных.
+- Необходимость высокой [[../../../../_inbox/Reliability|отказоустойчивости]]: Системы должны работать без перебоев, даже при сбоях отдельных компонентов.
+- **Требование оптимизации ресурсов**: Гибкое добавление мощности для сокращения расходов.
+
+При выборе подхода важно учитывать:
+- **Тип системы**: [[Монолитная архитектура|Монолитные приложения]] чаще масштабируются вертикально, а [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисные]] — [[highload/Горизонтальное масштабирование|горизонтально]].
+- **Сложность архитектуры**: Простые системы легче масштабировать вертикально, в то время как сложные системы требуют горизонтального подхода.
+- **Бюджет и долгосрочные цели**: Вертикальное масштабирование может быть дорого при достижении аппаратных лимитов, тогда как горизонтальное требует инвестиций в инфраструктуру.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-12-03]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- 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/Масштабирование по осям X, Y и Z.md

@@ -0,0 +1,60 @@
+---
+aliases:
+  - cube scaling
+  - Куб масштабирования приложений
+tags:
+  - maturity/🌱
+date:
+  - - 2024-04-12
+---
+Для [[../../meta/zero/00 HighLoad|систем с высокой нагрузкой]] [[Масштабирование информационной системы|масштабирование]] является ключевым аспектом архитектурного проектирования. Концепция масштабирования по осям X, Y и Z помогает понять, как распределить нагрузку и обеспечить стабильность работы приложения.
+
+![](../../meta/files/images/cfac08bc-c9b0-4894-ab40-7e319c5bc13b.jpg)
+## Масштабирование по оси Х
+Масштабирование по оси X — это увеличение количества одинаковых экземпляров приложения, работающих за [[highload/Балансировка нагрузки|балансировщиком нагрузки]]. Этот подход соответствует понятию [[highload/Горизонтальное масштабирование|горизонтального масштабирования]].
+
+**Как это работает**:  Запросы от клиентов распределяются [[highload/Балансировка нагрузки|балансировщиком]] между несколькими идентичными экземплярами системы.
+
+**Основная цель**:
+- Увеличение [[Throughput|пропускной способности]].
+- Повышение [[../../../../_inbox/Reliability|отказоустойчивости]] за счет резервирования.
+
+**Пример применения**: [[Монолитная архитектура|Монолитные приложения]], где запуск дополнительных экземпляров не требует изменения кода.
+
+![](../../meta/files/images/df56a7dd-ec73-4188-9502-8b6db06762f6.jpg)
+## Масштабирование по оси Z
+Масштабирование по оси Z предполагает разделение системы на подмножества данных, где каждый экземпляр приложения отвечает за обработку определенного набора данных.
+
+**Как это работает**: Входящий запрос направляется маршрутизатором к соответствующему экземпляру на основании определенного атрибута (например, `userid` или региона).
+
+**Основная цель**:
+- Уменьшение нагрузки на каждый экземпляр.
+- Ускорение обработки запросов за счет уменьшения объема данных, с которыми работает каждый узел.
+
+**Пример применения**: [[../../../../_inbox/Шардирование БД|Шардирование]] баз данных, где данные распределяются между разными серверами.
+
+![](../../meta/files/images/Pasted%20image%2020240412202007.png)
+
+## Масштабирование по оси Y
+Масштабирование по оси Y основывается на функциональной [[Декомпозиция на микросервисы|декомпозиции системы]]. Вместо дублирования или разделения данных приложение разбивается на отдельные модули или сервисы.
+
+**Как это работает**: Монолитное приложение делится на самостоятельные модули или микросервисы, каждый из которых отвечает за свою часть функционала.
+
+**Основная цель**:
+- Упрощение разработки и поддержки системы.
+- Устранение узких мест, связанных с усложнением монолита.
+
+**Пример применения**: [[../../../../wiki/zero/00 Микросервисная архитектура|Микросервисная архитектура]], где каждый сервис обрабатывает свои задачи (например, управление пользователями, обработка платежей, логирование).
+
+![](../../meta/files/images/99a03ca9-8253-4085-912e-459dd62f839d.jpg)
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Масштабирование информационной системы]]
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2024-04-12]]
+### Дополнительные материалы
+- 
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

dev/architecture/Монолитная архитектура.md

@@ -3,13 +3,14 @@ aliases:
   - монолит
   - монолиты
   - монолитного приложения
+  - Монолитные приложения
 tags:
   - maturity/🌱
 date: 2024-04-04
 ---
 Монолитная архитектура — это способ проектирования, разработки и деплоя [[../../../../_inbox/Информационная система|информационной системы]] как единого целого. Все компоненты приложения — от пользовательского интерфейса до базы данных — объединены в одном приложении. Такой подход остаётся популярным для многих проектов из-за его простоты на начальных этапах.
 
-Монолитный подход имеет ряд **преимуществ**, которые делают его привлекательным для небольших или средних проектов:
+Преимущества:
 - **Простота разработки**. Все инструменты разработки (например, IDE) сосредоточены на создании единого приложения. Это упрощает работу команды, особенно если проект небольшой и команда ограничена в ресурсах.
 - **Лёгкость внесения радикальных изменений**. В монолитной архитектуре вы можете одновременно менять код и структуру базы данных. После этого достаточно пересобрать и развернуть новое приложение.
 - **Простота тестирования**. Сквозное тестирование охватывает всю систему сразу. Инструменты, такие как Selenium, позволяют тестировать пользовательский интерфейс, API и внутреннюю логику в одном процессе.
@@ -17,7 +18,6 @@ date: 2024-04-04
 - **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за балансировщиком нагрузки, распределяя трафик между ними.
 
 Несмотря на простоту, монолитный подход имеет **ряд ограничений**, которые могут стать критическими при увеличении размера приложения или масштабировании бизнеса:
-
 - **Трудности с масштабированием**. Программные модули конкурируют за ресурсы. Например, модуль обработки изображений, нагружающий CPU, может негативно влиять на стабильность других модулей.
 - **Единые технологии для всех задач**. Монолит ограничивает возможность использовать разные технологии для разных частей системы. Например, вы не сможете использовать Java для одних модулей, а C++ — для других.
 - **Проблемы с надёжностью и стабильностью**. Утечка памяти в одном модуле может вызвать сбой всей системы, поскольку в монолите все компоненты тесно связаны.
@@ -26,7 +26,7 @@ date: 2024-04-04
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Архитектурная концепция]]
+**Родитель**:: [[Архитектурный паттерн]]
 **Источник**:: 
 **Автор**:: 
 **Создана**:: [[2024-04-04]]

dev/architecture/Паттерн проектирования.md

@@ -4,6 +4,7 @@ aliases:
   - шаблон проектирования
   - шаблонов проектирования
   - паттернов
+  - Design Pattern
 tags:
   - maturity/🌱
 date: 2023-11-05

dev/architecture/Распределенный монолит.md

@@ -19,7 +19,7 @@ date: 2024-11-24
 
 **Причины появления распределенного монолита**
 - **Недостаточное понимание микросервисных принципов**. При переходе от монолита к микросервисам важно пересмотреть подходы к разработке и взаимодействию между компонентами. Не все команды понимают, что микросервисы требуют не только разбиения на отдельные сервисы, но и пересмотра способов их взаимодействия и управления данными.
-- Излишняя [[Гранулярность микросервисов|гранулярность микросервисов]]. Желание сделать сервисы как можно более маленькими и специализированными иногда приводит к обратному результату — коммуникационные накладные расходы становятся слишком большими, и система превращается в распределенный монолит с большим количеством зависимостей.
+- Излишняя [[Декомпозиция на микросервисы|гранулярность микросервисов]]. Желание сделать сервисы как можно более маленькими и специализированными иногда приводит к обратному результату — коммуникационные накладные расходы становятся слишком большими, и система превращается в распределенный монолит с большим количеством зависимостей.
 - **Общие ресурсы**. Использование общих баз данных ([[Shared Database|Shared Database]]) или сервисов, которые нельзя изменить независимо, приводит к тому, что сервисы не могут быть развернуты или изменены самостоятельно. 
 - **Плохой дизайн API**. Сервисные интерфейсы, которые создают жесткие зависимости и требуют координации между разными сервисами, также способствуют появлению распределенного монолита.
 

dev/architecture/Реактивное программирование.md

@@ -7,7 +7,7 @@ date: 2023-10-26
 zero-link:
   - "[[../../meta/zero/00 Разработка|00 Разработка]]"
 parents:
-  - "[[Парадигмы разработки]]"
+  - "[[../Парадигма разработки]]"
 linked: 
 ---
 **Реактивное программирование** — это парадигма, ориентированная на потоки данных и распространение изменений. Она использует асинхронные потоки данных (например, Observables в RxJava), которые позволяют обрабатывать события по мере их поступления с автоматическим управлением параллелизмом и асинхронностью.
@@ -16,7 +16,7 @@ linked:
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
-**Родитель**:: [[Архитектурная концепция]]
+**Родитель**:: [[../Парадигма разработки|Парадигма разработки]]
 **Источник**:: 
 **Автор**:: 
 **Создана**:: [[2023-10-26]]

dev/Парадигма разработки.md

@@ -0,0 +1,26 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: "[[2023-10-26]]"
+zero-link: 
+parents: 
+linked:
+---
+- [Реактивное программирование](architecture/Реактивное%20программирование.md)
+- [[architecture/Асинхронное программирование|Асинхронное программирование]]
+***
+## Мета информация
+**Область**:: [[../meta/zero/00 Разработка|00 Разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2023-10-06]]
+### Дополнительные материалы
+- 
+### Дочерние заметки
+<!-- 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 -->

meta/files/images/comp/Pasted image 20240412202007.png.md5

@@ -0,0 +1 @@
+58cd85511a9bbbae258083d9dc08ee37

meta/files/images/comp/Pasted image 20241202191611.png.md5

@@ -0,0 +1 @@
+187f21259eee2f69e7d7dea1444e3bd3

meta/files/images/webp/99a03ca9-8253-4085-912e-459dd62f839d.webp.md5

@@ -0,0 +1 @@
+3b578dd093ce4a5fe91ba8e4f1e99037

meta/files/images/webp/Pasted image 20240412202007.webp.md5

@@ -0,0 +1 @@
+58cd85511a9bbbae258083d9dc08ee37

meta/files/images/webp/Pasted image 20241202191611.webp.md5

@@ -0,0 +1 @@
+187f21259eee2f69e7d7dea1444e3bd3

meta/files/images/webp/cfac08bc-c9b0-4894-ab40-7e319c5bc13b.webp.md5

@@ -0,0 +1 @@
+bc374cb42c96192448864ee0d2ae2c6e

meta/files/images/webp/df56a7dd-ec73-4188-9502-8b6db06762f6.webp.md5

@@ -0,0 +1 @@
+8b1e2c82f9bcfe00d3baf8fd01effd7b

meta/zero/00 HighLoad.md

@@ -9,6 +9,7 @@ aliases:
   - высоконагруженных системах
   - высоконагруженная система
   - высоконагруженных систем
+  - систем с высокой нагрузкой
 ---
 ## Что такое HighLoad?
 Например, один запрос в секунду – это нагрузка явно не highload, любой сервер, вроде бы, справится. Но, например, если он перекодирует видеоролики, то тут может наступить highload.