摘要:公司專屬應用程式架構、企業技術架構 參閱:序 消滅人狼 軟體的十大命題 編程規則
SOA、SOA、SOA!
現在許多企業都在進行基於SOA的應用治理,這裡的關鍵是服務和架構,架構在上一篇<架構簡述>中已經作了介紹,本文重點討論服務粒度設計原則和服務組合。
困擾目前應用領域的主要問題是服務的粒度如何把控,服務如何組合使用?
先說服務粒度,服務該如何劃分,粒度如何把握,這是系統的關鍵,目前應用領域在這方面沒有標準和指導原則,造成系統混亂、死板,也是目前應用軟體的主要癥結,如果解決好這個問題,許多事情迎刃而解。
目前各應用系統最大的問題在於背景服務實際上就是根據功能需求確定的(那些前後不分,沒有清晰服務概念的系統不在討論範圍之內),一切以功能為導向的設計都是庸俗設計,當我們在這樣面向功能的服務思路的影響下,服務粒度的劃分就永遠糾纏不清了,沒有基於業務本質的抽象,都是面向具體易變的功能,這時討論服務粒度都是毫無意義的,其實就是在圍繞功能編寫程式而已。
服務的劃分和粒度應該建立在架構的基礎上(參見),這才是SOA的精要,服務要劃分為服務元件和基礎服務元件兩各層面,這是服務設計的關鍵!
服務元件實現的功能類似於面向功能的服務,但細節上完全不同,它不同於傳統的服務直接操縱資料和處理商務邏輯,它不直接與資料層打交道,更不涉及具體的商務邏輯,它通過組合調用基礎服務元件實現一個具體的業務功能。
基礎服務元件不要面向功能,就是說它不關心是那個具體的業務功能在調用它,它面向業務領域的核心基礎邏輯,負責與業務對象和資料層互動,因此也封裝了該領域的資料。它的特徵是穩定的,與資料層是緊密關聯的,它與資料層一起構成應用系統穩定的核心和關鍵,其他部分包括服務元件和UI都是非關鍵和隨時可以替換的。
服務元件粒度的設計原則
將服務拆分為服務元件和基礎服務元件後,再談論粒度就有了基礎,首先服務元件的粒度不重要,按功能要求劃分即可;基礎服務元件的粒度才是設計的重點,這時基礎服務元件的設計擺脫了功能的束縛,就容易界定了,高內聚、低耦合是宏觀的指導原則,但不易把握,因此給出如下基本原則:
1) 獨立和完整性原則。
保證一個基礎服務元件業務概念的獨立和完整,這是基礎服務元件設計的最關鍵原則,一個基礎服務元件完成業務領域某個完整、而獨立的事項,它可以被多個服務元件共用使用,它做的事情既不多也不少,恰到好處。
2) 單一職責原則。
基礎服務元件職責要單一,只做一件事,做好本職工作,不做分外之事;只有做到單一職責,才能提高基礎服務的共用能力和穩定性。
3) 原子性原則。
基礎服務元件應該具備不可再分的性質,也就是說如果將一個基礎服務元件拆開,拆開的兩部分將從來不會被獨立使用,還必須聯合使用,這就是基礎服務元件的原子性;反之,如果一個基礎服務元件可以被拆分為兩或兩個以上的組件,並且它們都可以被獨立使用,說明該組件的職能不單一,不滿足原子性原則,必須進一步拆分。
4) 資料相關性原則。
基礎服務元件是對基礎商務邏輯和資料的封裝,它通常都會與資料層互動;如果不需要與資料層互動的組件,可以納入到公用函數層,不作為服務元件管理,例如,帳號合法性校正,計息模組等。
5) 相互通性原則。
基礎服務元件允許相互調用,可以使用共用公用庫函數。
把握好上面的原則,就可以合理地確定基礎服務元件的粒度了。
企業級應用系統架構圖
服務組合
服務組合是一個更廣泛的話題,涉及到架構的各個層面,單獨討論某一個具體層面都是片面的,從上面的圖可以清晰地看到服務組合在三個層面都會發生:
1) UI層 -- 豐富
一個複雜使用者介面可能會關聯多個後台服務、檔案服務、Message Service,可能會啟動或參與一個商務程序,這是服務組合最靈活、最豐富多彩的層面。
2) 中台 -- 靈活
中台的服務統一接入通常表現為對服務要求的簡單轉寄,服務組合則由流程平台或服務組合平台實現,它們通常表現為可視化的流程組織或服務過程指令碼語言。
這一層面是按商務程序或過程對服務的組合,是系統實現對業務靈活性的關鍵設計。
3) 後台服務層 -- 細膩
服務元件實際上是對基礎服務元件的過程組合,是面向功能的基礎封裝,我們雖然強調基礎服務元件的重要性,但服務元件才是真正提供各系統使用的服務,也就是說從應用系統的角度看,服務元件是唯一可見的服務,基礎服務元件被服務元件隔離和隱藏,服務元件是為了實現系統功能而對基礎服務元件進行的最有效組合。
這一層的服務組合的特點是細膩和相對穩定,它雖然沒有基礎服務那樣穩定,但相對於商務程序和UI層的組合而言還是相對穩定的。
參閱:http://blog.csdn.net/xabcdjon/article/details/6876058
http://blog.csdn.net/xabcdjon/article/details/6707050