Паттерны отказоустойчивой архитектуры - Александр Кривощёков

Перебои и ошибки в работе распределённых систем (будь то Web или IOT) совершенно обычная ситуация. Проблемы в работе с сетью, перебои в работе зависимостей и банальный человеческий фактор - та цена, которую мы платим за общую стабильность системы, лёгкую масштабируемость и гибкость в разработке.
На примере эволюции одного вымышленного (ну, почти вымышленного) сервиса по доставке напитков мы рассмотрим проблемы, с которыми он сталкивался, и решения, которые помогли с ними справиться.
Мы разберём паттерны построения отказоустойчивой системы и примеры их реализации в реальной жизни, которые позволяют нашей системе переживать самые критические моменты. Начав с простейших таймаутов, мы проделаем путь до толстых клиентов и тыкв.

[@Iska369]

Спасибо за доклад, на хайлоаде помню не успел все рассказать, а здесь все целиком, супер

[@viktorsemak3303]

Классный доклад! Спасибо!

[@MartinXProject]

Спасибо, супер!

[@szinner]

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

[@Dimoniada]

Спасибо за первые 2 паттерна)

[@Kitchen_Politics]

Спасибо, очень!

[@maximsaloduha1487]

Молодец! Благодарю!

[@sergeysergeev92]

Для deadline propagation нужна высокая точность синхронизации часов на всех включенных в цепочку обработки серверах. В ваших примерах хотя бы где-то в пределах 10 миллисекунд. Как вы этого добиваетесь? Не мешает ли тут географическая удаленность серверов, увеличивая люфт рассинхронизации?

[@sergeysergeev92]

Ссылка на презентацию не открывается ((

[@sergeymatpoc]

прикольно, пошел к чуваку на репу, а он уже оказывается в Реддите =). Поздравляю.

[@kaktusv6]

Каеф

[@hdnn1]

Ссылки мёртвые?

[@alexanderstepanov6034]

почти оговорился) "насинячиться")))

[@-dubok-]

Думаю, это была намеренная шутка.

[@revel8246]

Спасибо, очень интересно. Я только не понял о каких ручках докладчик упоминал несколько раз. Вроде речь была о программировании, а тут какие то дверные ручки

[@Val-Sfinx]

Это русскоязычный термин для эндпоинтов (endpoint) - это адрес на сервере или сервисе, на который отправляются запросы (requests)

[@revel8246]

@@Val-Sfinx интересно! А почему именно "ручка"?

[@Alexandrhub]

@@revel8246 handler - ручка :)

[@user-ju6lw2sw8f]

потому что можно за неё дергать :)@@revel8246

[@grebelnik]

@@revel8246 потому что "handler"

[@vanyadavidenko]

Книги судя по всему не случилось.

[@diatm1506]

Gof and Grasp так я их и не понял как применять на практике и реализовывать))) Иногда кажется что шаблоны и рефакторинг тесно связаны между собой)

[@user-oc7ft4yz4f]

Спасибо, очень хороший доклад. Докладчик - крут, но сахарок и белый хлебушек любит

[@user-im4jl5wd7l]

доклад отличный p.s. имхо только вот это оперирование счастьем пользователя аж слух режет, мораль это не понятия реального мира в капитализме, в реальности пользователь в следующий раз не купит через еду а закажет через самокат или сбермаркет

[@sergeymatpoc]

мораль простая. Фокус бизнеса должен быть на "счастье пользователя" (опять же, это не вырублено в камне, но один из вариантов подхода к ведению бизнеса). Постараюсь объяснить кратко. Можно вести бизнес относительно конкретных задач и целей. Первый вариант - ставить в приоритет какие-то внутренние процессы, например, создание самого безопасного приложения. Вводить ограничения, всякие DMZ, контроль репы (или его отсутствие вообще), только стабильные и современные, обновляемые операционные системы, полное огораживание системы от любых внешних влияний (подключения дисков и других носителей, доступ в интернет итд). Если непонятно - вот например так (по крайней мере раньше) работал Центробанк (РФ). Второй вариант - "код ради кода". Когда приоритет - в "идеальности" кода, т.е. даже если страдает функционал, код написан так идеально что работает на любом железе, даже в ущерб UI, безопасности, функционалу (быстрый, но простой). Из примеров - я бы сказал раньше некоторые разработчики игр этим баловались. Их движки были идеальными, но очень плохо масштабировались и поддерживались, и со временем (и апгрейдом систем) они просто перестали адекватно работать на современном железе. Впрочем, это и есть очевидная проблема - смысла делать "идеально" нет. Третий вариант - "минимализм". Т.е. все траты компании идут сугубо на развитие, например, оффлайн магазинов. А айти оплачивается по остаточному принципу. Тут понятно в каком состоянии будут онлайн составляющая и другие компоненты взаимодействия всей системы в-целом (логистики, магазинов, маркетинга, контроллирующих органов). ... А есть еще один вариант, когда компания ориентируется на пользователя. Т.е. подход к развитию бизнеса с точки зрения конечного пользователя. Т.е. в приоритет ставится именно комфорт пользователя, а не внутренние процессы. И вместо предыдущих вариантов, реализуется методология вокруг качества пользовательского взаимодействия. И с этой точки зрения если подходить - то эти все паттерны четко обретают смысл, т.к. в любых других роли пользователя в принятии решений нет. Зачем фокусироваться на пользователе - ответ тоже простой, именно пользователь приносит доход компании. И какая бы компания идеальная ни была, пока пользователь не счастлив - компания будет терять деньги. Конечно, приоритет зависит от конкретных обстоятельств и ситуации. В демократических обществах, где роль государства сводится к минимуму, у пользователей есть выбор практически во всем. И, конечно, бизнесы (да и некоторые госорганы в условиях конкурентной среды) будут стремиться сделать свой товар лучше чем у конкурентов чтобы получить прибыль. И эта конкуренция делает товары выше качеством (ниже по цене) без вреда конечному потребителю. Если у компании нет цели получить прибыль - тут уже вопрос к компании =).