Лучший Сервер приложений от Microsoft

Рассмотрим разные типы приложений.

Приложение для последовательной обработки

Приложение этого типа однопотоковое. Приложение получает массивы данных  и обрабатывает их одно за другим. BatchProcessing

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

В качестве сервера приложений этого типа работает сама операционная система. Программа запускается либо пользователем, либо по старту операционной системы. Windows service – это один из типов подобного приложения, для него Windows предоставляет дополнительные возможности, такие, как автоматический рестарт в случае ошибки.

Приложение – сервис

Программа-сервис постоянно ожидает запрос от клиента.  Если одновременно поступает много запросов, они ставятся в очередь на обработку. ShortRunningTransactions

Типичный представитель приложений этого класса – веб-сайт. Сервер приложений этого типа – Internet Information Server (IIS). Для каждого пользовательского запроса запускаеся отдельный процессорный поток, который завершается после выдачи результата пользователю. Если в приложении для последовательной обработки всегда работает только одна копия приложения, то здесь работают сразу несколько копий сервиса, по одной на каждый пользовательский запрос.  Обычно приложение не хранит данные клиента. Если по какой-то причине копия сервиса завершает работу с ошибкой и клиент не получает результат, клиент просто повторяет запрос и запускается другая копия сервиса. Данные хранит клиент, а не сервис. Сравним приложение-сервис с приложением для последовательной обработки. Последнее может обрабатывать только одну порцию данных одновременно. Кроме того обработка в нем не изолирована в отдельных копиях, и ошибка в обработке приведет к краху не одной копии, как в приложении-сервисе, а краху всего приложения. Надежная работа приложения-сервиса возможна тогда, когда приложение выполняет свою работу за короткое время. Если это время составляет часы и дни, то многократно возрастает возможность сбоя сервера приложения, соответственно уменьшается надежность тех копий приложения, которые во время краха находятся в памяти.

Приложение – долгоживущий сервис

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

LongRunningTransactions

Другая проблема долгоживущих сервисов – корреляция запросов.

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

В идеале механизм корреляции тоже обеспечивается сервером приложений.

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

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

Таким образом для долгоживущих сервисов возникает необходимость в дополнительных функциях сервера приложений:

  • хранилище данных копий сервисов;
  • системе корреляций запросов;
  • системе мониторинга и удаления «умерших» копий сервисов;
  • системе повтора запросов внишним сервисам

Как оказалось в арсенале Microsoft есть сервер приложений с подобными функциями. Это BizTalk Server.

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

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

Постоянно «измеряется пульс» и производится очистка памяти от «умерших» или завершенных копий сервисов.

Система вывода обеспечивает автоматическое повторение запросов внешним сервисам.

И самое главное качество BizTalk Server в качестве сервера приложений, это его надежность. Запущенные сервисы работают годами без присмотра. Пропадает электричество, «падают» сервера, пропадает сеть, ломаются жесткие диски. Но данные не пропадают. BizTalk автоматически перезапускается, прерванные сотни, тысячи копий сервисов восстанавливаются и продолжают работать как ни в чем ни бывало. Для этого работа в BizTalk Server элементарно распределяется между несколькоими компьютерами, а данные хранятся в SQL кластерах.

Оставьте комментарий

Filed under BizTalk, Integration Architecture, Microsoft

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s