Blue Green Deployment
Концепт: При необходимости деплойить новые изменения для проекта, старая версия кода становится "Синей". Новая версия кода становится "Зеленой". То есть в контексте одного деплоя появляется две продакшн версии (для минимизации времени простоя). В любое время один из них активен.
На деле: При подготовке новой версии приложения, зеленая версия проходит финальное тестирование. После того, как мы убедились, что зеленая работает как ожидается в продакшене, настраиваем роутер так, что бы все входящие запросы шли в зеленую операционную среду - синяя находится в режиме ожидания. Если зеленая версия устраивает своей работой и стабильности, делаем ее staging.
Преимущества: Всегда есть возможность откатиться до старого состояния путем переключения роутера обратно на синий продакшн.
Недостатки:
Нужно поддерживать 2 версии приложения ка минимум в процессе деплоймента. Иногда поддерживать два полностью параллельных энвароймента.
Что бы процесс проходил быстро и безболезненно нужны всевозможные инструменты сборки и автоматизации и их настройка.
Важно: обе версии должны быть максимально самостоятельными, но и максимально идентичными.
Хитрость: для адекватной работы БД, нужно разделить деплой изменения логических структур и обновление приложения. Для этого сначала нужно применить рефакторинг базы данных, чтобы изменить структуры для поддержки новой и старой версий приложения, задеплоить эти изменения, проверить, что всё хорошо работает, и у нас есть версия предыдущего состояния, и только потом задеплоить новую версию приложения (а когда обновления уже устаканились, удалить поддержку базы данных для старой версии).
В контексте микросервисов: необходимо дублировать тулы и их настройку и координацию самого сине-зеленого деплоймента на каждый сервис.
Шаблон Tolerant Reader
Концепция: будь консервативным к тому, что делаешь, будь либеральным к тому, что получаешь от других.
На деле: Всегда может возникнуть необходимость внести критическое изменение в обратную совместимость (backwards compatibility breaking change), нужно постараться делать это лишь в крайнем случае. Чтобы не менять свой сервис постоянно, создать его так, чтобы сервис приходилось менять только при изменении действительно важных данных. Для клиентского кода аппликабл.
Правила:
- Сервис должен отдавать клиенту такое API, которое в минимальном виде может что-то сломать (например, использовать такие форматы общения как Thrift и Protocol Buffers).
- Использовать только те поля данных, которые вам нужны и не использовать лишнее.
- Делать минимальные предположения о структуре данных (использовать XPath или JsonPath и не делать запросы напрямую).
Шаблон Consumer Deriver Contracts (Контракты, ориентированные на потребителя)
Зачем это нужно: В микросервисной архитектуре зависимости между сервисами являются источником проблем. Шаблон CDC помогает решать эти проблемы способом, устраивающим и разработчиков сервиса, и его потребителей.
Мы позволяем многое себе (из шаблона выше), но мы ожидаем от сервера определенных вещей.
Этот шаблон - контракты от клиента которые мы даем сервисным ребятам. С помощью Schematron.
Контракт - не только формат данных. Когда работаешь с внешнем сервисе хотим что бы он всегда отдавал данные 24 на 7 , из локальной сетки за такое то время отдавалось, из внешней за такое то, при нагрузке вели себя так вот. Концепция: Consumer-Driven Contracts позволяет поставщикам лучше понимать своих потребителей и фокусирует развитие сервиса на том, что нужно потребителям.Устное обсуждение деталей и превращение этого в тесты.
Это все инфа об их комминтменте и дефинитион оф дан, то что все хорошо, если выполняем его. У них при этом есть еще и инфа о том какие изменения являющиеся breaking для клиента (с помощью теста понятно), а какие нет. В случае опасных изменений - обсуждать с клиентом.
Концепция: Consumer-Driven Contracts позволяет поставщикам лучше понимать своих потребителей и фокусирует развитие сервиса на том, что нужно потребителям.
На деле:
- Поставщик сервиса должен предлагать потребителям схемы документов (Schematron), что бы они могли использовать его функциональность = контракт поставщика.
Детали:
- Контракт поставщика - описывает функциональность сервиса в виде набора экспортируемых элементов, необходимых для использования этой функциональности. Список элементов: схемы документов, интерфейсы, диалоги, политики, характеристики качества обслуживания.
UI (SPA) and Microservices
Два варианта:
- Монолитный UI использующий серверные микрослужбы. Сам UI, формы и стили определены в клиентском приложении и не зависят от микросервисов.
- Составной UI использующий микросервисы. UI создается и формируется самими микро службами. Некоторые микрослужбы отвечают за внешний вид определенных областей пользовательского интерфейса.Основное различие в том, что есть компоненты пользовательского интерфейса клиента на основе шаблонов (например, классы TypeScript), и модель представления, определяющая форму данных пользовательского интерфейса для этих шаблонов, поступает от каждой микрослужбы. Во время запуска приложения клиента каждый из компонентов пользовательского интерфейса клиента (например, классы TypeScript) регистрируется в микрослужбе инфраструктуры, которая предоставляет модели представления для данного сценария. Если микрослужба изменяет форму интерфейса, это приводит к изменению пользовательского интерфейса.