Как лучше всего интегрировать несколько систем?
Хорошо, где я работаю, у нас есть довольно значительное количество систем, написанных за последние пару десятилетий, которые мы поддерживаем.
Системы разнообразны тем, что несколько операционных систем (Linux, Solaris, Windows), несколько баз данных (несколько версий oracle, sybase и mysql) и даже несколько языков (C, C++, JSP, PHP и множество других) используемый.
Каждая система достаточно автономна, даже за счет ввода одних и тех же данных в несколько систем.
Недавно руководство решило, что мы должны выяснить, что нужно для того, чтобы все системы с удовольствием общались и обменивались данными.
Имейте в виду, что, хотя мы можем вносить изменения в программное обеспечение в любой из отдельных систем, полное переписывание какой-либо одной системы (или более) не является чем-то, что руководство может развлечь.
Первой мыслью нескольких разработчиков было прямое: если системе A нужны данные из системы B, она должна просто подключиться к базе данных системы B и получить ее. Аналогично, если ему нужно предоставить данные B, он должен просто вставить их в базу данных B.
Из-за путаницы используемых баз данных (и версий) другие разработчики считали, что у нас должна быть одна новая база данных, объединяющая таблицы из всех других систем, чтобы избежать необходимости манипулирования несколькими соединениями. Делая это, они надеются, что мы сможем объединить некоторые таблицы и избавиться от избыточного ввода данных.
Это время, когда меня привлекли мое мнение по поводу всего этого беспорядка.
Сама идея использования базы данных в качестве средства системного общения пахнет мне смешно. Бизнес-логику нужно будет разместить в нескольких системах (если система A хочет добавить данные в систему B, она лучше понимает правила B, касающиеся данных, прежде чем выполнять вставку), некоторым системам, скорее всего, придется выполнить какую-либо форму опроса базы данных, чтобы найти При любых изменениях их данных постоянное обслуживание будет головной болью, так как любое изменение схемы базы данных теперь распространяется на несколько систем.
Моей первой мыслью было выделить время и написать API / сервисы для разных систем, которые после написания могут быть легко использованы для передачи / извлечения данных взад и вперед. Многие другие разработчики считают, что это чрезмерно и гораздо больше работы, чем просто использование базы данных.
Итак, что будет лучшим способом заставить эти системы общаться друг с другом?
6 ответов
Интеграция разрозненных систем - моя ежедневная работа.
На вашем месте я бы приложил огромные усилия, чтобы избежать доступа к данным Системы A непосредственно из Системы B. Обновление базы данных Системы A из Системы B крайне неразумно. Это полная противоположность хорошей практике, чтобы сделать вашу бизнес-логику настолько размытой. Вы будете сожалеть об этом.
Идея центральной базы данных не обязательно плоха... но количество усилий, вероятно, находится в пределах порядка переписывания систем с нуля. Это, конечно, не то, что я бы попытался, по крайней мере, в форме, которую вы описываете. Это может быть успешным, но это намного, намного сложнее и требует гораздо большей дисциплины, чем подход двухточечной интеграции. Забавно слышать, что это звучит так же, как "ковбойский" подход - просто перетаскивать данные прямо в другие системы.
В целом ваши инстинкты кажутся довольно хорошими. Есть пара подходов. Вы упоминаете одно: внедрение услуг. Это не плохой путь, особенно если вам нужны обновления в режиме реального времени. Другое - это отдельное интеграционное приложение, которое отвечает за перетасовку данных. Это подход, который я обычно использую, но обычно потому, что я не могу изменить системы, которые я интегрирую, чтобы запросить данные, которые ему нужны; Я должен вставить данные. В вашем случае сервисный подход не плохой.
Я хотел бы сказать, что для кого-то, кто впервые приходит к системной интеграции, может быть неочевидным, что каждая часть данных в вашей системе должна иметь единственную, авторитетную точку правды. Если данные дублируются (и дублируются), и копии не согласуются друг с другом, копия в истинном смысле для этих данных должна быть правильной. Нет другого способа интегрировать системы, если бы сложность не казалась ввысь с экспоненциальной скоростью. Интеграция спагетти похожа на код спагетти, и ее следует избегать любой ценой.
Удачи.
РЕДАКТИРОВАТЬ:
Промежуточное программное обеспечение решает проблему транспорта, но это не главная проблема интеграции. Если системы расположены достаточно близко друг к другу, чтобы одно приложение могло передавать данные непосредственно в другое, они, вероятно, достаточно близки, чтобы сервис, предлагаемый одним, мог вызываться напрямую другим. Я бы не рекомендовал промежуточное программное обеспечение в вашем случае. Вы можете получить некоторую выгоду от этого, но это будет перевешиваться повышенной сложностью. Вам нужно решить одну проблему за один раз.
Похоже, вы можете исследовать очередь сообщений и промежуточное ПО, ориентированное на сообщения.
MSMQ и Java Message Service являются примерами.
Если вы идете к стратегии Middleware + Single Central Database, вы можете рассмотреть возможность достижения этого в несколько этапов. Вот логичный пошаговый процесс, который можно рассмотреть:
- Реализация сервисов /API для разных систем, которые предоставляют функциональные возможности для каждой системы.
- Внедрение промежуточного программного обеспечения, которое осуществляет доступ к этим API и обеспечивает интерфейс для всех систем для доступа к данным / услугам из других систем (доступ к данным из центрального источника, если имеется, в противном случае получает их из другой системы)
- Реализация только центральной базы данных без данных
- Внедрение служб кэширования / хранения данных на уровне промежуточного программного обеспечения, которые могут хранить / кэшировать данные в центральной базе данных всякий раз, когда к этим данным обращаются из любой из систем, например, если записи системы А 1 1-5 выбираются системой В через промежуточное программное обеспечение, промежуточное программное обеспечение Службы кэширования данных могут хранить эти записи в централизованной базе данных, и в следующий раз эти записи будут извлечены из центральной базы данных.
- Очистка данных может происходить параллельно
- Вы также можете создать механизм импорта для ежедневной загрузки данных из нескольких систем в центральную базу данных (автоматически или вручную).
Таким образом, усилия распределяются по нескольким этапам, и данные постепенно сохраняются в центральной базе данных на основе первого обращения к первому сохраненному.
Кажется, вы ищете мнения, поэтому я предоставлю мое.
Я согласен с другими разработчиками, что написание API для всех различных систем является чрезмерным. Скорее всего, вы сделаете это быстрее и получите гораздо больший контроль над этим, если просто воспользуетесь другим предложением о создании единой базы данных.
Непосредственное взаимодействие с помощью толкающих / тыкающих баз данных предоставляет множество внутренних деталей одной системы другой. Есть очевидные недостатки: обновление одной системы может сломать другую. Кроме того, могут быть технические ограничения в том, как одна система может обращаться к базе данных другой (рассмотрим, как приложение, написанное на C в Unix, будет взаимодействовать с базой данных SQL Server 2005, работающей на Windows 2003 Server).
Первое, что вы должны решить, это платформа, где будет находиться "основная база данных", и то же самое для промежуточного программного обеспечения, обеспечивающего столь необходимый клей. Вместо того чтобы идти к интеграции промежуточного программного обеспечения уровня API (такого как CORBA), я бы предложил вам рассмотреть промежуточное программное обеспечение, ориентированное на сообщения. MS Biztalk, Sun eGate и Oracle Fusion могут быть одними из вариантов.
Ваша идея новой базы данных - это шаг в правильном направлении. Возможно, вам захочется немного почитать о шаблоне Enterprise Entity Aggregation.
Сочетание "интеграции данных" с промежуточным программным обеспечением - это путь.
Одна из проблем, с которой вы столкнетесь, - это выровнять данные в каждой из разных систем, чтобы их можно было интегрировать в первую очередь. Может случиться так, что каждая из систем, которую вы хотите интегрировать, содержит совершенно разные наборы данных, но, скорее всего, это перекрывающиеся данные. Прежде чем углубляться в написание API:s (этот путь я бы также выбрал, учитывая ваше описание), я бы порекомендовал вам попробовать и придумать логическую модель данных для данных, которые необходимо интегрировать. Эта модель данных затем поможет вам использовать данные, которые вы имеете в разных системах, и сделает их более полезными для других баз данных.
Я также очень рекомендую итеративный подход к интеграции. С устаревшими системами существует так много неопределенности, что пытаться спроектировать и реализовать все это за один раз слишком рискованно. Начните с малого и продолжайте свой путь к разумно интегрированной системе. "Полностью интегрированный" вряд ли когда-либо стоит стремиться.