- Семь составляющих веб-приложений
автор: John Engates - На повестке (регламент встречи):
- Что мы ждём от веб-приложений
- Типичный сценарий работ
- Неплохие примеры
- Вопросы и ответы
- Чего мы ждём от сайтов
- Масштабируемость
- Высокая степень эксплуатационной готовности (полезности), высокая отдача
- Производительность (эффективность работы?)
- Простота управления
- Низкая стоимость (обслуживания, в том числе)
Изобилие рюшечекМножество приятных неожиданностей- И что он будет нам делать бабло, много бабла!
Это и есть семизначная мантра клиента-директора, думающего о заказе корпоративного сайта - Высокая готовность. Определение:
Высокая готовность (High Availability HA) - это такой подход к проектированию и реализации, который бы гарантировал известную степень уверенности в их (проектирования и разработки) непрерывности. Так-то!
Как это выглядит на примерах:- ваш сайт всегда работает и доступен
- юзеры счастливы
- вы не теряете денег из-за технических простоев
- (и это не увеличивает затраты на обслуживание сверх необходимого)
Это была мантра техдира проекта - Что на самом деле называется масштабируемостью
Масштабируемость (расширяемость) - это ожидаемое свойство системы, которое показывает её возможность к росту доходов в приятной форме, или легко увеличиваться по необходимости
(Дядька загнул круто. Масштабируемость - это способность системы к расширению и росту. Ну и увеличению доходности, да)
Чем не выражается масштабируемость:- чисто наращиванием мощностей (2МГц -> 3МГц)
- чем-то вроде операционных систем (Solaris vs Linux)
- особенностью софтовых технологий (Java - Python - Rails)
- особенностями платформ (Intel - AMD)
- оптимизацией кода (10 строк против 1000, утверждает этот дядька, ничего не решает)
- выбором технологии хранения (SAN vs NAS)
- большими красными буквамиРАСШИРЯЕМОСТЬ И ПРОИЗВОДИТЕЛЬНОСТЬ - НЕ ОДНО И ТОЖЕ
- картинки с примерами
красивые машинки, автомобильные развязки и писсуары - Истина первая:
Ничто не может множится, если таковым не спроектировано. - Истина вторая:
Если что-либо было спроектировано частями, может их наращивать без проблем. - Очень интересная "шкала боли" (игра слов с предыдущими пунктами)
- Типовые сценарии развития
Этап 1. Начало- Простая архитектура
- файрвол и балансировщик
- пара веб-серверов
- сервер БД
- внутреннее хранилище - Невеликая сложность и проблемность, быстрая разработка, богато фич разного рода и всё быстро
- Никакой избыточности (втч и в рабочей силе), низкая стоимость работ - прекрасный стартап!
- Простая архитектура
- Этап второй, всё тоже самое, но чуть-чуть по-больше
- Успешное ведение бизнеса - залог хороших отношений с законом
- Добавим немного файрволов и балансировщиков
- Добавим чуть больше веб-серверов для производительности
- Устаканим схему БД и соптимизируем её с помощью DBA (консультанта)
- Добавим баз
- Переведём хранилище на SAN или DAS
- Всё ещё просто, подходит для перспективных приложений
- Этап третий - Первые симптомы
- Публичность
- Устанавливается Squid или Vanish в режиме обратных прокси, или очень хороший балансировщик - для кеширования статичного контента
- Добавляем ещё сколько-то веб-серверов (управление контентом уже доставляет немалый головняк)
- Единственная БД не будет разделена когда-либо (раздельные операции чтения-записи - вся запись ведётся на единственный мастер сервер с несколькими вторичными серверами для чтения)
- Может возникнуть необходимость чё-нить переписать в приложении
- Картинка "Расширяемость применительно к серверам баз данных"
- Этап четвёртый - Боли усиливаются
- Кеширование на memcache
- Репликация не работает для всего (единственная база для записи - много баз для записи - результат: репликация работает долго)
- Приходит осознание необходимости разделения баз (конечно же, если ваша БД поддерживает этот механизм)
- Приходит осознание распределённых хранилищ для контента
- Необходимо серьёзное преобразование архитектуры приложения и базы (а разрабы могут не обладать подобным скилом)
- Этап пятый - Реально головняк!
- Приходит м-р Паника и остаётся жить.
Разве мы не могли сделать всё это раньше? (Список этого:
- Полное переосмысление приложения\бизнес-модели
- И почему мы не запланировали расширяемость системы на момент принятия решений по архитектуре? ) - Невозможность делимости как фичи приложения - что ещё мы можем использовать? (Варианты
- Разделение основанное на географическом принципе, по фамилии, по userID, etc
- Создание кластеров пользователей (пользовательская кластеризация) - Поведение приложения должно быть идентично на каждом пользовательском кластере
- Использование стурктуры хешей или мастер-сервера БД для определения какого пользователя на какой кластер подключить
- Приходит м-р Паника и остаётся жить.
- Этап шестой - Приход, мал-мала полегчало
- Расширяемая архитектура приложения и базы
- Удовлетворительное быстродействие
- Снова можно добавлять новую функциональность
- Оптимизация чего-нибудь в коде
- Продолжаем расти, но теперь вполне управляемо
- Этап седьмой - Исход в неизвестность
- Где нас ещё поджидают узкие места?
- Обеспечение питанием, площадь размещения
- Каналы и прочее - насколько велик ваш хостер?
- Проблемы систем защиты и балансировщиков нагрузки
- Хранилища данных
- Люди и проблемы
- Технологические ограничения расширяемости баз данных - всё ещё хотите хранить данные по схеме ключ-значение? - Что там насчёт "все яйца в одну корзину"?
- один датацентер
- одна копия данных
- проблемы репликации данных и балансировки по географичекому принципу
- Где нас ещё поджидают узкие места?
- Добрые советы
- Не изобретайте колесо, скопируйте у кого-нибудь другого
- Думайте просто
- Все вещи, сделанные проще некуда - не так уж просты. - А. Эйнштейн - Думайте горизонтально... не вертикально... в любых случаях (может, это идиома такая?)
Насколько затратно? - вместо - Насколько быстро? - Используйте подходящее обеспечение и оборудование
- Решайте проблемы легко и просто
- Приводите планы в действие
- Разделяйте различные сервисы
- Не проводите много изменений за один раз (это называется итеративность)
- Ещё немного добрых советов
- Не тратьте времени на оптимизацию оптимизации ("Преждевременная оптимизация преждевременна" (c)#phpclub@undernet.org)
- Возьмите вашу [правильно спроектированную] архитектуру, часто подстраивайте решения [под неё], и редко оптимизируйте (или никогда) - Проверяйте возможности к расширению подходящими нагрузочными тестами
- Сделайте это привычной практикой до того, как вы начнёте думать об их необходимости - Используйте кеширование до того, как почуствуется необходимость
- Много памяти и 64-битная платформа помогут вам (Use the Force, Luck! :)
- Проверяйте новые возможности до того, как выбор между производительностью и масштабируемостью станет проблемой
- Nice to have vs. have to have. И будет вам щасте:)
- Не тратьте времени на оптимизацию оптимизации ("Преждевременная оптимизация преждевременна" (c)#phpclub@undernet.org)
- Управляйте изменениями помня об доступности сайта
- Нельзя недооценивать необходимость правильной постановки технологического процесса и документации
- Избавьтесь от управленцев
- Разработка - тестирование - выпуск
- Работайте уместно сохраняя конъюнктуру - Используйте системы контроля версий
- Понятно, да: RCS, CVS, Subversion - Отслеживайте выпуски (короче, issue tracking - добрый совет использовать трекинговую систему. имхо помощь в разработке оказывают специализированные системы багтрекинга, а не хлам типа trac - у него другие задачи. Если и использовать систему контроля, то это должен быть комбайн, в котором прозрачно отслеживаются таймлайны, что-то типа eGroupWare. Кстати, этот совет противоречит отказу от менеджмента)
- Используйте стандарты кодирования
- Измените схему работ
- Планирование - тестирование - выполнение
- Оптимизированная на высокую доступность инфраструктура
1080слов, 7530знаков
Сообщения
