Post #25
187
👻 Пока по гошке скучно привыкаю к синтаксису(в кодварс), расскажу как на текущем проекте происходит переезд функционала на отдельный сервис(опыт распила монолита в вакансиях).
Главная задача плавный переезд, что в данном случае означает возможность увеличивать количество данных юзеров которые будут обрабатываться на сервисе. Т.е. запустили сервис и решили попробывать что случится если мы 10 процентов юзеров переведом втуда, и так далее увеличивая до 100 полностью переехав.
🦴 Как бы пресетап, CQRS паттерн, не обазательно, но удобно одна точка входа/выхода по сути команду которая раньше записывала/апдейтила в базу переделываем на месседж в кафку(либо пост запрос как пример) который прочитает наш сервис.
🦴 Flipper - наш главный гем который дает на функционал включения/выключения фич и их процентов
🦴 Redis - тоже можно и другую базу, просто пример реализации с редисом
💀
Начинаем с Flipper,
💀
- непосредственно в том месте где логика текущего функционала, там где у нас commad или query, к сожелению у меня например не все так гладко добавляли не только в одном месте(команда/кверя), но в процессе можно отрефакторить "контрабандой" - потом будем на перформансе хвастаться. Так как у нас какойто процент юзеров, то для новых это тоже актуально Flipper будет для каждого 10 нового юзера делать enable наш фича флаг.
-второе место это джоба которая сразу отправит нам 10 процентов юзеров и так далее пока не перевезем всех.
💀подробнее про второе место, а именно джобу
этот кусочек кода будет практически одинаковым для новых юзеров и для джобы
Но в джобе нам нужно запомнить данные которые уже отправились, потому что мы еще не раз ее запустим из-за того что запускаем по частям 10-20-30 и тд процентов юзеров(любых других данных), тут пригодится кэш
и добавляем в джобу еще один иф
после проверки Flipper.
Альтернативных гемов не встречал, мы его так же юзаем для любого другого нового функционала на монолите только для 100 процентов, таким образом если что то пошло не так можно не откатывать релиз а просто выключить в админке. Ну и так же АБ тестирование тоже с ним происходит, там уже тоже учитываются проценты.
Главная задача плавный переезд, что в данном случае означает возможность увеличивать количество данных юзеров которые будут обрабатываться на сервисе. Т.е. запустили сервис и решили попробывать что случится если мы 10 процентов юзеров переведом втуда, и так далее увеличивая до 100 полностью переехав.
🦴 Как бы пресетап, CQRS паттерн, не обазательно, но удобно одна точка входа/выхода по сути команду которая раньше записывала/апдейтила в базу переделываем на месседж в кафку(либо пост запрос как пример) который прочитает наш сервис.
🦴 Flipper - наш главный гем который дает на функционал включения/выключения фич и их процентов
🦴 Redis - тоже можно и другую базу, просто пример реализации с редисом
💀
Начинаем с Flipper,
Flipper.enable(:new_feature)- для простоты пишем это в консоле, у нас появляется функионал
Flipper.enabled?(:new_feature)- где так же вторым аргументом можно передать юзера, а так же
enable_percentage_of_actorsгде вторым аргументом процент который мы хотим установить. Соответсвенно в кодовой базе это будет выглядеть как добавление ифов с
Flipper.enabled?где в елсе будет старый функционал, а в ифе новый
💀
Мы делаем 2 способа отправки данных из монолита в сервис:
- непосредственно в том месте где логика текущего функционала, там где у нас commad или query, к сожелению у меня например не все так гладко добавляли не только в одном месте(команда/кверя), но в процессе можно отрефакторить "контрабандой" - потом будем на перформансе хвастаться. Так как у нас какойто процент юзеров, то для новых это тоже актуально Flipper будет для каждого 10 нового юзера делать enable наш фича флаг.
-второе место это джоба которая сразу отправит нам 10 процентов юзеров и так далее пока не перевезем всех.
💀подробнее про второе место, а именно джобу
actor = OpenStruct.new(flipper_id: “User;#{user_id}")
return if FeatureFlag.disabled?(:feature_flag, actor)
этот кусочек кода будет практически одинаковым для новых юзеров и для джобы
Но в джобе нам нужно запомнить данные которые уже отправились, потому что мы еще не раз ее запустим из-за того что запускаем по частям 10-20-30 и тд процентов юзеров(любых других данных), тут пригодится кэш
Rails.cache.write("#{user_id}_specific_key", user_id, expires_in: 90.days и добавляем в джобу еще один иф
return if Rails.cache.fetch(“#{user_id}_specific_key”).present? после проверки Flipper.
Альтернативных гемов не встречал, мы его так же юзаем для любого другого нового функционала на монолите только для 100 процентов, таким образом если что то пошло не так можно не откатывать релиз а просто выключить в админке. Ну и так же АБ тестирование тоже с ним происходит, там уже тоже учитываются проценты.
- 🔥 2
- ⚡ 1
