【天徳的回答(9票)】:

個(gè)人是某風(fēng)控系統(tǒng)的架構(gòu)師。

1，單機(jī)TPS1000+

2，相應(yīng)時(shí)間0.3秒以內(nèi)

應(yīng)該可以回答你這個(gè)問題，上圖

上面幾個(gè)圖大概就是風(fēng)控系統(tǒng)架構(gòu)的核心了

更正幾個(gè)不正確的觀念

1，需要一個(gè)高效快速的風(fēng)控引擎

錯。風(fēng)控需要快，快的平靜不在引擎，在數(shù)據(jù)讀取。

2，風(fēng)控系統(tǒng)需要規(guī)則引擎

錯。對于風(fēng)控系統(tǒng)來說，核心是要快，而且規(guī)則是很明確的，是就是是，不是就是不是，不需要推理庫。推理就慢，就可能混亂——牽涉進(jìn)去太多高大上概念了——這應(yīng)該是分析系統(tǒng)做的事情。

3，風(fēng)控系統(tǒng)很需要SOA

錯，SOA任何大于2個(gè)系統(tǒng)以上的應(yīng)用都需要。但是不是任何系統(tǒng)的關(guān)鍵。關(guān)鍵就是快。而且要慎重用SOA，太多的ws等調(diào)用會系統(tǒng)慢的一塌糊涂。

4，風(fēng)控系統(tǒng)需要一致性

錯。

風(fēng)控系統(tǒng)根本不能做到100%準(zhǔn)確率，一致性有毛用？！

風(fēng)控的目的是降低風(fēng)險(xiǎn)而不是杜絕風(fēng)險(xiǎn)。

完全杜絕風(fēng)險(xiǎn)的話，交易系統(tǒng)會慢的一塌糊涂，就沒啥交易了。

風(fēng)控系統(tǒng)目標(biāo)要求：剝離核心系統(tǒng)只能，加速核心系統(tǒng)處理速度，同時(shí)風(fēng)險(xiǎn)可控。要遵循大數(shù)原則。

【神宗的回答(1票)】:

風(fēng)控系統(tǒng)必須是獨(dú)立的并且使用客觀數(shù)據(jù)源。具體如何接入你們的交易流程要取決于你們所選用的messaging bus。架構(gòu)我想除了SOA沒有別的更好方案。

我們風(fēng)控系統(tǒng)分為pre trade，trade life cycle和post trade三個(gè)模塊直接接駁tibco主題:

前者用以檢查計(jì)算密集類規(guī)則，比如交易及交易組合對現(xiàn)有投資組合產(chǎn)生的各種風(fēng)險(xiǎn)檢查。我們還做到了某些不合規(guī)結(jié)果可以直達(dá)合規(guī)部門前端系統(tǒng)請求索取批準(zhǔn)口令

交易產(chǎn)生時(shí)是各種額度以及權(quán)限檢查，除了short selling以外基本不會涉及P&L的查詢所以相當(dāng)快速。對于某些自動高頻交易組合(basket)，在pre trade已經(jīng)做好了reservation，風(fēng)控的延遲幾乎可以忽略（烏龍指的檢查是必須的）。

post trade檢查應(yīng)對其他不可預(yù)測的交易結(jié)果。

風(fēng)控系統(tǒng)需要有高效的rule based engine，需要一個(gè)高效的服務(wù)內(nèi)repository(cache)。

【趙云濤的回答(0票)】:

你這個(gè)需求是比較典型的soa應(yīng)用場景，大致思路是風(fēng)控系統(tǒng)開放內(nèi)部服務(wù)，供其他交易系統(tǒng)查詢調(diào)用。

具體開放方式可以是webservice,jsonrpc等方式

【EthanLiu的回答(0票)】:

我們的系統(tǒng)碰到一樣的問題，你可以嘗試EDA(Event-driven architecture)的架構(gòu)處理。當(dāng)然，還是具體分析你的需求對數(shù)據(jù)一致性的要求

原文地址:知乎