최신 [2023 년 9 월 28 일] 서비스 및 마이크로 서비스 PDF 문제가 포함 된 정확한 SOA 설계 및 아키텍처 랩이있는 S90.08B 시험 [Q10-Q33]-Exams Labs Braindumps

질문 10

서비스 인벤토리에는 송장 관련 데이터 액세스 기능을 제공하는 다음 세 가지 서비스가 포함되어 있습니다: Invoice, InvProc, Proclnv입니다. 이러한 서비스는 서로 다른 프로젝트 팀에 의해 서로 다른 시기에 만들어졌으며 설계 표준을 준수할 필요가 없었습니다. 따라서 이러한 각 서비스에는 인보이스 데이터를 표현하는 서로 다른 데이터 모델이 있습니다.
현재 이 세 가지 서비스에는 각각 다른 서비스 소비자가 있습니다: 서비스 소비자 A는 인보이스 서비스(1)에 액세스하고, 서비스 소비자 B(2)는 InvProc 서비스에 액세스하며, 서비스 소비자 C(3)는 Proclnv 서비스에 액세스합니다. 각 서비스 소비자는 송장 관련 서비스의 데이터 액세스 기능을 호출하여 해당 서비스가 모든 송장 관련 서비스(4, 5, 6)에서 사용하는 공유 계정 데이터베이스와 상호 작용하도록 요구합니다.
또한 서비스 소비자 D는 공유 회계 데이터베이스의 인보이스 데이터에 직접 액세스하도록 설계되었습니다(7). (이 아키텍처의 맥락에서 서비스 소비자 D는 예시된 서비스 아키텍처와 관련된 리소스에 액세스하기 때문에 서비스 소비자로 분류됩니다.) 인보이스 서비스, InvProc 서비스 및 Proclnv 서비스가 동일한 서비스 인벤토리의 일부라고 가정할 때, 공식 엔드포인트 패턴을 완전히 적용하려면 어떤 단계가 필요할까요?

인보이스 관련 서비스 중 하나를 인보이스 데이터 액세스 기능을 제공하는 공식 서비스로 선택해야 합니다. 그런 다음 선택한 인보이스 관련 서비스에만 액세스하도록 서비스 소비자 A, B, C를 재설계해야 합니다. 서비스 소비자 D는 인보이스 관련 서비스에 의존하지 않으므로 공식 엔드포인트 패턴의 영향을 받지 않으며 계속해서 회계 데이터베이스에 직접 액세스할 수 있습니다. 서비스 추상화 원칙을 추가로 적용하여 현재 및 미래의 서비스 소비자로부터 공유 계정 데이터베이스 및 기타 구현 세부 정보의 존재를 숨길 수 있습니다.

인보이스 관련 서비스 중 하나를 인보이스 데이터 액세스 기능을 제공하는 공식 서비스로 선택해야 하며, 다른 두 서비스의 로직을 공식 인보이스 서비스의 컨텍스트 내에서 실행되도록 이동해야 합니다. 그런 다음 선택한 인보이스 관련 서비스에만 액세스하도록 서비스 소비자 A, B, C를 재설계해야 합니다. 서비스 소비자 D도 공유 계정 데이터베이스에 직접 액세스하지 않고 공식 인보이스 관련 서비스와 상호 작용하여 데이터 액세스를 수행하도록 재설계해야 합니다. 서비스 추상화 원칙을 추가로 적용하여 현재 및 미래의 서비스 소비자로부터 공유 계정 데이터베이스의 존재 및 기타 구현 세부 정보를 숨길 수 있습니다.

서비스 소비자 A, B, C는 이미 게시된 계약을 통해 데이터 액세스를 수행 중이므로 공식 엔드포인트 패턴의 영향을 받지 않습니다. 서비스 소비자 D는 공유 계정 데이터베이스에 직접 액세스하지 않고 공식 인보이스 관련 서비스와 상호 작용하여 데이터 액세스를 수행하도록 재설계해야 합니다. 서비스 추상화 원칙을 추가로 적용하여 현재 및 미래의 서비스 소비자로부터 공유 계정 데이터베이스의 존재 및 기타 구현 세부 정보를 숨길 수 있습니다.

인보이스 관련 서비스 중 하나를 인보이스 데이터 액세스 기능을 제공하는 공식 서비스로 선택해야 합니다. 서비스 소비자 D는 인보이스 관련 서비스에 의존하지 않으므로 공식 엔드포인트 패턴의 영향을 받지 않으며 계속해서 회계 데이터베이스에 직접 액세스할 수 있습니다.
서비스 느슨한 결합 원칙을 추가로 적용하여 공유 계정 데이터베이스 및 기타 구현 세부 정보에서 서비스 소비자 A, B, C를 분리할 수 있습니다.

설명
레거시 래퍼 패턴을 적용하여 컴포넌트 B를 공유 데이터베이스를 래핑하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 다시 적용하여 컴포넌트 C를 레거시 시스템 API의 래퍼 역할을 하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 컴포넌트 D에 다시 한 번 적용하여 파일 폴더에 대한 표준화된 액세스를 제공하는 다른 유틸리티 서비스로 분리할 수 있습니다. 서비스 파사드 패턴을 적용하여 컴포넌트 A와 새 래퍼 유틸리티 서비스 사이에 각각 하나씩 세 개의 파사드 컴포넌트를 추가할 수 있습니다. 이렇게 하면 파사드 구성 요소는 분리로 인해 발생할 수 있는 동작 변경을 보완할 수 있습니다.
서비스 구성 가능성 원칙은 서비스 A와 세 개의 새로운 래퍼 유틸리티 서비스에 추가로 적용하여 네 개의 서비스가 모두 새로운 서비스 구성에 참여하도록 최적화할 수 있습니다. 이렇게 하면 세 가지 구성 요소를 별도의 서비스로 분할하여 발생할 수 있는 성능 손실을 보완하는 데 도움이 됩니다.
레거시 래퍼 패턴을 적용하여 컴포넌트 B, C, D를 세 가지 유틸리티 서비스로 분리하면 IT 기업 내의 공유 리소스(데이터베이스 A, 레거시 시스템, 파일 폴더)를 전용 서비스로 적절하게 캡슐화하여 관리할 수 있습니다. 그런 다음 서비스 파사드 패턴을 사용하여 컴포넌트 A와 각각의 새로운 래퍼 유틸리티 서비스 사이에 파사드 구성 요소를 생성하여 서비스 소비자 A의 동작에 영향을 주지 않고 원활하게 상호 작용할 수 있도록 할 수 있습니다.
마지막으로 서비스 구성 가능성 원칙을 적용하여 서비스 A와 세 개의 새로운 래퍼 유틸리티 서비스가 새로운 서비스 구성에 참여하기에 최적화되도록 할 수 있습니다. 이렇게 하면 세 가지 구성 요소를 별도의 서비스로 분할하여 발생할 수 있는 성능 손실을 완화하는 데 도움이 됩니다.

질문 11

서비스 소비자 A가 서비스 A에 메시지를 전송합니다. 현재 서비스 A에는 세 개의 중복 구현(구현 1, 구현 2, 구현 3)이 있습니다. 서비스 소비자 A가 보낸 메시지는 서비스 에이전트 A(1)가 가로채고, 이 에이전트는 런타임에 메시지를 전달할 서비스 A의 구현을 결정합니다. 서비스 A의 세 가지 구현은 모두 동일한 물리적 서버에 상주합니다.
서비스 A의 중복 구현이 존재함에도 불구하고 때때로 성능이 여전히 좋지 않다는 말을 들었습니다. 또한 IT 기업의 다른 많은 클라이언트 및 애플리케이션에서 사용 중인 공유 데이터베이스에 액세스해야 하는 기능을 도입하기 위해 곧 서비스 A에 새로운 서비스 기능을 추가해야 한다는 안내를 받습니다. 이로 인해 서비스 A에 추가적인 성능 요구 사항이 추가될 것으로 예상됩니다.
새로운 서비스 기능 추가에 대비하여 성능을 개선하기 위해 이 서비스 아키텍처를 어떻게 변경할 수 있나요?

표준화된 서비스 계약 원칙을 적용하여 새로운 서비스 기능이 현재 설계 표준을 준수하는 방식으로 기존 서비스 계약을 확장하도록 할 수 있습니다. 중복 구현 패턴을 적용하여 서비스 A가 공유 데이터베이스에서 필요로 하는 데이터의 복사본이 있는 중복 데이터베이스를 포함하는 서비스 A의 별도 구현을 설정할 수 있습니다.

서비스 자율성 원칙을 적용하여 서비스 A의 개별 구현을 서로 다른 물리적 서버로 분리하여 더욱 격리할 수 있습니다. 새로운 서비스 기능이 추가되면 서비스 데이터 복제 패턴을 적용하여 서비스 A의 각 구현에 공유 데이터베이스에서 필요한 데이터의 자체 복사본을 제공할 수 있습니다.

서비스 루스 커플링 원칙은 표준화된 서비스 계약 원칙과 함께 적용하여 서비스 계약에 새로운 서비스 기능이 추가된 후 서비스 소비자 A가 공유 데이터베이스에 간접적으로 결합되지 않도록 할 수 있습니다. 레거시 래퍼 패턴을 적용하여 공유 데이터베이스에 표준화된 데이터 액세스 서비스 기능을 제공할 새로운 유틸리티 서비스를 구축할 수 있습니다.

서비스 자율성 원칙을 적용하여 서비스 A의 개별 구현을 서로 다른 물리적 서버로 분리하여 더욱 격리할 수 있습니다. 새로운 서비스 기능이 추가되면 상태 저장소 패턴을 적용하여 서비스 A의 각 구현에 공유 데이터베이스에서 필요한 데이터의 자체 복사본을 제공할 수 있습니다.

질문 12

서비스 A, B 및 C는 비독립적인 작업 서비스입니다. 서비스 A와 서비스 B는 동일한 공유 상태 데이터베이스를 사용하여 런타임에 상태 데이터를 지연시킵니다.
세 서비스를 평가한 결과, 각 서비스에는 불가지론적 로직이 일부 포함되어 있는데, 이는 불가지론적 로직과 함께 번들로 제공되기 때문에 재사용할 수 없는 것으로 나타났습니다.
또한 서비스 A, 서비스 B 및 공유 상태 데이터베이스가 각각 물리적으로 분리된 환경에 있기 때문에 서비스 A와 서비스 B가 공유 상태 데이터베이스와 상호 작용하는 데 필요한 원격 통신으로 인해 런타임 성능이 부당하게 저하되고 있다고 판단합니다.
오케스트레이션 패턴을 적용하면 이 아키텍처를 어떻게 개선할 수 있을까요?

오케스트레이션 패턴을 적용하면 공식 엔드포인트, 상태 저장소, 서비스 데이터 복제 패턴이 자동으로 적용되어 공유 상태 데이터베이스가 서비스 A와 B의 공식 서비스 엔드포인트를 통해 복제되어 각 작업 서비스가 고유한 전용 상태 데이터베이스를 가질 수 있는 환경이 만들어집니다.

오케스트레이션 패턴을 적용하면 서비스 A, B, C에 존재하는 애그노스틱 로직과 비애그노스틱 로직을 깔끔하게 분리할 수 있는 환경이 조성되어 서비스 재사용성 원칙을 적용하여 재사용 가능성이 보장된 새로운 애그노스틱 서비스를 설계할 수 있게 됩니다. 오케스트레이션 환경에 의해 지원되고 로컬로 제공되는 상태 저장소 패턴은 서비스 A와 B가 공유할 수 있는 중앙 상태 데이터베이스를 제공하며, 로컬 상태 데이터베이스는 원격 통신의 문제를 방지합니다.

오케스트레이션 패턴을 적용하면 보상 서비스 트랜잭션이 자동으로 적용되는 환경이 조성되어 서비스 A와 B가 원격으로 상태 데이터베이스에 액세스해야 하는 성능 문제를 보완하는 데 사용할 수 있는 정교한 예외 로직을 생성할 수 있습니다. API 게이트웨이 및 서비스 브로커 패턴도 자동으로 적용되어 중앙 처리 계층에서 공통 변환 기능을 제공하여 새로운 애그노스틱 서비스를 위해 생성해야 하는 서비스 계약의 불균형을 극복하는 데 도움을 줍니다.

오케스트레이션 패턴은 필요한 상태 저장소의 호스팅을 지원하지 않으므로 이 아키텍처에는 적용할 수 없습니다.

질문 13
전시를 참조하십시오.

서비스 A는 송장 관련 처리를 위한 기능적 컨텍스트가 있는 SOAP 기반 웹 서비스입니다. 서비스 B는 데이터베이스에 대한 일반 데이터 액세스를 제공하는 REST 기반 유틸리티 서비스입니다.
이 서비스 구성 아키텍처에서 서비스 소비자 A는 송장 XML 문서가 포함된 SOAP 메시지를 서비스 A로 보냅니다(1). 그런 다음 서비스 A는 인보이스 XML 문서를 서비스 B로 보내고(2), 서비스 B는 인보이스 문서를 데이터베이스에 기록합니다(3).
서비스 소비자 A가 송장 문서를 표현하는 데 사용하는 데이터 모델은 XML 스키마 A를 기반으로 합니다.
서비스 A의 서비스 계약은 XML 스키마 B를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B의 서비스 계약은 XML 스키마 A를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B가 송장 기록을 작성해야 하는 데이터베이스는 독점적인 쉼표로 구분된 값(CSV) 형식의 전체 비즈니스 문서만 수락합니다.
서비스에서 사용하는 XML 스키마의 비호환성으로 인해 현재 존재하는 서비스를 사용하여 서비스 소비자 A에서 서비스 소비자 B로 송장 문서를 전송할 수 없습니다. 계약 중앙 집중화 패턴이 적용되고 있고 논리 중앙 집중화 패턴이 적용되지 않는다고 가정할 때 런타임 성능 요구 사항을 증가시키는 로직을 추가하지 않고 서비스 소비자 A에서 데이터베이스에 송장 문서를 전송할 수 있도록 하려면 어떤 조치를 취할 수 있나요?

서비스 소비자 A는 XML 스키마 B를 사용하도록 재설계하여 전송하는 SOAP 메시지가 서비스 A의 서비스 계약에 부합하도록 할 수 있습니다.
그런 다음 데이터 모델 변환 패턴을 적용하여 서비스 A가 전송한 SOAP 메시지를 서비스 B에서 사용하는 XML 스키마 A를 준수하도록 변환할 수 있습니다. 그런 다음 표준화된 서비스 계약 원칙을 서비스 B와 서비스 소비자 A에 적용하여 송장 XML 문서가 불필요한 검증을 피하도록 최적화해야 합니다.

서비스 소비자 A의 특수 인보이스 처리 로직이 서비스 B로 복사된 후 서비스 소비자 A가 서비스 B로 직접 인보이스 문서를 전송하도록 서비스 구성을 재설계할 수 있습니다.
서비스 소비자 A와 서비스 B는 XML 스키마 A를 사용하기 때문에 변환 로직이 필요하지 않습니다. 서비스 소비자 A는 서비스 소비자 B가 사용하는 데이터베이스와 호환되는 형식으로 송장 문서를 보낼 필요가 없으므로 자연스럽게 서비스 느슨한 결합 원칙이 적용됩니다.

서비스 소비자 A는 송장 문서를 데이터베이스에 직접 작성하도록 재설계할 수 있습니다. 이렇게 하면 서비스 A와 서비스 B의 개입을 피할 수 있으므로 성능 요구 사항이 줄어듭니다.
또한 서비스 소비자 A가 데이터베이스에 직접 연결되는 데이터 액세스 로직을 포함하도록 함으로써 서비스 느슨한 결합 원칙의 적용을 지원합니다.

서비스 소비자 A가 서비스 소비자 B에게 직접 송장 문서를 보내도록 서비스 구성을 재설계할 수 있습니다.
서비스 소비자 A와 서비스 B는 XML 스키마 A를 사용하기 때문에 변환 로직이 필요하지 않습니다. 서비스 소비자 A는 서비스 소비자 B가 사용하는 데이터베이스와 호환되는 형식으로 송장 문서를 보낼 필요가 없으므로 자연스럽게 논리 중앙 집중화 패턴이 적용됩니다.

질문 14
전시를 참조하십시오.

서비스 A는 서비스 B에 메시지(2)를 보내 서비스 B가 응답 메시지(3)로 서비스 A에 데이터를 반환하도록 요청하는 작업 서비스입니다. 수신된 응답에 따라 서비스 A는 응답이 필요 없는 서비스 C에 메시지를 보내야 할 수도 있습니다(4).
서비스 A는 서비스 B에 접속하기 전에 먼저 자체 데이터베이스에서 코드 값 목록을 검색한 다음(1) 이 데이터를 자체 메모리에 저장해야 합니다. 서비스 C에 메시지를 보내야 하는 경우 서비스 A는 서비스 B로부터 받은 데이터와 코드 값 목록의 데이터를 결합하여 서비스 C에 보낼 메시지를 만들어야 합니다. 서비스 A가 서비스 C를 호출할 필요가 없는 경우 코드 값을 버림으로써 작업을 완료할 수 있습니다.
서비스 A와 서비스 C는 서비스 인벤토리 A에, 서비스 B는 서비스 인벤토리 B에 상주합니다.
서비스 인벤토리 A의 서비스는 서비스 인벤토리 B의 서비스와 다른 설계 표준 및 기술을 기반으로 하는 서비스 계약으로 설계되었다고 들었습니다. 그 결과 서비스 A는 SOAP 기반 웹 서비스이고 서비스 B는 JSON 형식의 메시지를 교환하는 REST 서비스입니다. 따라서 서비스 A와 서비스 B는 현재 통신할 수 없습니다. 또한 서비스 C는 많은 동시 서비스 소비자가 많이 액세스하는 애그노스틱 서비스입니다. 서비스 C는 사용 임계값에 자주 도달하며, 그 동안에는 서비스를 사용할 수 없고 전송된 메시지가 수신되지 않습니다.
이러한 문제를 해결하기 위해 어떤 조치를 취할 수 있나요?

데이터 모델 변환 패턴은 런타임에 한 데이터 모델에서 다른 데이터 모델로 메시지를 변환할 수 있는 중간 처리 계층을 서비스 A와 서비스 B 사이에 설정하여 적용할 수 있습니다. 중간 라우팅 및 서비스 에이전트 패턴을 적용하여 서비스 B가 응답 메시지를 보내면 서비스 에이전트가 메시지를 가로채고 그 내용에 따라 메시지를 서비스 A로 전달하거나 서비스 C로 라우팅할 수 있습니다. 서비스 자율성 원칙은 중복 구현 패턴과 함께 서비스 C에 추가로 적용하여 보다 안정적이고 확장 가능한 서비스 아키텍처를 구축하는 데 도움을 줄 수 있습니다.

데이터 형식 변환 패턴은 런타임에 메시지를 한 데이터 형식에서 다른 데이터 형식으로 변환할 수 있는 서비스 A와 서비스 B 사이에 중간 처리 계층을 설정하여 적용할 수 있습니다. 비동기 대기열 패턴을 적용하면 서비스 A와 서비스 C 사이에 중간 대기열을 설정하여 서비스 A가 서비스 C로 메시지를 보내야 할 때 대기열이 메시지를 저장하고 메시지가 성공적으로 전달될 때까지 서비스 C로 재전송할 수 있도록 할 수 있습니다. 서비스 자율성 원칙은 중복 구현 패턴과 함께 서비스 C에 추가로 적용하여 보다 안정적이고 확장 가능한 서비스 아키텍처를 구축하는 데 도움이 될 수 있습니다.

데이터 모델 변환 패턴은 런타임에 한 데이터 모델에서 다른 데이터 모델로 메시지를 변환할 수 있는 중간 처리 계층을 서비스 A와 서비스 B 사이에 설정하여 적용할 수 있습니다. 중간 라우팅 및 서비스 에이전트 패턴을 적용하여 서비스 B가 응답 메시지를 보낼 때 서비스 에이전트가 메시지를 가로채고 그 내용에 따라 메시지를 서비스 A로 전달하거나 서비스 C로 라우팅할 수 있습니다. 서비스 상태 저장소 패턴을 통해 서비스 상태 비저장 원칙을 적용하여 서비스 A가 상태 데이터베이스에 코드 값 데이터를 쓸 수 있도록 서비스 B의 응답을 대기하는 동안 서비스 상태 저장소 패턴을 적용할 수 있습니다.

데이터 형식 변환 패턴은 런타임에 메시지를 한 데이터 형식에서 다른 데이터 형식으로 변환할 수 있는 서비스 A와 서비스 B 사이에 중간 처리 계층을 설정하여 적용할 수 있습니다. 비동기 대기열 패턴을 적용하면 서비스 A와 서비스 B 사이에 중간 대기열을 설정하여 서비스 A가 서비스 B로 메시지를 보내야 할 때 대기열이 메시지를 저장하고 성공적으로 전달될 때까지 서비스 B로 메시지를 재전송할 수 있습니다. 서비스 재사용성 원칙은 중복 구현 패턴과 함께 서비스 C에 추가로 적용하여 보다 재사용 가능하고 확장 가능한 서비스 아키텍처를 구축하는 데 도움이 될 수 있습니다.

질문 15
전시를 참조하십시오.

서비스 소비자 A와 서비스 A는 서비스 인벤토리 A에 상주합니다. 서비스 B와 서비스 C는 서비스 인벤토리 B에 상주합니다. 서비스 D는 월드와이드웹을 통해 공개적으로 액세스할 수 있는 퍼블릭 서비스입니다. 이 서비스는 IT 기업 내에서 독립적으로 배포할 수 있도록 구매도 가능합니다. 서비스 인벤토리 B에는 서비스 추상화 원칙이 엄격하게 적용되기 때문에 서비스 B와 서비스 C에 대해 제공되는 유일한 정보는 공개된 서비스 계약서뿐입니다. 서비스 D의 경우 서비스 계약과 서비스 수준 계약(SLA)이 제공됩니다. SLA에 따르면 서비스 D는 매일 밤 11시부터 자정까지 계획된 중단이 있습니다.
귀하는 서비스 인벤토리 A에 대한 서비스를 구축하는 프로젝트 팀의 아키텍트로서 서비스 인벤토리 A와 서비스 인벤토리 B의 소유자가 일반적으로 협조적이거나 의사소통이 원활하지 않다는 말을 들었습니다. 교차 인벤토리 서비스 구성은 허용되지만 직접 지원되지는 않습니다. 따라서 서비스 B 및 서비스 C에 대한 SLA를 사용할 수 없으며 이러한 서비스의 사용 가능 여부에 대한 지식이 없습니다. 서비스 계약에 따르면 서비스 인벤토리 B의 서비스는 서비스 인벤토리 A의 서비스와 다른 데이터 모델과 다른 전송 프로토콜을 사용한다는 것을 확인할 수 있습니다. 또한 최근 테스트 결과에 따르면 서비스 D의 성능은 다른 조직의 서비스 소비자로부터 받는 동시 접속량이 많아 예측하기 어렵다는 것을 알 수 있습니다. 또한 서비스 소비자 A가 서비스 인벤토리 A의 응답을 기다리는 동안 얼마나 오랫동안 상태를 유지해야 하는지에 대한 우려가 있다고 들었습니다.
이러한 문제를 해결하기 위해 어떤 조치를 취할 수 있나요?

이벤트 중심 메시징 패턴을 적용하여 서비스 소비자 A와 서비스 A 사이에 구독자-발행자 관계를 설정할 수 있습니다. 이렇게 하면 서비스 소비자 A가 상태 저장 상태를 유지할 필요 없이 세 가지 데이터 값을 수집할 수 있을 때마다 서비스 소비자 A에 응답을 제공할 수 있는 유연성을 확보할 수 있습니다. 비동기 대기열 패턴을 적용하여 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이에 중앙 메시징 대기열을 배치할 수 있습니다. 데이터 모델 변환 및 프로토콜 브리징 패턴을 적용하여 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이의 통신을 활성화할 수 있습니다. 중복 구현 패턴을 적용하여 서비스 D의 복사본을 사내로 가져와 서비스 인벤토리 A의 일부가 되도록 할 수 있습니다.

비동기 큐잉 패턴을 적용하여 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이에 중앙 메시징 큐를 배치하고 서비스 A와 서비스 소비자 A 사이에 별도의 메시징 큐를 배치할 수 있습니다. 데이터 모델 변환 및 프로토콜 브리징 패턴을 적용하여 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이의 통신을 가능하게 하고 중복 구현 패턴을 적용하여 서비스 D의 복사본을 사내에 가져올 수 있습니다. 레거시 래퍼 패턴을 추가로 적용하여 서비스 인벤토리 A에 사용된 설계 표준을 준수하는 표준화된 서비스 계약으로 서비스 D를 래핑할 수 있습니다.

컨테이너화 패턴을 적용하여 서비스 A가 자율적으로 처리를 수행할 수 있는 환경을 구축할 수 있습니다. 이를 통해 서비스 A는 서비스 소비자 A에게 응답 메시지를 일관되게 제공할 수 있는 유연성을 확보할 수 있습니다. 비동기 큐잉 패턴을 적용하여 중앙 메시징 큐를 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이, 서비스 A와 서비스 D 사이에 배치할 수 있으며, 데이터 모델 변환 및 프로토콜 브리징 패턴을 적용하여 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이의 통신을 가능하게 할 수 있습니다.

비동기 큐잉 패턴을 적용하여 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이, 서비스 A와 서비스 D 사이에 메시지 큐를 배치하고, 서비스 A와 서비스 소비자 A 사이에 별도의 메시지 큐를 배치할 수 있습니다. 데이터 모델 변환 및 프로토콜 브리징 패턴을 적용하여 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이, 서비스 A와 서비스 D 사이의 통신을 가능하게 하고, 중복 구현 패턴을 적용하여 서비스 D의 복사본을 사내에 가져올 수 있습니다. 레거시 래퍼 패턴을 추가로 적용하여 서비스 인벤토리 B에 사용된 설계 표준을 준수하는 표준화된 서비스 계약으로 서비스 D를 래핑할 수 있습니다.

질문 16

서비스 A는 송장 관련 처리를 위한 기능적 컨텍스트가 있는 SOAP 기반 웹 서비스입니다.
서비스 B는 데이터베이스에 대한 일반 데이터 액세스를 제공하는 REST 기반 유틸리티 서비스입니다.
이 서비스 구성 아키텍처에서 서비스 소비자 A는 송장 XML 문서가 포함된 SOAP 메시지를 서비스 A로 보냅니다(1). 그런 다음 서비스 A는 인보이스 XML 문서를 서비스 B로 보내고(2), 서비스 B는 인보이스 문서를 데이터베이스에 기록합니다(3).
서비스 소비자 A가 송장 문서를 표현하는 데 사용하는 데이터 모델은 XML 스키마 A를 기반으로 합니다.
서비스 A의 서비스 계약은 XML 스키마 B를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B의 서비스 계약은 XML 스키마 A를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B가 송장 기록을 작성해야 하는 데이터베이스는 독점적인 쉼표로 구분된 값(CSV) 형식의 전체 비즈니스 문서만 수락합니다.
서비스에서 사용하는 XML 스키마의 비호환성으로 인해 현재 존재하는 서비스를 사용하여 서비스 소비자 A에서 서비스 소비자 B로 송장 문서를 전송할 수 없습니다. 계약 중앙 집중화 패턴이 적용되고 있고 논리 중앙 집중화 패턴이 적용되지 않는다고 가정할 때 런타임 성능 요구 사항을 증가시키는 로직을 추가하지 않고 서비스 소비자 A에서 데이터베이스에 송장 문서를 전송할 수 있도록 하려면 어떤 조치를 취할 수 있나요?

서비스 소비자 A가 전송하는 SOAP 메시지가 서비스 A의 서비스 계약을 준수하도록 XML 스키마 B를 사용하도록 재설계할 수 있습니다. 그런 다음 데이터 모델 변환 패턴을 적용하여 서비스 A가 전송하는 SOAP 메시지가 서비스 B에서 사용하는 XML 스키마 A를 준수하도록 변환할 수 있습니다. 그런 다음 표준화된 서비스 계약 원칙을 서비스 B와 서비스 소비자 A에 적용하여 송장 XML 문서가 불필요한 검증을 피하도록 최적화해야 합니다.

서비스 소비자 A가 서비스 A의 특수 인보이스 처리 로직을 서비스 B에 복사한 후 서비스 소비자 B가 직접 인보이스 문서를 전송하도록 서비스 구성을 재설계할 수 있습니다.

서비스 소비자 A와 서비스 B는 XML 스키마 A를 사용하기 때문에 변환 로직이 필요하지 않습니다. 서비스 소비자 A는 서비스 소비자 B가 사용하는 데이터베이스와 호환되는 형식으로 송장 문서를 보낼 필요가 없으므로 자연스럽게 서비스 느슨한 결합 원칙이 적용됩니다.

서비스 소비자 A는 송장 문서를 데이터베이스에 직접 쓰도록 재설계할 수 있습니다. 이렇게 하면 서비스 A와 서비스 B의 개입을 피하여 성능 요구 사항을 줄일 수 있습니다. 또한 서비스 소비자 A가 데이터베이스에 직접 연결되는 데이터 액세스 로직을 포함하도록 하여 서비스 느슨한 결합 원칙의 적용을 지원합니다.

서비스 소비자 A가 송장 문서를 서비스 소비자 B에게 직접 전송하도록 서비스 구성을 재설계할 수 있습니다. 서비스 소비자 A와 서비스 B는 XML 스키마 A를 사용하므로 변환 로직이 필요하지 않습니다. 서비스 소비자 A는 서비스 소비자 B가 사용하는 데이터베이스와 호환되는 형식으로 송장 문서를 보낼 필요가 없으므로 자연스럽게 로직 중앙 집중화 패턴이 적용됩니다.

질문 17

서비스 A가 서비스 소비자 A(1)로부터 메시지를 받으면 컴포넌트 A가 메시지를 처리합니다. 이 컴포넌트는 먼저 메시지 값을 사용하여 데이터베이스 A를 쿼리하여 추가 데이터를 검색하는 컴포넌트 B(2)를 호출합니다. 그런 다음 컴포넌트 B는 추가 데이터를 컴포넌트 A에 반환하고, 컴포넌트 A는 레거시 시스템의 API와 상호 작용하여 새 데이터 값을 검색하는 컴포넌트 C(3)를 호출합니다.
그런 다음 컴포넌트 C는 데이터 값을 컴포넌트 A로 다시 반환합니다.
다음으로 컴포넌트 A는 축적된 데이터 중 일부를 컴포넌트 D(4)로 전송하고, 컴포넌트 D는 특정 폴더에 있는 텍스트 파일에 데이터를 씁니다. 그런 다음 컴포넌트 D는 정기적으로 예약된 일괄 가져오기를 통해 이 파일을 다른 시스템으로 가져올 때까지 기다립니다. 가져오기가 완료되면 컴포넌트 D는 성공 또는 실패 코드를 컴포넌트 A에 반환합니다. 컴포넌트 A는 마지막으로 지금까지 수집한 모든 데이터가 포함된 응답을 서비스 소비자 A(5)에 보내고 서비스 소비자 A는 모든 데이터를 데이터베이스 B에 씁니다(6).
구성 요소 A, B, C, D는 서비스 A 서비스 아키텍처에 속합니다. 데이터베이스 A, 레거시 시스템 및 파일 폴더는 IT 기업 내에서 공유 리소스입니다.
서비스 A는 지난 몇 년 동안 성장한 서비스 아키텍처를 가진 엔티티 서비스입니다. 서비스 인벤토리 전반의 재설계 프로젝트의 결과로 서비스 소비자 A와 관련된 서비스 A의 동작을 방해하지 않으면서 컴포넌트 B, C, D가 제공하는 로직을 세 가지 유틸리티 서비스로 분리하기 위해 서비스 A 서비스 아키텍처를 다시 검토하라는 요청을 받게 됩니다.
이러한 요구 사항을 충족하기 위해 어떤 조치를 취할 수 있나요?

레거시 래퍼 패턴을 적용하여 컴포넌트 B를 공유 데이터베이스를 래핑하는 별도의 래퍼 유틸리티 서비스로 분리할 수 있습니다. 비동기 대기열 패턴을 적용하여 구성 요소 A와 구성 요소 C 사이에 메시징 대기열을 배치하여 레거시 시스템을 사용할 수 없거나 IT 기업의 다른 부분에서 많이 액세스할 수 있는 시간 동안 통신할 수 있도록 할 수 있습니다. 서비스 페이게이트 패턴을 적용하여 구성 요소 A와 구성 요소 D 사이에 페이게이트 구성 요소를 추가하여 동작의 변화를 보상할 수 있습니다.
서비스 자율성 원칙을 서비스 A에 추가로 적용하여 컴포넌트를 별도의 래퍼 유틸리티 서비스로 분할함으로써 발생할 수 있는 성능 손실을 보완할 수 있습니다.

레거시 래퍼 패턴을 적용하여 컴포넌트 B를 공유 데이터베이스를 래핑하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 다시 적용하여 컴포넌트 C를 레거시 시스템 API의 래퍼 역할을 하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 컴포넌트 D에 다시 한 번 적용하여 파일 폴더에 대한 표준화된 액세스를 제공하는 또 다른 유틸리티 서비스로 분리할 수 있습니다. 서비스 페이게이트 패턴을 적용하여 컴포넌트 A와 새 래퍼 유틸리티 서비스 사이에 각각 하나씩 세 개의 페이게이트 컴포넌트를 추가할 수 있습니다. 이렇게 하면 페이게이트 구성 요소는 분리로 인해 발생할 수 있는 동작 변경을 보완할 수 있습니다. 서비스 컴포저빌리티 원칙은 서비스 A와 3개의 새로운 래퍼 유틸리티 서비스에 추가로 적용하여 4개의 서비스 모두 새로운 서비스 구성에 참여하도록 최적화할 수 있습니다. 이렇게 하면 세 가지 구성 요소를 별도의 서비스로 분리할 때 발생할 수 있는 성능 손실을 보완하는 데 도움이 됩니다.

레거시 래퍼 패턴을 적용하여 컴포넌트 B를 공유 데이터베이스를 래핑하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 다시 적용하여 컴포넌트 C를 레거시 시스템 API의 래퍼 역할을 하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 컴포넌트 D도 별도의 서비스로 분리하고 이벤트 중심 메시징 패턴을 적용하여 이 새 서비스와 컴포넌트 A 사이에 게시자-구독자 관계를 설정할 수 있습니다. 그런 다음 서비스 소비자 A와 컴포넌트 A 간의 상호작용을 재설계하여 컴포넌트 A가 먼저 컴포넌트 B 및 새 래퍼 서비스와 상호작용하도록 할 수 있습니다. 그런 다음 서비스 A는 서비스 소비자 A에게 최종 메시지를 다시 전송합니다. 서비스 구성 가능성 원칙은 서비스 A와 세 개의 새로운 래퍼 유틸리티 서비스에 추가로 적용되어 네 개의 서비스가 모두 새로운 서비스 구성에 참여하도록 최적화될 수 있습니다. 이렇게 하면 세 가지 구성 요소를 별도의 서비스로 분할하여 발생할 수 있는 성능 손실을 보완하는 데 도움이 됩니다.

레거시 래퍼 패턴을 적용하여 컴포넌트 B가 공유 데이터베이스를 래핑하는 별도의 래퍼 유틸리티 서비스로 분리되도록 할 수 있습니다. 상태 저장소 및 상태 메시징 패턴을 적용하여 메시징 저장소를 구성 요소 A와 구성 요소 C 사이에 배치하여 레거시 시스템을 사용할 수 없거나 IT 기업의 다른 부분에서 많이 액세스할 수 있는 시간 동안 메타 데이터 중심 통신이 가능하도록 할 수 있습니다. 서비스 페이게이트 패턴을 적용하여 컴포넌트 A와 컴포넌트 D 사이에 페이게이트 컴포넌트를 추가하여 동작의 변화를 보상할 수 있습니다. 서비스 스테이트리스 원칙을 서비스 A에 추가로 적용하여 구성 요소를 별도의 래퍼 유틸리티 서비스로 분할함으로써 발생할 수 있는 성능 손실을 보완할 수 있습니다.

질문 18

서비스 A는 공유 데이터베이스에서 주기적으로 복제되는 데이터가 포함된 데이터베이스에 일반 데이터 액세스 로직을 제공하는 유틸리티 서비스입니다(1). 서비스 A의 설계에 표준화된 서비스 계약 원칙이 적용되었기 때문에 서비스 계약은 완전히 표준화되었습니다.
서비스 A의 서비스 아키텍처는 세 명의 서비스 소비자가 액세스하고 있습니다. 서비스 소비자 A는 서비스 A 구현의 일부인 컴포넌트를 직접 호출하여 액세스합니다(2). 서비스 소비자 B는 서비스 계약에 액세스하여 서비스 A를 호출합니다(3). 서비스 소비자 C는 서비스 A 구현의 일부인 복제된 데이터베이스에 직접 액세스합니다(4).
서비스 소비자 A와 C가 게시된 서비스 A 서비스 계약을 우회하는 이유는 보안상의 이유로 서비스 A 서비스 계약을 구성하는 API의 기능 하위 집합에 액세스할 수 없기 때문이라고 들었습니다. 부정적인 형태의 결합을 피하면서 이러한 보안 제한을 적용하기 위해 서비스 A 아키텍처를 어떻게 변경할 수 있을까요?

계약 중앙화 패턴을 적용하면 모든 서비스 소비자가 게시된 서비스 계약을 통해 서비스 A 아키텍처에 액세스하도록 강제할 수 있습니다. 이렇게 하면 데이터베이스가 교체될 때 문제를 일으킬 수 있는 부정적인 형태의 결합을 방지할 수 있습니다. 그런 다음 서비스 추상화 원칙을 적용하여 기본 서비스 아키텍처 세부 사항을 숨겨 향후 서비스 소비자가 기본 서비스 구현의 어떤 부분에도 액세스하도록 설계할 수 없도록 할 수 있습니다.

계약 중앙화 패턴을 적용하여 서비스 소비자가 게시된 서비스 계약을 통해서만 서비스 A 아키텍처에 액세스하도록 강제할 수 있습니다. 그런 다음 서비스 느슨한 결합 원칙을 적용하여 중앙 집중식 서비스 계약에 기본 서비스 구현에 종속되거나 파생된 콘텐츠가 포함되지 않도록 할 수 있습니다.

계약 중앙화 패턴은 서비스 소비자가 게시된 서비스 계약을 통해서만 서비스 A 아키텍처에 액세스하도록 하기 위해 적용될 수 있습니다. 동시 계약 패턴은 하나 이상의 대체 서비스 계약을 설정하기 위해 서비스 A에 적용할 수 있습니다. 이를 통해 권한 수준이 다른 서비스 소비자가 서비스 A의 게시된 서비스 계약을 통해 서로 다른 유형의 서비스 로직에 액세스할 수 있습니다.

계약 중앙 집중화 패턴을 적용하여 서비스 소비자가 게시된 서비스 계약을 통해서만 서비스 A 아키텍처에 액세스하도록 강제할 수 있습니다. 무권한 기능 패턴은 서비스 A에 적용하여 다양한 권한 수준을 가진 서비스 소비자를 위한 대체 서비스 기능 집합을 설정할 수 있습니다.

질문 19
전시를 참조하십시오.

서비스 A가 서비스 소비자 A(1)로부터 메시지를 받으면 컴포넌트 A가 메시지를 처리합니다.
이 컴포넌트는 먼저 컴포넌트 B(2)를 호출하여 메시지의 값을 사용하여 데이터베이스 A를 쿼리하여 추가 데이터를 검색합니다. 그런 다음 컴포넌트 B는 추가 데이터를 컴포넌트 A에 반환하고, 컴포넌트 A는 레거시 시스템의 API와 상호 작용하여 새 데이터 값을 검색하는 컴포넌트 C(3)를 호출합니다. 그런 다음 컴포넌트 C는 데이터 값을 다시 컴포넌트 A로 반환합니다.
다음으로 컴포넌트 A는 축적된 데이터 중 일부를 컴포넌트 D(4)로 전송하고, 컴포넌트 D는 특정 폴더에 있는 텍스트 파일에 데이터를 씁니다. 그런 다음 컴포넌트 D는 정기적으로 예약된 일괄 가져오기를 통해 이 파일을 다른 시스템으로 가져올 때까지 기다립니다. 가져오기가 완료되면 컴포넌트 D는 성공 또는 실패 코드를 컴포넌트 A에 반환합니다. 컴포넌트 A는 마지막으로 지금까지 수집한 모든 데이터가 포함된 응답을 서비스 소비자 A(5)에 보내고 서비스 소비자 A는 모든 데이터를 데이터베이스 B에 씁니다(6).
구성 요소 A, B, C, D는 서비스 A 서비스 아키텍처에 속합니다. 데이터베이스 A, 레거시 시스템 및 파일 폴더는 IT 기업 내에서 공유 리소스입니다.
서비스 A는 지난 몇 년 동안 성장한 서비스 아키텍처를 가진 엔티티 서비스입니다. 서비스 인벤토리 전반의 재설계 프로젝트의 결과로 서비스 소비자 A와 관련된 서비스 A의 동작을 방해하지 않으면서 컴포넌트 B, C, D가 제공하는 로직을 세 가지 유틸리티 서비스로 분리하기 위해 서비스 A 서비스 아키텍처를 다시 검토하라는 요청을 받게 됩니다.
이러한 요구 사항을 충족하기 위해 어떤 조치를 취할 수 있나요?

레거시 래퍼 패턴을 적용하여 컴포넌트 B를 공유 데이터베이스를 래핑하는 별도의 래퍼 유틸리티 서비스로 분리할 수 있습니다. 비동기 대기열 패턴을 적용하여 구성 요소 A와 구성 요소 C 사이에 메시징 대기열을 배치하여 레거시 시스템을 사용할 수 없거나 IT 기업의 다른 부분에서 많이 액세스할 수 있는 시간 동안 통신할 수 있도록 할 수 있습니다. 서비스 페이게이트 패턴을 적용하여 구성 요소 A와 구성 요소 D 사이에 페이게이트 구성 요소를 추가하여 동작의 변화를 보상할 수 있도록 할 수 있습니다. 서비스 자율성 원칙을 서비스 A에 추가로 적용하여 구성 요소를 별도의 래퍼 유틸리티 서비스로 분할함으로써 발생할 수 있는 성능 손실을 보완할 수 있습니다.

레거시 래퍼 패턴을 적용하여 컴포넌트 B를 공유 데이터베이스를 래핑하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 다시 적용하여 컴포넌트 C를 레거시 시스템 API의 래퍼 역할을 하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 컴포넌트 D에 다시 한 번 적용하여 파일 폴더에 대한 표준화된 액세스를 제공하는 또 다른 유틸리티 서비스로 분리할 수 있습니다. 서비스 페이게이트 패턴을 적용하여 컴포넌트 A와 새 래퍼 유틸리티 서비스 사이에 각각 하나씩 세 개의 페이게이트 컴포넌트를 추가할 수 있습니다. 이렇게 하면 페이게이트 구성 요소는 분리로 인해 발생할 수 있는 동작 변경을 보완할 수 있습니다. 서비스 컴포저빌리티 원칙은 서비스 A와 3개의 새로운 래퍼 유틸리티 서비스에 추가로 적용하여 4개의 서비스 모두 새로운 서비스 구성에 참여하도록 최적화할 수 있습니다. 이렇게 하면 세 가지 구성 요소를 별도의 서비스로 분리할 때 발생할 수 있는 성능 손실을 보완하는 데 도움이 됩니다.

레거시 래퍼 패턴을 적용하여 컴포넌트 B를 공유 데이터베이스를 래핑하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 레거시 래퍼 패턴을 다시 적용하여 컴포넌트 C를 레거시 시스템 API의 래퍼 역할을 하는 별도의 유틸리티 서비스로 분리할 수 있습니다. 컴포넌트 D도 별도의 서비스로 분리하고 이벤트 중심 메시징 패턴을 적용하여 이 새 서비스와 컴포넌트 A 사이에 게시자-구독자 관계를 설정할 수 있습니다. 그런 다음 서비스 소비자 A와 컴포넌트 A 간의 상호작용을 재설계하여 컴포넌트 A가 먼저 컴포넌트 B 및 새 래퍼 서비스와 상호작용하도록 할 수 있습니다. 그런 다음 서비스 A는 서비스 소비자 A에게 최종 메시지를 다시 전송합니다. 서비스 구성 가능성 원칙은 서비스 A와 세 개의 새로운 래퍼 유틸리티 서비스에 추가로 적용되어 네 개의 서비스가 모두 새로운 서비스 구성에 참여하도록 최적화될 수 있습니다. 이렇게 하면 세 가지 구성 요소를 별도의 서비스로 분할하여 발생할 수 있는 성능 손실을 보완하는 데 도움이 됩니다.

레거시 래퍼 패턴을 적용하여 컴포넌트 B가 공유 데이터베이스를 래핑하는 별도의 래퍼 유틸리티 서비스로 분리되도록 할 수 있습니다. 상태 저장소 및 상태 메시징 패턴을 적용하여 메시징 저장소를 구성 요소 A와 구성 요소 C 사이에 배치함으로써 레거시 시스템을 사용할 수 없거나 IT 기업의 다른 부분에서 많이 액세스할 수 있는 시간 동안 메타 데이터 중심 통신이 가능하도록 할 수 있습니다. 서비스 페이게이트 패턴을 적용하여 컴포넌트 A와 컴포넌트 D 사이에 페이게이트 컴포넌트를 추가하여 동작의 변화를 보상할 수 있도록 할 수 있습니다. 서비스 스테이트리스 원칙을 서비스 A에 추가로 적용하여 구성 요소를 별도의 래퍼 유틸리티 서비스로 분할함으로써 발생할 수 있는 성능 손실을 보완할 수 있습니다.

질문 20
전시를 참조하십시오.

서비스 A가 서비스 B에 메시지를 보냅니다(1). 서비스 B가 메시지 내용을 데이터베이스 A에 쓴 후(2), 서비스 A에 응답 메시지를 다시 보냅니다(3). 그런 다음 서비스 A는 서비스 C로 메시지를 보냅니다(4). 이 메시지를 수신한 서비스 C는 서비스 D로 메시지를 보내고(5), 서비스 D는 메시지 내용을 데이터베이스 B에 쓰고(6) 다시 서비스 C로 응답 메시지를 발행합니다(7).
서비스 A 및 서비스 D는 서비스 인벤토리 A에, 서비스 B 및 서비스 C는 서비스 인벤토리 B에 있습니다.
이 서비스 구성 아키텍처에서 네 가지 서비스 모두 송장 관련 데이터를 XML 형식으로 교환하고 있다고 합니다. 그러나 서비스 인벤토리 A의 서비스는 인보이스 데이터에 서비스 인벤토리 B의 서비스와 다른 XML 스키마를 사용하도록 표준화되어 있습니다. 또한 데이터베이스 A는 CSV(쉼표로 구분된 값) 형식의 데이터만 받아들일 수 있으므로 XML 형식의 데이터는 받아들일 수 없습니다. 데이터베이스 B는 XML 형식의 데이터만 허용합니다. 그러나 이 데이터베이스는 서비스 인벤토리 A 또는 서비스 인벤토리 B의 서비스에서 사용하는 XML 스키마와 다른 독점적인 XML 스키마를 사용하여 송장 데이터를 나타내는 레거시 데이터베이스입니다.
이 네 가지 서비스 간에 계획된 데이터 교환을 활성화하려면 어떤 조치를 취할 수 있나요?

데이터 모델 변환 패턴은 데이터 모델 변환 로직이 서비스 A와 서비스 B 사이, 서비스 C와 서비스 D 사이, 서비스 D 로직과 데이터베이스 B 사이에 위치하도록 적용할 수 있으며, 데이터 형식 변환 패턴은 데이터 형식 변환 로직이 서비스 A와 서비스 C 사이, 서비스 B 로직과 데이터베이스 A 사이에 위치하도록 적용할 수 있습니다.

프로토콜 브리징 패턴은 프로토콜 변환 로직이 서비스 B 로직과 데이터베이스 A 사이에 위치하도록 적용할 수 있으며, 데이터 형식 변환 패턴은 데이터 형식 변환 로직이 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이, 서비스 C와 서비스 D 사이, 서비스 D 로직과 데이터베이스 B 사이에 위치하도록 적용할 수 있습니다.

데이터 모델 변환 패턴은 데이터 모델 변환 로직이 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이, 서비스 C와 서비스 D 사이, 서비스 D 로직과 데이터베이스 B 사이에 위치하도록 적용할 수 있으며, 데이터 형식 변환 패턴은 데이터 형식 변환 로직이 서비스 B 로직과 데이터베이스 A 사이에 위치하도록 적용할 수 있습니다.

프로토콜 브리징 패턴은 프로토콜 변환 로직이 서비스 A와 서비스 B 사이, 서비스 A와 서비스 C 사이, 서비스 C와 서비스 D 사이에 위치하도록 적용할 수 있으며, 데이터 형식 변환 패턴은 데이터 형식 변환 로직이 서비스 B 로직과 데이터베이스 A 사이, 서비스 D 로직과 데이터베이스 B 사이에 위치하도록 적용할 수 있습니다.

질문 21
전시를 참조하십시오.

서비스 A, B 및 C는 비독립적인 작업 서비스입니다. 서비스 A와 서비스 B는 동일한 공유 상태 데이터베이스를 사용하여 런타임에 상태 데이터를 지연시킵니다.
세 서비스를 평가한 결과, 각 서비스에는 불가지론적 로직이 일부 포함되어 있는데, 이는 불가지론적 로직과 함께 번들로 제공되기 때문에 재사용할 수 없는 것으로 나타났습니다.
또한 서비스 A, 서비스 B 및 공유 상태 데이터베이스가 각각 물리적으로 분리된 환경에 있기 때문에 서비스 A와 서비스 B가 공유 상태 데이터베이스와 상호 작용하는 데 필요한 원격 통신으로 인해 런타임 성능이 부당하게 저하되고 있다고 판단합니다.
오케스트레이션 패턴을 적용하면 이 아키텍처를 어떻게 개선할 수 있을까요?

오케스트레이션 패턴을 적용하면 공식 엔드포인트, 상태 저장소, 서비스 데이터 복제 패턴이 자동으로 적용되어 공유 상태 데이터베이스가 서비스 A와 B의 공식 서비스 엔드포인트를 통해 복제되어 각 작업 서비스가 고유한 전용 상태 데이터베이스를 가질 수 있는 환경이 만들어집니다.

오케스트레이션 패턴을 적용하면 서비스 A, B, C에 존재하는 애그노스틱 로직과 비애그노스틱 로직을 깔끔하게 분리할 수 있는 환경이 만들어지며, 서비스 재사용성 원칙을 적용하여 재사용 가능성이 보장된 새로운 애그노스틱 서비스를 설계해야 할 필요가 있습니다. 오케스트레이션 환경에 의해 지원되고 로컬로 제공되는 상태 저장소 패턴은 서비스 A와 B가 공유할 수 있는 중앙 상태 데이터베이스를 제공하며, 로컬 상태 데이터베이스는 원격 통신의 문제를 방지합니다.

오케스트레이션 패턴을 적용하면 보상 서비스 트랜잭션이 자동으로 적용되는 환경이 조성되어 서비스 A와 B가 원격으로 상태 데이터베이스에 액세스해야 하는 성능 문제를 보완하는 데 사용할 수 있는 정교한 예외 로직을 생성할 수 있습니다. API 게이트웨이 및 서비스 브로커 패턴도 자동으로 적용되어 중앙 처리 계층에서 공통 변환 기능을 제공하여 새로운 애그노스틱 서비스를 위해 생성해야 하는 서비스 계약의 불균형을 극복하는 데 도움을 줍니다.

오케스트레이션 패턴은 필요한 상태 저장소의 호스팅을 지원하지 않으므로 이 아키텍처에는 적용할 수 없습니다.

질문 22

클라이언트 및 벤더 서비스는 현재 여러 서비스 구성의 일부인 애그노스틱 서비스입니다. 따라서 이러한 서비스는 때때로 여러 서비스 소비자가 동시에 액세스할 수 있습니다.
클라이언트 서비스는 주로 클라이언트 데이터베이스에 데이터 액세스 로직을 제공하지만 다른 서비스와 협력하여 고객의 신용 등급을 결정하기도 합니다. 벤더 서비스는 일부 데이터 액세스 로직을 제공하지만 특수한 비즈니스 요구 사항에 따라 다양한 동적 보고서를 생성할 수도 있습니다.
두 서비스의 런타임 활동에 대한 과거 통계를 검토한 결과, 클라이언트 서비스가 점점 더 많은 수의 서비스 소비자에게 서비스를 제공하고 있는 것으로 나타났습니다. 이 서비스는 정기적으로 시간이 초과되고 있으며, 이로 인해 서비스 소비자들이 요청을 재시도함에 따라 호출률이 증가합니다. 공급업체 서비스는 때때로 서비스 수준 계약(SLA)을 충족하는 데 어려움을 겪으며, 이러한 상황이 발생하면 페널티가 부과됩니다.
최근 고객 서비스의 관리자는 서비스 인벤토리 외부의 새로운 서비스 소비자에게 고객 서비스를 제공할 것이라는 통지를 받았습니다. 클라이언트 서비스는 인터넷을 통해 서비스에 연결하는 모든 서비스 소비자에게 무료 신용 평가 점수를 제공할 것입니다. 벤더 서비스는 서비스 인벤토리 내부에 유지되며 외부 액세스에 노출되지 않습니다.
다음 중 이러한 문제와 요구 사항을 해결하는 솔루션을 설명하는 문장은 어느 것입니까?

API 게이트웨이 패턴은 인벤토리 엔드포인트 패턴과 함께 서비스 인벤토리에 적용하여 외부 서비스 소비자가 액세스하고 클라이언트 서비스와 상호 작용하여 외부 서비스 소비자 요청을 처리하는 인벤토리 엔드포인트 서비스 및 중개 처리 계층을 설정할 수 있습니다. 중복 구현 패턴은 클라이언트 및 벤더 서비스 모두에 적용하여 가용성과 확장성을 높일 수 있습니다.

공식 엔드포인트 패턴은 클라이언트 서비스에 적용하여 서비스 인벤토리 외부의 서비스 소비자가 사용할 수 있는 관리형 엔드포인트를 설정할 수 있습니다. 동시 계약 패턴은 공급업체 서비스에 적용하여 첫 번째 연결 시도가 실패할 경우 대체 클라이언트 서비스 구현과 연결할 수 있도록 할 수 있습니다.

상태 저장소 패턴을 클라이언트 및 벤더 서비스에 적용하여 런타임 성능 문제를 극복하는 데 사용할 수 있는 중앙 명세서 관리 데이터베이스를 구축할 수 있습니다. 공식 엔드포인트 패턴을 추가로 적용하여 서비스 인벤토리 외부의 서비스 소비자를 위한 클라이언트 서비스의 가용성 및 확장성을 높일 수 있습니다.

마이크로서비스 배포 패턴은 클라이언트 서비스에 적용되어 더 다양한 서비스 소비자에 대한 자율성과 응답성을 향상시킵니다. 컨테이너화 패턴은 벤더 서비스에 적용되어 보고서 관련 처리를 위한 고도의 격리된 관리 환경을 구축합니다. 엔드포인트 리디렉션 패턴은 서비스 인벤토리 외부에 있는 서비스 소비자의 요청 메시지가 클라이언트 서비스에서 리디렉션되도록 하기 위해 추가로 적용됩니다.

질문 23

그림에 표시된 서비스 A의 아키텍처는 서비스 A의 핵심 로직이 시간이 지남에 따라 데이터베이스 및 독점 레거시 시스템(1)에 연결하고 서로 다른 서비스 소비자가 액세스하는 두 개의 개별 서비스 계약(2)을 지원하기 위해 어떻게 확장되었는지를 보여줍니다.
서비스 계약은 서비스 로직과 완전히 분리되어 있습니다. 따라서 서비스 로직은 서비스 계약과 기본 구현 리소스(데이터베이스 및 레거시 시스템)에 연결됩니다.
서비스 A에는 현재 세 명의 서비스 소비자가 있습니다. 서비스 소비자 A와 서비스 소비자 B는 서비스 A의 두 서비스 계약에 액세스합니다(3, 4). 서비스 소비자 C는 서비스 계약을 우회하여 서비스 로직에 직접 액세스합니다(5).
현재 A 서비스에서 사용 중인 데이터베이스와 레거시 시스템을 다른 제품으로 교체한다고 들었습니다. 두 서비스 계약은 핵심 서비스 로직과 완전히 분리되어 있지만, 새로운 제품 도입으로 인해 핵심 서비스 로직이 이전과 다르게 동작할 수 있다는 우려가 여전히 존재합니다.
새로운 제품 도입에 대비하여 서비스 소비자 A와 B에 미치는 영향을 최소화하기 위해 서비스 소비자 A 아키텍처를 변경하려면 어떤 조치를 취할 수 있나요? 서비스 소비자 C와의 소비자 간 결합을 피하기 위해 취할 수 있는 추가 조치는 무엇인가요?

서비스 페이게이트 패턴은 핵심 서비스 로직과 서비스 소비자 A와 B 사이에 페이게이트 구성 요소를 배치하는 데 적용될 수 있으며, 이러한 페이게이트 구성 요소는 서비스 A의 동작을 규제하도록 설계됩니다. 서비스 추상화 원칙은 서비스 A의 핵심 서비스 로직의 구현 세부 사항을 숨겨서 이 로직의 구현 변경을 차단하는 데 적용될 수 있습니다. 스키마 중앙 집중화 패턴을 적용하여 서비스 소비자 C가 기존 서비스 계약 중 하나를 통해 서비스 A에 액세스하도록 강제할 수 있습니다.

계약 중앙 집중화 패턴을 적용하여 세 번째 서비스 계약을 함께 추가할 수 있습니다. 이렇게 하면 서비스 소비자 C가 새 서비스 계약을 통해 서비스 A에 액세스하게 됩니다. 서비스 페이게이트 패턴을 적용하여 새 서비스 계약과 서비스 소비자 C 사이에 페이게이트 구성 요소를 배치하여 서비스 A의 동작을 규제할 수 있습니다. 서비스 추상화 원칙을 적용하여 서비스 A의 구현 세부 사항을 숨겨 향후 서비스 소비자가 서비스 A의 기본 자원에 직접 액세스하지 못하도록 설계할 수 있습니다.

서비스 페이게이트 패턴은 핵심 서비스 로직과 두 서비스 컨트랙트 사이에 페이게이트 구성 요소를 배치하는 데 적용할 수 있습니다. 이러한 페이게이트 구성 요소는 서비스 A의 동작을 규제하도록 설계되며, 부정적인 형태의 결합을 피하기 위해 서비스 느슨한 결합 원칙을 적용할 수 있습니다.

서비스 페이게이트 패턴은 핵심 서비스 로직과 구현 리소스(데이터베이스 및 레거시 시스템) 사이에 페이게이트 구성 요소를 배치하는 데 적용할 수 있습니다. 이러한 페이게이트 구성 요소는 서비스 A의 핵심 서비스 로직이 기본 구현 리소스의 변경으로부터 격리되도록 설계됩니다. 스키마 중앙 집중화 및 엔드포인트 리디렉션 패턴을 적용하여 서비스 소비자 C가 기존 서비스 계약 중 하나를 통해 서비스 A에 액세스하도록 강제할 수도 있습니다.