Следующий вопрос, который мы должны рассмотреть, это масштабируемость. Попросту говоря, о масштабируемости системы можно судить по ответу на следующий вопрос: «могу ли я нарастить данную систему на порядок или более и будет ли она после этого работать?». Для того, чтобы ответить на этот вопрос, вы должны проанализировать несколько определяющих факторов:
сколько процессорного времени, памяти и других ресурсов вы используете?
насколько интенсивно компоненты системы обмениваются сообщениями?
можете ли вы распределить вашу систему между несколькими сетевыми узлами?
Первый вопрос вполне очевиден и не требует дополнительных объяснений.
Если вы используете половину процессорного времени и половину памяти, то скорее всего вы не сможете увеличить размер системы более чем в два раза (допуская что использование ресурсов возрастает линейно с размером системы).
Второй вопрос также из разряда использования ресурсов – если вы применяете интенсивный обмен сообщениями, со временем вы просто «забьете» полосу пропускания вашего канала передачи данных. Так что если даже процессор загружен всего на 10%, но при этом полоса пропускания используется на 90%, вы достигните предела возможностей вашего канала передачи данных в первую очередь. Все это подводит нас к третьему, основному, вопросу о масштабируемости. Если вы используете довольно большое количество ресурсов на одной рабочей станции, то традиционным решением масштабируемости будет разделение нагрузки по нескольким сетевым узлам. Давайте «промасштабируем» наш пример с системой безопасности на университетский городок. Нет сомнений что применение одного компьютера для обслуживания сотен (или тысяч) запорных механизмов дверей, считывателей карт и других устройств, не будет являться правильным решением. Такая система скорее всего моментально развалится под напором поступающих данных при проведении учебной пожарной тревоги, когда по всей территории городка одновременно все начнут пользоваться своими карточками чтобы вернуться на место после отбоя тревоги.
Вместо этого мы лучше создадим отдельные контролируемые «зоны».
Как правило, в таких случаях принято располагать зоны в пределах существующих границ. Например, если на территории городка, который вы собираетесь контролировать, находится 15 зданий. В этом случае я бы сразу порекомендовал использовать 15 управляющих компьютеров – по одному на каждое здание.
Используя такое деление, вы разбиваете большую часть вашей проблемы на меньшие составляющие. Теперь вам не придется иметь дело с одной огромной монолитной системой безопасности, вместо этого вы можете работать с 15 индивидуальными (и гораздо меньшими) системами.
Во время разработки деталей вашего проекта вы должны рассчитать максимальную возможную нагрузку на один узел системы – какое количество замков и считывателей карт узел сможет обслужить во время пиковой нагрузки (как в нашем примере с пожарной тревогой). После этого вы можете подобрать соответствующий компьютер, который сможет справиться с ожидаемой нагрузкой.
Вы могли бы использовать один компьютер в качестве выделенного сервера базы данных системы безопасности. Тогда каждый из 15 управляющих компьютеров будет посылать запрос выделенному серверу для проверки прав доступа. Возможно что в этом случае выделенный сервер сможет обслуживать до 200 управляющих компьютеров. Если это действительно так, значит вы свою задачу выполнили: система действительно масштабируема. В противном случае дизайн системы необходимо пересмотреть и попытаться разбить ее на подсистемы другим способом. В нашем примере системы безопасности база данных, которая хранит информацию о правах доступа довольно статична – мы не будем изменять ее каждую миллисекунду. Обычно мы будем обновлять базу данных при изменении в штате компании – новый служащий может быть принят на работу, контракт с кем-то может быть разорван или кому-то потребуется изменить права доступа. Это означает что мы можем прибегнуть к распределению базы данных с главного сервера на «зеркальные» сервера с помощью рассылки сообщений в базе. Именно эти зеркальные сервера будут обрабатывать повседневные операции по обработке запросов прав доступа.