您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關SOA/微服務的要求和原則是什么,文章內容質量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關知識有一定的了解。
SOA思想的核心根據定義可以拆分為兩個重要的內容,一個是根據業務建模和架構設計過程找尋到粗粒度的可重用的服務;其二是這些服務可以組合,可以組裝和編排以滿意業務流程的需求。前者重點對應的是ESB服務總線,而后者重點對應的BPM和BPEL相關業務能力。
按照優先順序需要解決的問題:解耦,復用,編排,控制
一個完整的業務系統通過業務建模和架構分析應該根據松耦合的原則拆分為多個業務組件,業務組件最終轉換為應用系統實現中的應用模塊(服務組件+技術組件)。每一個組件都相對獨立,都可以獨立進行分析設計,開發,測試,部署和后續運維的管理。
解耦要做到徹底,不僅業務層進行組件拆分,底層數據源等也要完全拆分開。
組件對外提供的應該是服務,不應該是通道形式的CRUD。
服務本身就是輕量API,通信采用webservice,rest還是消息等其他方式并不重要,重要的是服務接口和契約不變。
服務的目的不僅僅是為了解決組件間的交互,這僅僅達到了服務能夠松耦合各個組件的目的。而為了滿足服務的可復用性,即需要考慮在各個業務模塊的基礎上,應該有一個更加底層的提供共性能力的基礎公共模塊,這個模塊提供共享的可復用的服務能力出來。
技術組件:安全,消息,緩存,文件,日志,異常,流程引擎等。
組件劃分的粒度需要詳細設計,每個組件內聚的領域活動可能依賴多個服務,甚至其他組件。這時要保證組件之間不能混亂的交叉調用。業務流程的實現或復雜業務邏輯的實現應該體現服務組裝或服務編排的思想。
組件領域活動內依賴的其他組件服務越少越好。
編排服務盡量避免分布式事務處理,需要考慮自行實現事務管理方案。
組件領域活動內不依賴該組件內的其他服務。
組件內服務之間保持獨立性,避免業務重疊,一旦發現業務重疊重新考慮服務的設計。
一個業務系統內部可以選擇實現一個最簡單的服務總線,也叫做系統內部輕量ESB。
實現這個目的并不是為了UDDI統一的服務目錄庫。而是業務系統本身服務化后,組件之間會出現大量的服務消費和調用,一個業務系統需要對這些業務訪問調用進行統一的管控,包括服務運行監控,安全和鑒權,統一服務地址等。這些是基本的需求。
當然沒有真正意義上的服務總線也不要緊,一個業務系統服務化后,在一種標準的模塊化服務架構下,是很容易的實施和接入到一個ESB上面的。這個并不是基于 SOA架構的業務系統的重點。包括現在的OSGI框架,也并不是完全的符合輕量ESB總線的要求。而對業務系統引入了更多在實現上的復雜性。
關于SOA/微服務的要求和原則是什么就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。