Паттерны отказоустойчивой архитектуры - Александр Кривощёков
Vložit
- čas přidán 28. 06. 2022
- Перебои и ошибки в работе распределённых систем (будь то Web или IOT) совершенно обычная ситуация. Проблемы в работе с сетью, перебои в работе зависимостей и банальный человеческий фактор - та цена, которую мы платим за общую стабильность системы, лёгкую масштабируемость и гибкость в разработке.
На примере эволюции одного вымышленного (ну, почти вымышленного) сервиса по доставке напитков мы рассмотрим проблемы, с которыми он сталкивался, и решения, которые помогли с ними справиться.
Мы разберём паттерны построения отказоустойчивой системы и примеры их реализации в реальной жизни, которые позволяют нашей системе переживать самые критические моменты. Начав с простейших таймаутов, мы проделаем путь до толстых клиентов и тыкв. - Věda a technologie
Спасибо за доклад, на хайлоаде помню не успел все рассказать, а здесь все целиком, супер
Классный доклад! Спасибо!
0. "Яндекс.Вода" - 2:38
1. Retry - 4:44
2. Deadlines - 17:15
3. Rate limiting - 24:06
4. Circuit breaker - 33:25
5. Rich client - 40:20
6. Dummy (aka Pumpkin) - 46:24
7. Прочие паттерны - 51:38
Для deadline propagation нужна высокая точность синхронизации часов на всех включенных в цепочку обработки серверах. В ваших примерах хотя бы где-то в пределах 10 миллисекунд. Как вы этого добиваетесь? Не мешает ли тут географическая удаленность серверов, увеличивая люфт рассинхронизации?
Спасибо за первые 2 паттерна)
Спасибо, супер!
Спасибо, очень!
Молодец! Благодарю!
Ссылка на презентацию не открывается ((
Ссылки мёртвые?
Спасибо, очень интересно. Я только не понял о каких ручках докладчик упоминал несколько раз. Вроде речь была о программировании, а тут какие то дверные ручки
Это русскоязычный термин для эндпоинтов (endpoint) - это адрес на сервере или сервисе, на который отправляются запросы (requests)
@@Val-Sfinx интересно! А почему именно "ручка"?
@@revel8246 handler - ручка :)
потому что можно за неё дергать :)@@revel8246
@@revel8246 потому что "handler"
прикольно, пошел к чуваку на репу, а он уже оказывается в Реддите =).
Поздравляю.
почти оговорился) "насинячиться")))
Думаю, это была намеренная шутка.
Каеф
Gof and Grasp так я их и не понял как применять на практике и реализовывать))) Иногда кажется что шаблоны и рефакторинг тесно связаны между собой)
Книги судя по всему не случилось.
Спасибо, очень хороший доклад. Докладчик - крут, но сахарок и белый хлебушек любит
доклад отличный p.s. имхо только вот это оперирование счастьем пользователя аж слух режет, мораль это не понятия реального мира в капитализме, в реальности пользователь в следующий раз не купит через еду а закажет через самокат или сбермаркет
мораль простая.
Фокус бизнеса должен быть на "счастье пользователя" (опять же, это не вырублено в камне, но один из вариантов подхода к ведению бизнеса).
Постараюсь объяснить кратко. Можно вести бизнес относительно конкретных задач и целей.
Первый вариант - ставить в приоритет какие-то внутренние процессы, например, создание самого безопасного приложения. Вводить ограничения, всякие DMZ, контроль репы (или его отсутствие вообще), только стабильные и современные, обновляемые операционные системы, полное огораживание системы от любых внешних влияний (подключения дисков и других носителей, доступ в интернет итд). Если непонятно - вот например так (по крайней мере раньше) работал Центробанк (РФ).
Второй вариант - "код ради кода". Когда приоритет - в "идеальности" кода, т.е. даже если страдает функционал, код написан так идеально что работает на любом железе, даже в ущерб UI, безопасности, функционалу (быстрый, но простой). Из примеров - я бы сказал раньше некоторые разработчики игр этим баловались. Их движки были идеальными, но очень плохо масштабировались и поддерживались, и со временем (и апгрейдом систем) они просто перестали адекватно работать на современном железе. Впрочем, это и есть очевидная проблема - смысла делать "идеально" нет.
Третий вариант - "минимализм". Т.е. все траты компании идут сугубо на развитие, например, оффлайн магазинов. А айти оплачивается по остаточному принципу. Тут понятно в каком состоянии будут онлайн составляющая и другие компоненты взаимодействия всей системы в-целом (логистики, магазинов, маркетинга, контроллирующих органов).
...
А есть еще один вариант, когда компания ориентируется на пользователя. Т.е. подход к развитию бизнеса с точки зрения конечного пользователя. Т.е. в приоритет ставится именно комфорт пользователя, а не внутренние процессы. И вместо предыдущих вариантов, реализуется методология вокруг качества пользовательского взаимодействия. И с этой точки зрения если подходить - то эти все паттерны четко обретают смысл, т.к. в любых других роли пользователя в принятии решений нет.
Зачем фокусироваться на пользователе - ответ тоже простой, именно пользователь приносит доход компании. И какая бы компания идеальная ни была, пока пользователь не счастлив - компания будет терять деньги.
Конечно, приоритет зависит от конкретных обстоятельств и ситуации. В демократических обществах, где роль государства сводится к минимуму, у пользователей есть выбор практически во всем. И, конечно, бизнесы (да и некоторые госорганы в условиях конкурентной среды) будут стремиться сделать свой товар лучше чем у конкурентов чтобы получить прибыль. И эта конкуренция делает товары выше качеством (ниже по цене) без вреда конечному потребителю. Если у компании нет цели получить прибыль - тут уже вопрос к компании =).