пятница, 27 мая 2016 г.

Не очередями сообщений едиными или что такое федерализация данных

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

Одним из очевидных и наиболее популярных подходов к интеграции данных является их распространение путем передачи из базы данных одного приложения в базу данных другого. Tак как бизнес хочет видеть данные в каждом приложении, участвующем в бизнес-процессах компании, как можно быстрее, обмен информацией реализуется путем передачи небольших порций данных по очередям сообщений (синхронное распространение данных оставим вне рассмотрения, в последнее время оно не является мейнстримом, т.к. привносит с собой сильную связность между информационными системами). Поскольку современные решения класса Enterprise Service Bus (ESB) содержат удобнейшие зачастую декларативно настраиваемые адаптеры к большому количеству СУБД и провайдеров очередей сообщений (Message-oriented Middleware (MOM)), а также поставляются с визуальными редакторами, в разы ускоряющими разработку, то их и выбирают для решения вышеозначенной задачи. В итоге внедрение сервисной шины предприятия воспринимается как реализация асинхронного обмена данными между несколькими источниками, в большинстве своем представляющими собой реляционные базы данных тех или иных корпоративных приложений. Вариантом подхода является вставка данных не непосредственно в базу, а через некие сервисы, предоставляемые системой-приемником, что абстрагирует детали строения ее базы данных от разработчиков интеграции.





Недостатки распространения данных


Описанный выше подход к интеграции обладает рядом недостатков.

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

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

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

2) Обеспечение правильного порядка сообщений;
1) Обеспечение обработки сообщений один и только один раз;
2) Обеспечение правильного порядка сообщений.

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

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


(сообщения передаются по очереди, никто не знает, какое достигнет приемника первым)

Федерализация данных


Шаблон подробнейшим образом описан в статье Information service patterns, Part 1: Data federation pattern (имеется перевод на русский язык). Обращаю внимание на описание шаблона в контексте сервисно-ориентированной архитектуры.

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

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

Часто использование федерализации данных рассматривается как первый шаг к внедрению сервисно-ориентированной архитектуры (SOA).


В статье приведен следующий пример: сервис getCustomerCreditCardData извлекает информацию о клиенте и его последних транзакциях по кредитной карте. При этом информация о клиентах хранится в программном обеспечении класса Master Data Management (MDM), например в некотором Customer Data Hub'е, а информация о транзакциях по картам - в АБС банка. Задача сервиса - извлечь информацию из хаба, затем извлечь нужную информацию из АБС, сопоставить записи и сформировать ответ, представленный в соответствующем формате. При этом, очень важно, сервис getCustomerCreditCardData допускает повторное использование со стороны нескольких потребителей.

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

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

Применимость шаблона "федерализация данных"


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

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

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

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

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

Ограничения при внедрении шаблона "федерализация данных"


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

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

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

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

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

Выводы


Как мы рассмотрели в статье, привычный разработчикам интеграционных решений подход с распространением данных не лишен ряда существенных недостатков. Конечно, бывают ситуации, когда создание избыточности данных оправдано, но иногда за построением репликации данных с помощью очередей сообщений кроются, во-первых, непонимание разработчиками концепции SOA и, во-вторых, применение решений класса ESB не по назначению. Сервисные шины предприятия были придуманы для того, чтобы на них реализовывать сервисы, соответствующие описанным классиками принципам: стандартизированный контракт, слабая связность, абстракция от избыточных деталей, повторное использование, автономность, отсутствие состояния, обнаруживаемость и способность участвовать в композиции. Однако, поскольку инструментарий, поставляемый вместе с продуктами класса ESB, существенно упрощает разработку, то на их базе начали реализовывать асинхронное распространение данных. Некоторым свидетельством распространенности такого подхода являются обсуждения вида "зачем нужны Oracle Service Bus и IBM Integration Bus, если у нас есть Apache Camel и Spring Integration?" на форумах в сети Интернет.

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

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

Материалы



Понравилось сообщение - подпишитесь на блог

Комментариев нет:

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

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