Лекция 1.

«Техническая система.»

Требования:

• Производительность

• Надежность

• Безопасность

• Масштабируемость

• Универсальность

• Обратная совместимость

• Внешняя совместимость с аппаратным ПО

• Соответствие определенным стандартам

Архитектура:

• Системная (выделяем компоненты, компонент выполняет функцию)

• Программная

• Архитектура данных

Компонент – модульная часть системы, которая инкапсулирует ее содержимое

В итоге используют клиент-серверную архитектуру.

Слои:

1. Представление

2. Бизнес-логика

3. Доступ к данным

Файл-серверная архитектура

Плюсы:

1. Простота организации, низкая стоимость и высокая скорость разработки. 2. Наличие развитых средств разработки интерфейса, систем БД и СУБД. 3. Многопользовательский режим работы с данными. 4. Удобство централизованного управления доступом. Минусы:

1. Перегрузка трафика (для выборки полезных данных необходимо просмотреть на стороне клиента весь соответствующий файл целиком). 2. Децентрализованное решение проблем целостности и согласованности данных, одновременного доступа к ним, что снижает надежность приложения. 3. Слабые возможности расширения, необходимость переустановки ПО на клиентских местах. 4. Низкая производительность, зависящая от производительности сети, сервера, клиента.

Клиент-серверная архитектура (Двухуровневая архитектура)

Плюсы:

1.Полная поддержка многопользовательской работы. 2. Гарантия целостности данных. 3. Возможность распределения функции системы между несколькими независимыми компьютерами в сети; 4. Все данные хранятся на сервере, который защищен гораздо лучше клиентов; на сервере проще обеспечить контроль доступа к данным клиентов с соответствующими полномочиями. Недостатки: 1. При изменении бизнес-логики, надо обновлять пользовательское ПО на каждом клиенте. 2. Высокие требования к пропускной способности коммуникационных каналов. 3. Слабая защита данных от взлома недобросовестными пользователями системы. 4. Сложность администрирования и настройки рабочих мест пользователей. 5. Необходимость использования мощных ПК на клиентских местах. 6. Высокая сложность разработки из-за того, что бизнес-логика и интерфейс находятся в одной программе.

Толстый клиент – обработка на клиенте Достоинства:

Недостатки:

• В случае изменения одного объекта, нужно изменить все

• Сложность администрирования и настройки рабочих мест пользователей

• Ресурсные затраты на клиентские рабочие места

• Высокая сложность и стоимость разработки всей системы в целом

• Плохая масштабируемость

Тонкий клиент – обработка на сервере Достоинства:

• Полноценная поддержка многопользовательской работы

• Гарантия целостности данных

Недостатки:

• Высокие требования к пропускному каналу и качеству связи

• Высокие требования к производительности серверной компоненты

• Слабая защита от взлома

Трехуровневая клиент-серверная архитектура

Плюсы:

• Возможность распределенности обработки

• Удобство в обновлении ПО и регламентных работ

• Высокий уровень безотказности

Минусы:

• Высокая стоимость разработки и поддержки сервера

Формы:

1. Веб-архитектура

1. 1С

	Клиент	Сервер приложений	Сервер хранения
Доступ к данным			Доступ к данным Хранилище файлов
Бизнес-логика		Web-сервер Обработка ORM
Представление данных	Интерфейс

Кластер серверов с неуправляемой балансировкой – все взаимозаменяемы

2. MS Exchange

отдельно

• Сервера отчетов

• Сервера приложений

• Web-сервера

Глобальные проблемы: Все структуры «тяжелы» для масштабируемости.

Трехзвенная архитектура (распределительная)

Распределительная архитектура Цели:

1. Повысить производительность (обработка)

2. Повысить надежность за счет дублирования узлов

3. Снизить коммуникативные расходы за счет приближения обработки узлов к потребителю

4. Повысить мощность за счет разграничения серверов

Сложности при создании распределительной архитектуры:

1. Обеспечить целостность данных

2. Оптимизировать распределение ресурсов при неравномерной нагрузки

3. Синхронизация событий и взаимоблокировок

4. Обеспечить мониторинг и диагностику

5. Стандартизация интерфейсов

Варианты решений. Трехзвенная архитектура:

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

Не ООП вариант

Модули на разных серверах т.е. метод RPC

Используется модуль-заглушка

Минусы:

1.Передача данных по сети из AS1 в AS2

Недостаток: работа с данными(постоянная пересылка данных на другие сервера)

1. ОО- варианты(объектно-ориентированные) 1. Сериализация объектов- сжатие объектов в структуру и передача на другие серверы. Недостаток: должно быть одинаковое окружение 2. RMI- удаленный вызов объекта, находящегося на другом сервере 3. CORBA (на шинах)-архитектура брокера объектных запросов. Использование шин запросов. (Только ООП)

4. Rabbit MQ- как и CORBA только не ООП, более абстрактная структура. Позволяет создавать очереди и распределять нагрузку.

2. Балансировка нагрузки

   1. Синхронная Связь с клиентами поддерживает живой балансировщик. Достоинства: четкий контроль нагрузки; возможность диагностики Недостатки: две очереди (на вход/на выход)

   2. Асинхронная

Задача балансировщика только на вход, СП передает данные сразу клиенту, минуя балансировщика. Недостатки: -балансировщик не контролирует серверы, поэтому нужно дополнительно системы мониторинга. -безопасность (разные сертификаты шифрования у балансировщика и сервера) Достоинства: -доп работа с очередями с помощью балансировщика на входе.