SOA 的路究竟要怎麼走

SOA 的路究竟要怎麼走 ?

    大家都知道SOA是服務導向架構，是構造分布式系統的應用程式的方法。它將應用程式功能作為服務傳送給終端使用者或者其他服務。它可解決企業跨平台的問題,是企業跨平台系統的技術解決方案。有了SOA以後，最原始的三層結構發生了變化。很多人在原先的商務邏輯層之上再加一層叫服務層，或者是把商務邏輯層命名了服務層，其目的就是為了提供給UI或者是其它系統的不再是一個類庫而是一個服務，這個服務可以跨平台使用。這樣的一個出發點是相當好的,也正因為這樣一個出發點，很多人喜歡上了SOA，開始SOA的艱辛旅途了。

      開始SOA，很多人或公司首先就會想到需要規範目前公司的開發方法。把原先本來是商務邏輯層的類的方法包裝成一個個服務。於是乎在公司的的開發標準上就多了這樣一條規範。盡量使用WCF或Web Service編寫系統服務提供給其它用戶或UI層使用。這就樣每個程式員都開始編寫服務了，為公司的SOA架構早點實現而努力。公司為實現這樣一個目標也早在2年前就開始著手一些符合SOA架構理念的中間件(或者說ESB 產品）。可是到目前為止，這些項目都停滯不前。當然這裡面有各種各樣的原因，如：成熟的真正符合SOA架構理念的產品實在太少 ，真正有SOA架構理念實踐經驗的人也太少了。沒有經驗，所以公司考慮各種風險問題就不敢盲目實施。這些都不是我今天要分享的問題。我要分享的問題是：很多人或公司在準備應用SOA之前沒有作出充分的評估和對以前開發中面臨的問題作出充分的觀注。

      以前在沒有考慮SOA時，編寫起服務來很輕鬆，覺得無非就是對以前編寫的商務邏輯層的方法進行包裝而已。最近在做一個項目的分析和架構設計的時候，由於此系統涉及的關聯絡統之多，所以想也沒想太多，按原來的方法編寫服務就是了。可是到後來當我快完成系統設計的時候。我才發現很多服的功能被重複設計，有的該拆分的沒有拆分，但不該拆分的被拆分了。從而也導致了很多地方使用了服務調用服務，並可能是嵌套了幾層，特別是一些本來就需要調用外部服務的功能 。很多人也可能說這樣做也沒有什麼問題。有些人認為服務應該拆分的越小越好，這樣才能達到重用的可能。有些人又覺得嵌套服務這樣的做法會造成嚴重的系統效能問題，實踐也確實證明了這一點。

     這就是所謂的服務粒度問題,服務粒度究竟要怎麼來把握？同時各服務之間又怎麼實現事務機制，分散式交易真是可行嗎。如果是，為什麼如此多人不推薦使用。解決事務問題還有其它解決方案嗎？針對這些問題大家又有什麼建設性的建議呢，在SOA實施之前，我們要準備些什麼呢？在這裡希望大家一起探討，謝謝！