Лекция посвящена обсуждению следующих вопросов:
В ИТ-инфраструктуре компании может параллельно существовать множество технологий. Зачастую в нее входят различные аппаратные платформы, языки программирования, операционные системы и системы коммуникаций.
На базе этой инфраструктуры организуются службы, каждая из которых обеспечивает возможность выполнения действия или получения информации. Службы могут предоставляться для внутренних нужд компании или использования поставщиками и клиентами предприятия.
Как одно целое, службы и предназначенная для их поддержки инфраструктура образуют систему. Для представления любой точки в такой системе, способной быть местом размещения службы, могущей запрашивать службу или соединять себе подобные воедино, в книге используется общее понятие узел. Узлы могут являться отдельными аппаратными серверами, а могут группами встречаться в программных компонентах одного сервера.
Новые службы способны вводить в систему новые технологии. Однако им зачастую необходимо взаимодействовать со службами, которые уже существуют, используя для этого существующий набор технологий.
К тому же компания может испытывать желание технологически состыковать собственную систему с системами других предприятий или предоставлять внешние интерфейсы к своей системе существующим и потенциальным клиентам или бизнеспартнерам.
Программные приложения, разработанные компанией с целью запроса и предоставления служб, требуют связи со службами, реализуемыми системой. Эти службы находятся в разных ее узлах, а те могут быть созданы с использованием различных инфраструктурных компонентов и технологий.
Технологии промежуточного ПО образуют абстрактный слой между инфраструктурными компонентами и приложениями, стремящимися получить доступ к инфраструктуре для реализации служб. В дальнейшем промежуточное ПО становится частью инфраструктуры, играя в системе роль общего слоя, объединяющего узлы.
Слой промежуточного ПО способен упростить разработку и сопровождение приложений, реализующих сами службы или запросы к ним, что позволяет сосредоточить внимание на бизнес-логике служб, а не на сложностях доступа к имеющимся в системе службам.
Создание очередей сообщений – технология промежуточного ПО, заметно упрощающая коммуникации между узлами одной системы, а также между узлами связи разных систем.
Основу упомянутой технологии образуют два главных понятия: сообщение и очередь.
Входящему в систему узлу нередко требуется передать данные или запросить службу другого узла в той же или связанной с ней системе. Эту порцию информации или запрос можно считать примерами сообщений.
Сообщение может содержать простые данные в формате символов или чисел, сложную двоичную информацию, запрос, команду или смесь всего перечисленного. Важно, чтобы любой целевой узел, принимающий сообщение, "понял" его формат. Однако объединяющая узлы инфраструктура приема и передачи сообщений не требует единого понимания. Она должна лишь гарантировать поддержание целостности информации в сообщении и его правильную доставку по назначению.
Инфраструктура сообщений "понимает" различия между программными и аппаратными составляющими, на которых работает тот или иной узел. Для обеспечения возможности прочитать данные на разных программно-аппаратных платформах может потребоваться перекодирование символьных и числовых данных. Инфраструктуру сообщений можно настроить так, чтобы это перекодирование осуществлялось прозрачным образом и каждое сообщение осталось корректным при его получении.
Для передачи сообщения по назначению к нему может понадобиться добавить дополнительные данные, сопровождающие его при пересылке в инфраструктуре. Заметим, что эти данные отделены от информации, содержащейся в сообщении, так же, как конверт существует независимо от письма, которое в него вложено.
Очередь – это контейнер для сообщений. Новые сообщения помещаются в конец очереди, а размещенные в ней, как правило, извлекаются из начала. Движение сообщений в пределах очереди показано на рис 2.1.
(рис 2.1) Очередь и прохождение сообщенийТакже для извлечения сообщений могут использоваться идентификаторы, которые с ними связаны. Сообщениям можно назначить приоритет, чтобы сообщения с высоким приоритетом извлекались из очереди быстрее сообщений с низким приоритетом, или логически сгруппировать так, чтобы одно из них зависело от другого.
Однако очереди не призваны стать заменой баз данных. Они оптимизированы для небольшого количества сообщений, проходящих их до своей доставки по назначению.
Эта простая, но действенная идея лежит в основе надежной и расширяемой инфраструктуры приема и передачи сообщений – инфраструктуры очередей сообщений. Понятие очереди используется в инфраструктуре очередей сообщений, в том числе, для решения следующих задач.
Служба, которая получает, потребляет и обрабатывает сообщения, может быть не готова обрабатывать каждое сообщение в момент его поступления, поскольку может быть занята обработкой другого сообщения или недоступна по какой-то иной причине. В то же время сообщения не могут поступать с одинаковой интенсивностью или не поступать в периоды занятости; спрос на работу службы может временно превышать ее возможности по обслуживанию. При наличии очереди между
Подобный режим работы называется асинхронным взаимодействием, так как источник может продолжить свою работу, как только сообщение будет помещено в очередь. Сравните его с синхронным взаимодействием, при котором он должен ожидать готовности получателя и полного завершения работы над сообщением для того, чтобы продолжить свою работу.
Служба может быть не настроена на обработку и потребление каждого сообщения при получении, а будет, напротив, ждать достижения некоего порога сообщений в конкретной очереди, чтобы обработать их как единый пакет или выполнить обработку всех сообщений, полученных в определенный период времени. Это позволит службе воспользоваться эффективностью масштаба обработки, а возможно, и обработать данные в тот период, когда другие связанные системы и службы не функционируют.
При движении от отправителей к получателям сообщениям может требоваться пройти промежуточные узлы системы. Количество узлов, которые пройдет сообщение, а также место расположения пункта назначения сообщения может быть неизвестно стороне отправления или оказаться изменено. Сетевые соединения между промежуточными узлами или сами промежуточные узлы иногда могут быть недоступны. Поместив очередь как буфер между всеми узлами системы, можно ставить сообщения на ожидание в любой точке, где они останутся до тех пор, пока узел или сетевое соединение не станет снова доступным, после чего сообщение автоматически перейдет к следующему узлу.
Многие сообщения предназначены для потребления лишь однажды. Точка внутри системы, где сообщение будет использовано, может быть как известна, так и неизвестна для отправителя. Однако сам отправитель обеспечивает инфраструктуру сообщений достаточной информацией для того, чтобы доставить сообщение только одному потребителю.
В режиме межточечного обмена сообщение приходит один и только один раз в единственное корректное место своего назначения.
Процесс межточечного обмена можно представить двумя общими категориями.
Сообщение передается службе, выполняющей действие на базе этого сообщения. При его обработке служба может сформировать новое сообщение, но источник запроса не получает никаких явных свидетельств происходящего.
Иллюстрацией этого может быть сообщение с обновлением информации в базе данных или сообщение с подробностями события, факт наступления которого требует тех или иных действий, к примеру отправки сообщений системным администраторам.
Сообщение передается службе, выполняющей действие на базе этого сообщения и посылающей ответ для его отправителя.
Пример подобной работы – запрос информации в базе данных и посылаемый как реакция на него ответ или сообщение-запрос с подробным описанием действия, которое требует выполнения и может иметь несколько результатов, – исход такого события отсылается как ответ.
В процессе межточечного обмена каждый узел, которому нужна информация, должен знать те конкретные службы, которые могут ему ее предоставить. Аналогично и службы, передающие информацию, должны знать о тех конкретных узлах, которым передают свои данные, и времени, когда это сделать.
Предоставляемые инфраструктурой очередей сообщений в рамках модели межточечного обмена функции "отправил – забыл" и "запрос – ответ" служат решением при множестве обстоятельств. Однако в отношении данных, перечисленных ниже, модель межточечного обмена имеет ограничения.
Со временем какая-то информация может меняться, и обращающийся к ней узел системы может быть вынужден отслеживать ее изменения. При этом узлу должна быть предоставлена информация при запуске обработки, после чего его необходимо уведомлять о любых происходящих с ней изменениях.
Информация такого рода называется состоянием. Примером состояния служит текущая цена акций компании, имеющая значение в любой момент времени, но также могущая в любой момент измениться; узлу же, возможно, требуется отслеживать рыночные
Для поддержания актуальности данных об изменениях информации по принципу "запрос – ответ" узел должен посылать службе периодические запросы текущего состояния информации. Для этого он должен знать об узлах, где расположена служба предоставления информации. Такой подход называют опросом.
Опрос службы – неэффективный способ получения уведомлений об изменениях состояния. Большое число запросов может вернуть одно и то же значение, а посылающий запрос узел не получает информации об изменениях до отправки следующего запроса. Меньшие интервалы опроса могут повысить точность известной узлу информации, но повышают и требования к ресурсам службы и инфраструктуре системы.
Ряд действий должен производиться службой при наступлении того или иного события.
Информация с описанием события, которое наступило, называется информацией о событии. Например, при каждой продаже товара, находящегося на складе, служба управления складом может требовать обновления складской информации или отправки дополнительного заказа товара поставщику.
Возможности межточечного обмена позволяют отправлять службам сообщения о единичных событиях, когда они происходят. Однако каждый узел, который обнаруживает события или является их источником, должен знать обо всех узлах, где расположены службы, которым требуются такие события, и отправлять каждой из этих служб сообщение по очереди.
Модель публикации и подписки снимает эти ограничения.
В ней сообщения от одного или нескольких отправителей может получать произвольное число потребителей информации. При этом отправитель носит название издателя, а потребитель обозначается как подписчик.
Обмен по принципу публикации-подписки включает понятие темы, на которую, демонстрируя интерес, может подписаться любое количество потребителей информации. Такое положение дел аналогично тому, как если бы кто-то подписался лишь на журналы по интересным для него темам. Каждая тема предоставляет информацию о конкретном состоянии или событии.
Издатель может посылать сообщения с информацией по той или иной теме всем подписчикам этой темы, не зная, сколько таких подписчиков и на каких конкретно узлах они расположены. По этой причине обмен по принципу публикации-подписки полностью разрывает связь между поставщиком и потребителем информации.
Нуждаясь в информации о состоянии, подписчик может запросить текущее состояние информации при запуске обработки, а подписавшись на тему интересующей информации, он будет автоматически уведомляться об изменениях.
Нуждаясь в информации о событии, подписчик будет автоматически уведомляться о происходящих событиях, если подпишется на тему событий, представляющих для него интерес.
Для упрощения работы публикации и подписки необходим брокер, хранящий сведения о том, какие подписчики на какие темы подписаны и как им доставляются сообщения. Используя брокер, издатель может публиковать сообщения для всех подписчиков, не зная подробно, что они собой представляют.
По одной теме может иметься несколько издателей; подписчик по одной теме может являться источником публикуемых сведений по другим.
Модель обмена по принципу публикации-подписки является действенным механизмом, дающим возможность организации логического потока обновляемой информации от источников информации до всех ее потребителей. Гибкость такого решения обусловлена тем, что число подписчиков может динамически расти или падать без уведомления издателей.
Процесс передачи сообщения от источника к получателю может быть сложным и включать в себя пересылку через многочисленные промежуточные узлы и линии связи, различные по типу, скорости, качеству. Иногда в линиях связи наблюдается сбой, и сообщение не может достичь места своего назначения до восстановления соединения. К тому же во время генерации сообщения узел, которому оно отправляется, или промежуточный узел может оказаться недоступен либо быть занят.
Важной особенностью инфраструктуры очередей сообщений является то, что ресурсы разработки приложений, необходимые для решения этих проблем, как и другие ресурсы, описанные далее в книге, серьезно сокращены.
При пользовании инфраструктурой очередей сообщений для надежной отправки сообщения получателю необходимы следующие шаги.
Разработка бизнес-приложений, реализующих службы или запросы к ним, может оказаться дорогостоящим процессом, требующим значительного объема ресурсов. Инфраструктура очередей сообщений позволяет прикладным программистам больше времени уделить бизнес-логике реализации службы, а не проблемам коммуникации и непростому обслуживанию возникающих сбоев.
В отсутствие безопасной, гибкой и надежной инфраструктуры очередей сообщений прикладной программист вынужден заниматься дополнительной разработкой, решая следующие проблемы.
Другое важное обстоятельство состоит в том, насколько просто поддерживать приложения и взаимодействовать с ними после их первоначального написания. Разработавшие приложение программист или команда специалистов могут быть недоступны в то время, когда в продукт требуется внести изменения. Предъявляемые к приложению требования могут со временем расширяться, а доступ к существующим службам может понадобиться другим узлам, находящимся вне системы или внутри нее. Новые узлы могут содержать особые программные и аппаратные компоненты или оказаться подключены по другим каналам коммуникации.
Снизив объем задач интеграции, требующих решения при создании приложения, и заострив внимание при разработке на бизнес-логике, можно придать коду продукта структуру, более простую в сопровождении будущими разработчиками, которым понадобится внести в продукт изменения.
Программное обеспечение, расположенное между приложениями и базовыми инфраструктурными компонентами, с которыми приложения взаимодействуют, называется промежуточным. Промежуточное ПО способно обеспечить функциональность, нехарактерную для отдельного языка программирования, конкретной аппаратной платформы или операционной системы. Своего рода промежуточное ПО представляет собой и реализующая
Используя промежуточный слой, можно перенести код приложения на узлы с разными базовыми инфраструктурными компонентами или расширить его перечисленными узлами. Усилия по разработке продукта и в первом, и во втором случае значительно сократятся.
Процесс модификации приложения для выполнения на узле с новыми базовыми инфраструктурными компонентами именуется переносом, простота переноса приложения на другие компоненты инфраструктуры носит название переносимости.
Доступ к существующим службам, не использующим промежуточный слой, зачастую можно гибко расширить реализацией прокси, предоставляющего интерфейс между промежуточным слоем и существующей службой. В перспективе новые приложения будут обращаться к такой службе через промежуточный слой, используя прокси, а не путем доступа напрямую.
Планируя, проектируя, разрабатывая и предоставляя службу в ИТ-системе компании, важно учитывать, отвечает ли служба предъявляемым требованиям и способна ли она развиваться так, чтобы соответствовать им в дальнейшем.
Приведенный далее перечень описывает в целом употребление в этой книге набора терминов, применяемых в отношении служб в ИТ-системах организаций.
Все перечисленные параметры важно рассматривать вместе, а не каждый из них в отдельности.
Изначально предоставляемые службе ресурсы призваны гарантировать, что скорость ее работы и пропускная способность приемлемы при нагрузках ожидаемого объема. Оценивая исходные требования к ресурсам, необходимо учесть надежность и безопасность служб, поскольку технологии повышения безопасности и надежности могут неблагоприятно сказаться на скорости их работы.
В то же время, анализируя начальную производительность и пропускную способность, важно оценить и расширяемость службы. Служба, которая хорошо масштабируется, позволяет включать в систему дополнительные ресурсы для того, чтобы оперативно повысить пропускную способность и справиться с увеличившейся нагрузкой без негативного влияния на скорость своей работы. Если расширяемость службы не учитывать изначально, рост пропускной способности может потребовать значительного объема модификаций службы либо отрицательно повлиять на производительность таковой.
Другой важный аспект – работа системы в целом в период, когда нагрузка на ту или иную службу превысит пропускную способность. Зачастую это недолговременное явление, возникающее при пиковых обращениях. Кроме того, оно может постепенно или внезапно возникать с ростом спроса на конкретную службу, указывая на то, что требуется расширить пропускную способность. Если этого не учесть, то отрицательные последствия пренебрежения таким шагом могут образовать следующий возможный "букет".
Масштабируемость и скорость работы инфраструктуры очередей сообщений вкупе с умелым проектированием и грамотным планом могут придать системе реальную расширяемость. При этом ресурсы могут выделяться и освобождаться по мере надобности с учетом требований к пропускной способности и производительности системы в условиях меняющейся нагрузки на информационную среду предприятия.
Данные, передаваемые в инфраструктуре очередей сообщений, в общих чертах можно разделить на две категории.
Примером сказанного является запрос текущего состояния заказа; если запрос данных утерян либо на него не получен отклик, это не повлияет на текущее состояние заказа, и запрос можно повторить еще раз.
Примером этого является сообщение об оплате заказа; если сообщение с подтверждением платежа будет утеряно, статус заказа может стать некорректным. Возможно, клиент внес деньги в его оплату либо ему отправлена расписка в их получении, но состояние заказа внутри системы не отражает ни того, ни другого.
Критичную для бизнеса информацию содержит большинство сообщений, передаваемых в инфраструктуре очередей. По этой причине важно, чтобы инфраструктура предоставляла гарантии защиты подобных сообщений от их потери.
С обеспечением таких гарантий связан ряд обстоятельств, касающихся производительности, а потому сообщения с данными-ответами на запрос могут маркироваться как таковые для повышения скорости их прохождения в инфраструктуре.
Помимо защиты сообщений с критичной для бизнеса информацией от потери в инфраструктуре очередей важно, чтобы сообщения достигали заданного места своего назначения, а доставка происходила исключительно однократно.
Если сообщение было отправлено по допустимому в данной системе адресу, инфраструктура очередей сообщений обязана гарантировать, что сообщение будет доставлено получателю. Однако пункт назначения или промежуточные узлы могут быть недоступны на протяжении какого-то периода времени. В этом случае сообщения остаются в системе в состоянии ожидания, пока не смогут продолжить свое движение по назначению.
Поскольку отправитель запроса данных не может ожидать отклик сколь угодно долгое время, то к информации, получаемой по запросу, могут предъявляться иные требования. В итоге сообщения в инфраструктуре могут помечаться как устаревшие, если в произвольном узле системы они останутся дольше заданного временного периода.
Если сообщение достигает места назначения дважды, то результат этого может оказаться непредсказуемым. К примеру, двукратное получение сообщения с подтверждением платежа может создать видимость того, что клиент переплатил за услугу. Инфраструктура очередей сообщений должна предоставлять гарантии того, что единичное сообщение не может быть неожиданно доставлено по назначению дважды или оказаться в нескольких пунктах назначения одновременно.
Если сообщение нельзя доставить по назначению, работа системы должна быть четко описана для того, чтобы найти и вручную маршрутизировать сообщение. Невозможность доставки может быть обусловлена изменениями в инфраструктуре и переносом адреса назначения либо некорректной спецификацией назначения
Понятие однократной доставки охватывает все эти соображения. Такую доставку гарантирует
Далеко не всегда действия приложений можно воспринимать изолированно. Например, служба может прочитать сообщение, обновить данные о клиенте, а в завершение послать ответ. Каждое из трех действий самостоятельно, но при ошибке в любом из них ни одно действие выполнено быть не должно.
О таких действиях говорят, что они входят в единицу работы. Единицы работы включают отправку и получение сообщений, а также обновление информационных баз данных. Инфраструктура очередей сообщений должна поддерживать завершение или откат действий единицы работы в целом, дабы ни одно действие в ней не могло выполниться без выполнения остальных. Также возможность инициировать откат единицы работы в любой момент времени должно иметь само приложение.
Сбои в ИТ-системе компании могут происходить без каких-либо предупреждений и должны обрабатываться так, чтобы не приводить систему в противоречивое состояние. К примерам подобных сбоев относятся:
При построении ИТ-системы компании такие сбои необходимо учитывать и обеспечивать их согласованную и толерантную обработку. Элементы инфраструктуры очередей сообщений упрощают данный процесс, реализуя отказоустойчивую инфраструктуру работы служб и значительно снижая объем требуемой для выявления и обработки сбоев такого рода прикладной логики.
Дополнительно эти возможности способны помочь избежать сбоев, которые могут привести к отказу всей системы, позволяя службам оставаться доступными даже при появлении таковых.
Особую роль при разработке и развертывании новой службы в ИТ-системе компании играет ее тестирование. Раннее обнаружение проблемы может серьезно сократить влияние ее возникновения в будущем и снизить объем ресурсов, необходимых для ее устранения.
Рекомендуемая методика создания, тестирования и внедрения приложений предполагает наличие двух независимых сред.
В простой системе обе среды могут пользоваться одной и той же программно-аппаратной инфраструктурой. Однако полное разграничение этих сред может дать дополнительные преимущества и сократить возможность изменений в контролирующей среде, отрицательно влияющих на доступность служб производственной среды фирмы.
Характер и интенсивность загрузки служб, которые моделирует среда обеспечения контроля качества, должны предельно соответствовать аналогам из производственной среды предприятия. Чем меньше наблюдаемые различия, тем вероятнее обнаружение возможных проблем в контролирующей среде до их появления в производственной.
Если проблема наблюдается и допускает воспроизведение в контролирующей среде, в ней можно разработать и протестировать предлагаемое решение. Его создание может оказаться разрушительной процедурой и требовать осуществления шагов, нерекомендуемых к выполнению в производственной среде без предварительного тестирования. В контролирующей среде подобные изменения можно осуществить, описать и проверить, не влияя на производственную среду.
Элементом сопровождения программных компонентов системы является регулярная профилактика. Выполняя профилактические работы в контролирующей среде до повторения их в условиях производственной среды, вы значительно снизите вероятность неожиданного влияния операций сопровождения на доступность программных служб.
Немаловажным в ИТ-системе компании является тщательное изучение проблем безопасности и защиты. Доступ к службам и информации в рамках такой системы должен быть под контролем, а целостность передаваемых по сетям общего пользования закрытых и
Нередко важно гарантировать, что службы в ИТ-системе компании доступны только авторизованным сторонам – людям и приложениям.
Применение службы без авторизации или по злому умыслу может вызвать повреждение данных, которые хранятся в системе, или сделать конфиденциальную информацию доступной более широкой аудитории, чем это предполагалось правами доступа.
В целом
Инфраструктура очередей сообщений должна включать функции надежного распознавания сущности, пытающейся получить доступ к конкретной службе, а также правила выработки решений о том, располагает данная сущность правом обращения к службе или же нет.
Это может оказаться особенно важным при наличии служб, открытых внешним субъектам, – поставщикам фирмы или ее клиентам. В данном случае инфраструктура очередей должна иметь надежную и безопасную процедуру выдачи прав доступа к службам для внешних контрагентов.
Входящие в систему узлы могут быть связаны различными каналами связи, предназначенными для общего пользования или не имеющими защиты. Во избежание внешнего вмешательства в посылку и получение данных такие каналы связи надлежит защищать.
Технологии защиты каналов связи обеспечивают защиту от чтения или модификации секретных данных третьими сторонами. Также они защищают и от попыток имитации сущности, имеющей права доступа к службам внутри системы.
Внешнее вмешательство в систему по незащищенным каналам связи может вызвать нарушение целостного характера данных либо привести к недоступности служб.
На службы, реализуемые ИТ-системой компании, можно положиться в повседневной работе фирмы. Простои, при которых конкретная служба или их группа становится недоступной, могут отразиться на деятельности компании, в результате чего ею будут понесены убытки.
В широком смысле простои делятся на две категории.
Цель обеспечения высокой готовности служб – минимизация плановых и внеплановых простоев инфраструктуры. Этого можно добиться несколькими путями, включая следующие:
Надежность системы зависит от надежности всех ее компонентов, включая программные и аппаратные компоненты инфраструктуры, линии связи и приложения, реализующие функции служб. Заметный вклад в надежность системы в целом вносит использование стабильной и надежной инфраструктуры очередей сообщений с простыми интерфейсами для минимизации сложности ее служб.
Обновление и сопровождение компонентов, по возможности осуществляемое без перевода служб в недоступное состояние, позволяет сократить плановые простои. Первоначальное обновление контролирующей, а не производственной среды снижает вероятность изменений в поведении рабочего окружения, влекущих внеплановый останов.
Если система допускает эффективное, то есть автоматическое, восстановление после сбоя без потери целостности информации, последствия и продолжительность такого внепланового простоя будут гораздо меньше.
Если в компоненте системы наблюдается сбой, он может повлиять на систему и службы, которые ею предоставляются. В контексте очередей сообщений это воздействие можно разбить на следующие подгруппы:
Если в компоненте системы произойдет сбой, он повлияет на все зависимые от него компоненты. Те, в свою очередь, могут повлиять на другие, в конечном же итоге затронутыми могут оказаться одна или несколько служб системы.
Если в системе есть лишь один экземпляр службы либо все экземпляры конкретной службы зависят от конкретного компонента, то возникает единая точка отказа внутри системы.
Организуя в системе множество экземпляров службы, способных действовать независимо, можно обеспечить доступность службы для новых запросов даже после отказа нескольких экземпляров.
В контексте очередей сообщений это требует, чтобы новые сообщения, которые помещаются в очереди на отказавших узлах или проходящие через них, направлялись на другие узлы системы.
Прежде чем достичь пункта своего назначения, сообщение может пройти в системе вереницу узлов, а оказавшись на месте, оставаться там какое-то время, прежде чем служба начнет его обработку. Впрочем, и самой службе между потреблением сообщения и успешным окончанием всех действий над ним также необходимо определенное время.
Если компонент системы дал сбой, узлы, в которых размещены очереди и службы, могут, как следствие, тоже утратить функциональность. Это может произойти мгновенно, не оставляя инфраструктуре и приложениям времени на реакцию, как, например, в случае отказа аппаратуры. Пока узел продолжает быть недоступным, все сообщения в очередях в этом узле тоже продолжают быть недоступными. Такие сообщения называют "застрявшими" (stranded messages).
Если подобное сообщение содержит критичные для бизнеса данные, становится важным его надежно восстановить. Восстановление "застрявших" сообщений должно поддерживать целостность хранимой в них информации.
Корректно должна быть разрешена и ситуация с каждой выполнявшейся в момент сбоя единицей работы. Так, служба могла начать обрабатывать сообщение, но не успеть закончить его обслуживание.
Восстановление сообщений с критичными для бизнеса данными может осуществляться в жестких временных рамках, возврат к работе затронутых неисправимой ошибкой ресурсов – требовать времени и ручного вмешательства. В итоге для восстановления доступности сообщений на незатронутых сбоем ресурсах может потребоваться произвести ряд ручных или автоматических операций.
Отдельные катастрофические повреждения могут затронуть все ресурсы какого-либо узла, а возможно, и группы связанных друг с другом и находящихся на единой физической площадке узлов. Возврат к работе служб после подобных сбоев или восстановление данных на поврежденных узлах требует тщательного планирования и предварительной подготовки.
Компания может планомерно готовиться к такого рода проблемам, периодически снимая резервные копии данных в узлах системы, содержащих критичную для ведения бизнеса информацию. Используя стратегии резервирования, восстановить данные в полностью актуальном их состоянии на поврежденном узле (узлах) возможно далеко не всегда. Однако соблюдение таких стратегий может существенно сократить количество данных, утраченных при разрушительном останове.
Сведения о работе и использовании системы имеют важное практическое значение. Они могут стать показателем качества функционирования системы, индикатором производительности и пропускной способности при разных нагрузках, а также дать возможность отслеживать работу отдельных сущностей.
Мониторинг производительности в контексте инфраструктуры очередей сообщений включает замер количества и продолжительности тех действий, которые осуществляются при обращении служб к очередям сообщений или при движении сообщений сквозь очереди и промежуточные узлы. Результаты замеров могут служить для оценки производительности и пропускной способности служб, а также инфраструктуры, которая их поддерживает.
Такие данные могут оказаться полезны при наделении служб ресурсами или принятии решения о наращивании ресурсов для расширения пропускной способности службы. Кроме того, мониторинг производительности может принести пользу при выявлении любых внезапных или постепенных изменений в характере нагрузки системы с целью предупреждения проблем до их реального появления.
Учет в контексте очередей сообщений включает накопление информации об использовании отдельных очередей конкретными сущностями, которыми могут быть приложение, реализующее службу на основе данной очереди, внешний или внутренний пользователь.
Собранная при учете статистика позволяет установить и провести анализ характера использования системы и, к примеру, удостовериться, что качество обслуживания конкретной сущности соответствует ожиданиям. Другое применение таких данных – организация функции выставления счетов на оплату с учетом использования конкретной службы конкретной сущностью.
Лекция посвящена обсуждению следующих вопросов:
В ИТ-инфраструктуре компании может параллельно существовать множество технологий. Зачастую в нее входят различные аппаратные платформы, языки программирования, операционные системы и системы коммуникаций.
На базе этой инфраструктуры организуются службы, каждая из которых обеспечивает возможность выполнения действия или получения информации. Службы могут предоставляться для внутренних нужд компании или использования поставщиками и клиентами предприятия.
Как одно целое, службы и предназначенная для их поддержки инфраструктура образуют систему. Для представления любой точки в такой системе, способной быть местом размещения службы, могущей запрашивать службу или соединять себе подобные воедино, в книге используется общее понятие узел. Узлы могут являться отдельными аппаратными серверами, а могут группами встречаться в программных компонентах одного сервера.
Новые службы способны вводить в систему новые технологии. Однако им зачастую необходимо взаимодействовать со службами, которые уже существуют, используя для этого существующий набор технологий.
К тому же компания может испытывать желание технологически состыковать собственную систему с системами других предприятий или предоставлять внешние интерфейсы к своей системе существующим и потенциальным клиентам или бизнеспартнерам.
Программные приложения, разработанные компанией с целью запроса и предоставления служб, требуют связи со службами, реализуемыми системой. Эти службы находятся в разных ее узлах, а те могут быть созданы с использованием различных инфраструктурных компонентов и технологий.
Технологии промежуточного ПО образуют абстрактный слой между инфраструктурными компонентами и приложениями, стремящимися получить доступ к инфраструктуре для реализации служб. В дальнейшем промежуточное ПО становится частью инфраструктуры, играя в системе роль общего слоя, объединяющего узлы.
Слой промежуточного ПО способен упростить разработку и сопровождение приложений, реализующих сами службы или запросы к ним, что позволяет сосредоточить внимание на бизнес-логике служб, а не на сложностях доступа к имеющимся в системе службам.
Создание очередей сообщений – технология промежуточного ПО, заметно упрощающая коммуникации между узлами одной системы, а также между узлами связи разных систем.
Основу упомянутой технологии образуют два главных понятия: сообщение и очередь.
Входящему в систему узлу нередко требуется передать данные или запросить службу другого узла в той же или связанной с ней системе. Эту порцию информации или запрос можно считать примерами сообщений.
Сообщение может содержать простые данные в формате символов или чисел, сложную двоичную информацию, запрос, команду или смесь всего перечисленного. Важно, чтобы любой целевой узел, принимающий сообщение, "понял" его формат. Однако объединяющая узлы инфраструктура приема и передачи сообщений не требует единого понимания. Она должна лишь гарантировать поддержание целостности информации в сообщении и его правильную доставку по назначению.
Инфраструктура сообщений "понимает" различия между программными и аппаратными составляющими, на которых работает тот или иной узел. Для обеспечения возможности прочитать данные на разных программно-аппаратных платформах может потребоваться перекодирование символьных и числовых данных. Инфраструктуру сообщений можно настроить так, чтобы это перекодирование осуществлялось прозрачным образом и каждое сообщение осталось корректным при его получении.
Для передачи сообщения по назначению к нему может понадобиться добавить дополнительные данные, сопровождающие его при пересылке в инфраструктуре. Заметим, что эти данные отделены от информации, содержащейся в сообщении, так же, как конверт существует независимо от письма, которое в него вложено.
Очередь – это контейнер для сообщений. Новые сообщения помещаются в конец очереди, а размещенные в ней, как правило, извлекаются из начала. Движение сообщений в пределах очереди показано на рис 2.1.
(рис 2.1) Очередь и прохождение сообщенийТакже для извлечения сообщений могут использоваться идентификаторы, которые с ними связаны. Сообщениям можно назначить приоритет, чтобы сообщения с высоким приоритетом извлекались из очереди быстрее сообщений с низким приоритетом, или логически сгруппировать так, чтобы одно из них зависело от другого.
Однако очереди не призваны стать заменой баз данных. Они оптимизированы для небольшого количества сообщений, проходящих их до своей доставки по назначению.
Эта простая, но действенная идея лежит в основе надежной и расширяемой инфраструктуры приема и передачи сообщений – инфраструктуры очередей сообщений. Понятие очереди используется в инфраструктуре очередей сообщений, в том числе, для решения следующих задач.
Служба, которая получает, потребляет и обрабатывает сообщения, может быть не готова обрабатывать каждое сообщение в момент его поступления, поскольку может быть занята обработкой другого сообщения или недоступна по какой-то иной причине. В то же время сообщения не могут поступать с одинаковой интенсивностью или не поступать в периоды занятости; спрос на работу службы может временно превышать ее возможности по обслуживанию. При наличии очереди между
Подобный режим работы называется асинхронным взаимодействием, так как источник может продолжить свою работу, как только сообщение будет помещено в очередь. Сравните его с синхронным взаимодействием, при котором он должен ожидать готовности получателя и полного завершения работы над сообщением для того, чтобы продолжить свою работу.
Служба может быть не настроена на обработку и потребление каждого сообщения при получении, а будет, напротив, ждать достижения некоего порога сообщений в конкретной очереди, чтобы обработать их как единый пакет или выполнить обработку всех сообщений, полученных в определенный период времени. Это позволит службе воспользоваться эффективностью масштаба обработки, а возможно, и обработать данные в тот период, когда другие связанные системы и службы не функционируют.
При движении от отправителей к получателям сообщениям может требоваться пройти промежуточные узлы системы. Количество узлов, которые пройдет сообщение, а также место расположения пункта назначения сообщения может быть неизвестно стороне отправления или оказаться изменено. Сетевые соединения между промежуточными узлами или сами промежуточные узлы иногда могут быть недоступны. Поместив очередь как буфер между всеми узлами системы, можно ставить сообщения на ожидание в любой точке, где они останутся до тех пор, пока узел или сетевое соединение не станет снова доступным, после чего сообщение автоматически перейдет к следующему узлу.
Многие сообщения предназначены для потребления лишь однажды. Точка внутри системы, где сообщение будет использовано, может быть как известна, так и неизвестна для отправителя. Однако сам отправитель обеспечивает инфраструктуру сообщений достаточной информацией для того, чтобы доставить сообщение только одному потребителю.
В режиме межточечного обмена сообщение приходит один и только один раз в единственное корректное место своего назначения.
Процесс межточечного обмена можно представить двумя общими категориями.
Сообщение передается службе, выполняющей действие на базе этого сообщения. При его обработке служба может сформировать новое сообщение, но источник запроса не получает никаких явных свидетельств происходящего.
Иллюстрацией этого может быть сообщение с обновлением информации в базе данных или сообщение с подробностями события, факт наступления которого требует тех или иных действий, к примеру отправки сообщений системным администраторам.
Сообщение передается службе, выполняющей действие на базе этого сообщения и посылающей ответ для его отправителя.
Пример подобной работы – запрос информации в базе данных и посылаемый как реакция на него ответ или сообщение-запрос с подробным описанием действия, которое требует выполнения и может иметь несколько результатов, – исход такого события отсылается как ответ.
В процессе межточечного обмена каждый узел, которому нужна информация, должен знать те конкретные службы, которые могут ему ее предоставить. Аналогично и службы, передающие информацию, должны знать о тех конкретных узлах, которым передают свои данные, и времени, когда это сделать.
Предоставляемые инфраструктурой очередей сообщений в рамках модели межточечного обмена функции "отправил – забыл" и "запрос – ответ" служат решением при множестве обстоятельств. Однако в отношении данных, перечисленных ниже, модель межточечного обмена имеет ограничения.
Со временем какая-то информация может меняться, и обращающийся к ней узел системы может быть вынужден отслеживать ее изменения. При этом узлу должна быть предоставлена информация при запуске обработки, после чего его необходимо уведомлять о любых происходящих с ней изменениях.
Информация такого рода называется состоянием. Примером состояния служит текущая цена акций компании, имеющая значение в любой момент времени, но также могущая в любой момент измениться; узлу же, возможно, требуется отслеживать рыночные
Для поддержания актуальности данных об изменениях информации по принципу "запрос – ответ" узел должен посылать службе периодические запросы текущего состояния информации. Для этого он должен знать об узлах, где расположена служба предоставления информации. Такой подход называют опросом.
Опрос службы – неэффективный способ получения уведомлений об изменениях состояния. Большое число запросов может вернуть одно и то же значение, а посылающий запрос узел не получает информации об изменениях до отправки следующего запроса. Меньшие интервалы опроса могут повысить точность известной узлу информации, но повышают и требования к ресурсам службы и инфраструктуре системы.
Ряд действий должен производиться службой при наступлении того или иного события.
Информация с описанием события, которое наступило, называется информацией о событии. Например, при каждой продаже товара, находящегося на складе, служба управления складом может требовать обновления складской информации или отправки дополнительного заказа товара поставщику.
Возможности межточечного обмена позволяют отправлять службам сообщения о единичных событиях, когда они происходят. Однако каждый узел, который обнаруживает события или является их источником, должен знать обо всех узлах, где расположены службы, которым требуются такие события, и отправлять каждой из этих служб сообщение по очереди.
Модель публикации и подписки снимает эти ограничения.
В ней сообщения от одного или нескольких отправителей может получать произвольное число потребителей информации. При этом отправитель носит название издателя, а потребитель обозначается как подписчик.
Обмен по принципу публикации-подписки включает понятие темы, на которую, демонстрируя интерес, может подписаться любое количество потребителей информации. Такое положение дел аналогично тому, как если бы кто-то подписался лишь на журналы по интересным для него темам. Каждая тема предоставляет информацию о конкретном состоянии или событии.
Издатель может посылать сообщения с информацией по той или иной теме всем подписчикам этой темы, не зная, сколько таких подписчиков и на каких конкретно узлах они расположены. По этой причине обмен по принципу публикации-подписки полностью разрывает связь между поставщиком и потребителем информации.
Нуждаясь в информации о состоянии, подписчик может запросить текущее состояние информации при запуске обработки, а подписавшись на тему интересующей информации, он будет автоматически уведомляться об изменениях.
Нуждаясь в информации о событии, подписчик будет автоматически уведомляться о происходящих событиях, если подпишется на тему событий, представляющих для него интерес.
Для упрощения работы публикации и подписки необходим брокер, хранящий сведения о том, какие подписчики на какие темы подписаны и как им доставляются сообщения. Используя брокер, издатель может публиковать сообщения для всех подписчиков, не зная подробно, что они собой представляют.
По одной теме может иметься несколько издателей; подписчик по одной теме может являться источником публикуемых сведений по другим.
Модель обмена по принципу публикации-подписки является действенным механизмом, дающим возможность организации логического потока обновляемой информации от источников информации до всех ее потребителей. Гибкость такого решения обусловлена тем, что число подписчиков может динамически расти или падать без уведомления издателей.
Процесс передачи сообщения от источника к получателю может быть сложным и включать в себя пересылку через многочисленные промежуточные узлы и линии связи, различные по типу, скорости, качеству. Иногда в линиях связи наблюдается сбой, и сообщение не может достичь места своего назначения до восстановления соединения. К тому же во время генерации сообщения узел, которому оно отправляется, или промежуточный узел может оказаться недоступен либо быть занят.
Важной особенностью инфраструктуры очередей сообщений является то, что ресурсы разработки приложений, необходимые для решения этих проблем, как и другие ресурсы, описанные далее в книге, серьезно сокращены.
При пользовании инфраструктурой очередей сообщений для надежной отправки сообщения получателю необходимы следующие шаги.
Разработка бизнес-приложений, реализующих службы или запросы к ним, может оказаться дорогостоящим процессом, требующим значительного объема ресурсов. Инфраструктура очередей сообщений позволяет прикладным программистам больше времени уделить бизнес-логике реализации службы, а не проблемам коммуникации и непростому обслуживанию возникающих сбоев.
В отсутствие безопасной, гибкой и надежной инфраструктуры очередей сообщений прикладной программист вынужден заниматься дополнительной разработкой, решая следующие проблемы.
Другое важное обстоятельство состоит в том, насколько просто поддерживать приложения и взаимодействовать с ними после их первоначального написания. Разработавшие приложение программист или команда специалистов могут быть недоступны в то время, когда в продукт требуется внести изменения. Предъявляемые к приложению требования могут со временем расширяться, а доступ к существующим службам может понадобиться другим узлам, находящимся вне системы или внутри нее. Новые узлы могут содержать особые программные и аппаратные компоненты или оказаться подключены по другим каналам коммуникации.
Снизив объем задач интеграции, требующих решения при создании приложения, и заострив внимание при разработке на бизнес-логике, можно придать коду продукта структуру, более простую в сопровождении будущими разработчиками, которым понадобится внести в продукт изменения.
Программное обеспечение, расположенное между приложениями и базовыми инфраструктурными компонентами, с которыми приложения взаимодействуют, называется промежуточным. Промежуточное ПО способно обеспечить функциональность, нехарактерную для отдельного языка программирования, конкретной аппаратной платформы или операционной системы. Своего рода промежуточное ПО представляет собой и реализующая
Используя промежуточный слой, можно перенести код приложения на узлы с разными базовыми инфраструктурными компонентами или расширить его перечисленными узлами. Усилия по разработке продукта и в первом, и во втором случае значительно сократятся.
Процесс модификации приложения для выполнения на узле с новыми базовыми инфраструктурными компонентами именуется переносом, простота переноса приложения на другие компоненты инфраструктуры носит название переносимости.
Доступ к существующим службам, не использующим промежуточный слой, зачастую можно гибко расширить реализацией прокси, предоставляющего интерфейс между промежуточным слоем и существующей службой. В перспективе новые приложения будут обращаться к такой службе через промежуточный слой, используя прокси, а не путем доступа напрямую.
Планируя, проектируя, разрабатывая и предоставляя службу в ИТ-системе компании, важно учитывать, отвечает ли служба предъявляемым требованиям и способна ли она развиваться так, чтобы соответствовать им в дальнейшем.
Приведенный далее перечень описывает в целом употребление в этой книге набора терминов, применяемых в отношении служб в ИТ-системах организаций.
Все перечисленные параметры важно рассматривать вместе, а не каждый из них в отдельности.
Изначально предоставляемые службе ресурсы призваны гарантировать, что скорость ее работы и пропускная способность приемлемы при нагрузках ожидаемого объема. Оценивая исходные требования к ресурсам, необходимо учесть надежность и безопасность служб, поскольку технологии повышения безопасности и надежности могут неблагоприятно сказаться на скорости их работы.
В то же время, анализируя начальную производительность и пропускную способность, важно оценить и расширяемость службы. Служба, которая хорошо масштабируется, позволяет включать в систему дополнительные ресурсы для того, чтобы оперативно повысить пропускную способность и справиться с увеличившейся нагрузкой без негативного влияния на скорость своей работы. Если расширяемость службы не учитывать изначально, рост пропускной способности может потребовать значительного объема модификаций службы либо отрицательно повлиять на производительность таковой.
Другой важный аспект – работа системы в целом в период, когда нагрузка на ту или иную службу превысит пропускную способность. Зачастую это недолговременное явление, возникающее при пиковых обращениях. Кроме того, оно может постепенно или внезапно возникать с ростом спроса на конкретную службу, указывая на то, что требуется расширить пропускную способность. Если этого не учесть, то отрицательные последствия пренебрежения таким шагом могут образовать следующий возможный "букет".
Масштабируемость и скорость работы инфраструктуры очередей сообщений вкупе с умелым проектированием и грамотным планом могут придать системе реальную расширяемость. При этом ресурсы могут выделяться и освобождаться по мере надобности с учетом требований к пропускной способности и производительности системы в условиях меняющейся нагрузки на информационную среду предприятия.
Данные, передаваемые в инфраструктуре очередей сообщений, в общих чертах можно разделить на две категории.
Примером сказанного является запрос текущего состояния заказа; если запрос данных утерян либо на него не получен отклик, это не повлияет на текущее состояние заказа, и запрос можно повторить еще раз.
Примером этого является сообщение об оплате заказа; если сообщение с подтверждением платежа будет утеряно, статус заказа может стать некорректным. Возможно, клиент внес деньги в его оплату либо ему отправлена расписка в их получении, но состояние заказа внутри системы не отражает ни того, ни другого.
Критичную для бизнеса информацию содержит большинство сообщений, передаваемых в инфраструктуре очередей. По этой причине важно, чтобы инфраструктура предоставляла гарантии защиты подобных сообщений от их потери.
С обеспечением таких гарантий связан ряд обстоятельств, касающихся производительности, а потому сообщения с данными-ответами на запрос могут маркироваться как таковые для повышения скорости их прохождения в инфраструктуре.
Помимо защиты сообщений с критичной для бизнеса информацией от потери в инфраструктуре очередей важно, чтобы сообщения достигали заданного места своего назначения, а доставка происходила исключительно однократно.
Если сообщение было отправлено по допустимому в данной системе адресу, инфраструктура очередей сообщений обязана гарантировать, что сообщение будет доставлено получателю. Однако пункт назначения или промежуточные узлы могут быть недоступны на протяжении какого-то периода времени. В этом случае сообщения остаются в системе в состоянии ожидания, пока не смогут продолжить свое движение по назначению.
Поскольку отправитель запроса данных не может ожидать отклик сколь угодно долгое время, то к информации, получаемой по запросу, могут предъявляться иные требования. В итоге сообщения в инфраструктуре могут помечаться как устаревшие, если в произвольном узле системы они останутся дольше заданного временного периода.
Если сообщение достигает места назначения дважды, то результат этого может оказаться непредсказуемым. К примеру, двукратное получение сообщения с подтверждением платежа может создать видимость того, что клиент переплатил за услугу. Инфраструктура очередей сообщений должна предоставлять гарантии того, что единичное сообщение не может быть неожиданно доставлено по назначению дважды или оказаться в нескольких пунктах назначения одновременно.
Если сообщение нельзя доставить по назначению, работа системы должна быть четко описана для того, чтобы найти и вручную маршрутизировать сообщение. Невозможность доставки может быть обусловлена изменениями в инфраструктуре и переносом адреса назначения либо некорректной спецификацией назначения
Понятие однократной доставки охватывает все эти соображения. Такую доставку гарантирует
Далеко не всегда действия приложений можно воспринимать изолированно. Например, служба может прочитать сообщение, обновить данные о клиенте, а в завершение послать ответ. Каждое из трех действий самостоятельно, но при ошибке в любом из них ни одно действие выполнено быть не должно.
О таких действиях говорят, что они входят в единицу работы. Единицы работы включают отправку и получение сообщений, а также обновление информационных баз данных. Инфраструктура очередей сообщений должна поддерживать завершение или откат действий единицы работы в целом, дабы ни одно действие в ней не могло выполниться без выполнения остальных. Также возможность инициировать откат единицы работы в любой момент времени должно иметь само приложение.
Сбои в ИТ-системе компании могут происходить без каких-либо предупреждений и должны обрабатываться так, чтобы не приводить систему в противоречивое состояние. К примерам подобных сбоев относятся:
При построении ИТ-системы компании такие сбои необходимо учитывать и обеспечивать их согласованную и толерантную обработку. Элементы инфраструктуры очередей сообщений упрощают данный процесс, реализуя отказоустойчивую инфраструктуру работы служб и значительно снижая объем требуемой для выявления и обработки сбоев такого рода прикладной логики.
Дополнительно эти возможности способны помочь избежать сбоев, которые могут привести к отказу всей системы, позволяя службам оставаться доступными даже при появлении таковых.
Особую роль при разработке и развертывании новой службы в ИТ-системе компании играет ее тестирование. Раннее обнаружение проблемы может серьезно сократить влияние ее возникновения в будущем и снизить объем ресурсов, необходимых для ее устранения.
Рекомендуемая методика создания, тестирования и внедрения приложений предполагает наличие двух независимых сред.
В простой системе обе среды могут пользоваться одной и той же программно-аппаратной инфраструктурой. Однако полное разграничение этих сред может дать дополнительные преимущества и сократить возможность изменений в контролирующей среде, отрицательно влияющих на доступность служб производственной среды фирмы.
Характер и интенсивность загрузки служб, которые моделирует среда обеспечения контроля качества, должны предельно соответствовать аналогам из производственной среды предприятия. Чем меньше наблюдаемые различия, тем вероятнее обнаружение возможных проблем в контролирующей среде до их появления в производственной.
Если проблема наблюдается и допускает воспроизведение в контролирующей среде, в ней можно разработать и протестировать предлагаемое решение. Его создание может оказаться разрушительной процедурой и требовать осуществления шагов, нерекомендуемых к выполнению в производственной среде без предварительного тестирования. В контролирующей среде подобные изменения можно осуществить, описать и проверить, не влияя на производственную среду.
Элементом сопровождения программных компонентов системы является регулярная профилактика. Выполняя профилактические работы в контролирующей среде до повторения их в условиях производственной среды, вы значительно снизите вероятность неожиданного влияния операций сопровождения на доступность программных служб.
Немаловажным в ИТ-системе компании является тщательное изучение проблем безопасности и защиты. Доступ к службам и информации в рамках такой системы должен быть под контролем, а целостность передаваемых по сетям общего пользования закрытых и
Нередко важно гарантировать, что службы в ИТ-системе компании доступны только авторизованным сторонам – людям и приложениям.
Применение службы без авторизации или по злому умыслу может вызвать повреждение данных, которые хранятся в системе, или сделать конфиденциальную информацию доступной более широкой аудитории, чем это предполагалось правами доступа.
В целом
Инфраструктура очередей сообщений должна включать функции надежного распознавания сущности, пытающейся получить доступ к конкретной службе, а также правила выработки решений о том, располагает данная сущность правом обращения к службе или же нет.
Это может оказаться особенно важным при наличии служб, открытых внешним субъектам, – поставщикам фирмы или ее клиентам. В данном случае инфраструктура очередей должна иметь надежную и безопасную процедуру выдачи прав доступа к службам для внешних контрагентов.
Входящие в систему узлы могут быть связаны различными каналами связи, предназначенными для общего пользования или не имеющими защиты. Во избежание внешнего вмешательства в посылку и получение данных такие каналы связи надлежит защищать.
Технологии защиты каналов связи обеспечивают защиту от чтения или модификации секретных данных третьими сторонами. Также они защищают и от попыток имитации сущности, имеющей права доступа к службам внутри системы.
Внешнее вмешательство в систему по незащищенным каналам связи может вызвать нарушение целостного характера данных либо привести к недоступности служб.
На службы, реализуемые ИТ-системой компании, можно положиться в повседневной работе фирмы. Простои, при которых конкретная служба или их группа становится недоступной, могут отразиться на деятельности компании, в результате чего ею будут понесены убытки.
В широком смысле простои делятся на две категории.
Цель обеспечения высокой готовности служб – минимизация плановых и внеплановых простоев инфраструктуры. Этого можно добиться несколькими путями, включая следующие:
Надежность системы зависит от надежности всех ее компонентов, включая программные и аппаратные компоненты инфраструктуры, линии связи и приложения, реализующие функции служб. Заметный вклад в надежность системы в целом вносит использование стабильной и надежной инфраструктуры очередей сообщений с простыми интерфейсами для минимизации сложности ее служб.
Обновление и сопровождение компонентов, по возможности осуществляемое без перевода служб в недоступное состояние, позволяет сократить плановые простои. Первоначальное обновление контролирующей, а не производственной среды снижает вероятность изменений в поведении рабочего окружения, влекущих внеплановый останов.
Если система допускает эффективное, то есть автоматическое, восстановление после сбоя без потери целостности информации, последствия и продолжительность такого внепланового простоя будут гораздо меньше.
Если в компоненте системы наблюдается сбой, он может повлиять на систему и службы, которые ею предоставляются. В контексте очередей сообщений это воздействие можно разбить на следующие подгруппы:
Если в компоненте системы произойдет сбой, он повлияет на все зависимые от него компоненты. Те, в свою очередь, могут повлиять на другие, в конечном же итоге затронутыми могут оказаться одна или несколько служб системы.
Если в системе есть лишь один экземпляр службы либо все экземпляры конкретной службы зависят от конкретного компонента, то возникает единая точка отказа внутри системы.
Организуя в системе множество экземпляров службы, способных действовать независимо, можно обеспечить доступность службы для новых запросов даже после отказа нескольких экземпляров.
В контексте очередей сообщений это требует, чтобы новые сообщения, которые помещаются в очереди на отказавших узлах или проходящие через них, направлялись на другие узлы системы.
Прежде чем достичь пункта своего назначения, сообщение может пройти в системе вереницу узлов, а оказавшись на месте, оставаться там какое-то время, прежде чем служба начнет его обработку. Впрочем, и самой службе между потреблением сообщения и успешным окончанием всех действий над ним также необходимо определенное время.
Если компонент системы дал сбой, узлы, в которых размещены очереди и службы, могут, как следствие, тоже утратить функциональность. Это может произойти мгновенно, не оставляя инфраструктуре и приложениям времени на реакцию, как, например, в случае отказа аппаратуры. Пока узел продолжает быть недоступным, все сообщения в очередях в этом узле тоже продолжают быть недоступными. Такие сообщения называют "застрявшими" (stranded messages).
Если подобное сообщение содержит критичные для бизнеса данные, становится важным его надежно восстановить. Восстановление "застрявших" сообщений должно поддерживать целостность хранимой в них информации.
Корректно должна быть разрешена и ситуация с каждой выполнявшейся в момент сбоя единицей работы. Так, служба могла начать обрабатывать сообщение, но не успеть закончить его обслуживание.
Восстановление сообщений с критичными для бизнеса данными может осуществляться в жестких временных рамках, возврат к работе затронутых неисправимой ошибкой ресурсов – требовать времени и ручного вмешательства. В итоге для восстановления доступности сообщений на незатронутых сбоем ресурсах может потребоваться произвести ряд ручных или автоматических операций.
Отдельные катастрофические повреждения могут затронуть все ресурсы какого-либо узла, а возможно, и группы связанных друг с другом и находящихся на единой физической площадке узлов. Возврат к работе служб после подобных сбоев или восстановление данных на поврежденных узлах требует тщательного планирования и предварительной подготовки.
Компания может планомерно готовиться к такого рода проблемам, периодически снимая резервные копии данных в узлах системы, содержащих критичную для ведения бизнеса информацию. Используя стратегии резервирования, восстановить данные в полностью актуальном их состоянии на поврежденном узле (узлах) возможно далеко не всегда. Однако соблюдение таких стратегий может существенно сократить количество данных, утраченных при разрушительном останове.
Сведения о работе и использовании системы имеют важное практическое значение. Они могут стать показателем качества функционирования системы, индикатором производительности и пропускной способности при разных нагрузках, а также дать возможность отслеживать работу отдельных сущностей.
Мониторинг производительности в контексте инфраструктуры очередей сообщений включает замер количества и продолжительности тех действий, которые осуществляются при обращении служб к очередям сообщений или при движении сообщений сквозь очереди и промежуточные узлы. Результаты замеров могут служить для оценки производительности и пропускной способности служб, а также инфраструктуры, которая их поддерживает.
Такие данные могут оказаться полезны при наделении служб ресурсами или принятии решения о наращивании ресурсов для расширения пропускной способности службы. Кроме того, мониторинг производительности может принести пользу при выявлении любых внезапных или постепенных изменений в характере нагрузки системы с целью предупреждения проблем до их реального появления.
Учет в контексте очередей сообщений включает накопление информации об использовании отдельных очередей конкретными сущностями, которыми могут быть приложение, реализующее службу на основе данной очереди, внешний или внутренний пользователь.
Собранная при учете статистика позволяет установить и провести анализ характера использования системы и, к примеру, удостовериться, что качество обслуживания конкретной сущности соответствует ожиданиям. Другое применение таких данных – организация функции выставления счетов на оплату с учетом использования конкретной службы конкретной сущностью.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.