SOA 已經不是單純技術問題

　　SOA監管（SOA Governance）是SOA實施中的一個重要話題，但是很多人都搞不清楚其含義。我採訪過很多人，也閱讀過一些資料，才基本弄明白。總的感覺是，如果 直白地去講SOA監管的問題，必然引進大量的新術語，一般開發者實在不容易聽懂。如果能夠舉一個例子，那麼大家就容易理解得多。恰好昨天在書上看到一個真 實的故事，很形象地說明了SOA監管的意義。所以不妨跟大家分享一下。這個故事是關於Sun的，當然這類事情實際上曾經發生在很多大型公司裡。 

　　在90年代後期，Sun推出了一系列產品，包括Java、Solaris等，他們希望能夠儘可能地鼓勵使用者去使用這些產品，但是當時網速太慢， 通過 Internet下載幾百兆的軟體根本不現實，於是Sun在網站上推出一個電子商務服務，下面我們不妨稱之為服務A，你只要通過信用卡付10-20美刀快 遞費用

　　不久之後，這個程式設計師被調到了Java開發組。當時Sun的Java網站提供一個類似MSDN的Java產品光碟訂閱服務，下面不妨稱之為服務 B，這個服 務每季度向訂閱者寄送最新的Java產品光碟。當然，訂閱者也要通過信用卡付訂閱費。碰巧這項工作又交給了這位程式設計師來完成。他當然不願意重寫那個很麻煩 的信用卡結帳服務Z，既然原來的那個服務是通過HTTP暴露在內網裡的，何不復用之？他就簡單地複用了這個信用卡結帳服務Z，完成了任務。這樣，在90年 代後半期，這位程式設計師就率先實現了企業服務的複用。而十年後，服務的複用正是今天SOA追求的目標之一。 

　　這樣就形成了一個有趣的局面，即服務A中包含一個子服務Z，而服務B又依賴於服務Z，Z實際上成為了一個公共服務，但是這個祕密只有那個程式設計師和少數幾個人知道，Sun的經理們對此懵然不知。 

　　幾年之後，這位程式設計師離開了Sun，隨著他的離去，這個祕密變得更加不為人知。 

　　隨著網際網路的發展，人們已經習慣於從網上直接下載軟體，服務A已經變得越來越過時了。於是終於有一天，Sun的一個經理決定，關閉服務A。結果意想不到的事情發生了，隨著A的關閉，服務Z也被關閉了，這就導致服務B全面崩潰，所有的訂閱者都無法付款了。 

　　這就是一個缺乏監管的情況下產生的典型事故。在傳統的企業IT架構裡，當系統僅僅是部門級煙囪系統時，軟體模組之間的關係簡單，監管不是一個很 突出的問 題。而當各部門系統進行整合時，如果採用EAI/ETL方案，則也不大有監管的問題。只有在實施SOA的時候，把傳統的煙囪系統打散成為一個個可複用的服 務時，監管的問題就突出了。SOA監管的意圖，就是要讓各種服務以清晰有條理的方式組合協作起來，並清晰地度量每一個服務的開銷，評估每一個服務的開發和 維護所需的技術，確定當服務失效時採取的必要措施。總之，就是要把服務管起來，讓它們有組織有紀律的共同工作。如果沒有一個監管的制度和計劃，那麼就會出 現這樣的局面：服務與服務之間有什麼關係？不知道。服務之間彼此是否依賴？不知道。這兩個服務的功能是否重複？不知道。這個服務是否冗餘？不知道。開發維 護這個服務需要什麼技能？不知道。當用戶量增加時，維持這一服務的QoS所需的硬體消耗怎麼變化？不知道。當服務崩潰時，誰來接替？往誰那裡打電話？是否 有手工流程緊急應對？不知道！一大堆無法無天的服務以誰也想不到的方式攢在一起，任何一個點風吹草動都有可能會天下大亂。這就是缺乏監管的SOA將發生的 局面。這樣的SOA，與其說是一個系統，不如說是一團亂麻，一場災難。