Файл: Варианты архитектуры клиент-сервер (Основные понятия клиент-серверной архитектуры).pdf

Почему же так долго системы эволюционировали до казалось бы столь ясного и логичного подхода к архитектуре? Во первых необходимо сюда отнести инерцию человеческого мышления. Во вторых трудозатраты на разработку двухзвенной и трехзвенной архитектуры могут отличаться на порядки, а в самом начале и отличались ввиду полного отсутствия стандартизации, готовых фрейворков разработки и собственно сами языки программирования не давали такой широкой возможности. Она появилась наверное только с распространением объектно-ориентированных языков программирования. Отсутствие стандартов в данных областях, подразумевало, что каждый будет выдумывать свои протоколы общения между СУБД и сервером приложений (например). Современные платформы для построения информационных систем такого уровня могут использовать в качестве СУБД, например, Oracle, IBM DB2, MS SQL Server, PostgreSQL Server, что называется “из коробки”. Языки программирования, например C#, Java, имеют готовые фреймворки для работы с СУБД. Методология программирования также стандартизировала паттерны проектирования, например, MVC - Model, View, Controller. Где, Model - данные, View - отображение, Controller - отражает действия пользователя из View в Model. При этом бизнес-логика приложения может находиться как в Model, так и в Controller.

Требования к распределенным системам можно свести в следующий перечень:

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

Глава II. Современные реализации клиент-серверной архитектуры

2.1 Стандартизация

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

Таким образом, мы приходим к анализу существующих распределенных объектных моделей. На настоящий момент наибольшей проработанностью отличаются COM/DCOM/ActiveX и CORBA/DCE/Java. И COM, и CORBA — современные программные технологии, которые могут быть использованы для создания крупных корпоративных систем.

CORBA (Common Object Request Broker Architecture) — это набор открытых спецификаций интерфейсов, определяющий архитектуру технологии межпроцессного и платформонезависимого манипулирования объектами. Разработчиками данных интерфейсов являются OMG и X/Open.
Реализовать технологию в соответствии со спецификациями может кто угодно.

Рис. 2. Модели COM и CORBA

Функции CORBA и COM — это функции промежуточного программного обеспечения объектной среды. Для того чтобы обеспечить взаимодействие объектов и их интеграцию в цельную систему, архитектура промежуточного уровня должна реализовать несколько базовых принципов.

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

.Net же сам по себе есть программный коммерческий продукт, ориентированный, в первую очередь, на практическое использование. По этой причине в .Net кроме собственно архитектуры манипулирования объектами присутствует еще и вся инфраструктура, обеспечивающая распределенную обработку объектов в реальном программном и аппаратном окружении. Разработчиком .Net Framework является фирма Microsoft.

Одно из основных отличий CORBA и .Net заключается в подходе к разработке и развитию этих технологий. Условно можно назвать подход, принятый в CORBA, как "движение сверху", а подход .Net как "движение снизу". То есть, разработка и реализация в CORBA, в первую очередь, ведется от спецификаций OMG, которые хотя и основываются на практическом опыте разработчиков, но в своей основе, теоретические проекты интерфейсов, рассчитанные на практическую реализацию кем угодно.

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

2.2 Реализация клиент-серверной архитектуры в масштабных проектах

В современном мире, наиболее сложными и нагруженными являются пожалуй не корпоративные информационные системы, охватывающие тысячи пользователей, а представители игровой индустрии, такие как MMO-игры охватывающие миллионы пользователей по всему миру. Архитектура таких проектов должна быть масштабируемой. Ведь на старте проекта нагрузки как правило невелики, а впоследствии могут вырасти очень быстро. Также, нагрузка очень не регулярная, и характеризуется всплесками активности пользователей. Соответственно, архитектура должна уметь быстро наращивать мощности и распределять нагрузку таким образом, чтобы выдержать пик активности пользователей. Например в проекте “Eve-online”, при массовом присутствии (несколько тысяч) игроков в одном секторе, включается замедление игрового времени. В проекте “World of Tanks” используется блокировка входа избыточного количества игроков и физическое распределение серверов по географии присутствия пользователей.

В целом, архитектура ММО-проекта выглядит следующим образом:

Рис 3. Архитектура ММО

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

Рис 4. Текущие архитектуры современных информационных систем

Большая часть текущих информационных систем построены по архитектуре #5, сейчас очень активно развитие систем по #8. Хотя все остальные архитектуры также присутствуют. Например #6 это всякого рода почтовые службы типа mail.ru, gmail и т.д.

Если обобщать, то можно прикинуть векторы развития информационных систем:

Высоконагруженное облако.

Преимущества: Облака хорошо справляются с высокими нагрузками, хорошо масштабируются.

Недостатки: Плохая интерактивность с пользователем.

DB-центрический подход.

Преимущества: СУБД встроенное в приложение, работа с локальными данными.

Недостатки: сведение всего общения между приложениями на уровень данных.

Одноранговое взаимодействие (Peer-to-peer).

Преимущества: Сервера будут выполнять только функции брокера, локальное взаимодействие гораздо продуктивнее.

Недостатки: Вопрос доверия соседнему пиру. Отсутствие стандартизированных протоколов, библиотек, фреймворков для разработки ПО (весь инструментарий придется писать с нуля).

ЗАКЛЮЧЕНИЕ

Технологии не стоят на месте и по прежнему развиваются с высокой скоростью. Также как всегда, львиная доля решений не идет в ногу с технологическим лидером. Этому конечно есть множество совершенно обоснованных объяснений и причин. Даже сейчас встречаются информационные системы разработанные на FoxPro или Clipper под DOS (да, да, тот самый файл-серверный вариант) и самое главное, что они работают и востребованы. Но это в основном связано с утерей компетенций по постановке задачи, с дороговизной разработки аналогичного решения на современных технологиях и т.д.

В общем, если проанализировать и сгруппировать текущие потребности рынка, то получится следующий перечень:

• Highload — обработка интенсивного потока запросов;
• Big data — возможность обрабатывать большие объемы данных;
• Big memory и in-memory DB — высокая утилизация объемов памяти или перенос баз данных полностью в оперативную память;
• High connectivity — большое количество конкурентных (одновременных и долгоживущих) соединений клиентов к серверу.