網(wǎng)銀系統(tǒng)擁堵 SOA從治病良方到罪魁禍首

申請免費試用、咨詢電話：400-8352-114

網(wǎng)銀系統(tǒng)擁堵 SOA從治病良方到罪魁禍首

IT管理者本來寄希望于SOA解決系統(tǒng)運維中的一些問題，而這個治病的良藥，偏偏又可能帶來新的疾病，如網(wǎng)銀因系統(tǒng)擁堵而變慢。如何克服SOA架構(gòu)下的新問題，也就成了IT管理者所要面臨的首要任務。

系統(tǒng)運行維護一直是企業(yè)IT部門的重頭戲，而在銀行這樣擁有眾多應用系統(tǒng)的大型企業(yè)，運維問題顯得更加突出。當SOA架構(gòu)出現(xiàn)時，銀行的科技部又不得不去面臨一些嶄新的難題。他們本來寄希望SOA解決系統(tǒng)運維中的一些問題，而這個治病的良藥，偏偏又會帶來了副作用，如何在SOA架構(gòu)下克服這些不良反應，也就成了IT管理者所要面臨的首要任務。

業(yè)務高峰期的擁堵

系統(tǒng)擁堵是經(jīng)常會看到的場景。以網(wǎng)銀系統(tǒng)為例，上午10點鐘左右，是一天中最為集中的業(yè)務高峰，網(wǎng)銀系統(tǒng)發(fā)生了擁堵，造成的問題是客戶不能正常訪問和登錄。在實際工作中，首先能夠發(fā)現(xiàn)問題的往往不是IT運維部門，而是客戶服務部門，因為他們接到了大量的客戶投訴以及抱怨，當問題不斷發(fā)現(xiàn)和積累之后才逐步上報到IT管理者手中，然后運維部門才能予以解決。

這時，系統(tǒng)堵塞已發(fā)生半個小時之久，并造成了較為廣泛的不良影響。為什么運維人員沒能及時發(fā)現(xiàn)問題呢？其實，這不是他們工作不負責任，也不是領(lǐng)導的玩忽職守。網(wǎng)銀系統(tǒng)擁堵的原因并非出現(xiàn)在某個系統(tǒng)上，而是出現(xiàn)在SOA整合之后，多個系統(tǒng)并行和協(xié)同的處理引起了系統(tǒng)擁堵。

通過一個服務鏈路的示意圖，網(wǎng)銀系統(tǒng)擁堵的原因更容易被理解。A、B、C、D是銀行的客戶服務渠道，E、F、G、H都是后臺應用系統(tǒng)。假設A是網(wǎng)銀渠道，銀行客戶在A渠道上提交的服務請求被發(fā)送到ESB上，服務總線將請求進行處理和轉(zhuǎn)換之后，再發(fā)送到其他的后臺應用系統(tǒng)E和G，可能是一個，也可能是多個，而且其中要保證整個服務和事務的一致性，最后再將應答返回給渠道系統(tǒng)A。

經(jīng)分析，筆者發(fā)現(xiàn)每個應用系統(tǒng)都會存在自己的流量控制、超時控制、安全控制和用戶訪問控制。因為經(jīng)過了上線前的集成測試和壓力測試，所以點對點地去訪問某一個系統(tǒng)是不會有任何問題的。可是當通過SOA進行系統(tǒng)整合之后，卻發(fā)現(xiàn)各個系統(tǒng)之間的控制參數(shù)設置，并不是最優(yōu)的，甚至會造成互相矛盾和制約。

系統(tǒng)A、B、C、D、E、F、G、H所設定的流量控制值分別是 60、5、40、10、80、50、30、60，ESB的流量控制值是200。如果現(xiàn)在A系統(tǒng)流量值達到了60的峰值，執(zhí)行1～4步驟時，整個系統(tǒng)的服務都是正常的，但是由于G系統(tǒng)的設定值有限，大于30的并發(fā)服務請求被G系統(tǒng)拒絕，從而導致E系統(tǒng)需要做回滾處理、A系統(tǒng)的用戶服務請求造成堵塞。這樣來看，A系統(tǒng)設定的60并發(fā)流量是存在風險隱患的，在目前G系統(tǒng)不能提升處理能力的情況下，只能設定為30，這就是所謂的木桶短板效應。

參數(shù)設置難題

前面列舉的只是最為簡單的例子，其實在實際工作中所面臨的問題更為復雜、困難。針對SOA架構(gòu)所帶來的改變，運維管理上帶來的困擾主要體現(xiàn)在參數(shù)設置和系統(tǒng)監(jiān)控兩個方面。

系統(tǒng)參數(shù)的設置不盡合理的原因主要有六個方面。

第一，各系統(tǒng)建設和運行維護都是靠獨立的項目組來完成，各自形成了一套自成體系的流量和超時控制方法，可是當多個系統(tǒng)并行運行在SOA架構(gòu)下的時候，沒有一個統(tǒng)一的規(guī)則和機制來進行管理，必然會造成系統(tǒng)的整體運行不夠協(xié)調(diào)和匹配。

第二，各系統(tǒng)的控制參數(shù)都是根據(jù)當初自身的處理能力評估值來設定的，可是這些評估值與實際系統(tǒng)運行態(tài)的訪問壓力相比來說相去甚遠，這也是導致系統(tǒng)運行效率低下的原因之一。

第三，在正常交易狀況下，系統(tǒng)整體是穩(wěn)定運行的，可是當訪問量增大系統(tǒng)擁堵發(fā)生時，服務一旦被拒絕，必然會產(chǎn)生大量的沖正服務來占用通道流量，影響了其他正常服務請求。

第四，各個系統(tǒng)過于強調(diào)自我保護機制，運維人員希望能夠把系統(tǒng)安全風險降到最低，所以在設定系統(tǒng)參數(shù)時，會盡量考慮配置到系統(tǒng)承載能力的下限?？墒菑恼w應用上來講，保守的參數(shù)設置并不足以滿足系統(tǒng)的訪問壓力，從而降低了整體SOA架構(gòu)的系統(tǒng)資源利用率。

第五，從SOA架構(gòu)整體運行來看，并不能在擁堵發(fā)生時，發(fā)現(xiàn)在某個系統(tǒng)內(nèi)發(fā)生的是系統(tǒng)故障還是系統(tǒng)過載，而對于這兩種情況，運維人員完全會采取不同的處理方式。對于系統(tǒng)故障，應該采用系統(tǒng)隔離和故障修復的方式，而對于系統(tǒng)過載，是可以采用降低壓力和過載分流來進行處理。而在目前狀況下，這兩種情況是難以區(qū)分的。

第六，沒有結(jié)合故障隔離機制，也就是在系統(tǒng)故障發(fā)生時，需要將堵塞的服務請求進行隔離，避免影響正常的用戶訪問，而且單點所造成的系統(tǒng)堵塞很容易擴散到整個SOA架構(gòu)中的相關(guān)系統(tǒng)中，導致所有的服務請求受到影響。