KharkivJS 2015: Надежные системы из ненадежных компонент

Техники и подходы к написанию надежных систем из ненадежных компонентов на JavaScript (и в целом)

Transcript

1. @maxmaxmaxmax МАКСИМ КЛИМИШИН CTO GVMachines Inc. Надежные системы из ненадежных компонентов
2. Кода не будет
3. Нет
4. Сегодня поговорим о Тема ‣ Системной дизайне ‣ Архитектуре приложений ‣ Разработке ‣ Компонентах, ненадежных и надежных
6. Компонент Определения Нечто, что умеет делать что-то умное
7. Системный дизайн Определения Системный дизайн – это определения архитектуры, компонент, модулей, интерфейсов, данных и хранилищ, которые удовлетворяют определенные требования
8. Производительность Определения Производительность системы – это количество полезной работы, достигнутой компьютерной системой или множеством систем в сравнении с потраченным временем и использованными ресурсами
9. Архитектура Определения Архитектура ПО – это фундаментальные структурные решения, которые будет несоизмеримо дорого изменить после реализации
10. Архитектура ‣ Без параметров нет корреляции архитектуры с производительностью ‣ Производительность системы не коррелирует с поддерживаемостью системы
11. Maintainability Определения Поддерживаемость системы – это когда стоимость первоначальной реализации существенно больше в сравнении со стоимостью изменений
12. Ненадежные компоненты Определения Компоненты, которые не способны справиться с произвольным вводом, намеренными попытками навредить, нагрузкой и т.п.
13. Разработка
14. Легко vs Просто Разработка ‣ Просто – одна роль, концепция, измерение. Линейная сложность ‣ Легко – удобно, нетрудно. Легко в сравнении с чем-то
15. Легко Разработка ‣ Быстро стартуем ‣ Первый прототип ‣ Быстро ‣ Проходит время, новые требования ‣ Долго переписываем прототип в что-то работающее с новыми требованиями
16. Просто Разработка ‣ Разбираемся ‣ Стартуем с задержкой ‣ Прототип ‣ Новые требования ‣ Меняем
17. Что такое код? Разработка ‣ Код – это проекция ментальной модели автора о требованиях, записанной в виде соотв. конструкций ‣ Поддерживаемость – это средняя скорость проекции конструкций языка в ментальную модель требований + дополнение кода новыми требованиями
18. Проблемы Разработка ‣ Проекция ментальной модели ограничена способностями конкретного инженера одновременно удержать количество сущностей и связей между ними ‣ Легко упустить детали требований, если логика размазана (scattering) ‣ Легко упустить детали, если много сущностей связаны между собой (coupling)
19. REQUIREMENTS CODE REQUIREMENTS writing code by engineer #1 understanding by engineer #2
21. Надежность
22. Robustness Надежность Это способность компьютерной системы справляться с ошибками во время выполнения
23. Принципы Надежность ‣ Паранойя ‣ Тупость ‣ Опасные реализации ‣ Не может произойти
24. Проблема Надежность Поскольку количество вариантов произвольных данных на входе и выходе требуют слишком много времени для тестирования, невозможно их исчерпывающе протестировать.
25. VALIDATION COMPONENT PARANOIA STUPIDITY DANGEROUS IMPLEMENTS CAN'T HAPPEN INPUT OUTPUT
26. Справляемся с ошибками Надежность Но если компонент ненадежный… нужно изолировать отлов ошибок, уметь их понимать и реагировать соответственно.
27. VALIDATION COMPONENT PARANOIA STUPIDITY DANGEROUS IMPLEMENTS CAN'T HAPPEN INPUT ERRORS DISPATCHER OUTPUT
28. Подходы к решению
29. В теории Подходы к решению Браузер – закрытая система до тех пор, пока мы не подключим: ‣ ajax requests ‣ web sockets ‣ web-workers
30. Подходы к решению
31. Архитектурно Подходы к решению ‣ Унифицировать data flow ‣ Контролировать пропускную способность ‣ Валидировать input с помощью соотв. средств (Robustness principles) ‣ Описать состояние приложения в явном виде
32. Подходы к решению ‣ Унифицировать обработку ошибок до поэлементной и реализовать протокол реакции системы на ошибки ‣ Коды ошибок (выполнил/не выполнил) ‣ Реализовать техники повторной обработки: ‣ Retry ‣ Backoff (напр. exponential backoff) ‣ Redundancy
33. Выводы
34. Для разработки надежной системы нужно Выводы ‣ Писать поддерживаемый код ‣ Унифицированная обработка ошибок ‣ Протокол реакции на ошибки ‣ Контроль скорости входящего потока ‣ Валидация данных на входе
35. Redundancy Избыточность ‣ Написать две реализации одной спецификации ‣ И сравнивать результаты работы
36. Производительность Выводы ‣ Производительность можно оценить ‣ Для оценки нужны параметры – какая цель, что мы хотим обрабатывать и с какой скоростью ‣ Пример: ‣ Какой будет λ на входе в конкретном канале? ‣ Какой μ обработки потока? ‣ Что будет, если увеличить λ в 10 раз?
37. COMPONENT VER#2 RATE CHECK VALIDATION OUTPUT DATA SOURCE PAYLOAD ERRORS DISPATCHER COMPONENT VER#1 REDUNDANCY Архитектура надежного компонента
38. GLOBAL ERRORS DISPATCHER
40. Спасибо. Thanks! @maxmaxmaxmax