Управление Web-сервисами. Кейт Матсудейра: Масштабируемая веб-архитектура и распределенные системы

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

Основное внимание в данной главе уделяется анализу веб-систем, хотя часть материала может быть экстраполирована и на другие распределенные системы.

1.1 Принципы построения распределенных веб-систем

Что именно означает создание и управление масштабируемым веб-сайтом или приложением? На примитивном уровне это просто соединение пользователей с удаленными ресурсами через Интернет. А ресурсы или доступ к этим ресурсам, которые рассредоточены на множестве серверов и являются звеном, обеспечивающим масштабируемость веб-сайта.

Как большинство вещей в жизни, время, потраченное заранее на планирование построения веб-службы может помочь в дальнейшем; понимание некоторых соображений и компромиссов, стоящих позади больших веб-сайтов, может принести плоды в виде более умных решений при создании меньших веб-сайтов. Ниже некоторые ключевые принципы, влияющие на проектирование крупномасштабных веб-систем:

Доступность: длительность работоспособного состояния веб-сайта критически важна по отношению к репутации и функциональности многих компаний. Для некоторых более крупных онлайновых розничных магазинов, недоступность даже в течение нескольких минут может привести к тысячам или миллионам долларов потерянного дохода. Таким образом, разработка их постоянно доступных и эластичных к отказу систем и является и фундаментальным деловым и технологическим требованием. Высокая доступность в распределенных системах требует внимательного рассмотрения избыточности для ключевых компонентов, быстрого восстановления после частичных системных отказов и сглаженного сокращения возможностей при возникновении проблем.
Производительность: Производительность веб-сайта стала важным показателем для большинства сайтов. Скорость веб-сайта влияет на работу и удовлетворенность пользователей, а также ранжирование поисковыми системами - фактор, который непосредственно влияет на удержание аудитории и доход. В результате, ключом является создание системы, которая оптимизирована для быстрых ответов и низких задержек.
Надежность: система должна быть надежной, таким образом, чтобы определенный запрос на получение данных единообразно возвращал определенные данные. В случае изменения данных или обновления, то тот же запрос должен возвращать новые данные. Пользователи должны знать, если что-то записано в систему или храниться в ней, то можно быть уверенным, что оно будет оставаться на своем месте для возможности извлечения данных впоследствии.
Масштабируемость: Когда дело доходит до любой крупной распределенной системы, размер оказывается всего лишь одним пунктом из целого списка, который необходимо учитывать. Не менее важным являются усилия, направленные на увеличение пропускной способности для обработки больших объемов нагрузки, которая обычно и именуется масштабируемость системы. Масштабируемость может относиться к различным параметрам системы: количество дополнительного трафика, с которым она может справиться, насколько легко нарастить ёмкость запоминающего устройства, или насколько больше других транзакций может быть обработано.
Управляемость: проектирование системы, которая проста в эксплуатации еще один важный фактор. Управляемость системы приравнивается к масштабируемости операций «обслуживание" и «обновления». Для обеспечения управляемости необходимо рассмотреть вопросы простоты диагностики и понимания возникающих проблем, легкости проведения обновлений или модификации, прихотливости системы в эксплуатации. (То есть, работает ли она как положено без отказов или исключений?)
Стоимость: Стоимость является важным фактором. Она, очевидно, может включать в себя расходы на аппаратное и программное обеспечение, однако важно также рассматривать другие аспекты, необходимые для развертывания и поддержания системы. Количество времени разработчиков, требуемое для построения системы, объем оперативных усилий, необходимые для запуска системы, и даже достаточный уровень обучения - все должно быть предусмотрено. Стоимость представляет собой общую стоимость владения.

Каждый из этих принципов является основой для принятия решений в проектировании распределенной веб-архитектуры. Тем не менее, они также могут находиться в противоречии друг с другом, потому что достижение целей одного происходит за счет пренебрежения другими. Простой пример: выбор простого добавления нескольких серверов в качестве решения производительности (масштабируемость) может увеличивать затраты на управляемость (вы должны эксплуатировать дополнительный сервер) и покупку серверов.

При разработке любого вида веб-приложения важно рассмотреть эти ключевые принципы, даже если это должно подтвердить, что проект может пожертвовать один или больше из них.

1.2 Основы

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

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

Пример: Приложение хостинга изображений

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

Вообразите систему, где пользователи имеют возможность загрузить свои изображения на центральный сервер, и при этом изображения могут запрашиваться через ссылку на сайт или API, аналогично Flickr или Picasa. Для упрощения описания давайте предположим, что у этого приложения есть две основные задачи: возможность загружать (записывать) изображения на сервер и запрашивать изображения. Безусловно, эффективная загрузка является важным критерием, однако приоритетом будет быстрая доставка по запросу пользователей (например, изображения могут быть запрошены для отображения на веб-странице или другим приложением). Эта функциональность аналогична той, которую может обеспечить веб-сервер или граничный сервер Сети доставки контента (Content Delivery Network, CDN). Сервер CDN обычно хранит объекты данных во многих расположениях, таким образом, их географическое/физическое размещение оказывается ближе к пользователям, что приводит к росту производительности.

Другие важные аспекты системы:

Количество хранимых изображений может быть безгранично, таким образом, масштабируемость хранения необходимо рассматривать именно с этой точки зрения.
Должна быть низкая задержка для загрузок/запросов изображения.
Если пользователь загружает изображение на сервер, то его данные должны всегда оставаться целостными и доступными.
Система должна быть простой в обслуживании (управляемость).
Так как хостинг изображений не приносит большой прибыли, система должна быть экономически эффективной.

Другая потенциальная проблема с этим дизайном состоит в том, что у веб-сервера, такого как Apache или lighttpd обычно существует верхний предел количества одновременных соединений, которые он в состоянии обслужить (значение по умолчанию - приблизительно 500, но оно может быть намного выше), и при высоком трафике записи могут быстро израсходовать этот предел. Так как чтения могут быть асинхронными или использовать в своих интересах другую оптимизацию производительности как gzip-сжатие или передача с делением на порции, веб-сервер может переключить чтения подачи быстрее и переключиться между клиентами, обслуживая гораздо больше запросов, чем максимальное число соединений (с Apache и максимальным количеством соединений, установленном в 500, вполне реально обслуживать несколько тысяч запросов чтения в секунду). Записи, с другой стороны, имеют тенденцию поддерживать открытое соединение на протяжении всего времени загрузки. Так передача файла размером 1 МБ на сервер могла занять больше 1 секунды в большинстве домашних сетей, в результате веб-сервер сможет обработать только 500 таких одновременных записей.

Рисунок 1.2: Разделение чтения и записи

Предвидение подобной потенциальной проблемы свидетельствует о необходимости разделения чтения и записи изображений в независимые службы, показанные на . Это позволит не только масштабировать каждую из них по отдельности (так как вероятно, что мы будем всегда делать больше чтений, чем записей), но и быть в курсе того, что происходит в каждой службе. Наконец, это разграничит проблемы способные возникнуть в будущем, что упростит диагностику и оценку проблемы медленного доступа на чтение.

Преимущество этого подхода состоит в том, что мы в состоянии решить проблемы независимо друг от друга - при этом нам не придется думать о необходимости записи и получении новых изображений в одном контексте. Обе из этих служб все еще используют глобальный корпус изображений, но при использовании методов соответствующих определенной службе, они способны оптимизировать свою собственную производительность (например, помещая запросы в очередь, или кэшируя популярные изображения - более подробно об этом речь пойдет далее). Как с точки зрения обслуживания, так и стоимости каждая служба может быть масштабирована независимо по мере необходимости. И это является положительным фактором, поскольку их объединение и смешивание могло бы непреднамеренно влиять на их производительность, как в сценарии, описанном выше.

Конечно, работа вышеупомянутой модели будет оптимальной, в случае наличия двух различных конечных точек (фактически, это очень похоже на несколько реализаций провайдеров «облачного» хранилища и Сетей доставки контента). Существует много способов решения подобных проблем, и в каждом случае можно найти компромисс.

К примеру, Flickr решает эту проблему чтения-записи, распределяя пользователи между разными модулями, таким образом, что каждый модуль может обслуживать только ограниченное число определенных пользователей, и когда количество пользователи увеличиваются, больше модулей добавляется к кластеру (см. презентацию масштабирования Flickr,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). В первом примере проще масштабировать аппаратные средства на основе фактической нагрузки использования (число чтений и записей во всей системе), тогда как масштабировние Flickr просиходит на основе базы пользователей(однако, здесь используется предположение равномерного использования у разных пользователей, таким образом, мощность нужно планировать с запасом). В прошлом недоступность или проблема с одной из служб приводили в нерабочее состояние функциональность целой системы (например, никто не может записать файлы), тогда недоступность одного из модулей Flickr будет влиять только на пользователей, относящихся к нему. В первом примере проще выполнить операции с целым набором данных - например, обновляя службу записи, чтобы включить новые метаданные, или выполняя поиск по всем метаданным изображений - тогда как с архитектурой Flickr каждый модуль должен был быть подвергнут обновлению или поиску (или поисковая служба должна быть создана, чтобы сортировать те метаданные, которые фактически для этого и предназначены).

Что касается этих систем - не существует никакой панацеи, но всегда следует исходить из принципов, описанных в начале этой главы: определить системные потребности (нагрузка операциями «чтения» или «записи» или всем сразу, уровень параллелизма, запросы по наборам данных, диапазоны, сортировки, и т.д.), провести сравнительное эталонное тестирование различных альтернатив, понять условия потенциального сбоя системы и разработать комплексный план на случай возникновения отказа.

Избыточность

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

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

Создание избыточности в системе позволяет избавиться от слабых мест и обеспечить резервную или избыточную функциональность на случай нештатной ситуации. Например, в случае наличия двух экземпляров одной и той же службы, работающей в «продакшн», и один из них выходит из строя полностью или частично, система может преодолеть отказ за счет переключения на исправный экземпляр .
Переключение может происходить автоматически или потребовать ручного вмешательства.

Другая ключевая роль избыточности службы - создание архитектуры, не предусматривающей разделения ресурсов . С этой архитектурой каждый узел в состоянии работать самостоятельно и, более того, в отсутствие центрального «мозга», управляющего состояниями или координирующего действия других узлов. Она способствует масштабируемости, так как добавление новых узлов не требует специальных условий или знаний. И что наиболее важно, в этих системах не найдется никакой критически уязвимой точки отказа, что делает их намного более эластичными к отказу.

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

Рисунок 1.3: Приложение хостинга изображений с избыточностью

Сегментирование

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

Вертикальное масштабирование предполагает добавление большего количества ресурсов к отдельному серверу. Так, для очень большого набора данных это означало бы добавление большего количества (или большего объема) жестких дисков, и таким образом весь набор данных мог бы разместиться на одном сервере. В случае вычислительных операций это означало бы перемещение вычислений в более крупный сервер с более быстрым ЦП или большим количеством памяти. В любом случае, вертикальное масштабирование выполняется для того, чтобы сделать отдельный ресурс вычислительной системы способным к дополнительной обработке данных.

Горизонтальное масштабирование, с другой стороны, предполагает добавление большего количества узлов. В случае большого набора данных это означало бы добавление второго сервера для хранения части всего объема данных, а для вычислительного ресурса это означало бы разделение работы или загрузки через некоторые дополнительные узлы. Чтобы в полной мере воспользоваться потенциалом горизонтального масштабирования, его необходимо реализовать как внутренний принцип разработки архитектуры системы. В противном случае изменение и выделение контекста, необходимого для горизонтального масштабирования может оказаться проблематичным.

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

В нашем примере сервера изображения, возможно, что единственный файловый сервер, используемый для хранения изображения, можно заменить множеством файловых серверов, при этом каждый из них будет содержать свой собственный уникальный набор изображений. (См. .) Такая архитектура позволит системе заполнять каждый файловый сервер изображениями, добавляя дополнительные серверы, по мере заполнения дискового пространства. Дизайн потребует схемы именования, которая свяжет имя файла изображения с содержащим его сервером. Имя изображения может быть сформировано из консистентной схемы хеширования, привязанной к серверам. Или альтернативно, каждое изображение может иметь инкрементный идентификатор, что позволит службе доставки при запросе изображения обработать только диапазон идентификаторов, привязанных к каждому серверу (в качестве индекса).

Рисунок 1.4: Приложение хостинга изображений с избыточностью и сегментированием

Конечно, есть трудности в распределении данных или функциональности на множество серверов. Один из ключевых вопросов - местоположение данных ; в распределенных системах, чем ближе данные к месту проведения операций или точке вычисления, тем лучше производительность системы. Следовательно, распределение данных на множество серверов потенциально проблематично, так как в любой момент, когда эти данные могут понадобиться, появляется риск того, что их может не оказаться по месту требования, серверу придется выполнить затратную выборку необходимой информации по сети.

Другая потенциальная проблема возникает в форме
несогласованности (неконсистетности) .Когда различные сервисы выполняют считывание и запись на совместно используемом ресурсе, потенциально другой службе или хранилище данных, существует возможность возникновения условий «состязания» - где некоторые данные считаются обновленными до актуального состояния, но в реальности их считывание происходит до момента актуализации - и таком случае данные неконсистентны. Например, в сценарии хостинга изображений, состояние состязания могло бы возникнуть в случае, если бы один клиент отправил запрос обновления изображения собаки с изменением заголовка «Собака» на «Гизмо», в тот момент, когда другой клиент считывал изображение. В такой ситуации неясно, какой именно заголовок, «Собака» или «Гизмо», был бы получен вторым клиентом.

Есть, конечно, некоторые препятствия, связанные с сегментированием данных, но сегментирование позволяет выделять каждую из проблем из других: по данным, по загрузке, по образцам использования, и т.д. в управляемые блоки. Это может помочь с масштабируемостью и управляемостью, но риск все равно присутствует. Есть много способов уменьшения риска и обработки сбоев; однако, в интересах краткости они не охвачены в этой главе. Если Вы хотите получить больше информации по данной теме, вам следует взглянуть на блог-пост по отказоустойчивости и мониторингу.

1.3. Структурные компоненты быстрого и масштабируемого доступа к данным

Рассмотрев некоторые базовые принципы в разработке распределенных систем, давайте теперь перейдем к более сложному моменту - масштабирование доступа к данным.

Самые простые веб-приложения, например, приложения стека LAMP, схожи с изображением на .

Рисунок 1.5: Простые веб-приложения

С ростом приложения возникают две основных сложности: масштабирование доступа к серверу приложений и к базе данных. В хорошо масштабируемом дизайне приложений веб-сервер или сервер приложений обычно минимизируется и часто воплощает архитектуру, не предусматривающую совместного разделения ресурсов. Это делает уровень сервера приложений системы горизонтально масштабируемым. В результате использовании такого дизайна тяжёлый труд сместится вниз по стеку к серверу базы данных и вспомогательным службам; именно на этом слое и вступают в игру настоящие проблемы масштабирования и производительности.

Остальная часть этой главы посвящена некоторым наиболее распространенным стратегиям и методам повышения производительности и обеспечения масштабируемости подобных типов служб путем предоставления быстрого доступа к данным.

Рисунок 1.6: Упрощенное веб-приложение

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

Для рассмотрения данного раздела давайте предположим, что у Вас есть много терабайт (ТБ) данных, и Вы позволяете пользователям получать доступ к небольшим частям этих данных в произвольном порядке. (См. .)
Схожей задачей является определение местоположения файла изображения где-нибудь на файловом сервере в примере приложения хостинга изображений.

Рисунок 1.7: Доступ к определенным данным

Это особенно трудно, потому что загрузка терабайтов данных в память может быть очень накладной и непосредственно влияет на количество дисковых операций ввода-вывода. Скорость чтения с диска в несколько раз ниже скорости чтения из оперативной памяти - можно сказать, что доступ к памяти с так же быстр, как Чак Норрис, тогда как доступ к диску медленнее очереди в поликлинике. Эта разность в скорости особенно ощутима для больших наборов данных; в сухих цифрах доступ к памяти 6 раз быстрее, чем чтение с диска для последовательных операций чтения, и в 100,000 раз - для чтений в случайном порядке (см. «Патологии Больших Данных», http://queue.acm.org/detail.cfm?id=1563874).). Кроме того, даже с уникальными идентификаторами, решение проблемы нахождения местонахождения небольшой порции данных может быть такой же трудной задачей, как и попытка не глядя вытащить последнюю конфету с шоколадной начинкой из коробки с сотней других конфет.

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

Кэши

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

Каким же образом кэш может использоваться для ускорения доступа к данным в рамках нашего примера API? В этом случае существует несколько мест, подходящих размещения кэша. В качестве одного из возможных вариантов размещения можно выбрать узлы на уровне запроса, как показано на
.

Рисунок 1.8: Размещение кэша на узле уровня запроса

Размещение кэша непосредственно на узле уровня запроса позволяет локальное хранение данных ответа. Каждый раз, когда будет выполняться запрос к службе, узел быстро возвратит локальные, кэшированные данные, если таковые существуют. Если это не будет в кэше, то узел запроса запросит данные от диска. Кэш на одном узле уровня запроса мог также быть расположен как в памяти (которая очень быстра), так и на локальном диске узла (быстрее, чем попытка обращения к сетевому хранилищу).

Рисунок 1.9: Системы кэшей

Что происходит, когда вы распространяете кеширование на множество узлов? Как Вы видите , если уровень запроса будет включать множество узлов, то вполне вероятно, что каждый узел будет и свой собственный кэш. Однако, если ваш балансировщик нагрузки в произвольном порядке распределит запросы между узлами, то тот же запрос перейдет к различным узлам, таким образом увеличивая неудачные обращения в кэш. Двумя способами преодоления этого препятствия являются глобальные и распределенные кэши.

Глобальный кэш

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

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

Рисунок 1.10: Глобальный кэш, где кэш ответственен за извлечение

Рисунок 1.11: Глобальный кэш, где узлы запроса ответственны за извлечение

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

Распределенный кэш

Данные индексы часто хранятся в памяти или где-нибудь очень локально по отношению к входящему запросу клиента. Berkeley DB (BDB) и древовидные структуры данных, которые обычно используются, чтобы хранить данные в упорядоченных списках, идеально подходят для доступа с индексом.

Часто имеется много уровней индексов, которые служат картой, перемещая вас от одного местоположения к другому, и т.д., до тех пор пока вы не получите ту часть данных, которая вам необходима. (См. )

Рисунок 1.17: Многоуровневые индексы

Индексы могут также использоваться для создания нескольких других представлений тех же данных. Для больших наборов данных это - отличный способ определить различные фильтры и виды, не прибегая к созданию многих дополнительных копий данных.

Например, предположим, что система хостинга изображений, упомянутая выше, на самом деле размещает изображения книжных страниц, и сервис обеспечивает возможность клиентских запросов по тексту в этих изображениях, ища все текстовое содержимое по заданной теме также, как поисковые системы позволяют вам искать по HTML-содержимому. В этом случае все эти книжные изображения используют очень много серверов для хранения файлов, и нахождение одной страницы для представления пользователю может быть достаточно сложным. Изначально обратные индексы для запроса произвольных слов и наборов слов должны быть легкодоступными; тогда существует задача перемещения к точной странице и месту в этой книге и извлечения правильного изображения для результатов поиска. Таким образом, в этом случае инвертированный индекс отобразился бы на местоположении (таком как книга B), и затем B может содержать индекс со всеми словами, местоположениями и числом возникновений в каждой части.

Инвертированный индекс, который может отобразить Index1 в схеме выше, будет выглядеть примерно так: каждое слово или набор слов служат индексом для тех книг, которые их содержат.

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

И это ключевой момент в крупномасштабных системах, потому что даже будучи сжатыми, эти индексы могут быть довольно большими и затратными для хранения. Предположим, что у нас есть много книг со всего мира в этой системе, - 100,000,000 (см. запись блога «Внутри Google Books»)- и что каждая книга состоит только из 10 страниц (в целях упрощения расчетов) с 250 словами на одной странице: это суммарно дает нам 250 миллиардов слов. Если мы принимаем среднее число символов в слове за 5, и каждый символ закодируем 8 битами (или 1 байтом, даже при том, что некоторые символы на самом деле занимают 2 байта), потратив, таким образом, по 5 байтов на слово, то индекс, содержащий каждое слово только один раз, потребует хранилище емкостью более 1 терабайта. Таким образом, вы видите, что индексы, в которых есть еще и другая информация, такая, как наборы слов, местоположение данных и количества употреблений, могут расти в объемах очень быстро.

Создание таких промежуточных индексов и представление данных меньшими порциями делают проблему «больших данных» более простой в решении. Данные могут быть распределены на множестве серверов и в то же время быть быстродоступны. Индексы - краеугольный камень информационного поиска и база для сегодняшних современных поисковых систем. Конечно, этот раздел лишь в общем касается темы индексирования, и проведено множество исследований о том, как сделать индексы меньше, быстрее, содержащими больше информации (например, релевантность), и беспрепятственно обновляемыми. (Существуют некоторые проблемы с управляемостью конкурирующими условиями, а также с числом обновлений, требуемых для добавления новых данных или изменения существующих данных, особенно в случае, когда вовлечены релевантность или оценка).

Очень важна возможность быстро и легко найти ваши данные, и индексы - самый простой и эффективный инструмент для достижения этой цели.

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

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

Рисунок 1.18: Балансировщик нагрузки

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

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

Рисунок 1.19: Множественные балансировщики нагрузки

Как и прокси, некоторые балансировщики нагрузки могут также направлять запросы по-разному, в зависимости от типа запроса. Они также известны как реверсивные (обратные) прокси.

Управление данными, специфичными для определенного сеанса пользователя, является одной из проблем при использовании балансировщиков нагрузок. На сайте электронной коммерции, когда у Вас есть только один клиент, очень просто позволить пользователям помещать вещи в свою корзину и сохранять ее содержимое между визитами (это важно, так как вероятность продажи товара значительно возрастает, если по возвращении пользователя на сайт, продукт все еще находится в его корзине). Однако если пользователь направлен к одному узлу для первого сеанса, и затем к другому узлу во время его следующего посещения, то могут возникать несоответствия, так как новый узел может не иметь данных относительно содержимого корзины этого пользователя. (Разве вы не расстроитесь, если поместите упаковку напитка Mountain Dew в Вашу корзину, и, когда вернетесь, ее там уже не будет?) Одно из решений может состоять в том, чтобы сделать сеансы «липкими», так чтобы пользователь был всегда направлен к тому же узлу. Однако использование в своих интересах некоторых функций надежности, таких как автоматическая отказоустойчивость, будет существенно затруднено. В этом случае корзина пользователя всегда будет иметь содержание, но если их липкий узел станет недоступным, то будет необходим особый подход, и предположение о содержании корзины не будет больше верно (хотя, стоит надеяться, что это предположение не будет встроено в приложение). Конечно, данную проблему можно решить при помощи других стратегий и инструментов, как описанных в этой главе, таких как службы, так и многих других (как кэши браузера, cookie и перезапись URL).

Если у системы только несколько узлов, то такие приемы, как DNS-карусель, скорее всего окажутся более практичными, чем балансировщики загрузки, которые могут быть дорогими и увеличивать сложность системы добавлением ненужного уровня. Конечно, в больших системах есть все виды различных алгоритмов планирования и выравнивания нагрузки, включая как простые вроде случайного выбора или карусельного алгоритма, так и более сложные механизмы, которые принимают во внимание производительность особенности модели использования системы. Все эти алгоритмы позволяют распределить трафик и запросы, и могут обеспечить полезные инструменты надежности, такие как автоматическая отказоустойчивость или автоматическое удаление поврежденного узла (например, когда он перестает отвечать на запросы). Однако, эти расширенные функции могут сделать диагностику проблем громоздкой. Например, в ситуациях с высокой нагрузкой, балансировщики нагрузки будут удалять узлы, которые могут работать медленно или превышать время ожидания (из-за шквала запросов), что только усугубит ситуацию для других узлов. В этих случаях важен обширный контроль потому, что даже если кажется, что полный системный трафик и нагрузка снижаются (так как узлы обслуживают меньшее количество запросов) - отдельные узлы могут оказаться нагруженными до предела.

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

Очереди

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

Рисунок 1.20: Синхронный запрос

Представьте себе систему, в которой каждый клиент запрашивает задачу удаленного обслуживания. Каждый из этих клиентов отправляет свой запрос серверу, который выполняет задачи как можно быстрее и возвращает их результаты соответствующим клиентам. В маленьких системах, где один сервер (или логическая служба) может обслуживать поступающих клиентов так же быстро, как они прибывают, ситуации такого рода должны работать нормально. Однако, когда сервер получает больше запросов, чем он может обработать, тогда каждый клиент вынужден ожидать завершения обработки запросов других клиентов, прежде чем ответ на его собственный запрос будет сгенерирован. Это - пример синхронного запроса, изображенного на .

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

Рисунок 1.21: Использование очередей для управления запросами

Очереди входа. Механизм работы очереди очень прост: задача приходит, попадает в очередь, и затем «рабочие» принимают следующую задачу, как только у них появляется возможность обработать ее. (См. .) Эти задачи могут представлять собой простые записи в базу данных или что-то столь же сложное как генерация изображения предварительного просмотра для документа. Когда клиент отправляет запросы постановки задач в очередь, ему больше не требуется ожидать результатов выполнения; вместо этого запросы нуждаются только в подтверждении факта их получения должным образом. Это подтверждение может позже служить ссылкой на результаты работы, когда клиент затребует их.

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

Очереди также обеспечивают некоторую защиту от приостановок обслуживания и отказов. Например, довольно просто создать очень устойчивую очередь, которая может повторить запросы на обслуживание, которые перестали работать из-за кратковременных отказов сервера. Более предпочтительно использовать очередь, чтобы реализовывать гарантии качества обслуживания, чем показывать клиентам временные перебои в работе сервиса, требуя сложной и часто противоречивой обработки ошибок на стороне клиентов.

Очереди - основной принцип в управлении распределенной передачей между различными частями любой крупномасштабной распределенной системы, и есть много способов реализовать их. Есть довольно много реализаций очередей с открытым исходным кодом как RabbitMQ ,
ActiveMQ ,
BeanstalkD , но некоторые также используют службы как

масштабирование

distributed computing

web-разработка

Kate Matsudaira

Добавить метки

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

является повторно используемым;

определяется одним или несколькими явными технологически-независимыми интерфейсами;

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

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

1.1 Основы Web-сервисов

Web-сервисы - это новая перспективная архитектура, которая обеспечивает новый уровень распределённости. Вместо разработки или приобретения компонентов и их встраивания в ИС предлагается покупать время их работы и формировать программную систему, которая осуществляет вызовы методов из компонентов, которые принадлежат и поддерживаются независимыми провайдерами. Благодаря Web-сервисам функции любой программы в сети могут стать доступными через Интернет. Самый простой пример Web-сервиса - система Passport на Hotmail , которая позволяет создать аутентификацию пользователей на собственном сайте.

В основе Web-сервисов лежат следующие универсальные технологии:

TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;

HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;

XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.

Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС . В этом и заключается основное принципиальное отличие веб-сервисов от предшественников.

Веб-сервисы - это XML-приложения, осуществляющие связывание данных с программами, объектами, базами данных либо с деловыми операциями целиком. Между веб-сервисом и программой осуществляется обмен XML-документами, оформленными в виде сообщений. Стандарты веб-сервисов определяют формат таких сообщений, интерфейс, которому передается сообщение, правила привязки содержания сообщения к реализующему сервис приложению и обратно, а также механизмы публикации и поиска интерфейсов.

XML (англ. e X tensible M arkup L anguage - расширяемыйязык разметки ; произносится [икc-эм-эль ]). РекомендованКонсорциумом Всемирной паутины (W3C). Спецификация XML описывает XML-документы и частично описывает поведение XML-процессоров (программ, читающих XML-документы и обеспечивающих доступ к их содержимому). XML разрабатывался как язык с простым формальнымсинтаксисом , удобный длясоздания и обработки документов программам и одновременно удобный для чтения и создания документов человеком, с подчёркиванием нацеленности на использование в Интернете. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать разметку в соответствии с потребностями к конкретной области, будучи ограниченным лишь синтаксическими правилами языка. Сочетание простого формального синтаксиса, удобства для человека, расширяемости, а также базирование на кодировкахЮникод для представления содержания документов привело к широкому использованию как собственно XML, так и множества производных специализированных языков на базе XML в самых разнообразных программных средствах.

Стандартные XML-приложения

XML можно использовать не только для описания отдельного документа. Индивидуальный пользователь, компания или комитет по стандартам может определить необходимый набор элементов XML и структуру документа, которые будут применяться для особого класса документов. Подобный набор элементов и описание структуры документа называют XML-приложением или XML-словарем . Например, организация может определить XML-приложение для создания документов, описывающих молекулярные структуры, мультимедиа презентации или содержащих векторную графику.

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

Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI) , осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.

Как видно из рис. 1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.

Рис.1. Веб-сервисы взаимодействуют с прикладными системами

Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения , преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого связующего программного обеспечения (middleware ).

Простой пример: поиск информации

В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL ):

http://www.google.com/search?q=Skate+boots&btnG=Google+Search

Этот пример иллюстрирует простоту веб-взаимодействия (например, поиска, покупки акций или запроса маршрута движения), где параметры и ключевые слова внедряются непосредственно в URL. В данном случае представлен простой запрос поиска skate boots (ботинки с коньками) в строке обращения к поисковой машине Google. Ключевое слово search (искать) представляет сервис, к которому будет осуществлено обращение, а параметр Skate+boots является строкой поиска, которая была введена в HTML-форме на странице веб-сайта Google. Сервис поиска Google передаст этот запрос к различным поисковым машинам, которые вернут список URL для страниц, на которых имеется соответствие параметру поиска Skate+boots. Данный малоэффективный способ поиска в Сети полностью основан на установлении соответствия указанной текстовой строки и индексированных HTML-страниц.

XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа :

xmlns:s="www.xmlbus.com/SearchService">

Skate

boots

size 7.5

Отправка запроса в виде XML-документа имеет следующие преимущества: возможность определения типов данных и структур, большую гибкость и расширяемость. XML может представлять структурированные данные или данные определенного типа (например, допустимо указывать значение поля size (размер) как в виде строки цифр, так и в форме числа с плавающей точкой) и содержать больший объем информации, чем это допускает URL.

Данный пример представлен в форме SOAP-сообщения (Simple Object Access Protocol) - стандартной формы обмена XML-сообщениями - одной из технологий, лежащих в основе веб-сервисов. В SOAP-сообщении имя запрашиваемого сервиса и входные параметры представлены в виде отдельных XML-элементов. Рассматриваемый пример также иллюстрирует использование пространства имен XML (xmlns:), еще одного важного элемента веб-сервисов. Благодаря тому, что XML-документы поддерживают разные типы данных, сложные структуры и объединение схем, современные технологии веб-сервисов обеспечивают значительное преимущество над существующими возможностями обращения к программным приложениям посредством HTML и URL.

5.1.1 Основы Web-сервисов

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

В основе Web-сервисов лежат следующие универсальные технологии:

TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;

HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;

XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.

Универсальность этих технологий – основа для понимания веб-сервисов. Они основаны только на общепринятых, открытых и формально независимых от поставщиков технологиях. Только посредством этого достигается главное преимущество веб-сервисов как концепции построения распределенных ИС – их универсальность, т. е. возможность применения для любых операционных систем, языков программирования, серверов приложений и т. д. Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС. В этом и заключается основное принципиальное отличие веб-сервисов от предшественников.

Веб-сервисы - это XML-приложения, осуществляющие связывание данных с программами, объектами, базами данных либо с деловыми операциями целиком. Между веб-сервисом и программой осуществляется обмен XML-документами, оформленными в виде сообщений. Стандарты веб-сервисов определяют формат таких сообщений, интерфейс, которому передается сообщение, правила привязки содержания сообщения к реализующему сервис приложению и обратно, а также механизмы публикации и поиска интерфейсов.

Веб-сервисы могут использоваться во многих приложениях. Независимо от того, откуда запускаются веб-сервисы, с настольных компьютеров клиентов или с переносных, они могут использоваться для обращения к таким интернет-приложениям, как система предварительных заказов или контроля выполнения заказов. Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI), осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.

Как видно из рис. 5.1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.

Рис.5.1. Веб-сервисы взаимодействуют с прикладными системами

Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения, преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого связующего программного обеспечения (middleware).

Простой пример: поиск информации

В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL):

http://www.google.com/search?q=Skate+boots&btnG=Google+Search

XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа:

xmlns:s="www.xmlbus.com/SearchService">

Skate

boots

size 7.5

Отправка запроса в виде XML-документа имеет следующие преимущества: возможность определения типов данных и структур, большую гибкость и расширяемость. XML может представлять структурированные данные или данные определенного типа (например, допустимо указывать значение поля size (размер) как в виде строки цифр, так и в форме числа с плавающей точкой) и содержать больший объем информации, чем это допускает URL.

Следующее поколение Сети

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

Использование веб-сервисов очень выгодно с коммерческой точки зрения. За счет повсеместного распространения веб-сервисов Интернет становится более эффективным, особенно при осуществлении коммерческих сделок. Сочетая прямой доступ к программным приложениям и коммерческим документам, веб-сервисы следующего поколения Сети обеспечат полностью автоматическое взаимодействие, что позволит обращаться непосредственно к данным программ, игнорируя знакомые веб-страницы. Более того, основные компоненты веб-сервисов, скорее всего, будут предоставляться и публиковаться множеством различных компаний, специализирующихся на отдельных функциональных элементах (проверка полномочий, координация сделок, ведение счетов). Это обеспечит непосредственное взаимодействие "приложение-приложение" - принцип, лежащий в основе веб-сервисов и определяющий их суть и реализацию.

ОБЩЕЕ ВЗАИМОПОНИМАНИЕ

Технология веб-сервисов существует на очень высоком уровне абстракции, позволяя поддерживать множество одновременных определений, которые иногда бывают противоречивы. На простейшем уровне веб-сервисы могут восприниматься как интернет-ориентированные текстовые брокеры интеграции. Любые данные могут преобразовываться в ASCII-текст и обратно, и этот подход в течение долгого времени был общим знаменателем для систем графического вывода и систем управления базами данных. Ориентированные на использование текста системы также лежат в основе успешного развития Интернета, на котором базируется дополнительная абстракция веб-сервисов. Любой компьютер или операционная система может поддерживать HTML, браузеры и веб-сервисы; и при получении по сети файлов им совершенно безразлично и даже неизвестно, с каким типом прикладной системы они взаимодействуют.

Преимущества и недостатки веб-сервисов.

К преимуществам веб-сервисов можно отнести следующее:

Веб-сервисы позволяют компании интегрировать свои бизнес-процессы с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости, чем с использованием других интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития;

Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают;

Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в компании ИС, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них. Таким образом, обеспечивается сохранность уже сделанных инвестиций в IT-инфраструктуру и не идет увеличения требуемых, поскольку нет необходимости в радикальных изменениях;

Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).

К недостаткам (минусам) веб-сервисов можно отнести:

Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;

Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries);

Добавление к функциям сервера приложений функциональности провайдера веб-сервисов в силу новизны технологий может представлять определенную трудность;

Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

Таким образом, преимущества представляют собой стратегические бизнес-преимущества компаний, а недостатки имеют технологический характер и обусловлены новизной технологий, решение этих проблем лишь вопрос времени.

Определение веб-сервиса

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

является повторно используемым;

определяется одним или несколькими явными технологически-независимыми интерфейсами;

Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.

Web-сервисы - новое слово в технологии распределенных систем. Спецификация Open Net Environment (ONE) корпорации Sun Microsystems и инициатива. Net корпорации Microsoft обеспечивают инфраструктуры для написания и развертывания Web -сервисов. В настоящий момент имеется несколько определений Web -сервиса. Web -сервисом может быть любое приложение, имеющее доступ к Web , например, Web -страница с динамическим содержимым. В более узком смысле Web -сервис - это приложение, которое предоставляет открытый интерфейс, пригодный для использования другими приложениями в Web . Спецификация ONE Sun требует, чтобы Web -сервисы были доступны через HTTP и другие Web -протоколы, чтобы дать возможность обмениваться информацией посредством XML -сообщений и чтобы их можно было найти через специальные сервисы - сервисы поиска. Для доступа к Web -сервисам разработан специальный протокол - Simple Object Access Protocol (SOAP) ,который представляет средства взаимодействия на базе XML для многих Web -сервисов. Web -сервисы особенно привлекательны тем, что могут обеспечить высокую степень совместимости между различными системами.

Гипотетический Web -сервис, разработанный в соответствии с архитектурой ONE Sun , может принимать форму, в которой реестр сервисов публикует описание Web -сервиса в виде документа .

Огромный потенциал Web -сервисов определяется не технологией, примененной для их создания. HTTP , XML и другие протоколы, используемые Web -сервисами, не новы. Функциональная совместимость и масштабируемость Web -сервисов подразумевает, что разработчики могут быстро создавать большие приложения и более крупные Web -сервисы из меньших Web -сервисов. Спецификация Sun Open Net Environment описывает архитектуру для создания интеллектуальных Web-сервисов .Интеллектуальные Web -сервисы задействуют общее операционное окружение. Совместно используя контекст, интеллектуальные Web -сервисы могут выполнять стандартную аутентификацию для финансовых транзакций, предоставлять рекомендации и указания в зависимости от географического местоположения компаний, участвующих в электронном бизнесе .

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

Взаимосвязь этих технологий условно представлена на рис. 10.1 .

Рис. 10.1.

По сути, Web -сервисы являются одним из вариантов реализации компонентной архитектуры , при которой приложение рассматривается как совокупность компонентов, взаимодействующих друг с другом. Как уже неоднократно говорилось, взаимодействие компонент, выполняющихся на разных платформах, представляет собой достаточно сложную задачу, в частности, требует разработки коммуникационного протокола , учитывающего особенности передачи данных между различными платформами. Одной из основных идей, положенных в основу рассматриваемой технологии Web -сервисов, является отказ от бинарного коммуникационного протокола . Обмен сообщениями между компонентами системы осуществляется посредством передачи XML -сообщений. Поскольку XML -сообщения представляют собой текстовые файлы, транспортный протокол передачи может быть самый различный - XML -сообщения можно передавать по HTTP -, SMTP -, FTP -протоколам, причем использование различных транспортных протоколов прозрачно для приложений. Как уже говорилось, протокол, обеспечивающий возможность взаимодействия Web -сервисов, называется SOAP (Simple Object Access Protocol ). Он определен на основе XML . SOAP обеспечивает взаимодействие распределенных систем, независимо от объектной модели или используемой платформы. Данные в рамках SOAP передаются в виде XML -документов особого формата. SOAP не навязывает какого-либо определенного транспортного протокола. Однако в реальных приложениях наиболее часто реализуется передача SOAP -сообщений по протоколу HTTP . Также широко распространено использование в качестве транспортного протокола SMTP , FTP и даже "чистого" TCP . Итак, SOAP определяет механизм, с помощью которого Web -сервисы могут вызывать функции друг друга. В каком-то смысле работа этого протокола напоминает вызов удаленной процедуры - вызывающая сторона знает имя Web -сервиса, имя его метода, параметры, которые метод принимает, оформляет вызов этого метода в виде SOAP -сообщения и отсылает его Web -сервису.

Однако описанный подход годится лишь в том случае, если заранее известны "сигнатуры" методов, которые реализует Web -сервис. Но как быть, если это не так? Для решения этой проблемы в модель Web -сервиса введен дополнительный слой - слой описания интерфейсов сервисов. Этот слой представлен в виде описания WSDL .

Согласно определению W3C , " WSDL - формат XML для описания сетевых сервисов как набора конечных операций, работающих при помощи сообщений, содержащих документно-ориентированную или процедурно-ориентированную информацию". Документ WSDL полностью описывает интерфейс Web -сервиса с внешним миром. Он предоставляет информацию об услугах, которые можно получить, воспользовавшись методами сервиса, и способах обращения к этим методам. Таким образом, в случае если сигнатура метода Web -сервиса точно не известна (например, она изменилась со временем), у целевого Web -сервиса может быть запрошено WSDL -описание - файл, в котором эта информация будет содержаться.

Следующим слоем технологии является сервис Universal Description, Discovery and Integration (UDDI) .Эта технология предполагает ведение реестра Web -сервисов. Подключившись к этому реестру, потребитель сможет найти Web -сервисы, которые наилучшим образом подходят для решения его задач. Технология UDDI дает возможность поиска и публикации нужного сервиса, причем эти операции могут быть выполнены как человеком, так и другим Web -сервисом или специальной программой-клиентом. UDDI , в свою очередь, также представляет собой Web -сервис.

Таким образом, Web -сервисы являются еще одной реализацией системного программного обеспечения промежуточного слоя . Отличительной чертой этой технологии является ее независимость от используемого программного и аппаратного обеспечения, а также использование широко применяемых открытых стандартов (таких как XML ) и стандартных коммуникационных протоколов.

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

Следует отметить, что с их применением могут строиться и так называемые "стандартные" приложения, где в качестве Web -сервиса оформляется серверная часть.

Простой протокол доступа к объектам (SOAP)

Базовым протоколом, обеспечивающим взаимодействие в среде Web -сервисов, является протокол

Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.

Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим.

Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Веб-сервера Apache также имеется возможность выполнять Веб-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects ).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

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

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений.

В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки ( WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Веб-сайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений , поддерживающим спецификаци ю J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" ( B2C – business-to-consumer). Не менее важными становятся и задачи интеграции Веб-приложений c данными и приложениями партнеров с целью реализации схемы "предприятие-предприятие" ( B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

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

Обобщая вышесказанное можно выделить основные особенности веб-архитектуры [ , ]:

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

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рис. 5.9 .

Рис. 5.9.

5.1.8. Сервис-ориентированная архитектура

Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP . Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс UDDI .

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

(SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами .

OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом ( OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.

В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции.

Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)

Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).

Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются :

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

Принципы SOA:

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

Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.

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

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путем комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определенного платформо-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах.Net и сервисы на Java, работающие на платформах Java EE , могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

, , Терминал , Сервер приложений , Сервер базы данных , Архитектура распределенных систем , , Сервис-ориентированная архитектура .