Как лучше всего интегрировать несколько систем?

Question

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

Системы отличаются тем, что используются несколько операционных систем (Linux, Solaris, Windows), несколько баз данных (несколько версий oracle, sybase и mysql) и даже несколько языков (C, C ++, JSP, PHP и множество других).

Каждая система достаточно автономна, даже за счет ввода одних и тех же данных в несколько систем.

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

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

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

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

Примерно в это время ко мне обратились за моим мнением по поводу всего этого бардака.

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

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

Итак, каков был бы наилучший способ заставить эти системы взаимодействовать друг с другом?

Answer 1

Интеграция разрозненных систем - это моя повседневная работа.

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

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

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

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

Удачи.

Редактировать:

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

Answer 2

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

MSMQ и Служба сообщений Java быть примером.

Answer 3

Похоже, вы ищете мнения, поэтому я приведу свое.

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

Answer 4

Одна из задач, с которой вы столкнетесь, заключается в согласовании данных в каждой из различных систем таким образом, чтобы их можно было интегрировать в первую очередь.Возможно, каждая из систем, которые вы хотите интегрировать, содержит совершенно разные наборы данных, но более вероятно, что эти данные перекрываются.Прежде чем погрузиться в написание API: s (по этому маршруту я бы тоже пошел, учитывая ваше описание) Я бы порекомендовал вам попробовать создать логическую модель данных для данных, которые необходимо интегрировать.Затем эта модель данных поможет вам использовать данные, имеющиеся у вас в различных системах, и сделает их более полезными для других баз данных.

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

Answer 5

Прямое взаимодействие через базы данных pushing / poking предоставляет множество внутренних деталей одной системы другой.Есть очевидные недостатки:обновление одной системы может привести к поломке другой.Более того, могут существовать технические ограничения в том, как одна система может обращаться к базе данных другой (рассмотрим, как приложение, написанное на C в Unix, будет взаимодействовать с базой данных SQL Server 2005, работающей в Windows 2003 Server).

Первое, что вам нужно решить, это платформа, на которой будет находиться "основная база данных", и то же самое для промежуточного программного обеспечения, обеспечивающего столь необходимый клей.Вместо того, чтобы переходить к интеграции промежуточного программного обеспечения уровня API (такого как CORBA), я бы посоветовал вам рассмотреть промежуточное программное обеспечение, ориентированное на сообщения.MS Biztalk, eGate от Sun и Oracle Fusion могут быть некоторыми из вариантов.

Ваша идея создания новой базы данных - это шаг в правильном направлении.Возможно, вам захочется немного почитать о Агрегирование корпоративных объектов закономерность.

Правильный путь - это сочетание "интеграции данных" с промежуточным программным обеспечением.

Answer 6

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

1. Реализация сервисов / API для различных систем, которые предоставляют функциональность для каждой системы
2. Реализация промежуточного программного обеспечения, которое обращается к этим API и предоставляет интерфейс для всех систем для доступа к данным / службам из других систем (обращается к данным из центрального источника, если таковой имеется, в противном случае получает их из другой системы)
3. Реализация только центральной базы данных, без данных
4. Реализация служб кэширования / хранения данных на уровне промежуточного программного обеспечения, которые могут хранить / кэшировать данные в центральной базе данных всякий раз, когда к этим данным осуществляется доступ из любой из систем, напримерЕСЛИ записи 1-5 системы A извлекаются Системой B через промежуточное программное обеспечение, службы кэширования данных промежуточного программного обеспечения могут сохранять эти записи в централизованной базе данных, и в следующий раз эти записи будут извлечены из центральной базы данных
5. Очистка данных может происходить параллельно
6. Вы также можете создать механизм импорта для ежедневной отправки данных из нескольких систем в центральную базу данных (автоматически или вручную).

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