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

Question

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

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

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

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

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

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

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

Речь идет о времени, когда меня привлекли к моему мнению на весь беспорядок.

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

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

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

Answer 1

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

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

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

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

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

Удачи.

EDIT:

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

Answer 2

Кажется, вы ищете мнения, поэтому я предоставил свои.

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

Answer 3

Похоже, что вы можете изучить Message Queuing и message-oriented middleware.

MSMQ и Java Message Service является примерами.

Answer 4

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

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

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

Комбинация «интеграция данных» с промежуточным программным обеспечением - это путь.

Answer 5

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

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

Answer 6

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

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

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