Архитектуры распределенных приложений.
Клиент-сервер
Первый тип, который будет нами изучен, - архитектура "клиент-сервер" (рис. 2.1). Это в настоящее время наиболее распространенная архитектура, в которой выполнено, пожалуй, большинство работающих информационных систем. Существует даже мнение, что почти все остальные архитектуры могут быть представлены как большая или меньшая вариация этой, базовой.
Рис. 2.1. Архитектура "клиент-сервер"
В традиционном понимании система, выполненная в архитектуре "клиент-сервер", представляет собой совокупность взаимодействующих компонент двух типов - клиентов и серверов. Обычным также является разнесение этих компонент по узлам двух типов - соответственно узлам-клиентам и узлам-серверам. Клиенты обращаются к серверам с запросами, серверы их обрабатывают и возвращают результат. Клиент, вообще говоря, может обращаться с запросами к нескольким серверам. Серверы также могут обращаться с запросами друг к другу. Таким образом, типичный протокол для одного факта взаимодействия может быть представлен в виде двух обменов - запрос на сервер и ответ сервера.
Наиболее часто встречающийся класс приложений, выполненных в архитектуре "клиент-сервер", - различные приложения, работающие с базами данных. В таком случае в качестве сервера выступает СУБД, обеспечивающая выполнение запросов клиента, который, в свою очередь, реализует интерфейс пользователя.
Рассмотренные далее модели систем, по сути, являются вариациями архитектуры "клиент-сервер".
Модель сервиса (один сервис - много серверов)
Модель сервиса (рис. 2.2) представляет собой реализацию ситуации, при которой одну услугу реализует не один, а несколько серверов, представляемых клиенту как единое целое. Строго говоря, предложенная модель является чистым клиент-сервером, у которого сервер имеет сложную структуру (не монолитен). Этот вариант особенно хорош для критичных сервисов, для которых недопустима приостановка обслуживания. Поскольку сервис реализуется сразу несколькими серверами, остановка одного из них не является критической1. Для прекращения обслуживания клиентов необходима остановка всех серверов системы. Кроме того, такая схема позволяет реализовать различные стратегии балансировки нагрузки между серверами системы.
|
|
Рис. 2.2. Модель сервиса
Таким образом, может быть существенно увеличена как производительность системы, так и ее устойчивость к сбоям. Однако наряду с плюсами у предложенной модели есть и минусы: самый большой - более сложная реализация по сравнению с базовой архитектурой. В самом деле, поскольку все серверы обеспечивают один и тот же сервис, возникают проблемы либо с репликацией обрабатываемых данных (поддержание на всех серверах системы актуальной копии данных), либо с поддержанием целостности распределенных данных.
Технология подключения через proxy
Примером системы, построенной в такой архитектуре, является привычная система из браузера, прокси-сервера и веб-сервера.
Отличием от ранее рассмотренных моделей является то, что клиент соединяется не с сервером, а с неким промежуточным компонентом (посредником) (рис. 2.3). Этот посредник, в свою очередь, от имени кли-
Рис. 2.3. Технология подключения через proxy
|
|
ента передает запрос серверу. При этом посредник может сам решать, на какой из серверов послать запрос (возможны стратегии балансировки нагрузки). Кроме того, он может поддерживать кэш последних задаваемых запросов и при очередном запросе пользователя вернуть ему ответ, не обращаясь к серверу2.
Следует отметить, что при неправильном построении посредник может стать узким местом всей системы.
Как уже говорилось ранее, этот подход особенно часто применяют при работе в Internet.