Лекция 1.
«Техническая система.»
Требования:
-
Производительность
-
Надежность
-
Безопасность
-
Масштабируемость
-
Универсальность
-
Обратная совместимость
-
Внешняя совместимость с аппаратным ПО
-
Соответствие определенным стандартам
Архитектура:
-
Системная (выделяем компоненты, компонент выполняет функцию)
-
Программная
-
Архитектура данных
Компонент – модульная часть системы, которая инкапсулирует ее содержимое
В итоге используют клиент-серверную архитектуру.
Слои:
-
Представление
-
Бизнес-логика
-
Доступ к данным
Файл-серверная архитектура
Плюсы:
1. Простота организации, низкая стоимость и высокая скорость разработки. 2. Наличие развитых средств разработки интерфейса, систем БД и СУБД. 3. Многопользовательский режим работы с данными. 4. Удобство централизованного управления доступом. Минусы:
1. Перегрузка трафика (для выборки полезных данных необходимо просмотреть на стороне клиента весь соответствующий файл целиком). 2. Децентрализованное решение проблем целостности и согласованности данных, одновременного доступа к ним, что снижает надежность приложения. 3. Слабые возможности расширения, необходимость переустановки ПО на клиентских местах. 4. Низкая производительность, зависящая от производительности сети, сервера, клиента.
Клиент-серверная архитектура (Двухуровневая архитектура)
Плюсы:
1.Полная поддержка многопользовательской работы. 2. Гарантия целостности данных. 3. Возможность распределения функции системы между несколькими независимыми компьютерами в сети; 4. Все данные хранятся на сервере, который защищен гораздо лучше клиентов; на сервере проще обеспечить контроль доступа к данным клиентов с соответствующими полномочиями. Недостатки: 1. При изменении бизнес-логики, надо обновлять пользовательское ПО на каждом клиенте. 2. Высокие требования к пропускной способности коммуникационных каналов. 3. Слабая защита данных от взлома недобросовестными пользователями системы. 4. Сложность администрирования и настройки рабочих мест пользователей. 5. Необходимость использования мощных ПК на клиентских местах. 6. Высокая сложность разработки из-за того, что бизнес-логика и интерфейс находятся в одной программе.
Толстый клиент – обработка на клиенте Достоинства:
Недостатки:
-
В случае изменения одного объекта, нужно изменить все
-
Сложность администрирования и настройки рабочих мест пользователей
-
Ресурсные затраты на клиентские рабочие места
-
Высокая сложность и стоимость разработки всей системы в целом
-
Плохая масштабируемость
Тонкий клиент – обработка на сервере Достоинства:
-
Полноценная поддержка многопользовательской работы
-
Гарантия целостности данных
Недостатки:
-
Высокие требования к пропускному каналу и качеству связи
-
Высокие требования к производительности серверной компоненты
-
Слабая защита от взлома
Трехуровневая клиент-серверная архитектура
Плюсы:
-
Возможность распределенности обработки
-
Удобство в обновлении ПО и регламентных работ
-
Высокий уровень безотказности
Минусы:
-
Высокая стоимость разработки и поддержки сервера
Формы:
-
Веб-архитектура
-
1С
|
Клиент |
Сервер приложений |
Сервер хранения |
Доступ к данным |
|
|
Доступ к данным Хранилище файлов
|
Бизнес-логика |
|
Web-сервер Обработка ORM |
|
Представление данных |
Интерфейс |
|
|
Кластер серверов с неуправляемой балансировкой – все взаимозаменяемы
-
MS Exchange
отдельно
-
Сервера отчетов
-
Сервера приложений
-
Web-сервера
Глобальные проблемы: Все структуры «тяжелы» для масштабируемости.
Трехзвенная архитектура (распределительная)
Распределительная архитектура Цели:
-
Повысить производительность (обработка)
-
Повысить надежность за счет дублирования узлов
-
Снизить коммуникативные расходы за счет приближения обработки узлов к потребителю
-
Повысить мощность за счет разграничения серверов
Сложности при создании распределительной архитектуры:
-
Обеспечить целостность данных
-
Оптимизировать распределение ресурсов при неравномерной нагрузки
-
Синхронизация событий и взаимоблокировок
-
Обеспечить мониторинг и диагностику
-
Стандартизация интерфейсов
Варианты решений. Трехзвенная архитектура:
RPC – метод с удаленным вызовом процедур. Остальные модули хранятся на разных серверах и могут вызываться с других серверов.
Не ООП вариант
Модули на разных серверах т.е. метод RPC
Используется модуль-заглушка
Минусы:
1.Передача данных по сети из AS1 в AS2
Недостаток: работа с данными(постоянная пересылка данных на другие сервера)
-
ОО- варианты(объектно-ориентированные) 1. Сериализация объектов- сжатие объектов в структуру и передача на другие серверы. Недостаток: должно быть одинаковое окружение 2. RMI- удаленный вызов объекта, находящегося на другом сервере 3. CORBA (на шинах)-архитектура брокера объектных запросов. Использование шин запросов. (Только ООП)
4. Rabbit MQ- как и CORBA только не ООП, более абстрактная структура. Позволяет создавать очереди и распределять нагрузку.
-
Балансировка нагрузки
-
Синхронная Связь с клиентами поддерживает живой балансировщик. Достоинства: четкий контроль нагрузки; возможность диагностики Недостатки: две очереди (на вход/на выход)
-
Асинхронная
-
Задача балансировщика только на вход, СП передает данные сразу клиенту, минуя балансировщика. Недостатки: -балансировщик не контролирует серверы, поэтому нужно дополнительно системы мониторинга. -безопасность (разные сертификаты шифрования у балансировщика и сервера) Достоинства: -доп работа с очередями с помощью балансировщика на входе.