Файл: Модель клиент-сервер (Применение модели «клиент-сервер» в разработке web-приложения).pdf

Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы.

Данный вид архитектуры называют еще архитектурой с "толстым" клиентом. Здесь логика представления данных и бизнес-логика размещаются на клиенте, который (скажем, в случае, когда сервером является система управления базами данных) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL. Но не стоит забывать, что необходимость установки "толстых клиентов", требующих значительного количества специальных библиотек и специальной настройки окружения, на большое число пользовательских компьютеров с различными операционными средами, как правило, вызывает массу проблем.

В качестве альтернативы возникла также двухзвенная архитектура "с тонким клиентом". При этом в идеале программа-клиент реализует лишь графический интерфейс пользователя (GUI) и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеале клиентом является просто интернет-браузер, который имеется в стандартной операционной среде любого пользовательского компьютера и не требует специальной настройки, установки специализированного ПО и т.п. К сожалению, такая схема тоже не свободна от недостатков, хотя бы уже потому, что серверу иногда приходится брать на себя несвойственные для него функции реализации бизнес логики приложения (например, серверу СУБД приходится выполнять расчеты).

1.3. Многоуровневая архитектура клиент-сервер

Multitier architecture - разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.

Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура (трехзвенная архитектура, three-tier), предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

В качестве примера многоуровневой архитектуры взаимодействия клиент-сервер можно привести любую современную систему управления базами данных, где с клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура.

На рисунке наглядно отражены три уровня: первый – клиент, отправляющий запросы и второй – сервер приложения, отвечающий на запросы клиента и отправляющий запросы на чтение/запись, третий – сервер базы данных, отвечающий на запросы сервера приложения

Рис. 1.3. Многоуровневая модель взаимодействия клиент-сервер

Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные запросы к базе данных. На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.

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

Третий уровень – это хранилище данных. Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.

В простейшей конфигурации физически сервер приложений может быть совмещен с сервером базы данных на одном компьютере, к которому по сети подключается один или несколько терминалов.

В "правильной" (с точки зрения безопасности, надежности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминал

Плюсами данной архитектуры являются:

• клиентское ПО не нуждается в администрировании;
• масштабируемость;
• конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
• высокая безопасность;
• высокая надежность;
• низкие требования к скорости канала (сети) между терминалами и сервером приложений;
• низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

Минусами данной архитектуры являются:

• усложнение серверной части и, как следствие, затраты на администрирование и обслуживание;
• более высокая сложность создания приложений;
• сложность администрирования;
• высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
• высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

Начало процессу развития корпоративного программного обеспечения в многозвенной архитектуре было положено еще в рамках технологии "клиент-сервер". В них наряду с клиентской частью приложения и сервером баз данных появились серверы приложений (Application Servers). В идеале:

• программа-клиент реализует GUI, передает запросы серверу приложений и принимает от него ответ,

• сервер приложений реализует бизнес-логику и обращается с запросами к серверу "третьего уровня" (например, серверу базы данных за данными), сервер третьего уровня обслуживает запросы сервера приложений. Программа-клиент, таким образом, может быть "тонкой".

Даная архитектура также может быть рассмотрена с позиции сайта: первый уровень можно считать браузером, с помощью которого посетитель заходит на сайт, второй уровень – это связка Nginx + NodeJS, а третий уровень – это база данных.

1.4. Преимущества и недостатки

Преимуществом модели взаимодействия клиент-сервер является то, что программный код клиентского приложения и серверного разделен. Если мы говорим про локальные компьютерные сети, то к преимуществам архитектуры клиент-сервер можно отнести:

• пониженные требования к машинам клиентов, так как большая часть вычислительных операций будет производиться на сервере
• гибкость, которая позволяет администратору сделать локальную сеть более защищенной;
• возможность внести изменения на каждом из звеньев можно осуществлять независимо;
• снижение нагрузки на сеть на сеть, поскольку звенья не обмениваются между собой большими объемами информации;
• обеспечение масштабирования и простая модернизация оборудования и программного обеспечения, поддерживающего каждое из звеньев, в том числе обновление серверного парка и терминального оборудования, СУБД и т.д.;
• возможность создавать приложения на стандартных языках третьего или четвертого поколения (Java, C/C++).

К недостаткам модели взаимодействия клиент-сервер можно отнести:

• стоимость серверного оборудования значительно выше клиентского;
• обязательная мобильность в как можно более широком классе аппаратно-программных сред.
• наличие специально обученного и подготовленного человека для обслуживания сервера. Если в локальной сети ложится сервер, то и клиенты не смогут работать (в качестве частного случая можно привести пример: мощности сервера не всегда хватает, чтобы удовлетворит запросы клиентов, если вы хоть раз работали с биллинговыми системами, то понимаете о чем речь: время ожидания ответа от сервера может быть очень большим).

1.5. Актуальность

Итак, мы разобрались что из себя представляет модель «клиент-сервер», знаем какие компоненты включает и где полезно применима. Взвесив преимущества и недостатки, можем судить о ценности данной модели и архитектуры для современных информационных систем.

Замечу, что большинство существующих информационных продуктов повседневного пользования, такие как мессенджеры, электронная почта, социальные сети и поисковые системы, работают именно как сложные сети из клиентов и серверов. Считаю, что модель «клиент-сервер» сейчас развита и актуальна как никогда. Возможности подхода я хочу продемонстрировать в следующей главе.

2. Применение модели «клиент-сервер» в разработке web-приложения

2.1. Описание задачи

Для демонстрации преимуществ модели клиент-сервер создадим клиент-серверное приложение «Виджет погоды». Необходимо написать виджет, при размещении кода которого на любой странице любого сайта появлялся бы прогноз погоды для Москвы, Санкт-Петербурга, либо Нижнего Новгорода.

API для получения данных – api.openweathermap.org. Данные виджетов будем хранить в базе Redis, серверный код должен быть написан на node.js

Должен быть реализован web-интерфейс, реализующий следующие возможности:

- создание любого количества экземпляров виджетов со своими настройками;

- изменение настроек ранее созданных виджетов;

- получение кода виджета для вставки его на страницу;

Настройки, доступные из интерфейса:

- Город

- На сколько дней выдавать прогноз (1, 3 или на неделю)

- Горизонтальный или вертикальный блок

Технологии, которые понадобятся для выполнения задания:

Окружение:

- http://nodejs.org – сервер на JavaScript

- http://redis.io – кеш-сервер

Библиотеки и фреймворки:

- http://getbootstrap.com – готовый набор css стилей

- http://expressjs.com – библиотека для создания веб-сервера на JavaScript

- https://github.com/NodeRedis/node-redis – обертка для работы с кеш-сервером Redis

- https://github.com/request/request – http-клиент для сервера NodeJS

- https://github.com/pugjs/pug – html шаблонизатор

Клиентский код, реализующий размещение виджета на сторонней странице, должен быть реализован с минимальным использованием сторонних фреймворков.

2.2. Алгоритм реализации решения

1. Опишем необходимые элементы проекта.
2. Создадим и настроим проект, установим зависимости.
3. Напишем серверную часть кода.
4. Напишем клиентскую часть кода.
5. Проверим работу приложения и сравним с описанием задачи.

2.3. Описание необходимых элементов проекта

Разделим механики необходимого приложения на две части – клиентскую и серверную. Клиент будет представлять из себя веб-страницы в браузере, сервер – expressjs веб-сервер на базе NodeJS, база данных – локальное in-memory хранилище на базе Redis.

Для начала сформируем список необходимых страниц для клиента в браузере:

список виджетов

форма добавления виджета

форма редактирования виджета

виджет

Для них необходимо будет создать шаблоны для отображения в браузере.

Затем перейдем к списку запросов, на которые сможет отвечать сервер:

- GET / – главная страница, отображение списка виджетов

- GET /widget/add – отображение формы добавление виджета

- POST /widget/add – непосредственно сохранение данных нового виджета и редирект на главную страницу

- GET /widget/edit – отображение формы редактирования виджета

- POST /widget/edit – непосредственно сохранение данных виджета и редирект на главную страницу