Обновление

dev/architecture/12-Factor App.md

@@ -0,0 +1,57 @@
+---
+aliases:
+  - двенадцатифакторное приложение
+tags:
+  - maturity/🌱
+  - content/experience
+date: 2024-12-08
+---
+**Двенадцатифакторное приложение (12-Factor App)** — это методология разработки приложений, предложенная инженерами Heroku. Она описывает набор из 12 принципов, которые помогают создавать программное обеспечение, подходящее для облачных сред.
+
+Основные цели этой методологии:
+- Простое масштабирование.
+- Портативность между средами.
+- Упрощение разработки и развертывания.
+
+Эти принципы применимы ко всем видам приложений, но особенно полезны для веб-приложений и микросервисов.
+
+**Принципы двенадцатифакторного приложения**
+
+**Единая кодовая база** должна управляться в системе контроля версий и использоваться во всех средах. Все ветки и деплойменты одного микросервиса привязаны к одному репозиторию. Не должно быть такого, чтобы на один стенд деплой происходил из одного репозитория, а на другой из другого.
+
+> Думал, а как можно нарушить этот принцип. И вспомнил случай. После переименования сервиса в GitLab пришлось сделать для одного стенда форк репозитория, чтобы собраться со старым названием для фикса. Это было связано с тем, что все стенды зависели от названия репозитория, поэтому было невозможно переименовать сервис только для одного стенда.
+
+**Зависимости**. Явное объявление и изоляция зависимостей. Используйте менеджеры зависимостей.
+
+**Конфигурация**. Храните конфигурацию отдельно от кода. Используйте переменные окружения для настройки среды. Пример: URL базы данных, секреты или ключи API задаются через ENV, а не в коде.
+
+**Внешние ресурсы**. Базы данных, очереди, файловые хранилища рассматриваются как прикрепляемые ресурсы. Пример: База данных PostgreSQL или очередь RabbitMQ могут быть заменены без изменения кода.
+
+**Сборка, выпуск, выполнение**. Четкое разделение стадий: сборка приложения, создание релиза и его выполнение.
+
+**Процессы**. Приложение должно быть построено из одного или нескольких независимых процессов. Каждый процесс приложения отвечает за свою задачу (например, обработка HTTP-запросов, фоновые задания).
+
+**Stateless**. Приложение не должно хранить данные или состояние внутри процессов. Все состояния хранятся во внешних ресурсах. Пример: Сессии пользователей сохраняются в Redis, а не в оперативной памяти приложения. Если процесс падает или перезапускается, состояние не теряется, так как оно хранится в Redis, базе данных или другой внешней системе.
+
+**Привязка портов**. Приложение экспортирует HTTP (или другой) сервис через привязанный порт.
+
+**Параллелизм**. Процессы должны быть разделены на масштабируемые модули.
+
+**Среда разработки = среда продакшена**. Минимизируйте различия между стендами разработки и продакшеном.
+
+**Журналирование**. Приложение пишет события в поток вывода (stdout), а обработкой логов занимается внешняя система. Пример: Логи собираются через Elasticsearch или Datadog.
+
+**Административные задачи**. Запускайте административные задачи, такие как миграции базы данных, вместе с запуском сервиса.
+***
+## Мета информация
+**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-12-08]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Database per service.md

@@ -23,7 +23,7 @@ date: 2024-11-24
 
 Лучшие практики
 - **Чёткие границы владения данными**. Определите чёткие границы владения данными для каждого сервиса, - [[Bounded Context|Ограниченный контекст]]. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными.
-- [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны.
+- [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны.
 - **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций.
 - **API вместо прямого доступа к данным**. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать [[Инкапсуляция|инкапсуляцию]] и обеспечивает безопасное взаимодействие между сервисами.
 ***

dev/architecture/Serverless.md

@@ -0,0 +1,53 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-12-08
+---
+**Serverless-архитектура** — это модель разработки приложений, при которой серверы все еще существуют, но управление ими полностью скрыто от разработчиков. Вместо этого, разработчики пишут небольшие, автономные функции, которые исполняются в облачной среде. Инфраструктурой управляет провайдер (например, AWS, Azure, Google Cloud).
+
+Несмотря на название, серверы в Serverless есть, но разработчики:
+- Не управляют серверами напрямую.
+- Не занимаются их настройкой, мониторингом или масштабированием.
+- Платят только за фактическое время выполнения кода (pay-as-you-go).
+
+**Основные принципы**
+- **Вызов на основе событий**. Код (функция) запускается в ответ на событие: HTTP-запрос, запись в базу данных, загрузка файла и т. д. Пример: загрузка изображения в облако запускает функцию для изменения его размера.
+- **Автоматическое масштабирование**. Серверная инфраструктура автоматически увеличивает или уменьшает количество ресурсов в зависимости от нагрузки. Пример: при росте числа запросов добавляются новые инстансы функции.
+- **Оплата за использование**. Вы платите только за фактическое время выполнения кода, а не за простаивающие серверы. Пример: если функция исполняется 200 мс, вы платите только за эти миллисекунды.
+- **Фокус на коде**. Разработчики сосредотачиваются на написании бизнес-логики, а не на настройке инфраструктуры.
+
+**Преимущества Serverless**
+- **Снижение затрат**. Отсутствие расходов на простаивающие ресурсы. Вы платите только за выполнение кода.
+- **Автоматическое масштабирование**. Приложение автоматически адаптируется к изменяющимся нагрузкам.
+- **Быстрота разработки**. Упрощённое управление инфраструктурой позволяет сосредоточиться на бизнес-логике.
+- **Упрощённое развертывание**. Разработчики могут быстро выкатывать изменения, так как управление серверами осуществляется провайдером.
+
+**Недостатки**
+- **Задержки холодного старта**. При запуске функции, которая долгое время не использовалась, может возникнуть задержка из-за необходимости инициализации контейнера.
+- **Ограниченная гибкость**. Провайдеры накладывают ограничения на использование определённых языков, библиотек и объёма ресурсов.
+- **Трудности отладки**. Локальное тестирование может быть сложным из-за особенностей облачных платформ.
+- **Зависимость от провайдера**. Использование специфичных для платформы инструментов может усложнить переносимость приложения.
+- **Высокая стоимость при больших нагрузках**. Для очень нагруженных систем Serverless может оказаться дороже традиционной модели.
+
+Serverless подходит, если:
+- Вы разрабатываете приложения с переменной нагрузкой.
+- Вам нужна быстрая обработка событий (ETL, IoT, уведомления).
+- Вы хотите минимизировать управление инфраструктурой.
+
+Serverless может быть не лучшим выбором, если:
+- Требуется минимальная задержка (например, в высоконагруженных системах реального времени).
+- Вы работаете с задачами, требующими долгого выполнения или сложных вычислений.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Архитектурный паттерн]]
+**Источник**:: 
+**Создана**:: [[2024-12-08]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Shared Database.md

@@ -19,7 +19,7 @@ date: 2024-11-24
  
 **Лучшие практики для избежания Shared Database**
 - [[Database per Service]]. Каждый микросервис должен владеть своей собственной базой данных. Это позволяет сохранять автономность сервисов и исключает возможность прямого доступа к данным другого сервиса.
-- **Событийная синхронизация.** Если данные одного сервиса нужны другому, лучше использовать [[../../../../_inbox/Событийно-ориентированное программирование|событийную архитектуру]]. Сервис, владеющий данными, может отправлять события, на которые подписываются другие сервисы, что помогает синхронизировать информацию без необходимости прямого доступа к общей базе данных.
+- **Событийная синхронизация.** Если данные одного сервиса нужны другому, лучше использовать [[Событийно-ориентированная архитектура|событийную архитектуру]]. Сервис, владеющий данными, может отправлять события, на которые подписываются другие сервисы, что помогает синхронизировать информацию без необходимости прямого доступа к общей базе данных.
 - **Использование API для доступа к данным**. Вместо того чтобы обращаться к базе данных другого сервиса напрямую, следует использовать публичные API. Это позволяет соблюсти инкапсуляцию данных и уменьшить связанность между сервисами.
 ***
 ## Мета информация

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

@@ -30,11 +30,11 @@ date: 2024-10-01
 ### Дочерние заметки
 <!-- 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) -->
-- [[Событийно-ориентированное программирование]]
 - [[Inversion of Control]]
+- [[Архитектурный паттерн]]
 - [[Большой комок грязи]]
 - [[Много клиентов — один поток]]
 - [[Один клиент — один поток]]
 - [[Паттерн проектирования]]
-- [[Архитектурный паттерн]]
+- [[Событийно-ориентированная архитектура]]
 <!-- SerializedQuery END -->

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

@@ -2,6 +2,7 @@
 aliases:
   - архитектурный шаблон
   - Architectural Pattern
+  - архитектурный подход
 tags:
   - maturity/🌱
 date: 2024-12-02
@@ -9,6 +10,8 @@ date: 2024-12-02
 Архитектуры:
 - [[../../../../wiki/zero/00 Микросервисная архитектура|Микросервисная архитектура]]
 - [[Монолитная архитектура]]
+- [[Serverless|Serverless]]
+- [[Событийно-ориентированная архитектура]]
 
 - [[Event Sourcing]]
 ***
@@ -25,6 +28,7 @@ date: 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]]
+- [[Serverless]]
 - [[Монолитная архитектура]]
 - [[00 Микросервисная архитектура]]
 <!-- SerializedQuery END -->

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

@@ -23,7 +23,7 @@ date: 2024-11-24
 
 **Подходы к выбору гранулярности**
 - Разбиение по [[Доменная область|доменным областям]]. Этот подход предполагает разделение микросервисов по бизнес-доменам. Например, в системе для электронной коммерции могут существовать отдельные сервисы для управления каталогом товаров, работы с корзиной и обработкой платежей.
-- **Использование событий**. [[../../../../_inbox/Событийно-ориентированное программирование|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы.
+- **Использование событий**. [[Событийно-ориентированная архитектура|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы.
 - **Практика "Strangler Fig"**. Этот метод подразумевает постепенное выделение функциональности из монолита в микросервисы. Это помогает определить оптимальную гранулярность, анализируя, какие части системы требуют частых изменений и могут быть разделены без излишних коммуникационных накладных расходов.
 
 **Ошибки, которых следует избегать**

dev/architecture/Избыточность данных.md

@@ -26,7 +26,7 @@ date: 2024-11-24
 2. **Увеличение объёма хранилища**. Хранение данных в нескольких формах требует больше места в хранилище. Для высоконагруженных систем с большими объёмами данных это может стать значительным фактором.
 
 Лучшие практики для работы с избыточностью данных
-1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированное программирование|событийную архитектуру]], чтобы поддерживать согласованность данных. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений.
+1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать согласованность данных. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений.
 2. **Оценка необходимости избыточности**. Вводите избыточность только там, где это действительно необходимо для повышения производительности или удобства работы. Не стоит избыточно усложнять систему там, где этого можно избежать.
 3. **Мониторинг консистентности**. Внедряйте механизмы проверки и восстановления консистентности данных между копиями. Это поможет вовремя обнаружить и устранить расхождения.
 

dev/architecture/Много клиентов — один поток.md

@@ -9,7 +9,7 @@ parents:
   - "[[Архитектурная концепция]]"
 linked:
 ---
-Концепция “много клиентов — один поток” предполагает, что один [[../fundamental/Поток процесса ОС|поток]] может обрабатывать множество клиентских запросов. Это возможно благодаря асинхронному или [[../../../../_inbox/Событийно-ориентированное программирование|событийно-ориентированному подходу]], где поток не привязывается к одному запросу, а может переключаться между задачами в зависимости от их состояния (например, ожидания данных). Такой подход широко используется для решения проблем масштабируемости и производительности в современных [[../../meta/zero/00 HighLoad|высоконагруженных системах]].
+Концепция “много клиентов — один поток” предполагает, что один [[../fundamental/Поток процесса ОС|поток]] может обрабатывать множество клиентских запросов. Это возможно благодаря асинхронному или [[Событийно-ориентированная архитектура|событийно-ориентированному подходу]], где поток не привязывается к одному запросу, а может переключаться между задачами в зависимости от их состояния (например, ожидания данных). Такой подход широко используется для решения проблем масштабируемости и производительности в современных [[../../meta/zero/00 HighLoad|высоконагруженных системах]].
 
 В отличие от модели “[[один клиент — один поток]]”, где для каждого запроса создается отдельный поток, в модели “много клиентов — один поток” используется один или ограниченное количество потоков для обслуживания множества клиентов. Этот подход достигается за счет использования [[../../../../_inbox/Не блокирующийся ввод-вывод|неблокирующего ввода/вывода]] (non-blocking I/O) и [[Event Loop|событийного цикла]]. Когда клиентский запрос инициирует операцию, например обращение к базе данных, поток может освободиться и перейти к следующей задаче, вместо того чтобы блокироваться и ждать завершения операции.
 

dev/architecture/Один клиент — один поток.md

@@ -35,7 +35,7 @@ linked:
 **Современные альтернативы**
 С ростом масштабов приложений, особенно в веб-разработке, стали популярны асинхронные и реактивные подходы, где один поток может обслуживать множество клиентов, не создавая новый поток для каждого запроса. Такие подходы позволяют лучше использовать ресурсы системы:
 
-- **Асинхронные модели.** Серверы, такие как [[../../meta/zero/00 Nginx|Nginx]], используют [[../../../../_inbox/Событийно-ориентированное программирование|событийно-ориентированную архитектуру]], где запросы обрабатываются без необходимости создавать новый поток на каждый запрос. Это снижает потребление памяти и улучшает масштабируемость.
+- **Асинхронные модели.** Серверы, такие как [[../../meta/zero/00 Nginx|Nginx]], используют [[Событийно-ориентированная архитектура|событийно-ориентированную архитектуру]], где запросы обрабатываются без необходимости создавать новый поток на каждый запрос. Это снижает потребление памяти и улучшает масштабируемость.
 - [[Реактивное программирование|Реактивное программирование]]. В таких фреймворках, как [[../../meta/zero/00 Quarkus|Quarkus]], Vert.x или [[../../meta/zero/00 SpringBoot|Spring]] WebFlux, запросы обрабатываются асинхронно с использованием реактивных потоков, что позволяет эффективно распределять ресурсы даже при высокой нагрузке.
 
 ***

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

@@ -26,7 +26,7 @@ date: 2024-11-24
 Как избежать создания распределенного монолита
 - Слабая [[связанность]] и независимость деплоя. Стремитесь к тому, чтобы сервисы были как можно более независимыми друг от друга. Это касается не только разработки, но и данных. Каждому микросервису должна принадлежать [[Database per service|своя база данных]], чтобы минимизировать зависимость от других сервисов.
 - **Декомпозиция по бизнес-доменам**. Разделение системы на сервисы должно основываться на бизнес-логике и [[Доменная область|доменных областях]]. Сервисы должны быть построены вокруг конкретных бизнес-процессов, а не технических компонентов, что поможет избежать тесной связанности.
-- [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированное программирование]]. Использование событийной модели взаимодействия позволяет уменьшить тесную связанность сервисов и избавиться от необходимости прямого взаимодействия между ними. Сервисы реагируют на события, а не вызывают друг друга напрямую, что повышает автономность.
+- [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Использование событийной модели взаимодействия позволяет уменьшить тесную связанность сервисов и избавиться от необходимости прямого взаимодействия между ними. Сервисы реагируют на события, а не вызывают друг друга напрямую, что повышает автономность.
 - **Асинхронные коммуникации**. Использование асинхронных методов взаимодействия, таких как [[Брокер сообщений|очереди сообщений]], снижает связанность между сервисами и позволяет им работать независимо друг от друга.
 ***
 ## Мета информация

dev/architecture/Связанность.md

@@ -3,6 +3,7 @@ aliases:
   - coupling
   - связанности
   - связанность
+  - связанные
 tags:
   - maturity/🌱
 date: 2024-11-24

dev/architecture/Событийно-ориентированная архитектура.md

@@ -0,0 +1,51 @@
+---
+aliases:
+  - event-driven
+  - событийно-ориентированную архитектуру
+  - событийно-ориентированному подходу
+  - Событийно-ориентированная архитектура
+  - событийную архитектуру
+  - Событийная архитектура
+tags:
+  - maturity/🌱
+date:
+  - - 2024-03-19
+---
+Событийно-ориентированная архитектура — это [[Архитектурный паттерн|архитектурный подход]], при котором взаимодействие между компонентами системы строится вокруг обмена и обработки событий. Вместо традиционного подхода, где компоненты напрямую вызывают методы или функции друг друга, в событийно-ориентированной архитектуре компоненты реагируют на события, которые создаются внутри системы или поступают из внешних источников.
+
+В этой архитектуре основной фокус направлен на поток событий и их обработку, что позволяет системам быть более гибкими, асинхронными и хорошо масштабируемыми. События могут представлять собой любые значимые изменения состояния или действия: от пользовательских запросов и сообщений сервисов друг другу до сигналов от внешних устройств.
+
+**Ключевые элементы событийно-ориентированной архитектуры:**
+1. **События (Events):** Представляют собой факты или изменения состояния, которые происходят в системе. Например, поступление сообщения в [[../../../../_inbox/00 Kafka|Kafka]], нажатие кнопки в пользовательском интерфейсе или обновление данных в хранилище.
+2. **Обработчики событий (Event Handlers):** Компоненты или сервисы, которые "подписываются" на определённые типы событий и выполняют определённые действия в ответ на их возникновение. Обработчиком может быть микросервис, вызов функции или запуск определённой логики в реакцию на сигнал.
+3. **Цикл обработки событий (Event Loop) или Механизм распределения событий:** Центральный элемент, отвечающий за получение событий, их маршрутизацию и передачу нужным обработчикам. В распределённых системах его роль часто выполняет [[брокер сообщений]] или [[../../../../_inbox/Enterprise Service Bus|шина данных]].
+4. **Очередь событий (Event Queue):** Средство для буферизации и упорядочивания событий при высокой нагрузке или одновременном возникновении большого числа сигналов. Очередь обеспечивает последовательную, контролируемую обработку и повышает надёжность системы.
+
+**Какие задачи хорошо решает событийно-ориентированная архитектура:**
+- Ситуации, когда мгновенный ответ не критичен, но важна асинхронная и надёжная обработка. Например, асинхронная загрузка, парсинг и последующая обработка крупного XML-файла или событий из внешних систем.
+- Сценарии, где требуется легко масштабировать отдельные компоненты, реагирующие на поток входящих данных или сигналов.
+
+**Основные компоненты архитектуры:**
+- [[Брокер сообщений]], выступающий в роли центрального канала обмена событиями.
+- Слабо [[Связанность|связанные]] сервисы и микросервисы, которые подписываются на события и обрабатывают их по мере поступления.
+
+**Преимущества:**
+- Изоляция компонентов: каждый сервис может развиваться и масштабироваться независимо от других.
+- Простота развёртывания и интеграции новых сервисов за счёт слабой [[Связность|связности]].
+- Высокая производительность и масштабируемость: возможность обработки большого количества асинхронных операций в параллель.
+- Лёгкая адаптация под изменяющиеся потребности и нагрузки.
+
+**Недостатки:**
+- Сложность тестирования, поскольку трудно контролировать и предсказать порядок возникновения и обработки событий.
+- Повышенная сложность разработки и отладки из-за асинхронной природы взаимодействий между компонентами.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Архитектурный паттерн]]
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2204-03-19]]
+### Дополнительные материалы
+- 
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

dev/snippet/Файловый сервер на Samba.md

@@ -51,8 +51,9 @@ samba:
 	•	`[comment]` — описание расшаренного ресурса.
 
 **Доступные сборки Samba**:
-- 4.18.9-ro
+- 4.20.6-r1
-- 4.19.6-ro
+- 4.19.6-r0
+- 4.18.9-r0
 
 ***
 ## Мета информация