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