5. Масштабирование.
Чрезвычайно важным свойством программ
"автоматизации учета и
управления..." является возможность
масштабирования. Но при всей своей
важности, масштабирование - это то, на что
обращают наименьшее
внимание при выборе системы. И поставщики
программ стыдливо умалчивают
о проблемах с масштабированием в своей
продукции.
Прежде всего, - что такое масштабирование? Не буду
претендовать на
строгость в пояснении, попробую
проиллюстрировать на примерах.
1. Вот прошли недавно Олимпийские игры. Была и
информационная
поддержка Олимпиады. Назывались впечатляющие
цифры: компьютерные
системы выполняли десятки и сотни тысяч запросов
в секунду (!);
2. Поисковые интернет-серверы. Yandex, Aport, Google, Yahoo...
Эти
полезные уважаемые системы выполняют
одновременно огромное
количество запросов. И выполняют достаточно
надежно. Во всяком
случае, как правило, обращение к ним дает
успешный результат;
3. Огромные интернациональные корпорации,
владеющие информационными
системами, в составе которых многие тысячи (!)
подключенных
терминалов. И все это работает, и все это приносит
пользу, а не
головную боль и убытки...
Это один полюс. А вот другой:
1. Убогая система в составе 3, 5, 10 (уже много!), 20
(сенсация!), 50
(легенды!) компьютеров;
2. Черепашья скорость;
3. Надежность карточного домика;
4. Искусственные приемы поддержания
работоспособности, вроде "тот
отчет не запускать днем", а этот - только в
"монопольном" режиме...
Знакомая картина?
Причина разительного отличия эффективности - в
более мощной технике?
Нет! Это в последнюю очередь. Главное - правильная
архитектура
программного комплекса, предусматривающая
масштабируемость.
Масштабируемость и только масштабируемость
может обеспечить
функционирование сколько-нибудь большой
системы.
Отвлечемся на некоторое время от музыкального
магазина и представим
себя на месте руководителя телефонной
справочной службы "09". Вот вы -
руководитель такой службы. В вашем подчинении
десяток операторов на
своих рабочих местах. А рабочее место - это стол с
установленным на
нем компьютером. Компьютеры получают информацию
от общей базы данных.
Клиенты звонят, операторы нажимают на клавиши,
получают результаты
запроса на экране и отвечают клиентам. Все
работает приемлемо быстро и
надежно. Но население усиленно
"телефонизируется", и нагрузка на
справочную службу растет... Вам приходится
увеличивать количество
одновременно работающих операторов
("масштабироваться"). И вдруг
выясняется, что начинает сдавать компьютерная
система. Вот работала с
десятью компьютерами нормально, а пятнадцатью -
уже очень медленно.
Как быть? Можно попытаться применять более
мощные компьютеры или более
быструю сеть, но это только временное
косметическое решение. Гораздо
более правильно - просто применить две (три,
четыре...) одинаковые
компьютерные системы. Для каждой - своя база
данных, своя сеть, свой
сервер... Десять операторов - одна система,
двадцать - две, тридцать -
три, пять тысяч - пятьсот систем... Это и есть
масштабируемость. Ничто
не мешает получить сколь угодно большое
количество рабочих мест
операторов. И скорость падать не будет
пропорционально их числу.
Именно так устроено подавляющее число мощнейших
справочных систем.
Есть, конечно, тонкости и особенности, но
сущность остается - система
просто "умножается" в нужное число раз...
Точно так проходило бы
"масштабирование" и при отсутствии
компьютерной системы: каждому
оператору выдавался бы полный комплект
телефонных справочников.
Введем понятие "коэффициента
масштабируемости". В нашем решении такой
коэффициент будет равен 1 (не забывайте, я сделал
оговорку, что не
притязаю на полную строгость изложения!).
Значение коэффициента,
равное 1, указывает на то, что производительность
одного рабочего
места никак не падает с произвольным увеличением
общего количества
рабочих мест. Главной особенностью описанного
решения реализации
масштабируемости является полное отсутствие
"принципиально
разделяемых" ресурсов. Если бы, например,
увеличивалось число
установленных справочных программ и экземпляров
баз данных, но
оставалась бы единой компьютерная сеть, то
производительность
конкретного рабочего места падала бы
из-за появления разделяемого ресурса. И
коэффициент масштабируемости
системы неизбежно бы снизился.
Но служба "09" - это практически идеальный
случай. Далеко не всегда
можно обойтись без разделяемого ресурса.
Например, складская программа
изначально требует единой базы данных для всех
клиентов независимо от
количества таковых. Причем эта база данных может
модифицироваться
практически любым клиентом.
Разработчики систем решают проблемы
масштабирования по-разному. Это
может быть "дробление" базы данных (база
данных организовывается для
конкретной группы товара, региона и т.п.) Это
может быть
"функциональное" деление системы
(подсистема для бухгалтера,
менеджера, кладовщика...). Такие решения усложняют
систему и требуют
изощренных средств для получения комплексной (из
разных баз данных)
информации.
Но мы рассмотрели только один аспект
масштабируемости - падение
производительности с увеличением количества
пользователей. Есть и
другие стороны проблемы. Например, падение
производительности с
увеличением количества записей в базе данных и
динамики их
изменений...
Но в любом случае борьба за приемлемую
масштабируемость - это забота о
минимальной загрузке самых "узких" частей
системы. И это очень важно!
Самое "узкое" место системы при грамотной
разработке должно
использоваться МИНИМАЛЬНО!
Теперь вернемся к файл-серверной архитектуре
программы. Это, наоборот,
тот пример, когда самые критичные компоненты
нагружаются максимально.
Сетевые ресурсы предельно перегружаются, память
на жестких дисках
компьютера с базой данных просто разрывают на
куски клиентские
приложения и т.д.
Файл-серверная архитектура принципиально не
масштабируема. Можно
говорить об открытости программы, о тех или иных
ее преимуществах, но
говорить о масштабируемости нельзя.
Файл-серверная архитектура - тупик
для сколько-нибудь крупных применений, требующих
надежности. Именно
поэтому найти файл-серверную программу,
например, в банке очень
проблематично.
В случае с двухзвенной клиент-серверной
архитектурой дела обстоят не
лучше. Как ни крути, но в бизнес-приложениях
существует принципиально
разделяемый ресурс. Это база данных, которая, как
правило, должна быть
единой. А значит самым "узким" местом
системы является сервер базы
данных (SQL-сервер). А, как я уже говорил, для
достижения приемлемой
производительности программы, основанной на
двухзвенной архитектуре,
нужно предельно нагружать сервер базы данных:
как можно меньше работы
поручать клиентскому приложению и как можно
больше - SQL-серверу. Это
сильно разгружает сеть, но ставит крест на
масштабируемости. Попытка
максимально разгрузить клиентское приложение и
одновременно не
нагружать сервер базы данных приводит к
появлению среднего (третьего)
звена - сервера приложений и трехзвенной
архитектуры. Именно забота о
масштабируемости породила трехзвенную
клиент-серверную архитектуру
программ.
Продолжение следует...
Комментарии
13