logo
Проектирование инт-прил / лекции / Проектирование инет приложений

Особенности проектирования

Интернет-приложения, как правило, доступны всем участникам сети Интернет. Даже если Вашей целью является разработка какой-то узкоспециализированной информационной системы. Предположим, Вы разрабатываете информационную систему какого-то предприятия. Естественно, что одной из поставленной перед Вами задач будет задача разделения прав пользователей, кто и что сможет видеть внутри этой системы. Независимо от того, что Вы предпримете на клиентской части, серверная часть, "точка входа" в разрабатываемую Вами систему будет расположена в Интернете. Соответственно, доступна всей многомиллиардной аудитории. И далеко не факт, что вся эта аудитория лояльно настроена по отношению - нет, не лично к Вам, но к некой новой светящейся во Всемирной Сети и вызывающей интерес сущности. А что там, собственно, за ней находится? В отличие от классических пользовательских программ большую часть интернет-приложений не нужно устанавливать, никто не спросит Вашего разрешения на попытку "поработать" с Вашей системой. И наивно было бы предполагать, что все желающие будут использовать исключительно разработанный Вами пользовательский интерфейс.

Соответственно, при проектировании интернет-приложений волей-неволей приходится уделять повышенное внимание вопросам безопасности работы. При разработке системы безопасности основным принципом является разумная достаточность предпринимаемых мер. Нет никакого смысла проводить сканирование сетчатки глаза, снимать отпечатки пальцев, голосовой анализ, вытаскивать из процессора его серийный номер и из сетевой карты ее mac-адрес - и все это делать только для того, чтобы отобразить пользователю на экране сегодняшние новости.

Другой не менее важной особенностью является непрогнозируемая нагрузка. Сегодня Ваше приложение имеет 10 одновременно работающих клиентов в максимуме, а завтра их станет 1 миллион. Соответственно, при разработке приложения Вы ориентируетесь на 10 клиентов, это Ваша расчетная нагрузка. И нет никакого смысла сразу же делать приложение из расчета на миллион, потому что нагрузочная способность - это в, конечном счете, деньги и время. То и будет успешно потрачено, а вот миллион клиентов у Вашего - безусловно, замечательного! - приложения может и не появиться в силу целого ряда причин. Однако Вы должны предусмотреть возможность масштабирования системы таким образом, чтобы удержать лавинообразно нарастающую нагрузку.

Третья рассматриваемая нами особенность - это круглосуточная работоспособность приложения. Если мы говорим о локальной сети предприятия, то существует нерабочее время для сотрудников этого предприятия, существуют выходные, праздники. Иными словами, у администраторов всегда есть возможность что-то менять - в общем, не нарушая работоспособности системы. Переставить программное обеспечение, провести сервисные процедуры с базой данных и даже целиком поменять сервер на более мощный. При должной подготовке даже серьезные изменения в системе не скажутся на пользователях, поскольку к началу следующего рабочего дня их будет ждать полностью способная выполнять свои функции система. Совсем другая картина получается с интернет-приложениями, пользователи которых находятся в разных часовых поясах и имеют полное право затребовать функции разработанного Вами сервиса в любое время любого дня. А между тем задачи администрирования и сервисного обслуживания - никуда не исчезли, их по-прежнему необходимо выполнять. И единственная возможность позаботиться о волках и овцах одновременно - это правильная архитектура разрабатываемого Вами приложения, допускающая временную неработоспособность одной или нескольких компонент без нарушения функционала системы в целом. Это - возможно. Давайте попробуем посмотреть, куда мы попадем, если наберем в браузере строку http://www.mail.ru:

sally ~ # host www.mail.ru

www.mail.ru has address 217.69.141.21

www.mail.ru has address 217.69.141.22

Как видно, только этот запрос - http://www.mail.ru - готовы обработать два сервера. Два, а не один. А это значит, что выход из строя (аварийный или намеренный, с целью проведения сервисных процедур) одного из этих серверов не приведет к неработоспособности службы в целом, запрос пользователя все равно будет обработан.