Файл: Варианты архитектуры клиент-сервер (Стандартизация).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 31.03.2023

Просмотров: 197

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

.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 — большое количество конкурентных (одновременных и долгоживущих) соединений клиентов к серверу.