여러 시스템을 통합하는 것이 가장 좋습니까?

Question

좋아, 내가 일하는 곳에서 우리는 지난 수십 년 동안 우리가 유지하는 상당히 상당한 수의 시스템을 가지고 있습니다.

이 시스템은 여러 운영 체제 (Linux, Solaris, Windows), 여러 데이터베이스 (여러 버전의 Oracle, Sybase 및 MySQL) 및 여러 언어 (C, C ++, JSP, PHP 및 기타 여러 개)에서 다양합니다. 사용된.

각 시스템은 동일한 데이터를 여러 시스템에 입력하는 비용에도 불구하고 상당히 자율적입니다.

경영진은 최근 모든 시스템이 서로 행복하게 대화하고 데이터를 공유하는 데 필요한 것이 무엇인지 조사해야한다고 결정했습니다.

우리는 개별 시스템을 소프트웨어를 변경할 수 있지만 한 시스템 (또는 그 이상)을 완전히 다시 쓰는 것은 관리가 즐거울 수있는 것이 아닙니다.

여기서 여러 개발자들에 대한 첫 번째 생각은 간단한 것이 었습니다. 시스템 A가 시스템 B의 데이터가 필요하다면 System B의 데이터베이스에 연결되어 가져와야합니다. 마찬가지로 B 데이터를 제공 해야하는 경우 B 데이터베이스에 삽입해야합니다.

사용 된 데이터베이스 (및 버전)의 혼란으로 인해 다른 개발자는 여러 개의 연결을 저글링하지 않아도 다른 모든 시스템의 테이블을 결합하여 하나의 새로운 데이터베이스가 있어야한다는 의견을 가지고있었습니다. 이렇게함으로써 그들은 우리가 일부 테이블을 통합하고 중복 데이터 입력을 제거 할 수 있기를 바랍니다.

이것은 내가 전체 혼란에 대한 내 의견으로 들어온 시간입니다.

시스템 커뮤니케이션의 수단으로 데이터베이스를 사용한다는 전체 아이디어는 나에게 재미있는 냄새가납니다. 비즈니스 로직은 여러 시스템에 배치해야합니다 (시스템 A가 시스템에 데이터를 추가하려는 경우 B의 삽입을 수행하기 전에 데이터에 관한 B의 규칙을 더 잘 이해할 수 있습니다) 여러 시스템이 찾기 위해 일부 형태의 데이터베이스 폴링을 수행해야 할 것입니다. 데이터베이스 스키마에 대한 변경이 이제 여러 시스템을 전파하기 때문에 데이터 변경, 지속적인 유지 보수는 두통이 될 것입니다.

나의 첫 번째 생각은 시간을내어 다른 시스템에 대한 API/서비스를 작성하는 것이 었습니다. 한 번 작성한 것은 데이터를 앞뒤로 전달/검색하는 데 쉽게 사용될 수 있습니다. 다른 많은 개발자들은 데이터베이스를 사용하는 것보다 과도하고 훨씬 더 많은 작업이라고 생각합니다.

그렇다면 이러한 시스템이 서로 대화하도록하는 가장 좋은 방법은 무엇입니까?

Answer 1

이질적인 시스템을 통합하는 것은 나의 일입니다.

내가 당신이라면, 나는 시스템 B 내에서 직접 시스템 A의 데이터에 액세스하지 않기 위해 큰 노력을 기울일 것입니다. 업데이트 시스템 B의 시스템 A의 데이터베이스는 매우 현명하지 않습니다. 비즈니스 논리를 그렇게 확산시키는 것은 모범 사례와 정확히 반대입니다. 당신은 그것을 후회하게 될 것입니다.

중앙 데이터베이스에 대한 아이디어가 반드시 나쁘지는 않지만, 관련된 노력의 양은 아마도 시스템을 처음부터 다시 쓰는 순서 내에있을 것입니다. 그것은 적어도 당신이 묘사하는 형태로 내가 시도 할 것이 아닙니다. 성공할 수는 있지만, 훨씬 더 어렵고 포인트 간 통합 접근법보다 훨씬 더 많은 징계가 필요합니다. 데이터를 다른 시스템으로 직접 밀어 넣는 '카우보이'접근 방식과 같은 호흡에서 제안한 것을 듣는 것은 재밌습니다.

전반적으로 당신의 본능은 꽤 좋아 보입니다. 몇 가지 접근 방식이 있습니다. 당신은 하나를 언급합니다 : 서비스 구현. 특히 실시간으로 업데이트가 필요한 경우에는 나쁜 방법이 아닙니다. 다른 하나는 데이터를 뒤섞는 것을 담당하는 별도의 통합 응용 프로그램입니다. 그것은 내가 일반적으로 취하는 접근 방식이지만, 일반적으로 필요한 데이터를 요청하기 위해 통합하는 시스템을 변경할 수 없기 때문에 필요한 데이터를 변경할 수 없기 때문입니다. 데이터를 푸시해야합니다. 귀하의 경우 서비스 접근 방식은 나쁜 것이 아닙니다.

제가 말하고 싶은 한 가지는 누군가가 시스템 통합에 오는 사람에게 처음으로 분명하지 않을 수도 있습니다. 시스템의 모든 데이터는 단일의 권위있는 진실을 가져야한다는 것입니다. 데이터가 복제되고 (복제 된 경우) 사본이 서로 동의하지 않으면 해당 데이터에 대한 진실의 사본은 올바른 것으로 간주해야합니다. 복잡성이 기하 급수적으로 비명을 지르지 않고 시스템을 통합 할 수있는 다른 방법은 없습니다. 스파게티 통합은 스파게티 코드와 같으며 모든 비용으로 피해야합니다.

행운을 빕니다.

편집하다:

미들웨어는 운송 문제를 해결하지만 통합의 중심 문제는 아닙니다. 한 앱이 데이터를 다른 앱으로 직접 밀어 넣을 수있을 정도로 시스템이 충분히 가까워지면 아마도 하나가 제공하는 서비스를 다른 앱으로 직접 호출 할 수있을 정도로 가깝습니다. 귀하의 경우에는 미들웨어를 권장하지 않습니다. 당신은 그것으로부터 약간의 혜택을 얻을 수 있지만, 그것은 복잡성이 증가한 것보다 더 중요합니다. 한 번에 하나의 문제를 해결해야합니다.

Answer 2

조사하고 싶을 것 같습니다 메시지 대기 그리고 메시지 지향 미들웨어.

MSMQ 그리고 Java 메시지 서비스 예입니다.

Answer 3

당신이 의견을 찾고있는 것 같습니다. 그래서 나는 내 것을 제공 할 것입니다.

다른 시스템에 대해 API를 작성하는 것은 과도하다는 다른 개발자와 동의합니다. 단일 데이터베이스를 작성하겠다는 다른 제안을 수행하면 더 빨리 완료하고 훨씬 더 많은 제어를 할 수 있습니다.

Answer 4

당신이 가질 수있는 과제 중 하나는 각기 다른 시스템에서 데이터를 정렬하여 처음에 통합 될 수 있도록하는 것입니다. 통합하려는 각 시스템은 완전히 다른 데이터 세트를 유지하지만 겹치는 데이터 일 가능성이 높습니다. API : S를 작성하기 전에 (설명을 감안할 때 내가 취할 경로) 통합 해야하는 데이터에 대한 논리적 데이터 모델을 생각해내는 것이 좋습니다. 이 데이터 모델을 사용하면 다른 시스템에있는 데이터를 활용하고 다른 데이터베이스에 더 유용하게 만듭니다.

또한 통합에 대한 반복적 인 접근법을 강력히 추천합니다. 레거시 시스템을 사용하면 불확실성이 너무 많아서 한 번에이를 설계하고 구현하려는 시도는 너무 위험합니다. 작게 시작하고 합리적으로 통합 된 시스템으로 이동하십시오. "완전 통합"은 목표로 거의 가치가 없습니다.

Answer 5

푸시/ 파킹 데이터베이스를 통해 직접 인터페이스하면 한 시스템의 많은 내부 세부 사항이 다른 시스템에 노출됩니다. 명백한 단점이 있습니다. 한 시스템을 업그레이드하면 다른 시스템을 깨뜨릴 수 있습니다. 또한 한 시스템이 다른 시스템의 데이터베이스에 액세스 할 수있는 방법에는 기술적 인 제한이있을 수 있습니다 (UNIX의 C로 작성된 응용 프로그램이 Windows 2003 서버에서 실행되는 SQL Server 2005 데이터베이스와 상호 작용하는 방법을 고려하십시오).

가장 먼저 결정해야 할 것은 "마스터 데이터베이스"가 상주하는 플랫폼이며, 필요한 접착제를 제공하는 미들웨어의 경우 동일합니다. API 수준의 미들웨어 통합 (예 : CORBA)으로가는 대신 메시지 지향 미들웨어를 고려해야합니다. Biztalk, Sun 's Egate 및 Oracle's Fusion은 옵션 중 일부가 될 수 있습니다.

새로운 데이터베이스에 대한 귀하의 아이디어는 올바른 방향으로 나아가는 단계입니다. 조금 읽고 싶을 수도 있습니다 엔터티 엔터티 집계 무늬.

"데이터 통합"과 미들웨어의 조합이 진행되는 방법입니다.

Answer 6

Middleware + Single Central Database 전략으로 가고 있다면 여러 단계에서이를 달성하는 것을 고려할 수 있습니다. 다음은 고려할 수있는 논리적 계단식 프로세스입니다.

1. 각 시스템의 기능을 노출시키는 다른 시스템에 대한 서비스/API 구현
2. 이러한 API에 액세스하고 모든 시스템에 대한 인터페이스를 제공하는 미들웨어 구현 다른 시스템의 데이터/서비스에 액세스 할 수있는 인터페이스를 제공합니다 (사용 가능한 경우 Central 소스의 데이터에 액세스하면 다른 시스템에서이를 가져옵니다).
3. 데이터없이 중앙 데이터베이스의 구현
4. 중앙 데이터베이스에 데이터를 저장/캐시 할 수있는 미들웨어 수준에서 캐싱/데이터 저장 서비스 구현 시스템에서 데이터에 액세스 할 때마다 데이터가 액세스 할 때마다 시스템 A의 레코드 1-5가 미들웨어, 미들웨어를 통해 미들웨어를 통해 가져 오는 경우 데이터 캐싱 서비스는 이러한 레코드를 중앙 데이터베이스에 저장할 수 있으며 다음 에이 레코드가 중앙 데이터베이스에서 가져올 때
5. 데이터 정리는 동시에 발생할 수 있습니다
6. 또한 매일 여러 시스템에서 중앙 데이터베이스로 데이터를 푸시하는 가져 오기 메커니즘을 만들 수도 있습니다 (자동화 또는 매뉴얼).

이런 식으로 노력은 여러 이정표에 배포되며 데이터는 중앙 데이터베이스에 첫 번째 액세스 우선 저장 기준으로 점차 저장됩니다.