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

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Удачи.

EDIT:

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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