SOA架構暴露固有缺陷 CIO應時刻保持警惕

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

對于很多企業(yè)領導者來說，半夜兩三點電話響起不是什么好事情——這很可能意味著，企業(yè)出了事，而且這些事情很有可能不知道該由誰解決。

隨著企業(yè)規(guī)模的逐漸擴大，企業(yè)的復雜性也不斷增加，不同部門之間職責、利益、流程的交錯，讓包括部分高層管理者在內(nèi)的很多人不清楚，如果企業(yè)某個地方出了問題，到底應該追根溯源到哪個部門、哪個人。

這種現(xiàn)象對于已經(jīng)深入到企業(yè)每個角落的IT產(chǎn)品、IT服務也是如此。早上南京OA登錄不上去了——這到底是網(wǎng)絡問題，還是南京OA問題，或者是數(shù)據(jù)庫、服務器出錯了？IT部門到底應該找哪個供應商解決問題呢？

當我們把目光轉(zhuǎn)向SOA時，同樣的問題出現(xiàn)了——當應用因為一個根本性的故障而被迫終止的時候，應該由誰來負責接聽并處理用戶的緊急求助？

目前SOA已經(jīng)步入實施的縱深階段，然而，近來國外的一系列SOA實施案例表明，曾經(jīng)備受肯定的SOA架構正暴露出其架構的固有缺陷——當基于SOA的服務管理達到一定深度時，目前的SOA管理策略在服務故障的追根溯源方面力有未逮，這一現(xiàn)實對整個SOA架構和管理理念都提出了嚴峻的挑戰(zhàn)。國內(nèi)SOA用戶應該對這一動向保持足夠的警惕。

誰該為故障負責

分析師蘭蒂·海福納認為，曾經(jīng)被廣為稱贊的SOA的架構特性正在暴露出它的固有缺陷——目前，大部分應用了或正在應用SOA架構的公司和組織對于“應該由誰來負責響應故障求助”這一問題困惑不已。

從目前的狀況看，似乎總是能找到這樣或那樣的團隊負責提供應用故障服務，但是最后的結局往往是所有應用相關的開發(fā)團隊都被扯進來，圍繞糾纏不清的責任問題一籌莫展，問題的根源卻無從確認。

SOA架構擁有太多處于移動狀態(tài)的組件，因此，順藤摸瓜找到服務故障發(fā)生的根本肇因并不是一件容易的事情，更何況與此同時SOA還是一個由多個相互關聯(lián)的層組成的架構，這更增添了查錯的復雜性。

海福納認為，目前的大部分SOA管理工具必須進行有針對性的改進以應付這種尷尬局面。SOA管理工具必須具備鎖定深層次服務管理問題的能力。應該說，現(xiàn)有的SOA管理工具在定位問題的發(fā)生方面做得不錯，它們大都能在問題發(fā)生時通過一項服務提醒CIO，即使故障產(chǎn)生的環(huán)境非常復雜。比如在Java、.NET、消息中間件或者是遺留系統(tǒng)接口內(nèi)部這類環(huán)境，這些管理工具仍然能夠迅速發(fā)現(xiàn)問題。

但是，僅此而已。

CIO們被告知系統(tǒng)中產(chǎn)生了一個故障，“好吧，接下來問題來了，SOA服務產(chǎn)生了問題，我們該向誰撥打這個求助電話呢？”海福納說，面對實施過程復雜、需要由多個團隊協(xié)作的SOA架構中產(chǎn)生的問題，每個團隊都會龜縮在各自的陣地中大喊：“這不是我的錯——我負責的部分工作得很好！”這顯然是 CIO們始料不及，卻可能得到的唯一答案。