Спасибо за подробный разбор :) Отчасти согласен, но далеко не со всем. К примеру:
Стоп... актуализации? Т.е. та самая проблема, которая должна была решиться, возникает в новом качестве? Теперь она блокирует развертывание не только, если у вас что-то в коде и конфиге не так. Теперь придется найти ту самую диаграмму которая не сходится с конфигом и ее тоже поправить. Как ее найти? Кто поправить должен? Решение не предложено.
Как раз на самом раннем этапе тест и покажет максимально точно что и где нужно поправить. Если нужны изменения в архитектурной схеме — это делает разработчик и отправляет на ревью архитектору (ответственному за архитектуру решения тимлиду/техлиду).
В целом, как в треде уже отметили — это лишь первый шаг, на котором я не остановился (к примеру есть уже следующий шаг в плане автогенерации архитектурных схем) и не планирую останавливаться в дальнейшем =)
постараюсь выделить несколько причин: - потребителями одних и тех же данных могут быть несколько разных бизнес-логик; - нагрузка и ресурсоёмкость операций извлечения и обработки данных обычно разные. В случае совмещения, мы не сможем смасштабировать, к примеру, только операции обработки данных; - оба пункта выше являются конкретными примерами возможных проблем нарушения базового принципа единственности ответственности
тут вопрос во взаимодействии с пользователем, т.е. в UI/UX. Если мы понимаем, что за увлоный таймаут в 1 секунду мы не сможем пользователю сказать, что всё ок, транзакция выполнена или не ок, завершилась с ошибкой — то пользователю явно прозрачно об этом сообщаем. К примеру, секунду крутим лоадер, если за секунду не успели — говорим, что ещё обрабатывается, результат пришлём на почту, вкладку можно закрыть (или, "пожалуйста не закрывайте вкладку, обновим статус операции через 10 секунд"). Короче не кидаем пользователя в неопределенности с бесконечным лоадером. Но это уже несколько отдельная от отказоустойчивости тема :)
в вашем случае умирать быстро должны подключения и по цепочке запросы их инициализирующие, далее должен сработать circuit breaker. К сожалению, любой подход или паттерн можно понять и использовать искаженным образом — в общем случае, это не означает что принцип не верен
я указал в статье метрику — кол-во упавших тестов. Я не против классических моделей и метрик, я говорю о том, что только их недостаточно в общем случае
Есть конкретный пример с прошлой недели – при сбое не переподнялись только системы, на которые поставили тулзу для аварийного автоматического переключения. По моделям и алгоритмам – у них выше показатели надёжности, по факту – оказалось что ниже, чем у систем, куда ещё не успели поставить тулзу.
Правильность установки тулзы и ее работоспособность при разных условиях кроме как учебными сбоями не проверить
пять-шесть девяток – метрика на основе уже случившегося. Стресс-тесты позволят посчитать метрику "а что если" – сколько будет девяток (как быстро система поднимется), если умрёт тот или иной хост к примеру
словарь ударений размером примерно в 4 миллиона слов
а можно ли где-то скачать этот или любой другой словарь с ударениями русского языка? Или может быть есть opensource-модель, которая определеяет ударение в слове?
У Пелевина есть и аналогия попроще: каждый мозг/человек – это большой, сложный и уникальный мозаичный витраж; а сознание – это свет, прошедший сквозь данный витраж. Витраж может существовать без источника света, но сознания тогда не возникает
Микросервисная архитектура также снижает сложность внесения изменений в чужой код — ведь при достаточно мелкой гранулярности в самом микросервисе будет достаточно мало кода бизнес-логики, соответственно в нём будет проще разобраться. Сложность при этом скорее всего перейдёт на уровень внесения изменений в архитектуру. Такие изменения, естественно, также должны идти через pull request'ы и проходить review архитектора. Для этого архитектура также должна быть "as Code"
Опыт команды безусловно важен, я его и упоминаю во внешних факторах, которые необходимо учитывать. При этом вовсе необязательно, чтобы все разработчики были синьорами: при высоком уровне инфраструктуры добавление нового микросервиса сводится только к программированию бизнес-логики, и в случае мелкой гранулярности эти несколько строк кода легко можно поручить и менее опытному коллеге.
На мой взгляд, нельзя сказать что 10 сервисов на человека или 10 человек на сервис — плохо, опять же оптимальность соотношения будет зависеть от многих факторов. Главное избегать жесткой привязки: что конкретный микросервис знает и изменяет только конкретный разработчик, т.е. 20 микросервисов на двоих лучше, чем 10 на каждого. На некоторых проектах у нас примерно такое соотношение и получается (~40 микросервисов на 4 бэкенд разработчика)
естественно, если всё работает — ничего не трогай ) работает в плане стабильного time-to-market и качества при внесении изменений. В данной статье как раз и постарался выделить сигналы и моменты, когда пора не только разделять, но и объединять сервисы.
Про более общую тему рефакторинга архитектуры микросервисов (а не только про объединение/разделение) я говорю в следующем докладе (пока в открытом доступе есть только описание и слайды), надеюсь в будущем так же его опубликовать на хабр
да, только дело в том, что в живых проектах потребности, как правило, постоянно растут и видоизменяются. Тут главное не пересидеть — пока будем ждать промежуточного или окончательного устаканивания потребностей (которого может и не произойти), техдолг будет всё расти и расти, увеличивая сложность и стоимость требуемого рефакторинга
под отказоустойчивостью тут подразумеваю Fault tolerance. К примеру, при отказах более мелких сервисов у нас деградация по функциональности будет ниже, чем если ложаться крупные куски системы
Цена за доставку товара для покупателя интернет-магазина редко совпадает с ценой, которую транспортная компания возьмет с самого магазина
Т.е. эффективные тарифы, по которым считается стоимость доставки, в общем случае могут быть никак не связаны с тарифами доставщика.Соответственно хранятся и живут они в новом модуле
Спасибо за подробный разбор :) Отчасти согласен, но далеко не со всем. К примеру:
Как раз на самом раннем этапе тест и покажет максимально точно что и где нужно поправить. Если нужны изменения в архитектурной схеме — это делает разработчик и отправляет на ревью архитектору (ответственному за архитектуру решения тимлиду/техлиду).
В целом, как в треде уже отметили — это лишь первый шаг, на котором я не остановился (к примеру есть уже следующий шаг в плане автогенерации архитектурных схем) и не планирую останавливаться в дальнейшем =)
Лично мне нравится ресурс: https://microservices.io/
Конкретно про ACL-паттерн, есть здесь: https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer, но в несколько другом варианте реализации.
Также у меня есть несколько докладов про архитектуру и паттерны. Тут в том числе про ACL паттерн:
А тут в целом про более общие принципы проектирования:
постараюсь выделить несколько причин:
- потребителями одних и тех же данных могут быть несколько разных бизнес-логик;
- нагрузка и ресурсоёмкость операций извлечения и обработки данных обычно разные. В случае совмещения, мы не сможем смасштабировать, к примеру, только операции обработки данных;
- оба пункта выше являются конкретными примерами возможных проблем нарушения базового принципа единственности ответственности
тут вопрос во взаимодействии с пользователем, т.е. в UI/UX. Если мы понимаем, что за увлоный таймаут в 1 секунду мы не сможем пользователю сказать, что всё ок, транзакция выполнена или не ок, завершилась с ошибкой — то пользователю явно прозрачно об этом сообщаем. К примеру, секунду крутим лоадер, если за секунду не успели — говорим, что ещё обрабатывается, результат пришлём на почту, вкладку можно закрыть (или, "пожалуйста не закрывайте вкладку, обновим статус операции через 10 секунд"). Короче не кидаем пользователя в неопределенности с бесконечным лоадером. Но это уже несколько отдельная от отказоустойчивости тема :)
в вашем случае умирать быстро должны подключения и по цепочке запросы их инициализирующие, далее должен сработать circuit breaker. К сожалению, любой подход или паттерн можно понять и использовать искаженным образом — в общем случае, это не означает что принцип не верен
естественно всё зависит от требований и ограничений. Для кого-то лишний Redis будет несопостовимо дешевле возможных потерь, а для кого-то — дороже )
тут уже на лицо архитектурные ошибки — если мы синхронное взаимодействие пользователя с системой реализуем на бэкенде через асинхронщину
я указал в статье метрику — кол-во упавших тестов. Я не против классических моделей и метрик, я говорю о том, что только их недостаточно в общем случае
Есть конкретный пример с прошлой недели – при сбое не переподнялись только системы, на которые поставили тулзу для аварийного автоматического переключения. По моделям и алгоритмам – у них выше показатели надёжности, по факту – оказалось что ниже, чем у систем, куда ещё не успели поставить тулзу.
Правильность установки тулзы и ее работоспособность при разных условиях кроме как учебными сбоями не проверить
пять-шесть девяток – метрика на основе уже случившегося. Стресс-тесты позволят посчитать метрику "а что если" – сколько будет девяток (как быстро система поднимется), если умрёт тот или иной хост к примеру
а можно ли где-то скачать этот или любой другой словарь с ударениями русского языка? Или может быть есть opensource-модель, которая определеяет ударение в слове?
А тепловая смерть Вселенной со всеми возможными состояниями и комбинациями частиц – это «Гольденштерн все» из пелевинского Трансгуманизма :)
У Пелевина есть и аналогия попроще: каждый мозг/человек – это большой, сложный и уникальный мозаичный витраж; а сознание – это свет, прошедший сквозь данный витраж. Витраж может существовать без источника света, но сознания тогда не возникает
Микросервисная архитектура также снижает сложность внесения изменений в чужой код — ведь при достаточно мелкой гранулярности в самом микросервисе будет достаточно мало кода бизнес-логики, соответственно в нём будет проще разобраться. Сложность при этом скорее всего перейдёт на уровень внесения изменений в архитектуру. Такие изменения, естественно, также должны идти через pull request'ы и проходить review архитектора. Для этого архитектура также должна быть "as Code"
Опыт команды безусловно важен, я его и упоминаю во внешних факторах, которые необходимо учитывать. При этом вовсе необязательно, чтобы все разработчики были синьорами: при высоком уровне инфраструктуры добавление нового микросервиса сводится только к программированию бизнес-логики, и в случае мелкой гранулярности эти несколько строк кода легко можно поручить и менее опытному коллеге.
На мой взгляд, нельзя сказать что 10 сервисов на человека или 10 человек на сервис — плохо, опять же оптимальность соотношения будет зависеть от многих факторов. Главное избегать жесткой привязки: что конкретный микросервис знает и изменяет только конкретный разработчик, т.е. 20 микросервисов на двоих лучше, чем 10 на каждого. На некоторых проектах у нас примерно такое соотношение и получается (~40 микросервисов на 4 бэкенд разработчика)
естественно, если всё работает — ничего не трогай ) работает в плане стабильного time-to-market и качества при внесении изменений. В данной статье как раз и постарался выделить сигналы и моменты, когда пора не только разделять, но и объединять сервисы.
Про более общую тему рефакторинга архитектуры микросервисов (а не только про объединение/разделение) я говорю в следующем докладе (пока в открытом доступе есть только описание и слайды), надеюсь в будущем так же его опубликовать на хабр
да, только дело в том, что в живых проектах потребности, как правило, постоянно растут и видоизменяются. Тут главное не пересидеть — пока будем ждать промежуточного или окончательного устаканивания потребностей (которого может и не произойти), техдолг будет всё расти и расти, увеличивая сложность и стоимость требуемого рефакторинга
под отказоустойчивостью тут подразумеваю Fault tolerance. К примеру, при отказах более мелких сервисов у нас деградация по функциональности будет ниже, чем если ложаться крупные куски системы
Т.е. эффективные тарифы, по которым считается стоимость доставки, в общем случае могут быть никак не связаны с тарифами доставщика.Соответственно хранятся и живут они в новом модуле