diff --git a/dev/architecture/12-Factor App.md b/dev/architecture/12-Factor App.md new file mode 100644 index 00000000..2674472c --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Database per service.md b/dev/architecture/Database per service.md index c523fa0e..b3f400ad 100644 --- a/dev/architecture/Database per service.md +++ b/dev/architecture/Database per service.md @@ -23,7 +23,7 @@ date: 2024-11-24 Лучшие практики - **Чёткие границы владения данными**. Определите чёткие границы владения данными для каждого сервиса, - [[Bounded Context|Ограниченный контекст]]. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными. -- [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны. +- [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны. - **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций. - **API вместо прямого доступа к данным**. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать [[Инкапсуляция|инкапсуляцию]] и обеспечивает безопасное взаимодействие между сервисами. *** diff --git a/dev/architecture/Serverless.md b/dev/architecture/Serverless.md new file mode 100644 index 00000000..fc01dac8 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Shared Database.md b/dev/architecture/Shared Database.md index 05f087ed..1421d892 100644 --- a/dev/architecture/Shared Database.md +++ b/dev/architecture/Shared Database.md @@ -19,7 +19,7 @@ date: 2024-11-24 **Лучшие практики для избежания Shared Database** - [[Database per Service]]. Каждый микросервис должен владеть своей собственной базой данных. Это позволяет сохранять автономность сервисов и исключает возможность прямого доступа к данным другого сервиса. -- **Событийная синхронизация.** Если данные одного сервиса нужны другому, лучше использовать [[../../../../_inbox/Событийно-ориентированное программирование|событийную архитектуру]]. Сервис, владеющий данными, может отправлять события, на которые подписываются другие сервисы, что помогает синхронизировать информацию без необходимости прямого доступа к общей базе данных. +- **Событийная синхронизация.** Если данные одного сервиса нужны другому, лучше использовать [[Событийно-ориентированная архитектура|событийную архитектуру]]. Сервис, владеющий данными, может отправлять события, на которые подписываются другие сервисы, что помогает синхронизировать информацию без необходимости прямого доступа к общей базе данных. - **Использование API для доступа к данным**. Вместо того чтобы обращаться к базе данных другого сервиса напрямую, следует использовать публичные API. Это позволяет соблюсти инкапсуляцию данных и уменьшить связанность между сервисами. *** ## Мета информация diff --git a/dev/architecture/Архитектурная концепция.md b/dev/architecture/Архитектурная концепция.md index ed5f41f2..cbc8e985 100644 --- a/dev/architecture/Архитектурная концепция.md +++ b/dev/architecture/Архитектурная концепция.md @@ -30,11 +30,11 @@ date: 2024-10-01 ### Дочерние заметки -- [[Событийно-ориентированное программирование]] - [[Inversion of Control]] +- [[Архитектурный паттерн]] - [[Большой комок грязи]] - [[Много клиентов — один поток]] - [[Один клиент — один поток]] - [[Паттерн проектирования]] -- [[Архитектурный паттерн]] +- [[Событийно-ориентированная архитектура]] diff --git a/dev/architecture/Архитектурный паттерн.md b/dev/architecture/Архитектурный паттерн.md index f3e24172..2da88e69 100644 --- a/dev/architecture/Архитектурный паттерн.md +++ b/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 - [[Event Sourcing]] +- [[Serverless]] - [[Монолитная архитектура]] - [[00 Микросервисная архитектура]] diff --git a/dev/architecture/Декомпозиция на микросервисы.md b/dev/architecture/Декомпозиция на микросервисы.md index f129e8f4..06d8e657 100644 --- a/dev/architecture/Декомпозиция на микросервисы.md +++ b/dev/architecture/Декомпозиция на микросервисы.md @@ -23,7 +23,7 @@ date: 2024-11-24 **Подходы к выбору гранулярности** - Разбиение по [[Доменная область|доменным областям]]. Этот подход предполагает разделение микросервисов по бизнес-доменам. Например, в системе для электронной коммерции могут существовать отдельные сервисы для управления каталогом товаров, работы с корзиной и обработкой платежей. -- **Использование событий**. [[../../../../_inbox/Событийно-ориентированное программирование|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы. +- **Использование событий**. [[Событийно-ориентированная архитектура|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы. - **Практика "Strangler Fig"**. Этот метод подразумевает постепенное выделение функциональности из монолита в микросервисы. Это помогает определить оптимальную гранулярность, анализируя, какие части системы требуют частых изменений и могут быть разделены без излишних коммуникационных накладных расходов. **Ошибки, которых следует избегать** diff --git a/dev/architecture/Избыточность данных.md b/dev/architecture/Избыточность данных.md index 57081210..8028fc4a 100644 --- a/dev/architecture/Избыточность данных.md +++ b/dev/architecture/Избыточность данных.md @@ -26,7 +26,7 @@ date: 2024-11-24 2. **Увеличение объёма хранилища**. Хранение данных в нескольких формах требует больше места в хранилище. Для высоконагруженных систем с большими объёмами данных это может стать значительным фактором. Лучшие практики для работы с избыточностью данных -1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированное программирование|событийную архитектуру]], чтобы поддерживать согласованность данных. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений. +1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать согласованность данных. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений. 2. **Оценка необходимости избыточности**. Вводите избыточность только там, где это действительно необходимо для повышения производительности или удобства работы. Не стоит избыточно усложнять систему там, где этого можно избежать. 3. **Мониторинг консистентности**. Внедряйте механизмы проверки и восстановления консистентности данных между копиями. Это поможет вовремя обнаружить и устранить расхождения. diff --git a/dev/architecture/Много клиентов — один поток.md b/dev/architecture/Много клиентов — один поток.md index 863b78bf..6aff4c95 100644 --- a/dev/architecture/Много клиентов — один поток.md +++ b/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|событийного цикла]]. Когда клиентский запрос инициирует операцию, например обращение к базе данных, поток может освободиться и перейти к следующей задаче, вместо того чтобы блокироваться и ждать завершения операции. diff --git a/dev/architecture/Один клиент — один поток.md b/dev/architecture/Один клиент — один поток.md index d993c789..41669331 100644 --- a/dev/architecture/Один клиент — один поток.md +++ b/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, запросы обрабатываются асинхронно с использованием реактивных потоков, что позволяет эффективно распределять ресурсы даже при высокой нагрузке. *** diff --git a/dev/architecture/Распределенный монолит.md b/dev/architecture/Распределенный монолит.md index b1531d5e..0bd61428 100644 --- a/dev/architecture/Распределенный монолит.md +++ b/dev/architecture/Распределенный монолит.md @@ -26,7 +26,7 @@ date: 2024-11-24 Как избежать создания распределенного монолита - Слабая [[связанность]] и независимость деплоя. Стремитесь к тому, чтобы сервисы были как можно более независимыми друг от друга. Это касается не только разработки, но и данных. Каждому микросервису должна принадлежать [[Database per service|своя база данных]], чтобы минимизировать зависимость от других сервисов. - **Декомпозиция по бизнес-доменам**. Разделение системы на сервисы должно основываться на бизнес-логике и [[Доменная область|доменных областях]]. Сервисы должны быть построены вокруг конкретных бизнес-процессов, а не технических компонентов, что поможет избежать тесной связанности. -- [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированное программирование]]. Использование событийной модели взаимодействия позволяет уменьшить тесную связанность сервисов и избавиться от необходимости прямого взаимодействия между ними. Сервисы реагируют на события, а не вызывают друг друга напрямую, что повышает автономность. +- [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Использование событийной модели взаимодействия позволяет уменьшить тесную связанность сервисов и избавиться от необходимости прямого взаимодействия между ними. Сервисы реагируют на события, а не вызывают друг друга напрямую, что повышает автономность. - **Асинхронные коммуникации**. Использование асинхронных методов взаимодействия, таких как [[Брокер сообщений|очереди сообщений]], снижает связанность между сервисами и позволяет им работать независимо друг от друга. *** ## Мета информация diff --git a/dev/architecture/Связанность.md b/dev/architecture/Связанность.md index f1da0528..f5bf6692 100644 --- a/dev/architecture/Связанность.md +++ b/dev/architecture/Связанность.md @@ -3,6 +3,7 @@ aliases: - coupling - связанности - связанность + - связанные tags: - maturity/🌱 date: 2024-11-24 diff --git a/dev/architecture/Событийно-ориентированная архитектура.md b/dev/architecture/Событийно-ориентированная архитектура.md new file mode 100644 index 00000000..f3ffffec --- /dev/null +++ b/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]] +### Дополнительные материалы +- +### Дочерние заметки + diff --git a/dev/snippet/Файловый сервер на Samba.md b/dev/snippet/Файловый сервер на Samba.md index eff87cc2..de207c95 100644 --- a/dev/snippet/Файловый сервер на Samba.md +++ b/dev/snippet/Файловый сервер на Samba.md @@ -51,8 +51,9 @@ samba: • `[comment]` — описание расшаренного ресурса. **Доступные сборки Samba**: -- 4.18.9-ro -- 4.19.6-ro +- 4.20.6-r1 +- 4.19.6-r0 +- 4.18.9-r0 *** ## Мета информация