Компания IBM
Опубликован: 10.06.2008 | Доступ: свободный | Студентов: 732 / 55 | Оценка: 4.18 / 4.00 | Длительность: 26:27:00
Специальности: Системный архитектор
Лекция 2:

Понятие очередей сообщений

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >

2.3. Расширяемость и скорость работы

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

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

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

Все перечисленные параметры важно рассматривать вместе, а не каждый из них в отдельности.

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

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

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

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

  • Система будет не в состоянии обработать дополнительные запросы конкретной службы.
  • Скорость обслуживания отдельных запросов службы упадет до неприемлемого значения.
  • Снизится скорость работы прочих, реализуемых данной системой служб.
  • Возникнет фатальный сбой, такой как достижение пределов аппаратных ресурсов. Это вызовет недоступность отдельных служб на протяжении периода времени.Часто такую проблему обозначают как простой, или выход из строя.

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

2.4. Надежность служб и целостность данных

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

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

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

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

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

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

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

2.4.1. Однократная доставка

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

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

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

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

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

Понятие однократной доставки охватывает все эти соображения. Такую доставку гарантирует WebSphere MQ.

2.4.2. Единицы работы

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

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

2.4.3. Обработка ошибок

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

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

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

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

Примечание. Подробнее отказоустойчивость и единые точки отказа мы обсудим в "Понятие очередей сообщений" "Повышенная готовность"

2.4.4. Среда обеспечения контроля качества

Особую роль при разработке и развертывании новой службы в ИТ-системе компании играет ее тестирование. Раннее обнаружение проблемы может серьезно сократить влияние ее возникновения в будущем и снизить объем ресурсов, необходимых для ее устранения.

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

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

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

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

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

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

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >