я указал в статье метрику — кол-во упавших тестов. Я не против классических моделей и метрик, я говорю о том, что только их недостаточно в общем случае
Есть конкретный пример с прошлой недели – при сбое не переподнялись только системы, на которые поставили тулзу для аварийного автоматического переключения. По моделям и алгоритмам – у них выше показатели надёжности, по факту – оказалось что ниже, чем у систем, куда ещё не успели поставить тулзу.
Правильность установки тулзы и ее работоспособность при разных условиях кроме как учебными сбоями не проверить
пять-шесть девяток – метрика на основе уже случившегося. Стресс-тесты позволят посчитать метрику "а что если" – сколько будет девяток (как быстро система поднимется), если умрёт тот или иной хост к примеру
словарь ударений размером примерно в 4 миллиона слов
а можно ли где-то скачать этот или любой другой словарь с ударениями русского языка? Или может быть есть opensource-модель, которая определеяет ударение в слове?
У Пелевина есть и аналогия попроще: каждый мозг/человек – это большой, сложный и уникальный мозаичный витраж; а сознание – это свет, прошедший сквозь данный витраж. Витраж может существовать без источника света, но сознания тогда не возникает
Микросервисная архитектура также снижает сложность внесения изменений в чужой код — ведь при достаточно мелкой гранулярности в самом микросервисе будет достаточно мало кода бизнес-логики, соответственно в нём будет проще разобраться. Сложность при этом скорее всего перейдёт на уровень внесения изменений в архитектуру. Такие изменения, естественно, также должны идти через pull request'ы и проходить review архитектора. Для этого архитектура также должна быть "as Code"
Опыт команды безусловно важен, я его и упоминаю во внешних факторах, которые необходимо учитывать. При этом вовсе необязательно, чтобы все разработчики были синьорами: при высоком уровне инфраструктуры добавление нового микросервиса сводится только к программированию бизнес-логики, и в случае мелкой гранулярности эти несколько строк кода легко можно поручить и менее опытному коллеге.
На мой взгляд, нельзя сказать что 10 сервисов на человека или 10 человек на сервис — плохо, опять же оптимальность соотношения будет зависеть от многих факторов. Главное избегать жесткой привязки: что конкретный микросервис знает и изменяет только конкретный разработчик, т.е. 20 микросервисов на двоих лучше, чем 10 на каждого. На некоторых проектах у нас примерно такое соотношение и получается (~40 микросервисов на 4 бэкенд разработчика)
естественно, если всё работает — ничего не трогай ) работает в плане стабильного time-to-market и качества при внесении изменений. В данной статье как раз и постарался выделить сигналы и моменты, когда пора не только разделять, но и объединять сервисы.
Про более общую тему рефакторинга архитектуры микросервисов (а не только про объединение/разделение) я говорю в следующем докладе (пока в открытом доступе есть только описание и слайды), надеюсь в будущем так же его опубликовать на хабр
да, только дело в том, что в живых проектах потребности, как правило, постоянно растут и видоизменяются. Тут главное не пересидеть — пока будем ждать промежуточного или окончательного устаканивания потребностей (которого может и не произойти), техдолг будет всё расти и расти, увеличивая сложность и стоимость требуемого рефакторинга
под отказоустойчивостью тут подразумеваю Fault tolerance. К примеру, при отказах более мелких сервисов у нас деградация по функциональности будет ниже, чем если ложаться крупные куски системы
Цена за доставку товара для покупателя интернет-магазина редко совпадает с ценой, которую транспортная компания возьмет с самого магазина
Т.е. эффективные тарифы, по которым считается стоимость доставки, в общем случае могут быть никак не связаны с тарифами доставщика.Соответственно хранятся и живут они в новом модуле
Да, новый Тарификатор учитывает габариты товаров и при расчете объемного веса, и при компоновке товаров в посылки (коробки) с соответствующими алгоритмами поворотов/переворотов товаров :)
Формулы расчета объемного веса у доставщиков различаются — это тоже учитывается.
Настроить тарифы можно в том числе и так, чтобы брался максимальный из объемного и физического весов и по нему считалась стоимость доставки.
естественно всё зависит от требований и ограничений. Для кого-то лишний Redis будет несопостовимо дешевле возможных потерь, а для кого-то — дороже )
тут уже на лицо архитектурные ошибки — если мы синхронное взаимодействие пользователя с системой реализуем на бэкенде через асинхронщину
я указал в статье метрику — кол-во упавших тестов. Я не против классических моделей и метрик, я говорю о том, что только их недостаточно в общем случае
Есть конкретный пример с прошлой недели – при сбое не переподнялись только системы, на которые поставили тулзу для аварийного автоматического переключения. По моделям и алгоритмам – у них выше показатели надёжности, по факту – оказалось что ниже, чем у систем, куда ещё не успели поставить тулзу.
Правильность установки тулзы и ее работоспособность при разных условиях кроме как учебными сбоями не проверить
пять-шесть девяток – метрика на основе уже случившегося. Стресс-тесты позволят посчитать метрику "а что если" – сколько будет девяток (как быстро система поднимется), если умрёт тот или иной хост к примеру
а можно ли где-то скачать этот или любой другой словарь с ударениями русского языка? Или может быть есть opensource-модель, которая определеяет ударение в слове?
А тепловая смерть Вселенной со всеми возможными состояниями и комбинациями частиц – это «Гольденштерн все» из пелевинского Трансгуманизма :)
У Пелевина есть и аналогия попроще: каждый мозг/человек – это большой, сложный и уникальный мозаичный витраж; а сознание – это свет, прошедший сквозь данный витраж. Витраж может существовать без источника света, но сознания тогда не возникает
Микросервисная архитектура также снижает сложность внесения изменений в чужой код — ведь при достаточно мелкой гранулярности в самом микросервисе будет достаточно мало кода бизнес-логики, соответственно в нём будет проще разобраться. Сложность при этом скорее всего перейдёт на уровень внесения изменений в архитектуру. Такие изменения, естественно, также должны идти через pull request'ы и проходить review архитектора. Для этого архитектура также должна быть "as Code"
Опыт команды безусловно важен, я его и упоминаю во внешних факторах, которые необходимо учитывать. При этом вовсе необязательно, чтобы все разработчики были синьорами: при высоком уровне инфраструктуры добавление нового микросервиса сводится только к программированию бизнес-логики, и в случае мелкой гранулярности эти несколько строк кода легко можно поручить и менее опытному коллеге.
На мой взгляд, нельзя сказать что 10 сервисов на человека или 10 человек на сервис — плохо, опять же оптимальность соотношения будет зависеть от многих факторов. Главное избегать жесткой привязки: что конкретный микросервис знает и изменяет только конкретный разработчик, т.е. 20 микросервисов на двоих лучше, чем 10 на каждого. На некоторых проектах у нас примерно такое соотношение и получается (~40 микросервисов на 4 бэкенд разработчика)
естественно, если всё работает — ничего не трогай ) работает в плане стабильного time-to-market и качества при внесении изменений. В данной статье как раз и постарался выделить сигналы и моменты, когда пора не только разделять, но и объединять сервисы.
Про более общую тему рефакторинга архитектуры микросервисов (а не только про объединение/разделение) я говорю в следующем докладе (пока в открытом доступе есть только описание и слайды), надеюсь в будущем так же его опубликовать на хабр
да, только дело в том, что в живых проектах потребности, как правило, постоянно растут и видоизменяются. Тут главное не пересидеть — пока будем ждать промежуточного или окончательного устаканивания потребностей (которого может и не произойти), техдолг будет всё расти и расти, увеличивая сложность и стоимость требуемого рефакторинга
под отказоустойчивостью тут подразумеваю Fault tolerance. К примеру, при отказах более мелких сервисов у нас деградация по функциональности будет ниже, чем если ложаться крупные куски системы
Т.е. эффективные тарифы, по которым считается стоимость доставки, в общем случае могут быть никак не связаны с тарифами доставщика.Соответственно хранятся и живут они в новом модуле
Формулы расчета объемного веса у доставщиков различаются — это тоже учитывается.
Настроить тарифы можно в том числе и так, чтобы брался максимальный из объемного и физического весов и по нему считалась стоимость доставки.