S90.08B 문제 1
그림에 표시된 서비스 A의 아키텍처는 서비스 A의 핵심 논리가 데이터베이스 및 독점 레거시 시스템(1)에 연결하고 서로 다른 사용자가 액세스하는 두 개의 개별 서비스 계약(2)을 지원하기 위해 시간이 지남에 따라 어떻게 확장되었는지 보여줍니다. 서비스 소비자.
서비스 계약은 서비스 논리에서 완전히 분리됩니다. 따라서 서비스 논리는 서비스 계약 및 기본 구현 리소스(데이터베이스 및 레거시 시스템)에 연결됩니다.
서비스 A에는 현재 세 명의 서비스 소비자가 있습니다. 서비스 소비자 A와 서비스 소비자 B는 서비스 A의 두 가지 서비스 계약(3, 4)에 액세스합니다. 서비스 소비자 C는 서비스 계약을 우회하고 서비스 로직에 직접 액세스합니다(5).
현재 서비스 A에서 사용 중인 데이터베이스와 레거시 시스템이 다른 제품으로 교체되고 있다고 들었습니다. 두 서비스 계약은 핵심 서비스 로직에서 완전히 분리되어 있지만, 신제품 도입으로 인해 핵심 서비스 로직이 이전과 다르게 작동할 것이라는 우려는 여전히 존재합니다.
서비스 소비자 A와 B에 대한 영향을 최소화하기 위해 신제품 도입을 준비하면서 서비스 A 아키텍처를 변경하기 위해 어떤 조치를 취할 수 있습니까? 서비스 소비자 C와 소비자-구현 결합을 피하기 위해 어떤 추가 조치를 취할 수 있습니까?
S90.08B 문제 2
서비스 A는 공유 데이터베이스에서 주기적으로 복제되는 데이터를 포함하는 데이터베이스에 일반 데이터 액세스 논리를 제공하는 유틸리티 서비스입니다(1). 표준 서비스 계약 원칙이 서비스 A의 설계에 적용되었기 때문에 서비스 계약이 완전히 표준화되었습니다.
서비스 A의 서비스 아키텍처는 세 명의 서비스 소비자가 액세스하고 있습니다. 서비스 소비자 A는 직접 호출하여 서비스 A 구현의 일부인 구성 요소에 액세스합니다(2). 서비스 소비자 B는 서비스 계약(3)에 액세스하여 서비스 A를 호출합니다. 서비스 소비자 C는 서비스 A 구현의 일부인 복제된 데이터베이스에 직접 액세스합니다(4).
서비스 소비자 A와 C가 게시된 서비스 A 서비스 계약을 우회하는 이유는 보안상의 이유로 서비스 A 서비스 계약을 구성하는 API의 기능 하위 집합에 액세스할 수 없기 때문입니다. 부정적인 형태의 결합을 피하면서 이러한 보안 제한을 적용하기 위해 서비스 A 아키텍처를 어떻게 변경할 수 있습니까?
S90.08B 문제 3
서비스 A, B 및 C는 독립적인 작업 서비스입니다. 서비스 A와 서비스 B는 동일한 공유 상태 데이터베이스를 사용하여 런타임 시 상태 데이터를 연기합니다.
세 가지 서비스를 평가한 결과 각 서비스에는 불가지론적 논리와 함께 번들로 제공되기 때문에 재사용할 수 없는 일부 불가지론적 논리가 포함되어 있음이 밝혀졌습니다.
또한 평가에서는 서비스 A, 서비스 B 및 공유 상태 데이터베이스가 각각 물리적으로 분리된 환경에 있기 때문에 서비스 A 및 서비스 B가 공유 상태 데이터베이스와 상호 작용하는 데 필요한 원격 통신으로 인해 런타임 성능이 비합리적으로 저하된다는 사실을 확인합니다.
오케스트레이션 패턴을 적용하면 이 아키텍처를 어떻게 개선할 수 있습니까?
S90.08B 문제 4
서비스 소비자 A와 서비스 A는 서비스 인벤토리 A에 있습니다. 서비스 B와 서비스 C는 서비스 인벤토리 B에 있습니다. 서비스 D는 월드 와이드 웹을 통해 공개적으로 액세스할 수 있는 공용 서비스입니다. 이 서비스는 IT 기업 내에서 독립적으로 배포할 수 있도록 구매도 가능합니다. 서비스 인벤토리 B 내에서 서비스 추상화 원칙의 엄격한 적용으로 인해 서비스 B 및 서비스 C에 대해 사용할 수 있는 유일한 정보는 게시된 서비스 계약입니다. 서비스 D의 경우 서비스 계약과 SLA(서비스 수준 계약)를 사용할 수 있습니다. SLA는 서비스 D에 매일 밤 11시부터 자정까지 계획된 정전이 있음을 나타냅니다.
당신은 Service Inventory A에 대한 서비스를 구축하는 프로젝트 팀의 설계자입니다. Service Inventory A와 Service Inventory B의 소유자가 일반적으로 협조적이거나 의사소통이 원활하지 않다는 말을 들었습니다.
교차 인벤토리 서비스 구성은 허용되지만 직접 지원되지는 않습니다. 결과적으로 서비스 B 및 서비스 C에 대한 SLA가 제공되지 않으며 이러한 서비스의 사용 가능 여부를 알 수 없습니다. 서비스 계약을 기반으로 Service Inventory B의 서비스가 Service Inventory A의 서비스와 다른 데이터 모델 및 다른 전송 프로토콜을 사용하는지 확인할 수 있습니다. 또한 최근 테스트 결과에 따르면 Service D의 성능은 다음으로 인해 매우 예측하기 어렵습니다. 다른 조직의 서비스 소비자로부터 많은 양의 동시 액세스를 받습니다. 또한 서비스 소비자 A가 서비스 A의 응답을 기다리는 동안 상태 저장 상태를 유지해야 하는 기간에 대한 우려가 있다고 들었습니다.
이러한 문제를 해결하기 위해 어떤 조치를 취할 수 있습니까?
S90.08B 문제 5
전시회를 참조하십시오.
서비스 소비자 A는 서비스 A에게 비즈니스 문서가 포함된 메시지를 보냅니다(1). 비즈니스 문서는 메모리에 비즈니스 문서를 보관하고 구성 요소 B(3)에 복사본을 전달하는 구성 요소 A에 의해 수신됩니다. 구성 요소 B는 먼저 비즈니스 문서의 일부를 데이터베이스 A에 기록합니다(4). 그런 다음 구성요소 B는 전체 비즈니스 문서를 데이터베이스 B에 쓰고 비즈니스 문서의 일부 데이터 값을 쿼리 매개변수로 사용하여 데이터베이스 B에서 새 데이터를 검색합니다(5).
다음으로 구성 요소 B는 새로운 날짜*를 구성 요소 A(6)로 다시 반환하고, 구성 요소 A는 이를 메모리에 보관해 온 원본 비즈니스 문서와 병합한 다음 결합된 데이터를 데이터베이스 C(7)에 기록합니다. 서비스 소비자 A가 호출한 서비스 A 서비스 기능에는 동기식 요청-응답 데이터 교환이 필요합니다. 따라서 마지막 데이터베이스 업데이트 결과에 따라 서비스 A는 성공 또는 실패 코드가 포함된 메시지를 서비스 소비자 A(8)에게 반환합니다.
데이터베이스 A와 B는 공유되며 데이터베이스 C는 서비스 A 서비스 아키텍처 전용입니다.
이 아키텍처에는 몇 가지 문제가 있습니다. 구성 요소 A가 메모리에 보관해야 하는 비즈니스 문서(구성 요소 B가 처리를 완료하기를 기다리는 동안)는 매우 클 수 있습니다. 서비스 A가 이 데이터를 메모리에 유지하는 데 사용하는 런타임 리소스의 양은 특히 여러 서비스 소비자가 동시에 호출하는 경우 모든 서비스 인스턴스의 전반적인 성능을 저하시킬 수 있습니다. 또한 데이터베이스 A는 때때로 구성 요소 B에 응답하는 데 시간이 오래 걸리는 공유 데이터베이스이기 때문에 서비스 A가 서비스 소비자 A에 다시 응답하는 데 시간이 오래 걸릴 수 있습니다. 현재 서비스 소비자 A는 응답을 위해 최대 30초 동안 대기합니다. 그 이후에는 서비스 A에 대한 요청이 실패했다고 가정하고 서비스 A의 후속 응답 메시지는 거부됩니다.
이러한 문제를 해결하기 위해 어떤 조치를 취할 수 있습니까?
서비스 소비자 A는 서비스 A에게 비즈니스 문서가 포함된 메시지를 보냅니다(1). 비즈니스 문서는 메모리에 비즈니스 문서를 보관하고 구성 요소 B(3)에 복사본을 전달하는 구성 요소 A에 의해 수신됩니다. 구성 요소 B는 먼저 비즈니스 문서의 일부를 데이터베이스 A에 기록합니다(4). 그런 다음 구성요소 B는 전체 비즈니스 문서를 데이터베이스 B에 쓰고 비즈니스 문서의 일부 데이터 값을 쿼리 매개변수로 사용하여 데이터베이스 B에서 새 데이터를 검색합니다(5).
다음으로 구성 요소 B는 새로운 날짜*를 구성 요소 A(6)로 다시 반환하고, 구성 요소 A는 이를 메모리에 보관해 온 원본 비즈니스 문서와 병합한 다음 결합된 데이터를 데이터베이스 C(7)에 기록합니다. 서비스 소비자 A가 호출한 서비스 A 서비스 기능에는 동기식 요청-응답 데이터 교환이 필요합니다. 따라서 마지막 데이터베이스 업데이트 결과에 따라 서비스 A는 성공 또는 실패 코드가 포함된 메시지를 서비스 소비자 A(8)에게 반환합니다.
데이터베이스 A와 B는 공유되며 데이터베이스 C는 서비스 A 서비스 아키텍처 전용입니다.
이 아키텍처에는 몇 가지 문제가 있습니다. 구성 요소 A가 메모리에 보관해야 하는 비즈니스 문서(구성 요소 B가 처리를 완료하기를 기다리는 동안)는 매우 클 수 있습니다. 서비스 A가 이 데이터를 메모리에 유지하는 데 사용하는 런타임 리소스의 양은 특히 여러 서비스 소비자가 동시에 호출하는 경우 모든 서비스 인스턴스의 전반적인 성능을 저하시킬 수 있습니다. 또한 데이터베이스 A는 때때로 구성 요소 B에 응답하는 데 시간이 오래 걸리는 공유 데이터베이스이기 때문에 서비스 A가 서비스 소비자 A에 다시 응답하는 데 시간이 오래 걸릴 수 있습니다. 현재 서비스 소비자 A는 응답을 위해 최대 30초 동안 대기합니다. 그 이후에는 서비스 A에 대한 요청이 실패했다고 가정하고 서비스 A의 후속 응답 메시지는 거부됩니다.
이러한 문제를 해결하기 위해 어떤 조치를 취할 수 있습니까?