В систему закладывается 3 столпа: надежность, масштабируемость, удобство эксплуатации.
Надежность системы обуславливается правильностью работы, как этого ожидает пользователь, устойчивостью к сбоям и неправильному использованию программы, предотвращение несанкционированного доступа к системе, высокой производительностью при предполагаемой нагрузке и объеме данных.
Сбой (fault) и отказ (failure) — разные вещи. Сбой — прекращение или ошибка в работе одного из компонентов. Отказ — прекращение работы приложения в целом (прекращение предоставления сервиса пользователю).
Лучше спроектировать механизмы устойчивости к сбоям, которые бы предотвращали переход сбоев в отказы.
Сбои происходят чаще всего по трем факторам: аппаратные сбои, программные ошибки, человеческий фактор. Последняя причина занимает наибольший процент всех сбоев.
Масштабируемость (scalability) — способность системы справляться с возросшей на нее нагрузкой.
Для описания нагрузки на приложение, можно выбрать основные функции. Напр. в twitter — чтение домашней ленты и написание твита. Далее можно заняться описанием производительности. Главный показатель для онлайн-систем — это время отклика (это не равнозначно времени ожидания (!)).
Время отклика (response time) — фактическое время обработки запроса (время обслуживания, service time) + задержки сети + задержки очереди.
Время ожидания (latency) — время на протяжении которого запрос ожидает обслуживания.
Для метрики времени отклика лучше использовать процентили, а не среднее арифметическое. Их как раз можно встретить в таких документах, как SLO (service level objectives) и SLA (service level agreements). Важно измерять время отклика на стороне клиента, так как его время всегда равно времени самой медленно выполняющейся части запроса.
Бывает горизонтальное масштабирование (hs, распределение нагрузки по нескольким машинам) и вертикальное масштабирование (vs, улучшение железа). Их можно проводить как в ручном режиме (проще и предсказуемо) так и использовать адаптирующиеся системы меняющие конфигурации в зависимости от нагрузки. Хорошая практика — это баланс между этими двумя подходами (hs и vs). Так или иначе, все масштабируемые архитектуры строятся из универсальных блоков, на основе проверенных паттернах.
На начальных стадиях важнее скорость работы текущего состояния системы, чем её оптимизация под возможные нагрузки в будущем.
Удобство эксплуатации системы строится на основе трех принципов:
- Удобство эксплуатации. Облегчает поддержку системы.
- Простота. Облегчает ее понимание новыми инженерами.
- Возможность развития. Облегчает введение нового функционала.
Избежать усложнение кода по мере разработки приложения — использовать абстракции.
Чем проще система, тем легче ее менять. Важно на начальном этапе задать системе возможность развития (evolvability).
Top comments (0)