거래 시스템 디자인 패턴
거래 시스템 : 시스템 설계 - 제 1 부.
이 튜토리얼의 이전 섹션에서는 거래 시스템을 구성하는 요소를 살펴보고 실시간 거래 환경에서 이러한 시스템을 사용하는 데 따른 장단점에 대해 설명했습니다. 이 섹션에서는 시스템 트레이딩에 특히 적합한 시장을 조사하여 그 지식을 기반으로합니다. 그런 다음 다양한 장르의 거래 시스템을보다 심층적으로 살펴 보겠습니다.
주식 시장은 아마도 초보자들 사이에서 거래되는 가장 일반적인 시장 일 것입니다. 이 분야에서 워렌 버핏 (Warren Buffett)과 메릴린치 (Merrill Lynch)와 같은 거물급 기업이 우세하고 전통적인 가치 및 성장 투자 전략이 가장 보편적입니다. 그럼에도 불구하고 많은 기관들이 거래 시스템의 설계, 개발 및 구현에 상당한 투자를 해왔습니다. 개인 투자자들은 천천히이 경향에 동참하고 있습니다.
대량의 주식을 사용하면 거래자는 매우 다양한 휘발성 장외 주식 (OTC)에서부터 비 휘발성 파란색 칩에 이르기까지 다양한 유형의 주식에 대해 시스템을 테스트 할 수 있습니다.
거래 시스템의 효율성은 일부 주식, 특히 OTC 및 분홍색 시트 문제의 낮은 유동성으로 인해 제한 될 수 있습니다.
커미션은 성공적인 거래로 인해 이익을 얻을 수 있으며 손실을 증가시킬 수 있습니다. OTC와 핑크 시트 주식은 추가 수수료를 부과하기도합니다.
사용되는 주요 거래 시스템은 가치를 추구하는 시스템입니다. 즉, 보안이 과거 성과, 동급 업체 또는 시장 전반에 비해 저평가되어 있는지를 결정하기 위해 다양한 매개 변수를 사용하는 시스템입니다.
외환 시장 또는 외환 시장은 세계에서 가장 크고 가장 유동적 인 시장입니다. 세계의 정부, 은행 및 기타 대형 기관들은 매일 외환 시장에서 수조 달러를 거래합니다. forex에 기관 무역상의 대다수는 무역 체계에 의지합니다. 외환 거래를하는 개인의 경우에도 마찬가지이지만 경제 보고서 나이자 지불금을 기반으로하는 일부 거래는 마찬가지입니다.
이 시장의 유동성은 대량으로 인해 거래 시스템을보다 정확하고 효율적으로 만듭니다.
이 시장에는 커미션이없고 퍼짐 만 있습니다. 따라서 비용을 늘리지 않고도 많은 거래를하는 것이 훨씬 쉽습니다.
이용할 수있는 주식이나 상품의 양과 비교할 때, 거래 할 통화의 수는 제한되어 있습니다. 그러나 소액 국가의 통화 인 '이국적인 통화 쌍'의 가용성으로 인해 변동성의 범위가 반드시 제한되는 것은 아닙니다.
forex에서 사용 된 주요 거래 시스템은 트렌드를 따르는 시스템 (시장에서 인기있는 트렌드는 "트렌드는 당신의 친구"입니다) 또는 브레이크 아웃에서 구매하거나 판매하는 시스템입니다. 이는 경제 지표가 종종 한 번에 큰 물가 움직임을 유발하기 때문입니다.
주식, 외환 및 상품 시장은 모두 선물 거래를 제공합니다. 이 레버리지는 시스템 트레이딩에 널리 사용되는 수단으로 이용 가능한 레버리지가 많아지고 유동성과 변동성이 증가합니다. 그러나 이러한 요소는 두 가지 방법을 모두 줄일 수 있습니다. 이득을 증폭 시키거나 손실을 증폭시킬 수 있습니다. 이러한 이유로 선물의 사용은 일반적으로 고급 개인 및 기관 시스템 거래자를 위해 예약되어 있습니다. 이는 선물 시장을 자본화 할 수있는 트레이딩 시스템이 훨씬 더 많은 커스터마이징을 필요로하기 때문에보다 발전된 지표를 사용하고 개발하는데 더 오래 걸리기 때문입니다.
어떤 시장이 시스템 트레이딩에 가장 적합한 지 결정하는 것은 개인 투자자에게 달려 있습니다. 각 시장은 각각 장단점이 있습니다. 대부분의 사람들은 주식 시장에 대해 더 잘 알고 있으며 이러한 친숙 함으로 인해 거래 시스템을보다 쉽게 개발할 수 있습니다. 그러나 외환은 흔히 경험이 많은 거래자들 사이에서 거래 시스템을 운영하는 우수한 플랫폼으로 여겨지고 있습니다. 더욱이, 상인이 레버리지와 변동성을 증가 시키기로 결정하면 선물 대안은 항상 열려 있습니다. 궁극적으로 선택은 시스템 개발자의 손에 달려 있습니다.
시스템 트레이딩의 가장 일반적인 방법은 경향 추종 시스템입니다. 가장 근본적인 형태로, 이 시스템은 중요한 가격 움직임을 단순히 기다린 다음 그 방향으로 구매하거나 판매합니다. 이러한 유형의 시스템은 이러한 가격 변동이 추세를 유지할 수 있기를 희망합니다.
이동 평균 시스템.
기술적 분석에서 자주 사용되는 이동 평균은 일정 기간 동안 주식의 평균 가격을 단순히 표시하는 지표입니다. 경향의 본질은이 측정에서 파생됩니다. 진입과 퇴출을 결정하는 가장 일반적인 방법은 크로스 오버입니다. 이러한 논리는 간단합니다. 가격이 과거 가격 평균 (추세)보다 높거나 낮을 경우 새로운 추세가 형성됩니다. 다음은 IBM의 가격 (청색 선)과 20 일 MA (적색 선)를 나타내는 차트입니다.
이러한 유형의 시스템의 기본 개념은 이동 평균 시스템의 개념과 유사합니다. 새로운 최고점 또는 최저점이 설정되면 가격 움직임이 가장 큰 방향으로 이어질 가능성이 높습니다. 브레이크 아웃을 결정하는 데 사용할 수있는 한 가지 지표는 간단한 Bollinger Band & reg입니다. 위에 까는 것. Bollinger Bands & reg; 가격이 높고 낮은 가격의 평균을 보여주고, 가격이 밴드의 가장자리를 만날 때 발생합니다. 다음은 가격 (파란색 선)과 Bollinger Bands & reg를 그려주는 차트입니다. (회색 선) Microsoft의 :
Trend-Following 시스템의 단점 :
경험적 의사 결정 필요 - 추세를 결정할 때 항상 고려해야 할 경험 요소가 있습니다 : 역사적 추세의 지속 시간. 예를 들어, 이동 평균은 지난 20 일 동안 또는 지난 5 년 동안이 될 수 있으므로 개발자는 어떤 시스템이 시스템에 가장 적합한 지 결정해야합니다. 결정할 다른 요인은 브레이크 아웃 시스템의 평균 최고 및 최저입니다.
느린 자연 - 이동 평균 및 브레이크 아웃 시스템은 항상 뒤떨어져 있습니다. 다른 말로하면, 그들은 트렌드의 정확한 상단이나 하단을 결코 칠 수 없습니다. 이것은 필연적으로 잠재적 이익의 몰수를 가져 오며 때로는 중요 할 수 있습니다.
Whipsaw Effect - 경향 추종 시스템의 성공에 해로운 시장 세력 중 가장 일반적인 현상 중 하나입니다. Whipsaw 효과는 이동 평균이 거짓 신호를 생성 할 때 발생합니다. 즉 평균이 범위로 떨어지면 방향이 갑자기 바뀝니다. 효과적인 정지 손실 및 위험 관리 기술이 적용되지 않는 한 막대한 손실을 초래할 수 있습니다.
측면 시장 - 추세 추적 시스템은 본질적으로 실제로 경향을 보이는 시장에서만 수익을 창출 할 수 있습니다. 그러나 시장 또한 오랜 기간 동안 특정 범위 내에 머무르면서 옆으로 움직입니다.
극단적 인 변동성이 발생할 수 있음 - 때로는 추세를 따르는 시스템이 극단적 인 변동성을 겪을 수 있지만 상인은 자신의 시스템을 고수해야합니다. 그렇게 할 수 없다는 것은 확실한 실패를 초래할 것입니다.
기본적으로 카운터 트렌드 시스템의 목표는 최저 최저 가격으로 구매하고 최고 최고 가격으로 판매하는 것입니다. 이 추세 추종 시스템과의 주요 차이점은 추돌 시스템이 자체 수정이 아니라는 점입니다. 즉, 포지션을 종료 할 정해진 시간이 없기 때문에 무제한적인 잠재력을 갖게됩니다.
카운터 트렌드 시스템의 유형.
많은 종류의 시스템이 카운터 트렌드 시스템으로 간주됩니다. 한 방향의 운동량이 퇴색하기 시작하면 구매하는 것이 좋습니다. 이것은 오실레이터를 사용하여 가장 자주 계산됩니다. 예를 들어, stochastics 또는 다른 상대 강도 표시기가 특정 지점 아래로 떨어지면 신호가 생성 될 수 있습니다. 카운터 트레드 트레이딩 시스템에는 다른 유형이 있지만, 모두가 낮은 구매와 높은 매도와 같은 기본적 목표를 공유합니다.
예를 들어, 시스템 개발자가 결정해야하는 요소 중 하나는 상대 강도 지표가 희미 해지는 지점입니다.
극단적 인 변동성이 발생할 수 있음 - 이러한 시스템은 극단적 인 변동성을 경험할 수 있으며 이러한 변동성에도 불구하고 시스템을 고수 할 수 없으면 실패가 발생할 수 있습니다.
무제한 단점 - 앞서 언급했듯이 시스템이 자체 수정 기능이 없으므로 무제한적인 잠재력이 있습니다 (위치를 종료 할 시간이 없음).
거래 시스템이 적합한 주요 시장은 주식, 외환 및 선물 시장입니다. 각 시장에는 장점과 단점이 있습니다. 트레이딩 시스템의 두 가지 주요 장르는 트렌드 추종 시스템과 카운터 트렌드 시스템입니다. 이들의 차이점에도 불구하고 개발 단계에서 두 유형의 시스템 모두 개발자 측에서 경험적 의사 결정을 필요로합니다. 또한 이러한 시스템은 극심한 변동성을 겪기 때문에 일부 체력을 요구할 수 있습니다. 시스템 트레이더는이 시간 동안 자신의 시스템을 고수하는 것이 필수적입니다. 다음 연재에서는 거래 시스템을 설계하고 시스템 트레이더가 자신의 삶을 편하게하기 위해 사용하는 소프트웨어에 대해 논의하는 방법에 대해 자세히 살펴볼 것입니다.
거래 시스템 디자인 패턴
App Store를 통해 가져 오기 우리의 응용 프로그램 에서이 게시물을 읽으십시오!
Java Trading Application 개발 : 거래 규칙을 정의하기위한 패턴 / 프레임 워크가 있습니까?
시장에 주문을하기 위해 시장의 API를 사용할 거래 응용 프로그램을 설계하는 중입니다. 이것은 투자 은행에서 발견되는 복잡한 고성능 알고리즘 거래 애플리케이션이 아닙니다. 이것은 시장 조건 / 추세에 따라 아마 하루에 두세 번 거래하는 작은 개인 응용 프로그램 일뿐입니다.
응용 프로그램은 대략 다음 모듈 / 패키지로 구성됩니다.
- 실제 거래 알고리즘.
- 라이브 가격을 분석하기위한 수업 & amp; 구매 / 판매 신호를 생산하는 시장에서의 주문.
- 시장과의 연결을 유지하고 시장 정보를 검색하며 구매 / 판매 주문을하는 데 사용되는 클래스.
지금까지 응용 프로그램에 필요한 모든 것이 인터넷에서 사용 가능한 것으로 보입니다.
* 시장의 웹 서비스에 액세스하는 데 사용되는 Java 클래스를 생성하는 Apache CXF.
* 가격 분석을 수행하기위한 Apache Maths.
* 공장, 주제 / 관찰자, 주 등 다양한 디자인 패턴에 대한 위키피디아.
내가 정말로 붙어있는 곳은 알고리즘이다. 나는 상태 패턴을 사용하여 특정 시장 조건이 충족 될 때 수행되어야하는 다양한 로직을 논리적 그룹으로 나누기로 결정했습니다. 문제는 각 상태 클래스가 if 문을 폭발적으로 포함 할 가능성이 매우 높다는 것을 알기 시작했습니다.
내가 도울 수는 없지만 뭔가를 놓치고있는 것, 그리고 개발자가 주어진 비즈니스 컨텍스트의 모든 입력과 출력을 유한 수로 캡슐화 할 수 있도록하는 프레임 워크 나 디자인 패턴이 존재해야한다는 것을 알았습니다. 비즈니스 규칙 [알고리즘]을 작성할 수있는 비즈니스 작업 [입 / 출력]. 나는. 알고리즘을 하드 코딩하지 않고 응용 프로그램을 어떤 종류의 규칙 프로세서로 만들 수 있어야한다고 생각합니다. 불행히도 나는 이것을 어디에서 시작해야할지 모른다. 나는 네가 나에게 알려 주길 바란다면 내가 분명히 나의 딜레마에 대해 충분히 설명했으면 좋겠다. 고맙습니다.
몇 가지 규칙 엔진을 살펴볼 것입니다.
실시간 시장 데이터에 반응 할 가능성이 있습니다. 이것은 복잡한 이벤트 처리 (CEP) 도구가 완벽 할 수있는 것입니다. 검사.
알고리즘 트레이딩 시스템 아키텍처.
이전에이 블로그에서 지적 알고리즘 트레이딩 시스템의 개념적 아키텍처와 생산 알고리즘 트레이딩 시스템의 기능적 및 비 기능적 요구 사항에 대해 작성했습니다. 그 이후로 필자는 이러한 아키텍처 요구 사항을 충족시킬 수 있다고 믿는 시스템 아키텍처를 설계했습니다. 이 글에서는 ISO / IEC / IEEE 42010 시스템의 지침과 소프트웨어 엔지니어링 아키텍처 설명 표준을 따르는 아키텍처에 대해 설명합니다. 이 표준에 따르면 아키텍처 설명은 다음과 같아야합니다.
여러 표준화 된 아키텍처 뷰 (예 : UML) 및 설계 결정과 아키텍처 요구 사항 간의 추적 가능성 유지.
소프트웨어 아키텍처 정의.
시스템 아키텍처가 무엇인지에 대해서는 아직 합의가 이루어지지 않았습니다. 이 기사의 맥락에서 기능 요구 사항을 충족시키는 응용 프로그램 구성 요소를 지정, 배포 및 실행할 수있는 인프라로 정의됩니다. 기능 요구 사항은 시스템 및 해당 구성 요소의 예상 기능입니다. 비 기능 요구 사항은 시스템의 품질을 측정 할 수있는 방법입니다.
비 기능 요구 사항이 만족스럽지 않으면 기능 요구 사항을 완전히 만족시키는 시스템은 기대에 미치지 못할 수 있습니다. 이 개념을 설명하기 위해 다음과 같은 시나리오를 고려하십시오. 방금 구입했거나 구축 한 알고리즘 거래 시스템이 우수한 거래 결정을 내리지 만 조직의 위험 관리 및 회계 시스템과 완전히 작동하지 않습니다. 이 시스템이 귀하의 기대에 부응합니까?
개념적 아키텍처입니다.
개념적보기는 높은 수준의 세분화 수준에서 시스템에 존재하는 고급 개념과 메커니즘을 설명합니다. 이 수준에서 알고리즘 트레이딩 시스템은 4 개의 레이어와 두 가지 아키텍처 측면에서 분리 된 이벤트 기반 아키텍처 (EDA)를 따릅니다. 각 레이어 및 aspect 참조 아키텍처 및 패턴이 사용됩니다. 건축 패턴은 특정 요구 사항을 달성하기위한 입증 된 일반 구조입니다. 건축 측면은 여러 구성 요소에 걸쳐있는 교차 절단 문제입니다.
이벤트 중심 아키텍처 - 이벤트를 생성, 감지, 소비 및 반응하는 아키텍처입니다. 이벤트에는 실시간 시장 이동, 복잡한 이벤트 또는 트렌드, 거래 이벤트가 포함됩니다. 주문 제출.
이 다이어그램은 알고리즘 거래 시스템의 개념적 아키텍처를 보여줍니다.
참조 아키텍처.
비유를 사용하기 위해 기준 아키텍처는 내 하중 벽에 대한 청사진과 유사합니다. 이 청사진은 공통적으로 발생하는 요구 사항을 충족시키기 때문에 어떤 건물이 건설되고 있는지에 관계없이 여러 건물 설계에 재사용 할 수 있습니다. 마찬가지로 참조 아키텍처는 특정 요구 사항을 만족하는 구체적인 소프트웨어 아키텍처를 구성하는 데 사용할 수있는 일반 구조 및 메커니즘을 포함하는 템플릿을 정의합니다. 알고리즘 거래 시스템의 아키텍처는 공간 기반 아키텍처 (SBA)와 모델 뷰 컨트롤러 (MVC)를 참조로 사용합니다. 운영 데이터 저장소 (ODS), 추출 변환 및로드 (ETL) 패턴 및 데이터웨어 하우스 (DW)와 같은 우수 사례도 사용됩니다.
모델보기 컨트롤러 - 정보의 표현과 사용자의 상호 작용을 구분하는 패턴입니다. 공간 기반 아키텍처 - 느슨하게 연결된 처리 장치가 공간이라고하는 공유 연관 메모리 (아래 참조)를 통해 서로 상호 작용하는 인프라를 지정합니다.
구조보기.
아키텍처 구조 뷰는 알고리즘 거래 시스템의 구성 요소와 하위 구성 요소를 보여줍니다. 또한 이러한 구성 요소가 물리적 인프라에 어떻게 배치되는지를 보여줍니다. 이 뷰에 사용 된 UML 다이어그램에는 구성 요소 다이어그램과 배포 다이어그램이 포함됩니다. 다음은 SBA 참조 아키텍처의 전체 알고리즘 트레이딩 시스템 및 처리 단위의 배포 다이어그램과 각 계층의 관련 구성 요소 다이어그램 갤러리입니다.
자동화 된 상인 / 이벤트 처리 구성 요소 다이어그램 데이터 소스 및 사전 처리 계층 구성 요소 다이어그램 MVC 기반 사용자 인터페이스 구성 요소 다이어그램.
건축 전술.
소프트웨어 엔지니어링 연구소에 따르면 아키텍처 전술은 아키텍처 설계 결정을 통해 품질 속성 모델의 일부 측면을 조작하여 품질 요구 사항을 충족시키는 수단입니다. 알고리즘 거래 시스템 아키텍처에서 사용되는 간단한 예제는 연속 쿼리 구성 요소를 사용하여 운영 데이터 저장소 (ODS)를 '조작'하는 것입니다. 이 구성 요소는 복합 이벤트를 식별하고 추출하기 위해 ODS를 지속적으로 분석합니다. 아키텍처에서 사용되는 전술은 다음과 같습니다.
이벤트 및 순서 큐의 장애 패턴 이벤트 및 순서 큐의 공유 메모리 ODS의 CQL (Continuing Query Language) 수신 데이터의 필터 디자인 패턴을 사용한 데이터 필터링 모든 수신 및 송신 연결의 정체 방지 알고리즘 활성 큐 관리 (AQM ) 및 명시 적 정체 통지 업그레이드 용량을 갖춘 상용 컴퓨팅 리소스 (확장 가능) 모든 단일 실패 지점에 대한 능동 중복 ODS의 인덱싱 및 최적화 된 지속성 구조 ODS에 대한 정기적 인 데이터 백업 및 정리 스크립트 예약 모든 데이터베이스의 트랜잭션 내역 모든 오류를 탐지하는 명령 타임 스탬프가있는 이벤트에 주석 처리하여 '부실'이벤트를 건너 뜁니다. 최대 거래량 자동화 된 상인 구성 요소는 분석을 위해 메모리 내 데이터베이스를 사용합니다. AT에 연결하는 사용자 인터페이스의 2 단계 인증 사용자 인터페이스 및 AT 연결에 대한 암호화 MVC가보기를 관리하기위한 관찰자 디자인 패턴.
위의 목록은 아키텍처 설계 중 확인한 몇 가지 설계 결정 사항입니다. 그것은 전술의 완전한 목록이 아니다. 시스템이 개발됨에 따라 기능적 및 비 기능적 요구 사항을 충족시키기 위해 여러 가지 수준의 세분화 된 수준에서 추가적인 전술을 사용해야합니다. 다음은 장애 요인 디자인 패턴, 필터 디자인 패턴 및 연속 쿼리 구성 요소를 설명하는 세 가지 다이어그램입니다.
행동 적 견해.
이 아키텍처보기는 구성 요소와 계층이 서로 상호 작용하는 방법을 보여줍니다. 이는 아키텍처 설계를 테스트하고 시스템을 종단 간으로 이해하기위한 시나리오를 작성할 때 유용합니다. 이 뷰는 시퀀스 다이어그램과 활동 다이어그램으로 구성됩니다. 알고리즘 트레이딩 시스템의 내부 프로세스와 트레이더가 알고리즘 트레이딩 시스템과 상호 작용하는 방법을 보여주는 활동 다이어그램은 아래와 같습니다.
기술 및 프레임 워크.
소프트웨어 아키텍처 설계의 마지막 단계는 아키텍처를 실현하는 데 사용할 수있는 잠재적 기술 및 프레임 워크를 식별하는 것입니다. 일반적인 원칙으로서 기존 기술의 기능적 및 비 기능적 요구 사항을 적절하게 충족시키는 경우 더 나은 방법을 사용하는 것이 좋습니다. 프레임 워크는 구현 된 참조 아키텍처이다. JBoss는 JEE 참조 아키텍처를 구현하는 프레임 워크입니다. 알고리즘 트레이딩 시스템을 구현할 때 다음 기술과 프레임 워크가 흥미롭고 고려되어야합니다.
CUDA - NVidia는 고성능 전산 금융 모델링을 지원하는 많은 제품을 보유하고 있습니다. CPU 대신 GPU에서 몬테카를로 시뮬레이션을 실행할 때 성능을 최대 50 배 향상시킬 수 있습니다. Apache River - River는 분산 시스템을 개발하는 데 사용되는 툴킷입니다. 이것은 SBA 패턴 인 Apache Hadoop을 기반으로 애플리케이션을 빌드하기위한 프레임 워크로 사용되었습니다. 퍼베이시브 로깅이 필수 인 경우 Hadoop을 사용하면 큰 데이터 문제에 대한 흥미로운 솔루션을 제공합니다. Hadoop은 CUDA 기술을 지원하는 클러스터 환경에 배치 될 수 있습니다. AlgoTrader - 오픈 소스 알고리즘 거래 플랫폼. AlgoTrader는 자동화 된 상인 구성 요소의 위치에 잠재적으로 배치 될 수 있습니다. FIX 엔진 - FIX, FAST 및 FIXatdl을 포함한 FIX (Financial Information Exchange) 프로토콜을 지원하는 독립 실행 형 응용 프로그램입니다.
기술이나 프레임 워크는 아니지만 시스템과 구성 요소의 상호 운용성을 향상시키기 위해 API (Application Programming Interface)로 구성 요소를 구축해야합니다.
결론.
제안 된 아키텍처는 알고리즘 거래 시스템에서 확인 된 매우 일반적인 요구 사항을 충족 시키도록 설계되었습니다. 일반적으로 알고리즘 거래 시스템은 각 구현마다 다른 세 가지 요소로 복잡합니다.
외부 엔터프라이즈 및 Exchange 시스템에 대한 종속성 비 기능 요구 사항에 대한 도전과 진화하는 아키텍처 제약.
따라서 제안 된 소프트웨어 아키텍처는 특정 조직 및 규정 요구 사항을 충족시키고 지역 제약 조건을 극복하기 위해 사례별로 적용해야합니다. 알고리즘 거래 시스템 아키텍처는 자신의 알고리즘 거래 시스템을 설계하고자하는 개인 및 조직을위한 참고서 일뿐입니다.
사용 된 전체 사본 및 출처는 내 보고서 사본을 다운로드하십시오. 고맙습니다.
이전 이야기.
알고리즘 트레이딩 시스템 요구 사항.
다음 이야기.
Particle Swarm Optimization을 이용한 포트폴리오 최적화.
멋진 개관과 아키텍처에 대한 좋은 출발. 당신의 결론은 적절한 것이었고, 알고리즘 거래 소프트웨어 시스템이 관련성을 유지하기 위해 지속적인 백 테스트와 조정이 필요한 이유를 지적했습니다. 좋은 읽을 거리!
2016 년 2 월 1 일
상품 또는 고정 수입의 데이터가 부정확하거나 수신 속도가 느린 경우 모델은 특히 Black Swann 이벤트의 공간에서 계산하기가 어려울 수 있습니다.
이 기사를 주셔서 대단히 감사합니다. 1990 년대 후반부터 AI에 대해 생각해 봤는데 마침내 기술과 API가 일반적으로 제공됩니다. 기사와 블로그는 이전 연도의 꿈을 실현하는 첫 걸음을 내딛는 데 큰 도움이됩니다. 당신의 추가 벤처에 많은 감사와 행운을 빕니다!
귀하의 진전 상황을 계속 알려 주시기 바랍니다. 나는 아주 흥미 롭다. 고맙습니다.
댓글을 제출하십시오.
답장 취소.
Turing Finance를 팔로우하십시오.
Turing 금융 메일 링리스트.
Turing Finance의 친구들.
Quantocracy는 매일 매일 게시되는 새로운 분석에 대한 링크가있는 최고의 양적 금융 블로그 수집기입니다.
NMRQL은 내가 속한 양적 헤지 펀드 다. 우리는 기계 학습을 사용하여 시장을 이기고 시도합니다.
거래 시스템 디자인 패턴
(조나단 사이먼)
대규모 패턴 모음이나 패턴 언어에서 벗어나기 쉽습니다. 패턴은 아이디어를 재사용 가능한 형태로 추상화 한 것입니다. 흔히 패턴을 매우 유용하게 만드는 매우 일반적인 패턴은 이해하기 어렵게 만듭니다. 때때로 패턴을 이해하는 데 도움이되는 가장 좋은 방법은 실생활의 예입니다. 일어날 수있는 일에 대한 인위적 시나리오가 아닙니다. 그러나 실제로 일어나는 것과 일어날 일은 무엇인가.
이 장에서는 발견 프로세스를 사용하여 문제점을 해결하는 패턴을 적용합니다. 우리가 논의 할 시스템은 초기 설계부터 생산까지 2 년 동안 함께 일한 채권 거래 시스템입니다. 우리는 마주 치게되었던 시나리오와 문제 그리고 패턴으로 그것들을 해결하는 방법을 조사 할 것입니다. 여기에는 패턴을 선택하는 결정 프로세스뿐만 아니라 시스템 요구에 맞게 패턴을 결합하고 조정하는 방법이 포함됩니다. 또한 비즈니스 요구 사항, 고객 결정, 아키텍처 및 기술 요구 사항, 레거시 시스템 통합 등 실제 시스템에서 발생하는 세력을 고려하여이 모든 작업을 수행합니다. 이 접근법의 의도는 실용적인 응용을 통해 패턴 자체를보다 명확하게 이해하는 것입니다.
시스템 구축.
주요 월스트리트 투자 은행은 채권 매매 데스크의 업무 흐름을 간소화하기 위해 채권 가격 책정 시스템을 구축하기 시작했습니다. 현재 채권 거래자들은 다수의 채권 가격을 몇 개의 다른 거래 장소에 보내야하며 각 거래 장소에는 자체 사용자 인터페이스가 있습니다. 이 시스템의 목표는 단일 캡슐화 된 사용자 인터페이스에서 채권 시장에 특화된 고급 분석 기능과 함께 모든 채권 가격 책정의 세부 사항을 최소화하는 것입니다. 이는 다양한 통신 프로토콜을 통한 여러 구성 요소와의 통합 및 통신을 의미합니다. 시스템의 높은 수준의 흐름은 다음과 같습니다.
높은 수준의 흐름.
첫째, 시장 데이터가 시스템에 제공됩니다. 시장 데이터는 사람들이 자유 시장에서 채권을 사거나 팔고 자하는 것을 나타내는 채권의 가격 및 기타 자산과 관련된 데이터입니다. 시장 데이터는 즉시 데이터를 변경하는 분석 엔진으로 전송됩니다. 애널리틱스는 채권의 가격 및 기타 속성을 변경하는 금융 애플리케이션을위한 수학 함수를 말합니다. 이들은 입력 변수를 사용하여 함수의 결과를 특정 본드에 맞추는 일반 함수입니다. 각 상장 데스크톱에서 실행될 클라이언트 애플리케이션은 매매가별로 가격이 책정되는 각 채권에 대한 분석의 특성을 제어하면서 상거래 기준으로 분석 엔진을 구성합니다. 분석이 시장 데이터에 적용되면 수정 된 데이터가 다른 회사의 상인이 채권을 매매 할 수있는 다양한 거래 장소로 보내집니다.
패턴이있는 아키텍처.
시스템의 워크 플로우에 대한이 개요를 통해 우리는 설계 프로세스 중에 발생하는 일부 건축 문제에 접근 할 수 있습니다. Let†™ s는 우리가 지금까지 알고있는 것을 보았습니다. 거래자는 Windows NT 및 Solaris 워크 스테이션 모두에서 응답이 빠른 응용 프로그램이 필요합니다. 따라서 우리는 플랫폼 독립성과 사용자 입력 및 시장 데이터에 신속하게 응답 할 수 있기 때문에 클라이언트 애플리케이션을 Java 씩 클라이언트로 구현하기로 결정했습니다. 서버 측에서는 우리 시스템이 활용할 레거시 C ++ 구성 요소를 상속합니다. 시장 데이터 구성 요소는 TIBCO 정보 버스 (TIB) 메시징 인프라와 통신합니다.
우리는 다음 구성 요소를 상속 받고 있습니다.
시장 데이터 가격 공급 서버 : 들어오는 시장 데이터를 TIB에 게시합니다. 분석 엔진 : 들어오는 시장 데이터에 대한 분석을 수행하고 수정 된 시장 데이터를 TIB에 브로드 캐스트합니다. Contribution Server : 거래 장소와의 모든 통신을 수행합니다. 거래 장소는 은행이 통제하지 않는 제 3 자 구성 요소입니다.
기존 시장 데이터 하위 시스템.
유산 기여 하위 시스템.
개별 하위 시스템 (Java 씩 클라이언트, 시장 데이터 및 컨트 리뷰 션)이 통신하는 방법을 결정해야합니다. 두꺼운 클라이언트가 기존 서버와 직접 통신 할 수는 있지만 클라이언트에서 너무 많은 비즈니스 논리가 필요합니다. 대신, we†™ ll는 legacy servers†"시장 자료를위한 가격 설정 출입구에 거래 장소에 가격을 보내기를위한 기여금 출입구와 교통하기 위하여 자바 출입구 한 쌍을 건설합니다. 이렇게하면 이러한 영역과 관련된 비즈니스 논리를 멋지게 캡슐화 할 수 있습니다. 시스템의 현재 구성 요소는 다음과 같습니다. †marked로 표시된 연결. ”는 우리가 구성 요소의 일부가 어떻게 통신하는지 아직도 확신 할 수 없다는 것을 나타냅니다.
시스템과 그 구성 요소.
첫 번째 통신 질문은 데이터를 교환하기 위해 Java 씩 (thick) 클라이언트와 두 개의 Java 서버 구성 요소를 통합하는 방법입니다. Let†™ s는이 책에서 제안 된 네 가지 통합 스타일 인 파일 전송, 공유 데이터베이스, 원격 프로 시저 호출 및 메시징을 살펴 봅니다. 우리는 클라이언트와 데이터베이스 사이의 추상화 계층을 만들고 don†™ t가 클라이언트에 데이터베이스 액세스 코드를 갖고 싶어하므로 공유 데이터베이스를 즉시 제외 할 수 있습니다. 파일 전송은 현재 가격이 거래 장소로 보내지는 것을 보장하기 위해 최소한의 대기 시간이 필요하기 때문에 마찬가지로 배제 될 수 있습니다. 이로 인해 원격 프로 시저 호출 또는 메시징 중 하나가 선택됩니다.
Java 플랫폼은 원격 프로 시저 호출 및 메시징에 대한 기본 제공 지원을 제공합니다. RPC 스타일 통합은 RMI (Remote Method Invocation), CORBA 또는 EJB (Enterprise Java Beans)를 사용하여 수행 할 수 있습니다. Java Messaging Service (JMS)는 메시징 스타일 통합을위한 공통 API입니다. 따라서 두 가지 통합 스타일은 Java로 구현하기 쉽습니다.
따라서이 프로젝트, 원격 프로 시저 호출 또는 메시징에서 더 잘 작동합니까? There†™ s 가격 설정 출입구의 단지 1 개의 사례 및 체계에있는 기여금 출입구의 1 개의 인스턴스, 그러나 보통 많은 두꺼운 클라이언트는 동시에이 서비스 (특정 시간에 로그인되는 우연히 일어나는 각 채권 거래자를위한 하나)에 연결합니다. 또한이 은행은 다른 애플리케이션에서 활용할 수있는 일반적인 가격 책정 시스템을 원합니다. 따라서 알 수없는 수의 Think Client 외에도 게이트웨이에서 나오는 가격 데이터를 사용하는 다른 애플리케이션이 알려지지 않은 경우도 있습니다.
씩 클라이언트 (또는 가격 데이터를 사용하는 다른 응용 프로그램)는 RPC를 사용하여 게이트웨이에 전화를 걸면 가격 데이터를 받고 처리를 호출 할 수 있습니다. 그러나 가격 데이터는 지속적으로 게시되며 일부 고객은 특정 데이터에만 관심이 있으므로 적시에 적절한 고객에게 관련 데이터를 제공하는 것이 어려울 수 있습니다. 클라이언트는 게이트웨이를 폴링 할 수 있지만 많은 오버 헤드가 발생합니다. 게이 트웨이는 데이터를 사용할 수있게되는 즉시 클라이언트에서 데이터를 사용할 수 있도록하는 것이 좋습니다. 그러나 이것은 각 게이트웨이가 현재 어떤 클라이언트가 활성 상태이고 어떤 특정 데이터가 필요한지 추적해야합니다. 그런 다음 새 데이터 조각이 사용 가능 해지면 (초당 수없이 발생) 게이트웨이는 각 관심 클라이언트에게 클라이언트에 데이터를 전달하는 RPC를 만들어야합니다. 이상적으로 모든 클라이언트는 동시에 통보되어야하므로 각 RPC는 자체 스레드로 만들어야합니다. 이 작업은 가능하지만 매우 빠르게 복잡해지고 있습니다.
메시징은이 문제를 크게 단순화합니다. 메시징을 통해 다양한 유형의 가격 데이터에 대해 별도의 채널을 정의 할 수 있습니다. 그런 다음 게이트웨이가 새 데이터를 가져 오면 해당 데이터 유형에 대한 게시 - 구독 채널에 해당 데이터가 포함 된 메시지를 추가합니다. 한편 특정 유형의 데이터에 관심이있는 모든 고객은 해당 유형의 채널에서 수신 대기합니다. 이러한 방식으로, 게이트웨이는 청취자 애플리케이션이 얼마나 많은지 또는 그들이 무엇인지 알 필요없이 원하는 누구에게나 새로운 데이터를 쉽게 전송할 수 있습니다.
클라이언트는 여전히 게이트웨이에서 동작을 호출 할 수 있어야합니다. 두 개의 게이트웨이 만 있기 때문에 클라이언트가 메소드를 동 기적으로 호출하는 동안 차단할 수 있으므로 클라이언트 - 게이트웨이 호출은 RPC를 사용하여 쉽게 구현할 수 있습니다. 그러나 이미 게이트웨이 간 통신을 위해 메시징을 사용하고 있으므로 메시지는 클라이언트와 게이트웨이 간의 통신을 구현하는 데에도 유용합니다.
따라서 게이트웨이와 클라이언트 간의 모든 통신은 메시징을 통해 수행됩니다. 모든 구성 요소가 Java로 작성 되었기 때문에 JMS는 메시징 시스템으로 쉽게 선택할 수 있습니다. 이는 메시징 인프라를 거의 변경하지 않고 현재 시스템과 통합 할 수있는 메시지 버스 또는 아키텍처를 효과적으로 만듭니다. 이렇게하면 응용 프로그램의 비즈니스 기능을 은행이 개발하는 다른 응용 프로그램에서 쉽게 사용할 수 있습니다.
JMS와 통신하는 Java 구성 요소.
JMS는 단순히 사양이며 JMS 호환 메시징 시스템을 결정해야합니다. 우리는 IBM MQSeries JMS를 사용하기로 결정했습니다. 은행이 ibmIBM 상점이기 때문입니다. WebSphere 응용 프로그램 서버와 다른 많은 IBM 제품을 사용하기 때문입니다. 결과적으로 지원 인프라와 제품의 사이트 라이센스가 이미 있으므로 MQSeries를 사용하게됩니다.
다음 질문은 MQSeries 메시징 시스템을 독립형 C ++ Contribution 서버 및 TIBCO 기반 Market Data and Analytics Engine 서버와 연결하는 방법입니다. MQSeries 사용자가 TIB 메시지에 액세스 할 수있는 방법이 필요합니다. 그러나 어떻게? 아마도 Message Translator 패턴을 사용하여 TIB 메시지를 MQSeries 메시지로 변환 할 수 있습니다. MQSeries 용 C ++ 클라이언트는 Message Translator 역할을하지만 JMS Translator를 사용하면 JMS 서버 독립성이 희생됩니다. TIBCO에는 Java API가 있지만 고객 아키텍트와 관리자는이를 거부했습니다. 결과적으로 Message Translator 접근 방식을 포기해야합니다.
TIB 서 v에서 MQSeries 서 v 로의 브릿지는 C ++과 Java 간의 통신이 필요합니다. 우리는 CORBA를 사용할 수 있지만 메시징은 무엇입니까? Message Translator 패턴을 면밀히 살펴보면 통신 프로토콜 사용시 채널 어댑터와 관련이 있음을 알 수 있습니다. 채널 어댑터의 핵심은 비 메시징 시스템을 메시징 시스템에 연결하는 것입니다. 두 메시징 시스템을 연결하는 한 쌍의 채널 어댑터가 메시징 브릿지입니다.
메시징 브리지의 목적은 한 메시징 시스템에서 다른 메시징 시스템으로 메시지를 전송하는 것입니다. 이것은 언어 내 Java에서 C ++ 로의 의사 소통의 복잡성이 증가함에 따라 우리가 수행하고있는 작업입니다. 채널 어댑터와 CORBA의 조합을 사용하여 교차 언어 메시징 브리지를 구현할 수 있습니다. TIB와의 통신을 관리하는 C ++ 및 JMS와의 통신을 관리하는 Java에서 하나씩 두 개의 경량 채널 어댑터 서버를 구축 할 것입니다. 메시지 엔드 포인트 인이 두 채널 어댑터는 CORBA를 통해 서로 통신합니다. MQSeries에 대한 우리의 선택처럼 JNI가 회사 표준이기 때문에 CORBA를 사용합니다. 메시징 브리지는 겉으로는 호환되지 않는 메시징 시스템과 다른 언어 사이에서 시뮬레이션 된 메시지 번역을 효과적으로 구현합니다.
채널 어댑터를 사용하는 메시지 변환기.
다음 다이어그램은 게이트웨이 및 기타 구성 요소를 포함한 현재 시스템 설계를 보여줍니다. 이것은 패턴 적용의 좋은 예입니다. Message Translator 패턴을 구현하기 위해 두 개의 Channel Adapter를 비 메시징 프로토콜과 결합하여 하나의 패턴을 효과적으로 사용하여 다른 패턴을 구현했습니다. 또한 메시징 시스템을 비 메시징 시스템에 연결하는 대신 두 개의 메시징 시스템을 비 메시징 교차 언어 변환 프로토콜로 연결하도록 채널 어댑터의 컨텍스트를 변경했습니다.
채널 어댑터가있는 현재 시스템입니다.
채널 구성.
패턴 작업의 핵심은 언제 어떤 패턴을 사용할 것인지뿐만 아니라 가장 효과적으로 사용하는 방법을 아는 것입니다. 각 패턴 구현은 다른 설계 기준뿐만 아니라 기술 플랫폼의 특성을 고려해야합니다. 이 섹션에서는 분석 엔진과 통신하는 시장 데이터 서버의 컨텍스트에서 게시 - 구독 채널을 가장 효율적으로 사용하기 위해 동일한 검색 프로세스를 적용합니다.
실시간 시장 데이터는 TIB에서 시장 데이터를 브로드 캐스팅하는 C ++ 서버 인 시장 데이터 피드에서 시작됩니다. 시장 데이터 피드는 가격을 게시 할 각 채권에 대해 별도의 게시 - 구독 채널을 사용합니다. 새로운 채권마다 새로운 채널이 필요하기 때문에 약간 극단적으로 보일 수 있습니다. 하지만 실제로 TIBCO에서 채널을 만들 필요가 없기 때문에 그렇게 심각하지 않습니다. 오히려 채널은 주제라는 계층 적 이름 집합으로 참조됩니다. 그런 다음 TIBCO 서버는 주제별로 단일 메시지 흐름을 필터링하여 각 고유 주제를 단일 가상 채널로 보냅니다. 결과는 매우 가벼운 메시지 채널입니다.
몇 가지 채널을 통해 게시하는 시스템을 만들 수 있으며 구독자는 관심있는 가격에 대해서만 청취 할 수 있습니다. 구독자는 메시지 필터 또는 선택 소비자를 사용하여 관심있는 채권 가격에 대한 전체 데이터 흐름을 필터링하고 각 메시지 받은대로 처리해야합니다. 시장 데이터가 본드 전용 채널에 게시되면 구독자는 일련의 채권에 대한 업데이트를 등록 할 수 있습니다. 이를 통해 가입자는 채널을 선택적으로 구독하고 메시지 수신 후 결정하는 것이 아니라 관심있는 업데이트 만 수신함으로써 효과적으로 "필터"할 수 있습니다. 필터링을 피하기 위해 여러 채널을 사용하는 것이 비표준 메시징 채널 사용이라는 점에 유의해야합니다. 그러나 TIBCO 기술의 맥락에서 필터를 구현하거나 소유 할 것인지 또는 너무 많은 채널을 사용할지 여부보다는 TIBCO에 내장 된 채널 필터링을 실제로 사용할 것인지 결정합니다.
우리가 설계해야하는 다음 요소는 분석 엔진, 시장 데이터를 수정하고이를 TIB에 재방송하는 또 다른 C ++ / TIB 서버입니다. Java / JMS 개발 범위를 벗어나지 만 분석 엔진의 기본 '고객'이기 때문에 C ++ 팀과 긴밀하게 협력하여 설계하고 있습니다. 현재 문제는 새로 수정 된 시장 데이터를 가장 효율적으로 재방송하는 채널 구조를 찾는 것입니다.
시장 데이터 가격 피드로부터 상속 된 채권마다 하나의 전용 메시지 채널이 이미 있으므로 시장 데이터를 수정하고 채권 전용 메시지 채널에서 수정 된 시장 데이터를 재방송하는 것이 논리적 일 것입니다. 그러나 채권 가격을 수정하는 분석은 거래 상 구체적이기 때문에 이는 효과가 없습니다. 본드 메시지 채널에서 수정 된 데이터를 재방송하는 경우 일반 시장 데이터를 거래자 특정 데이터로 대체하여 데이터 무결성을 파괴합니다. 반면에 우리는 동일한 채널에 게시하는 상인 특정 시장 데이터에 대해 다른 메시지 유형을 사용할 수 있습니다. 구독자는 데이터 무결성을 손상시키지 않으려는 메시지를 결정할 수 있습니다. 그러나 고객은 다른 거래자를위한 메시지를 분리하기 위해 자체 필터를 구현해야합니다. 또한 가입자가받는 메시지가 상당히 증가하여 불필요한 부담이됩니다.
두 가지 옵션이 있습니다.
상인 당 하나의 채널 : 각 상인은 수정 된 시장 데이터에 대해 지정된 채널을 가지고 있습니다. 이렇게하면 원래의 시장 데이터가 그대로 유지되고 각 상인 애플리케이션은 수정 된 가격 업데이트를 위해 특정 상인 메시지 채널을 청취 할 수 있습니다. 본드 당 상인 당 하나의 채널 : 해당 채권의 수정 된 시장 데이터에 대해서만 개별 채권마다 하나의 메시지 채널을 만듭니다. 예를 들어, 채권 ABC에 대한 시장 데이터는 채널 "본드 ABC"에 게시되고, 상인 A에 대한 수정 된 시장 데이터는 메시지 채널 "상인 A, 본드 ABC"에 게시되고, 상인 B에 대한 시장 데이터는 "상인 B , 본드 ABC "등등.
상인 당 하나의 채널.
상인 당 채권마다 하나의 채널.
각 방법에는 장단점이 있습니다. 예를 들어 채권당 접근 방식은 훨씬 많은 메시지 채널을 사용합니다. 최악의 경우 시나리오에서 메시지 채널 수는 총 채권 수와 거래자 수를 곱한 값이됩니다. 우리는 약 20 명의 상인 만 있다는 것을 알기 때문에 만들어지는 채널 수에 상한선을 둘 수 있습니다. 이로 인해 상한값이 10,000 범위 미만으로 떨어지며 이는 시장 데이터 가격 피드가 사용하는 거의 100,000 개의 메시지 채널에 비해 너무 이색 적이 지 않습니다. 또한, 우리가 TIB와 메시지 채널을 사용하고 있기 때문에 상당히 저렴하므로 메시지 채널의 수가 심각한 문제는 아닙니다. 반면에 메시지 채널의 수는 관리 관점에서 문제가 될 수 있습니다. 채권이 추가 될 때마다 각 상인을위한 채널을 유지해야합니다. 이는 매우 역동적 인 시스템에서 심각 할 수 있습니다. 그러나 우리 시스템은 본질적으로 정적입니다. 또한 메시지 채널을 자동으로 관리하기위한 인프라도 있습니다. 이것은 유사한 접근 방식을 사용하는 레거시 구성 요소의 상속 된 아키텍처와 결합하여 단점을 최소화합니다. 이것은 불필요하게 과도한 수의 메시지 채널을 만들어야한다는 것을 의미하지는 않습니다. 오히려 이유가있을 때 많은 수의 메시지 채널을 사용하는 아키텍처 접근 방식을 구현할 수 있습니다.
그리고이 경우에 논리의 위치로 오는 이유가 있습니다. 트레이더 당 접근 방식을 구현하는 경우 애널리틱스 엔진에 입력 및 출력 채널을 그룹화하는 논리가 필요합니다. 애널리틱스 엔진의 입력 채널이 본드당이고 출력 메시지 채널이 상거래 당, 애널리틱스 엔진이 특정 거래자에 대한 여러 채권의 모든 분석 입력을 거래자 특정 출력 메시지 채널로 라우팅하도록 요구하기 때문입니다. 이를 통해 분석 엔진을 Content-Based Router로 효과적으로 전환하여 애플리케이션에 맞춤 라우팅 논리를 구현할 수 있습니다.
애널리틱스 엔진은 메시지 버스 구조 다음에있는 여러 다른 시스템에서 사용할 수있는 일반 서버입니다. 그래서 우리 don†™ t는 시스템 특정 기능으로 그것을 흐리게하고 싶습니다. 반면 채권 가격의 분석 결과를 소유 한 상인의 아이디어는 회사가 인정한 관행이기 때문에 채권당 접근 방식이 효과적입니다. 채권 접근법은 시장 데이터 피드의 메시지 채널 분리를 그대로 유지하면서 여러 메시지 채널을 추가합니다. 우리는 클라이언트에 도달하기 전에 Content-Based Router가 이러한 여러 채널을 관리 가능한 채널 수로 결합하기를 원합니다. 우리 don†™ t는 수천 또는 메시지 채널 s의 수천을 경청하기 위하여 trader†™ s 2 바탕 화면에 달리는 클라이언트 신청을 원한다. 이제 질문은 Content-Based Router를 어디에 둘 것인지를 결정합니다. 우리는 단순히 C ++ / TIB 채널 어댑터가 모든 메시지를 단일 메시지 채널의 가격 게이트웨이로 전달하도록 할 수 있습니다. 이것은 두 가지 이유로 나쁘다. 우리는 C ++과 Java 사이의 비즈니스 로직을 분리 할 것이고, 우리는 나중에 데이터 흐름에서 필터링을 피할 수 있도록 TIB 쪽에서 개별 메시지 채널의 이점을 잃을 것입니다. Java 구성 요소를 살펴보면 Pricing Gateway에 배치하거나 Pricing Gateway와 클라이언트 사이에 중간 구성 요소를 만들 수 있습니다.
이론적으로, 채권 기반의 메시지 채널 분리를 클라이언트 에까지 지속한다면 가격 결정 게이트웨이는 가격 결정 게이트웨이 및 분석 엔진과 동일한 채널 구조로 가격 정보를 재방송합니다. 이것은 JMS의 모든 본드 전용 TIB 채널의 복제를 의미합니다. Pricing Gateway와 클라이언트간에 중간 구성 요소를 만들지 만 Pricing Gateway는 여전히 JMS의 모든 채널을 복제해야합니다. 반면에 가격 결정 게이트웨이에 직접 로직을 구현하면 JMS вЂ에서 많은 수의 채널을 복제하지 않아도되므로 상인 당 하나의 순서로 훨씬 적은 수의 채널을 생성 할 수 있습니다. Pricing Gateway는 C ++ / TIB Channel Adapter를 통해 시스템의 모든 거래자의 각 채권에 대한 소비자로 등록됩니다. 그런 다음 가격 게이트웨이는 각 특정 클라이언트를 해당 특정 상인과 관련된 메시지 만 전달합니다. 이렇게하면 JMS 끝에서 적은 수의 메시지 채널 만 사용하면서 TIB 끝에서 분리의 이점을 극대화합니다.
클라이언트에 대한 완벽한 마켓 데이터 흐름.
메시지 채널 레이아웃 토론은 패턴 통합이 중요한 이유의 좋은 예입니다. 여기서 목표는 메시지 채널을 효과적으로 사용하는 방법을 파악하는 것이 었습니다. 당신은 isn†™ t를 충분히 사용한다고 말합니다. 가장 좋은 방법을 구현하고 현재의 문제를 해결하기 위해 시스템에 통합하는 방법을 찾아야합니다. 또한, 이 예는 실제 비즈니스 활동을 보여줍니다. 우리가 어떤 구성 요소에서 비즈니스 로직을 구현할 수 있다면, 우리는 상인 당 접근 방식을 따라갈 수 있었고 더 적은 수의 채널로 전체적으로보다 단순한 접근 방식을 구현할 수있었습니다.
메시지 채널 선택?
Java / JMS 구성 요소와 C ++ / TIBCO 구성 요소 사이의 통신 메커니즘을 알았으므로 Message Channel 구조화를 살펴 보았으므로 Java 구성 요소가 통신에 사용해야하는 JMS 메시지 채널의 유형을 결정해야합니다. JMS에서 사용 가능한 다른 메시지 채널 중에서 선택할 수 있기 전에 let†™는 시스템의 상위 메시지 흐름을 살펴 봅니다. 우리는 클라이언트와 통신하는 두 개의 게이트웨이 (가격 책정 및 컨트 리뷰 션)를 가지고 있습니다. 시장 데이터는 Pricing Gateway에서 클라이언트로 전달되며, Pricing Gateway는이를 Contribution Gateway로 보냅니다. 클라이언트 응용 프로그램은 가격 책정 게이트웨이에 메시지를 보내 각 본드에 적용되는 분석을 변경합니다. 또한 Contribution Gateway는 다른 거래 장소로 가격 업데이트 상태를 전달하는 메시지를 클라이언트 애플리케이션에 전송합니다.
시스템 메시지 흐름.
JMS 사양은 지점 간 채널 (JMS 대기열)과 게시 - 구독 채널 (JMS 주제)의 두 가지 메시지 채널 유형을 설명합니다. 발행 - 구독을 사용하는 경우 관심있는 모든 소비자가 메시지를 수신 할 수 있도록하는 반면, 포인트 투 포인트를 사용하는 경우 하나의 자격있는 소비자 만 특정 메시지를 수신하도록하는 것이 좋습니다.
많은 시스템은 단순히 모든 클라이언트 응용 프로그램에 메시지를 브로드 캐스팅하여 각 개별 클라이언트 응용 프로그램이 특정 메시지를 처리할지 여부를 자체적으로 결정하도록합니다. 각 클라이언트 응용 프로그램으로 보내지는 마켓 데이터 메시지가 많기 때문에이 응용 프로그램에는 사용할 수 없습니다. 우리가 관심없는 상인에게 시장 데이터 업데이트를 방송하면 시장 데이터 업데이트를 처리할지 여부를 결정하는 클라이언트 프로세서 사이클을 불필요하게 낭비하게됩니다.
지점 간 채널은 클라이언트가 고유 한 서버로 메시지를 보내고 그 반대의 경우도 있으므로 처음에는 좋은 선택으로 들립니다. 그러나 상인이 동시에 여러 기계에 로그인 할 수있는 비즈니스 요구 사항이었습니다. 두 대의 워크 스테이션에 동시에 로그인 한 상인이 있고 지점 간 가격 업데이트가 전송되면 두 클라이언트 응용 프로그램 중 하나에서만 메시지가 수신됩니다. 이는 포인트 - 투 - 포인트 채널의 한 소비자 만 특정 메시지를 수신 할 수 있기 때문입니다. 상인의 클라이언트 응용 프로그램의 각 그룹 중 첫 번째 그룹 만 메시지를 수신합니다.
가격 업데이트를위한 지점 간 메시징.
수신자 목록 패턴을 사용하여이를 해결할 수 있습니다. 수신자 목록 패턴은 수신자 목록에 메시지를 게시하여 수신자 목록의 클라이언트 만 메시지를 수신하도록합니다. 이 패턴을 사용하면 시스템은 각 상인과 관련된 모든 클라이언트 응용 프로그램 인스턴스로받는 사람 목록을 만들 수 있습니다. 특정 거래자와 관련된 메시지를 보내면받는 사람 목록의 각 응용 프로그램으로 메시지를 보냅니다. 이렇게하면 특정 상인과 관련된 모든 클라이언트 응용 프로그램 인스턴스가 메시지를 수신하게됩니다. 이 접근 방식의 단점은받는 사람을 관리하고 메시지를 전달하는 데 상당히 많은 구현 논리가 필요하다는 것입니다.
가격 업데이트에 대한 수신자 목록.
포인트 투 포인트 (point-to-point)가 작동하도록 만들어 졌을지라도, let†™는 더 좋은 방법이 있는지 알아 봅니다. 게시 - 구독 채널을 사용하여 시스템은 클라이언트 응용 프로그램 특정 채널이 아닌 상인 특정 채널에서 메시지를 브로드 캐스팅 할 수있었습니다. 이렇게하면 단일 상인에 대한 메시지를 처리하는 모든 클라이언트 응용 프로그램이 메시지를 수신하고 처리합니다.
가격 업데이트를위한 게시 - 구독 메시징.
게시 - 구독 채널 사용의 단점은 서버 구성 요소에서 고유 한 메시지 처리가 보장되지 않는다는 것입니다. 서버 구성 요소의 여러 인스턴스가 인스턴스화되고 각 인스턴스가 동일한 메시지를 처리하여 잘못된 가격을 보낼 가능성이 있습니다.
시스템 메시지 흐름을 상기하면, 각 메시지 채널에 대해 단일 통신 방향 만 만족 스럽다. 게시 - 가입과의 서버 - 클라이언트 통신은 만족 스럽지만 클라이언트 - 서버 통신은 만족스럽지 않고 서버 - 클라이언트가 아닌 지점 간 클라이언트 - 서버 통신은 만족 스럽습니다. 양방향으로 동일한 메시지 채널을 사용할 필요가 없기 때문에 각 메시지 채널을 한 방향으로 만 사용할 수 있습니다. 클라이언트 대 서버 통신은 지점 간 (point-to-point)으로 구현되며 서버 간 통신은 게시 - 가입으로 구현됩니다. 이러한 메시지 채널 조합을 사용하면 시스템은 포인트 - 투 - 포인트 메시징을 사용하는 서버 구성 요소와 직접 통신 할 수 있고 단점도없이 게시 - 가입의 멀티 캐스트 성향을 얻을 수 있습니다.
채널 유형을 사용한 메시지 흐름.
패턴으로 문제 해결.
패턴은 도구이며 패턴의 모음은 도구 상자입니다. 문제 해결에 도움이됩니다. 어떤 사람들은 패턴이 디자인 중에 만 유용하다고 생각합니다. 도구 상자 비유에 따르면 도구를 사용하여 집을 짓고 도구를 고칠 때 유용한 도구가 아니라는 것을 알 수 있습니다. 사실은 패턴이 잘 적용될 때 프로젝트 전체에서 유용한 도구라는 것입니다. 다음 섹션에서는 이전 섹션에서 사용한 것과 동일한 패턴 탐색 프로세스를 사용하여 현재 작업중인 시스템의 문제를 해결합니다.
시장 데이터 업데이트를 깜박입니다.
거래자는 채권에 대한 새로운 시장 데이터가 수신되면 표 셀이 깜박 거리면서 변경 사항을 명확하게 나타 내기를 원합니다. Java 클라이언트는 클라이언트 데이터 캐시 업데이트를 트리거하고 결국 테이블에서 깜박이는 새 데이터로 메시지를 수신합니다. 문제는 업데이트가 자주 발생한다는 것입니다. GUI 쓰레드 스택은 사용자 상호 작용에 반응 할 수 없기 때문에 과부하가되어 클라이언트를 동결시킵니다. 깜박이는 것이 최적화되고 업데이트 프로세스를 통해 메시지의 데이터 흐름에 집중한다고 가정합니다. 성능 데이터를 살펴보면 클라이언트 응용 프로그램이 몇 초 동안 여러 가지 업데이트를 수신하고 있음을 확인할 수 있습니다. 일부 업데이트는 밀리 초 미만으로 발생했습니다. 메시지 흐름을 느리게하는 데 도움이 될 수있는 두 가지 패턴은 수집기 및 메시지 필터입니다.
첫 번째 생각은 참조 메시지 다음에 작은 시간 동안 수신 된 업데이트를 버림으로써 메시지 흐름의 속도를 제어하는 메시지 필터를 구현하는 것입니다. 예를 들어, 서로 5 밀리 초 이내에 메시지를 무시한다고 가정 해 보겠습니다. 메시지 필터는 마지막으로 허용되는 메시지의 시간을 캐싱하고 다음 5 밀리 초 내에 수신 된 모든 것을 버릴 수 있습니다. 다른 응용 프로그램이 데이터 손실을 견딜 수 없을 수도 있지만 가격 업데이트 빈도로 인해 시스템에서 완벽하게 수용 할 수 있습니다.
시간 기반 메시지 필터.
이 접근 방식의 문제점은 모든 데이터 필드가 동시에 업데이트되지 않는다는 것입니다. 각 채권은 가격을 포함하여 약 50 개의 데이터 필드가 사용자에게 표시됩니다. 모든 필드가 모든 메시지에서 업데이트되는 것은 아닙니다. 시스템이 연속적인 메시지를 무시하면 중요한 데이터가 빠져 나갈 수 있습니다.
관심있는 다른 패턴은 Aggregator입니다. Aggregator는 여러 개의 관련 메시지를 단일 메시지로 조정하여 잠재적으로 메시지 흐름을 관리하는 데 사용됩니다. Aggregator는 첫 번째 집계 메시지의 본드 데이터 사본을 보관 한 다음 새 필드 또는 변경된 필드의 연속 메시지 만 업데이트 할 수 있습니다. 결국 집계 된 채권 데이터는 고객에게 메시지로 전달됩니다. 지금은 Aggregator가 메시지 필터와 같이 5 밀리 초마다 메시지를 전송한다고 가정합니다. 나중에 다른 대안을 찾아 보겠습니다.
부분적인 연속 업데이트가있는 Aggregator.
The Aggregator , like any other pattern, is not a silver bullet; it has its pluses and minuses that need to be explored. One potential minus is that implementing an Aggregator would reduce the message traffic by a great amount in our case only if many messages are coming in within a relatively short time regarding the same bond. On the other hand, we would accomplish nothing if the Java client only receives updates for one field across all of the traders bonds. For example, if we receive 1000 messages in a specified timeframe with 4 bonds of interest, we would reduce the message flow from 1000 to 4 messages over that timeframe. Alternatively, if we receive 1000 messages in the same timeframe with 750 bonds of interest, we will have reduced the message flow from 1000 to 750 messages; relatively little gain for the amount of effort. A quick analysis of the message updates proves that the Java client receives many messages updating fields of the same bond, and therefore related messages. So, Aggregator is in fact a good decision.
What's left is to determine how the Aggregator will know when to send a message it has been aggregating. The pattern describes a few algorithms for the Aggregator to know when to send the message. These include algorithms to cause the aggregator to send out its contents after a certain amount of time has elapsed, after all required fields in a data set have been completed, and others. The problem with all of these approaches is that the aggregator is controlling the message flow, not the client. And the client is the major bottleneck in this case, not the message flow.
This is because the Aggregator is assuming the consumers of its purged messages (the client application in this case) are Event-Driven Consumer s, or consumers that rely on events from an external source. We need to turn the client into a Polling Consumer , or a consumer that continuously checks for messages, so the client application can control the message flow. We can do this by creating a background thread that continuously cycles through the set of bonds and updates and flashes any changes that have occurred since the last iteration. This way, the client controls when messages are received and as a result, guarantees that it will never become overloaded with messages during high update periods. We can easily implement this by sending a Command Message to the Aggregator initiating an update. The Aggregator will respond with a Document Message containing the set of updated fields that the client will process.
The choice of Aggregator over Message Filter is clearly a decision based solely on the business requirements of our system. Each could help us solve our performance problems, but using the Message Filter would solve the problem at cost of the system data integrity.
Major Production Crash.
With the performance of the flashing fixed, we are now in production. One day the entire system goes down. MQSeries crashes, bringing several components down with it. We struggle with the problem for a while and finally trace it back to the MQSeries dead letter queue (an implementation of the Dead Letter Channel ). The queue grows so large that it brings down the entire server. After exploring the messages in the dead letter queue we find they are all expired market data messages. This is caused by “slow consumers, ” or consumers that do not process messages fast enough. While messages are waiting to be processed, they time out (see the Message Expiration pattern) and are sent to the Dead Letter Channel . The excessive number of expired market data messages in the dead letter queue is a clear indication that the message flow is too great – messages expire before the target application can consume them. We need to fix the message flow and we turn to patterns for help slowing down the message flow.
A reasonable first step is to explore solving this problem with the Aggregator as we recently used this pattern to solve the similar flashing market data control rate problem. The system design relies on the client application to immediately forward market data update messages to the trading venues. This means the system cannot wait to collect messages and aggregate them. So the Aggregator must be abandoned.
There are two other patterns that deal with the problem of consuming messages concurrently: Competing Consumers and Message Dispatcher . Starting with Competing Consumers , the benefit of this pattern is the parallel processing of incoming messages. This is accomplished using several consumers on the same channel. Only one consumer processes each incoming message leaving the others to process successive messages. Competing Consumers , however, will not work for us since we are using Publish-Subscribe Channel s in server-to-client communication. Competing Consumers on a Publish-Subscribe Channel channel means that all consumers process the same incoming message. This results in more work without any gain and completely misses the goal of the pattern. This approach also has to be abandoned.
On the other hand, the Message Dispatcher describes an approach whereby you add several consumers to a вЂ˜pool’. Each consumer can run its own execution thread. One main Message Consumer listens to the Channel and delegates the message on to an unoccupied Message Consumer in the pool and immediately returns to listening on the Message Channel . This achieves the parallel processing benefit of Competing Consumers , but works on Publish-Subscribe Channel s.
The Message Dispatcher in context.
Implementing this in our system is simple. We create a single JMSListener called the Dispatcher, which contains a collection of other JMSListener s called Performers. When the onMessage method of the Dispatcher is called, it in turn picks a Performer out of the collection to actually process the message. The result of which is a Message Listener (the Dispatcher) that always returns immediately. This guarantees a steady flow of message processing regardless of the message flow rate. Additionally, this works equally well on a Publish-Subscribe Channel s as it does on a Point-to-Point Channel s. With this infrastructure, messages can be received by the client application at almost any rate. If the client application is still slow to process the message after receiving them, the client application can deal with the delayed processing and potentially outdated market data rather than the messages expiring in the JMS Message Channel .
The crash discussed in this section and the fix using the Message Dispatcher is an excellent example of the limits of applying patterns. We encountered a performance problem based on a design flaw not allowing the client to process messages in parallel. This greatly improved the problem, but did not completely fix it. This is because the real problem was the client becoming a bottleneck. This couldn’t be fixed with a thousand patterns. We later addressed this problem by refactoring the message flow architecture to route messages directly from the Pricing Gateway to the Contribution Gateway. So patterns can help design and maintain a system, but don’t necessarily make up for poor upfront design.
Throughout this chapter, we have applied patterns to several different aspects of a bond trading system including solving initial upfront design problems and fixing a nearly job threatening production crash with patterns. We also saw these patterns as they already exist in third party product, legacy components, and our JMS and TIBCO messaging systems. Most importantly, these are real problems with the same types of architectural, technical and business problems we experience as we design and maintain our own systems. Hopefully reading about applying patterns to this system helps give you a better understanding of the patterns as well as how to apply them to your own systems.
그레고 호프 (Gregor Hohpe)와 바비 울프 (Bobby Woolf).
엔터프라이즈 통합에서 엔터프라이즈 변환에 이르기까지 :
저의 새로운 저서는 대규모 엔터프라이즈 IT의 37 회 에피소드를 통해 기술, 의사 소통 및 조직 기술을 적용하여 건축가가 IT 변환에서 중요한 역할을 수행하는 방법을 설명합니다.
(조나단 사이먼)
대규모 패턴 모음이나 패턴 언어에서 벗어나기 쉽습니다. 패턴은 아이디어를 재사용 가능한 형태로 추상화 한 것입니다. 흔히 패턴을 매우 유용하게 만드는 매우 일반적인 패턴은 이해하기 어렵게 만듭니다. 때때로 패턴을 이해하는 데 도움이되는 가장 좋은 방법은 실생활의 예입니다. 일어날 수있는 일에 대한 인위적 시나리오가 아닙니다. 그러나 실제로 일어나는 것과 일어날 일은 무엇인가.
이 장에서는 발견 프로세스를 사용하여 문제점을 해결하는 패턴을 적용합니다. 우리가 논의 할 시스템은 초기 설계부터 생산까지 2 년 동안 함께 일한 채권 거래 시스템입니다. 우리는 마주 치게되었던 시나리오와 문제 그리고 패턴으로 그것들을 해결하는 방법을 조사 할 것입니다. 여기에는 패턴을 선택하는 결정 프로세스뿐만 아니라 시스템 요구에 맞게 패턴을 결합하고 조정하는 방법이 포함됩니다. 또한 비즈니스 요구 사항, 고객 결정, 아키텍처 및 기술 요구 사항, 레거시 시스템 통합 등 실제 시스템에서 발생하는 세력을 고려하여이 모든 작업을 수행합니다. 이 접근법의 의도는 실용적인 응용을 통해 패턴 자체를보다 명확하게 이해하는 것입니다.
시스템 구축.
주요 월스트리트 투자 은행은 채권 매매 데스크의 업무 흐름을 간소화하기 위해 채권 가격 책정 시스템을 구축하기 시작했습니다. 현재 채권 거래자들은 다수의 채권 가격을 몇 개의 다른 거래 장소에 보내야하며 각 거래 장소에는 자체 사용자 인터페이스가 있습니다. 이 시스템의 목표는 단일 캡슐화 된 사용자 인터페이스에서 채권 시장에 특화된 고급 분석 기능과 함께 모든 채권 가격 책정의 세부 사항을 최소화하는 것입니다. 이는 다양한 통신 프로토콜을 통한 여러 구성 요소와의 통합 및 통신을 의미합니다. 시스템의 높은 수준의 흐름은 다음과 같습니다.
높은 수준의 흐름.
첫째, 시장 데이터가 시스템에 제공됩니다. 시장 데이터는 사람들이 자유 시장에서 채권을 사거나 팔고 자하는 것을 나타내는 채권의 가격 및 기타 자산과 관련된 데이터입니다. 시장 데이터는 즉시 데이터를 변경하는 분석 엔진으로 전송됩니다. 애널리틱스는 채권의 가격 및 기타 속성을 변경하는 금융 애플리케이션을위한 수학 함수를 말합니다. 이들은 입력 변수를 사용하여 함수의 결과를 특정 본드에 맞추는 일반 함수입니다. 각 상장 데스크톱에서 실행될 클라이언트 애플리케이션은 매매가별로 가격이 책정되는 각 채권에 대한 분석의 특성을 제어하면서 상거래 기준으로 분석 엔진을 구성합니다. 분석이 시장 데이터에 적용되면 수정 된 데이터가 다른 회사의 상인이 채권을 매매 할 수있는 다양한 거래 장소로 보내집니다.
패턴이있는 아키텍처.
시스템의 워크 플로우에 대한이 개요를 통해 우리는 설계 프로세스 중에 발생하는 일부 건축 문제에 접근 할 수 있습니다. Let†™ s는 우리가 지금까지 알고있는 것을 보았습니다. 거래자는 Windows NT 및 Solaris 워크 스테이션 모두에서 응답이 빠른 응용 프로그램이 필요합니다. 따라서 우리는 플랫폼 독립성과 사용자 입력 및 시장 데이터에 신속하게 응답 할 수 있기 때문에 클라이언트 애플리케이션을 Java 씩 클라이언트로 구현하기로 결정했습니다. 서버 측에서는 우리 시스템이 활용할 레거시 C ++ 구성 요소를 상속합니다. 시장 데이터 구성 요소는 TIBCO 정보 버스 (TIB) 메시징 인프라와 통신합니다.
우리는 다음 구성 요소를 상속 받고 있습니다.
시장 데이터 가격 공급 서버 : 들어오는 시장 데이터를 TIB에 게시합니다. 분석 엔진 : 들어오는 시장 데이터에 대한 분석을 수행하고 수정 된 시장 데이터를 TIB에 브로드 캐스트합니다. Contribution Server : 거래 장소와의 모든 통신을 수행합니다. 거래 장소는 은행이 통제하지 않는 제 3 자 구성 요소입니다.
기존 시장 데이터 하위 시스템.
유산 기여 하위 시스템.
개별 하위 시스템 (Java 씩 클라이언트, 시장 데이터 및 컨트 리뷰 션)이 통신하는 방법을 결정해야합니다. 두꺼운 클라이언트가 기존 서버와 직접 통신 할 수는 있지만 클라이언트에서 너무 많은 비즈니스 논리가 필요합니다. 대신, we†™ ll는 legacy servers†"시장 자료를위한 가격 설정 출입구에 거래 장소에 가격을 보내기를위한 기여금 출입구와 교통하기 위하여 자바 출입구 한 쌍을 건설합니다. 이렇게하면 이러한 영역과 관련된 비즈니스 논리를 멋지게 캡슐화 할 수 있습니다. 시스템의 현재 구성 요소는 다음과 같습니다. †marked로 표시된 연결. ”는 우리가 구성 요소의 일부가 어떻게 통신하는지 아직도 확신 할 수 없다는 것을 나타냅니다.
시스템과 그 구성 요소.
첫 번째 통신 질문은 데이터를 교환하기 위해 Java 씩 (thick) 클라이언트와 두 개의 Java 서버 구성 요소를 통합하는 방법입니다. Let†™ s는이 책에서 제안 된 네 가지 통합 스타일 인 파일 전송, 공유 데이터베이스, 원격 프로 시저 호출 및 메시징을 살펴 봅니다. 우리는 클라이언트와 데이터베이스 사이의 추상화 계층을 만들고 don†™ t가 클라이언트에 데이터베이스 액세스 코드를 갖고 싶어하므로 공유 데이터베이스를 즉시 제외 할 수 있습니다. 파일 전송은 현재 가격이 거래 장소로 보내지는 것을 보장하기 위해 최소한의 대기 시간이 필요하기 때문에 마찬가지로 배제 될 수 있습니다. 이로 인해 원격 프로 시저 호출 또는 메시징 중 하나가 선택됩니다.
Java 플랫폼은 원격 프로 시저 호출 및 메시징에 대한 기본 제공 지원을 제공합니다. RPC 스타일 통합은 RMI (Remote Method Invocation), CORBA 또는 EJB (Enterprise Java Beans)를 사용하여 수행 할 수 있습니다. Java Messaging Service (JMS)는 메시징 스타일 통합을위한 공통 API입니다. 따라서 두 가지 통합 스타일은 Java로 구현하기 쉽습니다.
따라서이 프로젝트, 원격 프로 시저 호출 또는 메시징에서 더 잘 작동합니까? There†™ s 가격 설정 출입구의 단지 1 개의 사례 및 체계에있는 기여금 출입구의 1 개의 인스턴스, 그러나 보통 많은 두꺼운 클라이언트는 동시에이 서비스 (특정 시간에 로그인되는 우연히 일어나는 각 채권 거래자를위한 하나)에 연결합니다. 또한이 은행은 다른 애플리케이션에서 활용할 수있는 일반적인 가격 책정 시스템을 원합니다. 따라서 알 수없는 수의 Think Client 외에도 게이트웨이에서 나오는 가격 데이터를 사용하는 다른 애플리케이션이 알려지지 않은 경우도 있습니다.
씩 클라이언트 (또는 가격 데이터를 사용하는 다른 응용 프로그램)는 RPC를 사용하여 게이트웨이에 전화를 걸면 가격 데이터를 받고 처리를 호출 할 수 있습니다. 그러나 가격 데이터는 지속적으로 게시되며 일부 고객은 특정 데이터에만 관심이 있으므로 적시에 적절한 고객에게 관련 데이터를 제공하는 것이 어려울 수 있습니다. 클라이언트는 게이트웨이를 폴링 할 수 있지만 많은 오버 헤드가 발생합니다. 게이 트웨이는 데이터를 사용할 수있게되는 즉시 클라이언트에서 데이터를 사용할 수 있도록하는 것이 좋습니다. 그러나 이것은 각 게이트웨이가 현재 어떤 클라이언트가 활성 상태이고 어떤 특정 데이터가 필요한지 추적해야합니다. 그런 다음 새 데이터 조각이 사용 가능 해지면 (초당 수없이 발생) 게이트웨이는 각 관심 클라이언트에게 클라이언트에 데이터를 전달하는 RPC를 만들어야합니다. 이상적으로 모든 클라이언트는 동시에 통보되어야하므로 각 RPC는 자체 스레드로 만들어야합니다. 이 작업은 가능하지만 매우 빠르게 복잡해지고 있습니다.
메시징은이 문제를 크게 단순화합니다. 메시징을 통해 다양한 유형의 가격 데이터에 대해 별도의 채널을 정의 할 수 있습니다. 그런 다음 게이트웨이가 새 데이터를 가져 오면 해당 데이터 유형에 대한 게시 - 구독 채널에 해당 데이터가 포함 된 메시지를 추가합니다. 한편 특정 유형의 데이터에 관심이있는 모든 고객은 해당 유형의 채널에서 수신 대기합니다. 이러한 방식으로, 게이트웨이는 청취자 애플리케이션이 얼마나 많은지 또는 그들이 무엇인지 알 필요없이 원하는 누구에게나 새로운 데이터를 쉽게 전송할 수 있습니다.
클라이언트는 여전히 게이트웨이에서 동작을 호출 할 수 있어야합니다. 두 개의 게이트웨이 만 있기 때문에 클라이언트가 메소드를 동 기적으로 호출하는 동안 차단할 수 있으므로 클라이언트 - 게이트웨이 호출은 RPC를 사용하여 쉽게 구현할 수 있습니다. 그러나 이미 게이트웨이 간 통신을 위해 메시징을 사용하고 있으므로 메시지는 클라이언트와 게이트웨이 간의 통신을 구현하는 데에도 유용합니다.
따라서 게이트웨이와 클라이언트 간의 모든 통신은 메시징을 통해 수행됩니다. 모든 구성 요소가 Java로 작성 되었기 때문에 JMS는 메시징 시스템으로 쉽게 선택할 수 있습니다. 이는 메시징 인프라를 거의 변경하지 않고 현재 시스템과 통합 할 수있는 메시지 버스 또는 아키텍처를 효과적으로 만듭니다. 이렇게하면 응용 프로그램의 비즈니스 기능을 은행이 개발하는 다른 응용 프로그램에서 쉽게 사용할 수 있습니다.
JMS와 통신하는 Java 구성 요소.
JMS는 단순히 사양이며 JMS 호환 메시징 시스템을 결정해야합니다. 우리는 IBM MQSeries JMS를 사용하기로 결정했습니다. 은행이 ibmIBM 상점이기 때문입니다. WebSphere 응용 프로그램 서버와 다른 많은 IBM 제품을 사용하기 때문입니다. 결과적으로 지원 인프라와 제품의 사이트 라이센스가 이미 있으므로 MQSeries를 사용하게됩니다.
다음 질문은 MQSeries 메시징 시스템을 독립형 C ++ Contribution 서버 및 TIBCO 기반 Market Data and Analytics Engine 서버와 연결하는 방법입니다. MQSeries 사용자가 TIB 메시지에 액세스 할 수있는 방법이 필요합니다. 그러나 어떻게? 아마도 Message Translator 패턴을 사용하여 TIB 메시지를 MQSeries 메시지로 변환 할 수 있습니다. MQSeries 용 C ++ 클라이언트는 Message Translator 역할을하지만 JMS Translator를 사용하면 JMS 서버 독립성이 희생됩니다. TIBCO에는 Java API가 있지만 고객 아키텍트와 관리자는이를 거부했습니다. 결과적으로 Message Translator 접근 방식을 포기해야합니다.
TIB 서 v에서 MQSeries 서 v 로의 브릿지는 C ++과 Java 간의 통신이 필요합니다. 우리는 CORBA를 사용할 수 있지만 메시징은 무엇입니까? Message Translator 패턴을 면밀히 살펴보면 통신 프로토콜 사용시 채널 어댑터와 관련이 있음을 알 수 있습니다. 채널 어댑터의 핵심은 비 메시징 시스템을 메시징 시스템에 연결하는 것입니다. 두 메시징 시스템을 연결하는 한 쌍의 채널 어댑터가 메시징 브릿지입니다.
메시징 브리지의 목적은 한 메시징 시스템에서 다른 메시징 시스템으로 메시지를 전송하는 것입니다. 이것은 언어 내 Java에서 C ++ 로의 의사 소통의 복잡성이 증가함에 따라 우리가 수행하고있는 작업입니다. 채널 어댑터와 CORBA의 조합을 사용하여 교차 언어 메시징 브리지를 구현할 수 있습니다. TIB와의 통신을 관리하는 C ++ 및 JMS와의 통신을 관리하는 Java에서 하나씩 두 개의 경량 채널 어댑터 서버를 구축 할 것입니다. 메시지 엔드 포인트 인이 두 채널 어댑터는 CORBA를 통해 서로 통신합니다. MQSeries에 대한 우리의 선택처럼 JNI가 회사 표준이기 때문에 CORBA를 사용합니다. 메시징 브리지는 겉으로는 호환되지 않는 메시징 시스템과 다른 언어 사이에서 시뮬레이션 된 메시지 번역을 효과적으로 구현합니다.
채널 어댑터를 사용하는 메시지 변환기.
다음 다이어그램은 게이트웨이 및 기타 구성 요소를 포함한 현재 시스템 설계를 보여줍니다. 이것은 패턴 적용의 좋은 예입니다. Message Translator 패턴을 구현하기 위해 두 개의 Channel Adapter를 비 메시징 프로토콜과 결합하여 하나의 패턴을 효과적으로 사용하여 다른 패턴을 구현했습니다. 또한 메시징 시스템을 비 메시징 시스템에 연결하는 대신 두 개의 메시징 시스템을 비 메시징 교차 언어 변환 프로토콜로 연결하도록 채널 어댑터의 컨텍스트를 변경했습니다.
채널 어댑터가있는 현재 시스템입니다.
채널 구성.
패턴 작업의 핵심은 언제 어떤 패턴을 사용할 것인지뿐만 아니라 가장 효과적으로 사용하는 방법을 아는 것입니다. 각 패턴 구현은 다른 설계 기준뿐만 아니라 기술 플랫폼의 특성을 고려해야합니다. 이 섹션에서는 분석 엔진과 통신하는 시장 데이터 서버의 컨텍스트에서 게시 - 구독 채널을 가장 효율적으로 사용하기 위해 동일한 검색 프로세스를 적용합니다.
실시간 시장 데이터는 TIB에서 시장 데이터를 브로드 캐스팅하는 C ++ 서버 인 시장 데이터 피드에서 시작됩니다. 시장 데이터 피드는 가격을 게시 할 각 채권에 대해 별도의 게시 - 구독 채널을 사용합니다. 새로운 채권마다 새로운 채널이 필요하기 때문에 약간 극단적으로 보일 수 있습니다. 하지만 실제로 TIBCO에서 채널을 만들 필요가 없기 때문에 그렇게 심각하지 않습니다. 오히려 채널은 주제라는 계층 적 이름 집합으로 참조됩니다. 그런 다음 TIBCO 서버는 주제별로 단일 메시지 흐름을 필터링하여 각 고유 주제를 단일 가상 채널로 보냅니다. 결과는 매우 가벼운 메시지 채널입니다.
몇 가지 채널을 통해 게시하는 시스템을 만들 수 있으며 구독자는 관심있는 가격에 대해서만 청취 할 수 있습니다. 구독자는 메시지 필터 또는 선택 소비자를 사용하여 관심있는 채권 가격에 대한 전체 데이터 흐름을 필터링하고 각 메시지 받은대로 처리해야합니다. 시장 데이터가 본드 전용 채널에 게시되면 구독자는 일련의 채권에 대한 업데이트를 등록 할 수 있습니다. 이를 통해 가입자는 채널을 선택적으로 구독하고 메시지 수신 후 결정하는 것이 아니라 관심있는 업데이트 만 수신함으로써 효과적으로 "필터"할 수 있습니다. 필터링을 피하기 위해 여러 채널을 사용하는 것이 비표준 메시징 채널 사용이라는 점에 유의해야합니다. 그러나 TIBCO 기술의 맥락에서 필터를 구현하거나 소유 할 것인지 또는 너무 많은 채널을 사용할지 여부보다는 TIBCO에 내장 된 채널 필터링을 실제로 사용할 것인지 결정합니다.
우리가 설계해야하는 다음 요소는 분석 엔진, 시장 데이터를 수정하고이를 TIB에 재방송하는 또 다른 C ++ / TIB 서버입니다. Java / JMS 개발 범위를 벗어나지 만 분석 엔진의 기본 '고객'이기 때문에 C ++ 팀과 긴밀하게 협력하여 설계하고 있습니다. 현재 문제는 새로 수정 된 시장 데이터를 가장 효율적으로 재방송하는 채널 구조를 찾는 것입니다.
시장 데이터 가격 피드로부터 상속 된 채권마다 하나의 전용 메시지 채널이 이미 있으므로 시장 데이터를 수정하고 채권 전용 메시지 채널에서 수정 된 시장 데이터를 재방송하는 것이 논리적 일 것입니다. 그러나 채권 가격을 수정하는 분석은 거래 상 구체적이기 때문에 이는 효과가 없습니다. 본드 메시지 채널에서 수정 된 데이터를 재방송하는 경우 일반 시장 데이터를 거래자 특정 데이터로 대체하여 데이터 무결성을 파괴합니다. 반면에 우리는 동일한 채널에 게시하는 상인 특정 시장 데이터에 대해 다른 메시지 유형을 사용할 수 있습니다. 구독자는 데이터 무결성을 손상시키지 않으려는 메시지를 결정할 수 있습니다. 그러나 고객은 다른 거래자를위한 메시지를 분리하기 위해 자체 필터를 구현해야합니다. 또한 가입자가받는 메시지가 상당히 증가하여 불필요한 부담이됩니다.
두 가지 옵션이 있습니다.
상인 당 하나의 채널 : 각 상인은 수정 된 시장 데이터에 대해 지정된 채널을 가지고 있습니다. 이렇게하면 원래의 시장 데이터가 그대로 유지되고 각 상인 애플리케이션은 수정 된 가격 업데이트를 위해 특정 상인 메시지 채널을 청취 할 수 있습니다. 본드 당 상인 당 하나의 채널 : 해당 채권의 수정 된 시장 데이터에 대해서만 개별 채권마다 하나의 메시지 채널을 만듭니다. 예를 들어, 채권 ABC에 대한 시장 데이터는 채널 "본드 ABC"에 게시되고, 상인 A에 대한 수정 된 시장 데이터는 메시지 채널 "상인 A, 본드 ABC"에 게시되고, 상인 B에 대한 시장 데이터는 "상인 B , 본드 ABC "등등.
상인 당 하나의 채널.
상인 당 채권마다 하나의 채널.
각 방법에는 장단점이 있습니다. 예를 들어 채권당 접근 방식은 훨씬 많은 메시지 채널을 사용합니다. 최악의 경우 시나리오에서 메시지 채널 수는 총 채권 수와 거래자 수를 곱한 값이됩니다. 우리는 약 20 명의 상인 만 있다는 것을 알기 때문에 만들어지는 채널 수에 상한선을 둘 수 있습니다. 이로 인해 상한값이 10,000 범위 미만으로 떨어지며 이는 시장 데이터 가격 피드가 사용하는 거의 100,000 개의 메시지 채널에 비해 너무 이색 적이 지 않습니다. 또한, 우리가 TIB와 메시지 채널을 사용하고 있기 때문에 상당히 저렴하므로 메시지 채널의 수가 심각한 문제는 아닙니다. 반면에 메시지 채널의 수는 관리 관점에서 문제가 될 수 있습니다. 채권이 추가 될 때마다 각 상인을위한 채널을 유지해야합니다. 이는 매우 역동적 인 시스템에서 심각 할 수 있습니다. 그러나 우리 시스템은 본질적으로 정적입니다. 또한 메시지 채널을 자동으로 관리하기위한 인프라도 있습니다. 이것은 유사한 접근 방식을 사용하는 레거시 구성 요소의 상속 된 아키텍처와 결합하여 단점을 최소화합니다. 이것은 불필요하게 과도한 수의 메시지 채널을 만들어야한다는 것을 의미하지는 않습니다. 오히려 이유가있을 때 많은 수의 메시지 채널을 사용하는 아키텍처 접근 방식을 구현할 수 있습니다.
그리고이 경우에 논리의 위치로 오는 이유가 있습니다. 트레이더 당 접근 방식을 구현하는 경우 애널리틱스 엔진에 입력 및 출력 채널을 그룹화하는 논리가 필요합니다. 애널리틱스 엔진의 입력 채널이 본드당이고 출력 메시지 채널이 상거래 당, 애널리틱스 엔진이 특정 거래자에 대한 여러 채권의 모든 분석 입력을 거래자 특정 출력 메시지 채널로 라우팅하도록 요구하기 때문입니다. 이를 통해 분석 엔진을 Content-Based Router로 효과적으로 전환하여 애플리케이션에 맞춤 라우팅 논리를 구현할 수 있습니다.
애널리틱스 엔진은 메시지 버스 구조 다음에있는 여러 다른 시스템에서 사용할 수있는 일반 서버입니다. 그래서 우리 don†™ t는 시스템 특정 기능으로 그것을 흐리게하고 싶습니다. 반면 채권 가격의 분석 결과를 소유 한 상인의 아이디어는 회사가 인정한 관행이기 때문에 채권당 접근 방식이 효과적입니다. 채권 접근법은 시장 데이터 피드의 메시지 채널 분리를 그대로 유지하면서 여러 메시지 채널을 추가합니다. 우리는 클라이언트에 도달하기 전에 Content-Based Router가 이러한 여러 채널을 관리 가능한 채널 수로 결합하기를 원합니다. 우리 don†™ t는 수천 또는 메시지 채널 s의 수천을 경청하기 위하여 trader†™ s 2 바탕 화면에 달리는 클라이언트 신청을 원한다. 이제 질문은 Content-Based Router를 어디에 둘 것인지를 결정합니다. 우리는 단순히 C ++ / TIB 채널 어댑터가 모든 메시지를 단일 메시지 채널의 가격 게이트웨이로 전달하도록 할 수 있습니다. 이것은 두 가지 이유로 나쁘다. 우리는 C ++과 Java 사이의 비즈니스 로직을 분리 할 것이고, 우리는 나중에 데이터 흐름에서 필터링을 피할 수 있도록 TIB 쪽에서 개별 메시지 채널의 이점을 잃을 것입니다. Java 구성 요소를 살펴보면 Pricing Gateway에 배치하거나 Pricing Gateway와 클라이언트 사이에 중간 구성 요소를 만들 수 있습니다.
이론적으로, 채권 기반의 메시지 채널 분리를 클라이언트 에까지 지속한다면 가격 결정 게이트웨이는 가격 결정 게이트웨이 및 분석 엔진과 동일한 채널 구조로 가격 정보를 재방송합니다. 이것은 JMS의 모든 본드 전용 TIB 채널의 복제를 의미합니다. Pricing Gateway와 클라이언트간에 중간 구성 요소를 만들지 만 Pricing Gateway는 여전히 JMS의 모든 채널을 복제해야합니다. 반면에 가격 결정 게이트웨이에 직접 로직을 구현하면 JMS вЂ에서 많은 수의 채널을 복제하지 않아도되므로 상인 당 하나의 순서로 훨씬 적은 수의 채널을 생성 할 수 있습니다. Pricing Gateway는 C ++ / TIB Channel Adapter를 통해 시스템의 모든 거래자의 각 채권에 대한 소비자로 등록됩니다. 그런 다음 가격 게이트웨이는 각 특정 클라이언트를 해당 특정 상인과 관련된 메시지 만 전달합니다. 이렇게하면 JMS 끝에서 적은 수의 메시지 채널 만 사용하면서 TIB 끝에서 분리의 이점을 극대화합니다.
클라이언트에 대한 완벽한 마켓 데이터 흐름.
메시지 채널 레이아웃 토론은 패턴 통합이 중요한 이유의 좋은 예입니다. 여기서 목표는 메시지 채널을 효과적으로 사용하는 방법을 파악하는 것이 었습니다. 당신은 isn†™ t를 충분히 사용한다고 말합니다. 가장 좋은 방법을 구현하고 현재의 문제를 해결하기 위해 시스템에 통합하는 방법을 찾아야합니다. 또한, 이 예는 실제 비즈니스 활동을 보여줍니다. 우리가 어떤 구성 요소에서 비즈니스 로직을 구현할 수 있다면, 우리는 상인 당 접근 방식을 따라갈 수 있었고 더 적은 수의 채널로 전체적으로보다 단순한 접근 방식을 구현할 수있었습니다.
메시지 채널 선택?
Java / JMS 구성 요소와 C ++ / TIBCO 구성 요소 사이의 통신 메커니즘을 알았으므로 Message Channel 구조화를 살펴 보았으므로 Java 구성 요소가 통신에 사용해야하는 JMS 메시지 채널의 유형을 결정해야합니다. JMS에서 사용 가능한 다른 메시지 채널 중에서 선택할 수 있기 전에 let†™는 시스템의 상위 메시지 흐름을 살펴 봅니다. 우리는 클라이언트와 통신하는 두 개의 게이트웨이 (가격 책정 및 컨트 리뷰 션)를 가지고 있습니다. 시장 데이터는 Pricing Gateway에서 클라이언트로 전달되며, Pricing Gateway는이를 Contribution Gateway로 보냅니다. 클라이언트 응용 프로그램은 가격 책정 게이트웨이에 메시지를 보내 각 본드에 적용되는 분석을 변경합니다. 또한 Contribution Gateway는 다른 거래 장소로 가격 업데이트 상태를 전달하는 메시지를 클라이언트 애플리케이션에 전송합니다.
시스템 메시지 흐름.
JMS 사양은 지점 간 채널 (JMS 대기열)과 게시 - 구독 채널 (JMS 주제)의 두 가지 메시지 채널 유형을 설명합니다. 발행 - 구독을 사용하는 경우 관심있는 모든 소비자가 메시지를 수신 할 수 있도록하는 반면, 포인트 투 포인트를 사용하는 경우 하나의 자격있는 소비자 만 특정 메시지를 수신하도록하는 것이 좋습니다.
많은 시스템은 단순히 모든 클라이언트 응용 프로그램에 메시지를 브로드 캐스팅하여 각 개별 클라이언트 응용 프로그램이 특정 메시지를 처리할지 여부를 자체적으로 결정하도록합니다. 각 클라이언트 응용 프로그램으로 보내지는 마켓 데이터 메시지가 많기 때문에이 응용 프로그램에는 사용할 수 없습니다. 우리가 관심없는 상인에게 시장 데이터 업데이트를 방송하면 시장 데이터 업데이트를 처리할지 여부를 결정하는 클라이언트 프로세서 사이클을 불필요하게 낭비하게됩니다.
지점 간 채널은 클라이언트가 고유 한 서버로 메시지를 보내고 그 반대의 경우도 있으므로 처음에는 좋은 선택으로 들립니다. 그러나 상인이 동시에 여러 기계에 로그인 할 수있는 비즈니스 요구 사항이었습니다. 두 대의 워크 스테이션에 동시에 로그인 한 상인이 있고 지점 간 가격 업데이트가 전송되면 두 클라이언트 응용 프로그램 중 하나에서만 메시지가 수신됩니다. 이는 포인트 - 투 - 포인트 채널의 한 소비자 만 특정 메시지를 수신 할 수 있기 때문입니다. 상인의 클라이언트 응용 프로그램의 각 그룹 중 첫 번째 그룹 만 메시지를 수신합니다.
가격 업데이트를위한 지점 간 메시징.
수신자 목록 패턴을 사용하여이를 해결할 수 있습니다. 수신자 목록 패턴은 수신자 목록에 메시지를 게시하여 수신자 목록의 클라이언트 만 메시지를 수신하도록합니다. 이 패턴을 사용하면 시스템은 각 상인과 관련된 모든 클라이언트 응용 프로그램 인스턴스로받는 사람 목록을 만들 수 있습니다. 특정 거래자와 관련된 메시지를 보내면받는 사람 목록의 각 응용 프로그램으로 메시지를 보냅니다. 이렇게하면 특정 상인과 관련된 모든 클라이언트 응용 프로그램 인스턴스가 메시지를 수신하게됩니다. 이 접근 방식의 단점은받는 사람을 관리하고 메시지를 전달하는 데 상당히 많은 구현 논리가 필요하다는 것입니다.
가격 업데이트에 대한 수신자 목록.
포인트 투 포인트 (point-to-point)가 작동하도록 만들어 졌을지라도, let†™는 더 좋은 방법이 있는지 알아 봅니다. 게시 - 구독 채널을 사용하여 시스템은 클라이언트 응용 프로그램 특정 채널이 아닌 상인 특정 채널에서 메시지를 브로드 캐스팅 할 수있었습니다. 이렇게하면 단일 상인에 대한 메시지를 처리하는 모든 클라이언트 응용 프로그램이 메시지를 수신하고 처리합니다.
가격 업데이트를위한 게시 - 구독 메시징.
게시 - 구독 채널 사용의 단점은 서버 구성 요소에서 고유 한 메시지 처리가 보장되지 않는다는 것입니다. 서버 구성 요소의 여러 인스턴스가 인스턴스화되고 각 인스턴스가 동일한 메시지를 처리하여 잘못된 가격을 보낼 가능성이 있습니다.
시스템 메시지 흐름을 상기하면, 각 메시지 채널에 대해 단일 통신 방향 만 만족 스럽다. 게시 - 가입과의 서버 - 클라이언트 통신은 만족 스럽지만 클라이언트 - 서버 통신은 만족스럽지 않고 서버 - 클라이언트가 아닌 지점 간 클라이언트 - 서버 통신은 만족 스럽습니다. 양방향으로 동일한 메시지 채널을 사용할 필요가 없기 때문에 각 메시지 채널을 한 방향으로 만 사용할 수 있습니다. 클라이언트 대 서버 통신은 지점 간 (point-to-point)으로 구현되며 서버 간 통신은 게시 - 가입으로 구현됩니다. 이러한 메시지 채널 조합을 사용하면 시스템은 포인트 - 투 - 포인트 메시징을 사용하는 서버 구성 요소와 직접 통신 할 수 있고 단점도없이 게시 - 가입의 멀티 캐스트 성향을 얻을 수 있습니다.
채널 유형을 사용한 메시지 흐름.
패턴으로 문제 해결.
패턴은 도구이며 패턴의 모음은 도구 상자입니다. 문제 해결에 도움이됩니다. 어떤 사람들은 패턴이 디자인 중에 만 유용하다고 생각합니다. 도구 상자 비유에 따르면 도구를 사용하여 집을 짓고 도구를 고칠 때 유용한 도구가 아니라는 것을 알 수 있습니다. 사실은 패턴이 잘 적용될 때 프로젝트 전체에서 유용한 도구라는 것입니다. 다음 섹션에서는 이전 섹션에서 사용한 것과 동일한 패턴 탐색 프로세스를 사용하여 현재 작업중인 시스템의 문제를 해결합니다.
시장 데이터 업데이트를 깜박입니다.
거래자는 채권에 대한 새로운 시장 데이터가 수신되면 표 셀이 깜박 거리면서 변경 사항을 명확하게 나타 내기를 원합니다. Java 클라이언트는 클라이언트 데이터 캐시 업데이트를 트리거하고 결국 테이블에서 깜박이는 새 데이터로 메시지를 수신합니다. 문제는 업데이트가 자주 발생한다는 것입니다. GUI 쓰레드 스택은 사용자 상호 작용에 반응 할 수 없기 때문에 과부하가되어 클라이언트를 동결시킵니다. 깜박이는 것이 최적화되고 업데이트 프로세스를 통해 메시지의 데이터 흐름에 집중한다고 가정합니다. 성능 데이터를 살펴보면 클라이언트 응용 프로그램이 몇 초 동안 여러 가지 업데이트를 수신하고 있음을 확인할 수 있습니다. 일부 업데이트는 밀리 초 미만으로 발생했습니다. 메시지 흐름을 느리게하는 데 도움이 될 수있는 두 가지 패턴은 수집기 및 메시지 필터입니다.
첫 번째 생각은 참조 메시지 다음에 작은 시간 동안 수신 된 업데이트를 버림으로써 메시지 흐름의 속도를 제어하는 메시지 필터를 구현하는 것입니다. 예를 들어, 서로 5 밀리 초 이내에 메시지를 무시한다고 가정 해 보겠습니다. 메시지 필터는 마지막으로 허용되는 메시지의 시간을 캐싱하고 다음 5 밀리 초 내에 수신 된 모든 것을 버릴 수 있습니다. 다른 응용 프로그램이 데이터 손실을 견딜 수 없을 수도 있지만 가격 업데이트 빈도로 인해 시스템에서 완벽하게 수용 할 수 있습니다.
시간 기반 메시지 필터.
이 접근 방식의 문제점은 모든 데이터 필드가 동시에 업데이트되지 않는다는 것입니다. 각 채권은 가격을 포함하여 약 50 개의 데이터 필드가 사용자에게 표시됩니다. 모든 필드가 모든 메시지에서 업데이트되는 것은 아닙니다. 시스템이 연속적인 메시지를 무시하면 중요한 데이터가 빠져 나갈 수 있습니다.
관심있는 다른 패턴은 Aggregator입니다. Aggregator는 여러 개의 관련 메시지를 단일 메시지로 조정하여 잠재적으로 메시지 흐름을 관리하는 데 사용됩니다. Aggregator는 첫 번째 집계 메시지의 본드 데이터 사본을 보관 한 다음 새 필드 또는 변경된 필드의 연속 메시지 만 업데이트 할 수 있습니다. 결국 집계 된 채권 데이터는 고객에게 메시지로 전달됩니다. 지금은 Aggregator가 메시지 필터와 같이 5 밀리 초마다 메시지를 전송한다고 가정합니다. 나중에 다른 대안을 찾아 보겠습니다.
부분적인 연속 업데이트가있는 Aggregator.
The Aggregator , like any other pattern, is not a silver bullet; it has its pluses and minuses that need to be explored. One potential minus is that implementing an Aggregator would reduce the message traffic by a great amount in our case only if many messages are coming in within a relatively short time regarding the same bond. On the other hand, we would accomplish nothing if the Java client only receives updates for one field across all of the traders bonds. For example, if we receive 1000 messages in a specified timeframe with 4 bonds of interest, we would reduce the message flow from 1000 to 4 messages over that timeframe. Alternatively, if we receive 1000 messages in the same timeframe with 750 bonds of interest, we will have reduced the message flow from 1000 to 750 messages; relatively little gain for the amount of effort. A quick analysis of the message updates proves that the Java client receives many messages updating fields of the same bond, and therefore related messages. So, Aggregator is in fact a good decision.
What's left is to determine how the Aggregator will know when to send a message it has been aggregating. The pattern describes a few algorithms for the Aggregator to know when to send the message. These include algorithms to cause the aggregator to send out its contents after a certain amount of time has elapsed, after all required fields in a data set have been completed, and others. The problem with all of these approaches is that the aggregator is controlling the message flow, not the client. And the client is the major bottleneck in this case, not the message flow.
This is because the Aggregator is assuming the consumers of its purged messages (the client application in this case) are Event-Driven Consumer s, or consumers that rely on events from an external source. We need to turn the client into a Polling Consumer , or a consumer that continuously checks for messages, so the client application can control the message flow. We can do this by creating a background thread that continuously cycles through the set of bonds and updates and flashes any changes that have occurred since the last iteration. This way, the client controls when messages are received and as a result, guarantees that it will never become overloaded with messages during high update periods. We can easily implement this by sending a Command Message to the Aggregator initiating an update. The Aggregator will respond with a Document Message containing the set of updated fields that the client will process.
The choice of Aggregator over Message Filter is clearly a decision based solely on the business requirements of our system. Each could help us solve our performance problems, but using the Message Filter would solve the problem at cost of the system data integrity.
Major Production Crash.
With the performance of the flashing fixed, we are now in production. One day the entire system goes down. MQSeries crashes, bringing several components down with it. We struggle with the problem for a while and finally trace it back to the MQSeries dead letter queue (an implementation of the Dead Letter Channel ). The queue grows so large that it brings down the entire server. After exploring the messages in the dead letter queue we find they are all expired market data messages. This is caused by “slow consumers, ” or consumers that do not process messages fast enough. While messages are waiting to be processed, they time out (see the Message Expiration pattern) and are sent to the Dead Letter Channel . The excessive number of expired market data messages in the dead letter queue is a clear indication that the message flow is too great – messages expire before the target application can consume them. We need to fix the message flow and we turn to patterns for help slowing down the message flow.
A reasonable first step is to explore solving this problem with the Aggregator as we recently used this pattern to solve the similar flashing market data control rate problem. The system design relies on the client application to immediately forward market data update messages to the trading venues. This means the system cannot wait to collect messages and aggregate them. So the Aggregator must be abandoned.
There are two other patterns that deal with the problem of consuming messages concurrently: Competing Consumers and Message Dispatcher . Starting with Competing Consumers , the benefit of this pattern is the parallel processing of incoming messages. This is accomplished using several consumers on the same channel. Only one consumer processes each incoming message leaving the others to process successive messages. Competing Consumers , however, will not work for us since we are using Publish-Subscribe Channel s in server-to-client communication. Competing Consumers on a Publish-Subscribe Channel channel means that all consumers process the same incoming message. This results in more work without any gain and completely misses the goal of the pattern. This approach also has to be abandoned.
On the other hand, the Message Dispatcher describes an approach whereby you add several consumers to a вЂ˜pool’. Each consumer can run its own execution thread. One main Message Consumer listens to the Channel and delegates the message on to an unoccupied Message Consumer in the pool and immediately returns to listening on the Message Channel . This achieves the parallel processing benefit of Competing Consumers , but works on Publish-Subscribe Channel s.
The Message Dispatcher in context.
Implementing this in our system is simple. We create a single JMSListener called the Dispatcher, which contains a collection of other JMSListener s called Performers. When the onMessage method of the Dispatcher is called, it in turn picks a Performer out of the collection to actually process the message. The result of which is a Message Listener (the Dispatcher) that always returns immediately. This guarantees a steady flow of message processing regardless of the message flow rate. Additionally, this works equally well on a Publish-Subscribe Channel s as it does on a Point-to-Point Channel s. With this infrastructure, messages can be received by the client application at almost any rate. If the client application is still slow to process the message after receiving them, the client application can deal with the delayed processing and potentially outdated market data rather than the messages expiring in the JMS Message Channel .
The crash discussed in this section and the fix using the Message Dispatcher is an excellent example of the limits of applying patterns. We encountered a performance problem based on a design flaw not allowing the client to process messages in parallel. This greatly improved the problem, but did not completely fix it. This is because the real problem was the client becoming a bottleneck. This couldn’t be fixed with a thousand patterns. We later addressed this problem by refactoring the message flow architecture to route messages directly from the Pricing Gateway to the Contribution Gateway. So patterns can help design and maintain a system, but don’t necessarily make up for poor upfront design.
Throughout this chapter, we have applied patterns to several different aspects of a bond trading system including solving initial upfront design problems and fixing a nearly job threatening production crash with patterns. We also saw these patterns as they already exist in third party product, legacy components, and our JMS and TIBCO messaging systems. Most importantly, these are real problems with the same types of architectural, technical and business problems we experience as we design and maintain our own systems. Hopefully reading about applying patterns to this system helps give you a better understanding of the patterns as well as how to apply them to your own systems.
그레고 호프 (Gregor Hohpe)와 바비 울프 (Bobby Woolf).
엔터프라이즈 통합에서 엔터프라이즈 변환에 이르기까지 :
저의 새로운 저서는 대규모 엔터프라이즈 IT의 37 회 에피소드를 통해 기술, 의사 소통 및 조직 기술을 적용하여 건축가가 IT 변환에서 중요한 역할을 수행하는 방법을 설명합니다.
Comments
Post a Comment