Приведу несколько распространённых стратегий развертывания приложений/сервисов, с акцентом на два момента:

• Без простоя — простаивают ли наши сервисы в процессе развертывания новой версии приложения.

• Целевые пользователи — можно ли предоставить возможность протестировать новый функционал приложения ограниченному количеству пользователей (фокус‑группе).

1. Big Bang Deployment
   
   Данная стратегия развертывания довольно проста: мы развертываем новую версию за один раз с простоем серверов. Для этой стратегии необходима подготовка. В случае сбоя в процессе развертывания мы откатываемся к предыдущей версии.
   
    — Без простоев — ????
    — Целевые пользователи — ????
   

2. Rolling Deployment
   
   Rolling Deployment (скользящее развёртывание) использует поэтапное развертывание в сравнении с первой стратегией. Серверы обновляются один за другим в течение определенного периода времени.
   
    — Без простоев — ????
    — Целевые пользователи — ????
   

3. Blue-Green Deployment
   
   При «сине‑зеленом» развертывании две среды развертываются в рабочей среде одновременно. Команда QA выполняет различные тесты в зеленой среде. Как только зеленая среда проходит тесты, балансировщик нагрузки переключает пользователей на нее.
   
    — Без простоев — ????
    — Целевые пользователи — ????
   

4. Canary Deployment
   
   При канареечном развертывании только небольшая часть серверов обновляется до новой версии, после прохождения всех тестов часть пользователей перенаправляется на канареечные серверы (обновленные серверы).
   
    — Без простоев — ????
    — Целевые пользователи — ????
   

5. Feature Toggle
   
   В рамках данной стратегии небольшой части пользователей выставляется флаг, который позволяет получить доступ к новой функции, в то время как другие пользователи работают со старым приложением. Ее можно использовать в сочетании с другими стратегиями.
   
    — Без простоев — ????
    — Целевые пользователи — ????

Теперь разберем пять популярных стратегий «жонглирования» данными между системами кэширования и базами данных.

1. Стратегия чтения данных — Cache Aside
   
   Когда приложению необходимо прочитать данные из базы данных, оно сначала проверяет кэш на наличие этих данных. Если данные доступны (a cache hit), кэшированные данные возвращаются. Если данные недоступны (a cache miss), приложение обращается к базе данных. Данные возвращаются приложению и кэш обновляется.

2. Стратегия чтения данных — Read Through
   
   Когда приложение запрашивает в кэше данные и в кэше их не оказывается, то система кэширования самостоятельно запрашивается эти данные из базы данных. При возвращении данных от базы данных система кэширования их сохраняет у себя и возвращает приложению.

3. Стратегия записи данных — Write Around
   
   В этой стратегии данные записываются только в базу данных без записи в кэш. Данные попадаю в кэш только по мере необходимости (см. первую стратегию). Такая стратегия хороша для приложений, которые не часто повторно считывают недавно записанные данные. Стратегия приводит к меньшей задержке записи, но большей задержке чтения, что является приемлемым компромиссом для таких сценариев.

4. Стратегия записи данных — Write Through
   
   В этой стратегии данные одновременно записываются в кэш и в базу данных. Порядок записи данных тут не важен, главное — это подтверждение того факта, что данные записаны в оба места. Стратегия хороша для приложений, которые часто записывают, а затем с еще большей частотой, считывают данные. Это приведет к несколько большей задержке записи, но низкой задержке чтения. Таким образом, можно потратить немного больше времени на запись данных один раз, но затем получить выгоду от частого чтения с низкой задержкой (латентностью).

5. Стратегия записи данных — Write Back or Write Behind
   
   В этой стратегии данные записываются в кэш, и этого нам достаточно чтобы убедится в том, что данные успешно записаны. Данные также записываются в базу данных, но в фоновом режиме (асинхронно с использованием очереди). Стратегия лучше всего подходит для смешанных операций (чтения или записи), поскольку операции чтения и записи имеют практически одинаковое время отклика.

Так какая стратегия больше подходит вам?

Если статья показалась вам интересной, то у меня в планах еще целая серия на эту тему. Так что, если не хотите их пропустить — буду благодарен за подписку на мой ТГ‑канал HowToSchool.