Лекция 12. Основные концепции проектирования корпоративных приложений (продолжение)

12.1. Концепция архитектурных слоёв

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

Концепция слоёв (layers) – это одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части.

Расчленение системы на слои предоставляет целый ряд преимуществ:

• Отдельный слой можно воспринимать как единое самодостаточное целое, не особенно заботясь о наличии других слоёв. (Пример – для создания службы FTP необходимо знать протокол TCP, но не тонкости Ethernet);
• Можно выбрать альтернативную реализацию базовых слоёв (приложения FTP способны работать без каких-либо изменений в среде Ethernet, по соединению PPP или в любой другой среде передачи информации);
• Зависимость между слоями можно свести к минимуму. (Так, при смене среды передачи информации (при условии сохранения функциональности слоя IP) служба FTP продолжит работу без изменений.);
• Каждый слой является удачным кандидатом на стандартизацию. (Например стек протоколов TCP/IP);
• Созданный слой может служить основой для нескольких различных слоёв более высокого уровня. (Протоколы TCP/IP используются приложениями FTP, telnet, SSH и HTTP. В противном случае для каждого протокола высокого уровня пришлось бы изобретать собственный протокол низкого уровня)

Схема расслоения обладает и определёнными недостатками:

• Слои способны удачно инкапсулировать многое, но не всё: модификация одного слоя подчас связана с необходимостью внесения каскадных изменений в остальные слои. Классический пример: поле добавленное в таблицу БД, подлежит воспроизведению в графическом интерфейсе и должно найти соответствующее отображение в каждом промежуточном слое.
• Наличие избыточных слоёв нередко снижает производительность системы.

Однако самое трудное при использовании архитектурных слоёв – это определение содержимого и границ ответственности каждого слоя.

Понятие слоя приобрело очевидную значимость в середине 1990-ых годов с появлением client/server. Это были системы с двумя слоями: клиент нёс ответственность за отображение пользовательского интерфейса и выполнения кода приложения, а роль сервера обычно поручалась СУБД.

С развитием ООП стали выделять бизнес-логику в отдельный слой. Таким образом пришли к трёхуровневой парадигме. Радикальный сдвиг в этом направлении произошёл с приходом web.

Обычно рассматриваются как минимум три основных слоя:

• Представление – охватывает всё, что имеет отношение к общению пользователя с системой. Он может быть настолько простым как командная строка, но может быть и HTML и толстым клиентом.
• Бизнес-логика – описывает основные функции приложения, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а так же передача информации слою источника данных.
• Источник данных – это подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют задания в интересах приложения. Код этой категории несёт ответственность за мониторинг транзакций, управление другими приложениями, обмен сообщениями и т.д. Для большинства корпоративных приложений основная честь логики источника данных сосредоточена в коде СУБД.

В дополнение к этим трём иногда выделяют отдельные слои: интеграции, слои служб, слои обеспечения безопасности, распределения и т.п. Вообще говоря, выбор того какие слои включать или исключать из рассмотрения лежит полностью на усмотрении архитектора конкретной системы. В его компетенции входит выбор слоёв, рассмотрение которых имеет смысл выделить с точки зрения потребности конкретного проекта. Важно понимать, что нельзя дать универсальных решений для описания систем, ибо такой подход неминуемо бы привёл к однобокости и неоправданным затратам с одной стороны и недостаточной детализацией с другой. Если архитектор (или разработчик) считает, что введение некоторого архитектурного слоя в модель и описание системы привнесёт очевидные плюсы – имеет смысл это сделать. Обратно, если введение нового слоя не приводит к каким-либо ощутимым выгодам, а лишь загромождает модель и описание системы излишними подробностями – имеет смысл объединять описание слоёв. Так, например, в слое «Источник данных» можно объединить такие слои как непосредственно связь с БД, так и связь со сторонними системами, если она проста и интуитивно понятна. Стоит однако отметить, что в случае с межсистемной связью (и интеграцией) такое бывает редко и как правило интеграционные слои, если интеграция в проекте присутствует, имеет смысл выделять при описании системы.

12.2. Физическое размещение слоёв.

В предыдущем разделе выделение слоёв носило исключительно логический характер, т.е. при реализации и развёртывании системы в эксплуатационном режиме, конкретного выделения слоёв может и не существовать. Так, система, описанная с точки зрения архитектурных слоёв, может вполне при реализации представлять собой монолитный код, запущенный как один процесс в одном адресном пространстве на одной ЭВМ. Как правило, однако, стараются, как минимум, разделять систему на программные модули, отвечающие её логическому разделению, с тем, чтобы усилить связь между её логическим описанием и реализацией. В последствии при поддержке и развитии системы это сильно облегчит задачу, так как упростит понимание системы. Кроме того, система сможет обладать всеми перечисленными плюсами послойной архитектуры, а именно, слои можно относительно независимо взаимозаменять, параллельно разрабатывать и тестировать, а так же стандартизовать (или использовать уже готовые и/или стандартные решения). Этот подход подчёркивает преследование принципов слабой связи (low coupling) и высокого зацепления (high cohesion), пропагандируемый при разработке сложных систем.

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

Тем не менее, существует ситуации, в которых физическое распределение является наиболее оправданным, а иногда и единственно возможным, подходом к построению систем, при котором (как правило, но не всегда) в соответствии с выделением архитектурных слоёв происходит физическое веление слоёв системы. Например, СУБД (как слой отвечающий за хранение и доступ к данным) может быть выделен в отдельный физический процесс запущенный на отдельной ЭВМ.

К возможным причинам физического распределения относятся:

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

Однако физическое распределение обладает рядом существенных недостатков, в связи с чем его всегда по возможности следует избегать. Исключением может быть разве что совсем типичные случаи распределения СУБД и сервера приложений (web-сервера) на разные машины, объединённые высокоскоростным выделенным (чтобы избежать коллизий) сегментом сети.

К недостаткам физического распределения относятся:

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

Таким образом, разработчик должен отдавать себе отчёт в том, что применяя физическое распределение можно добиться как раз обратного эффекта а именно снижение производительности и отказоустойчивости. Отдельно следует отметить то, что на систему, планирующуюся использоваться в распределённой конфигурации, накладывается ряд дополнительных требований. Например, при дублировании web-сервера может оказаться необходимым то, что все объекты, хранящиеся в HTTP сессии были бы сериализуемыми (serializable), в противном случае невозможно будет обеспечить отказоустойчивость.

Дата добавления: 2014-01-05