今天咱們談談SOFA模塊化,首先看一段SOFA的介紹:java
SOFABoot是螞蟻金服開源的基於Spring Boot的研發框架,它在Spring Boot的基礎上,提供了諸如 Readiness Check,類隔離,日誌空間隔離等能力。在加強了Spring Boot的同時,SOFABoot提供了讓用戶能夠在Spring Boot中很是方便地使用SOFA中間件的能力。git
在接觸SOFA的模塊化概念以前,我對服務端開發的模塊化認知停留在「模塊化」這個層面,我一般會按照下圖所示的結構組織本身負責的應用的代碼。 github
在Spring體系中的模塊(Module),就是經過不一樣的Spring上下文來管理各自模塊中的bean,在開發和編譯期實現模塊化,可是在運行時整個應用仍是在一個Spring上下文中,這些代碼還都是被一個類加載器加載的。面試
在圖1中,我在manager模塊中定義的bean,在service中能夠隨時引用,而不須要關注這個引用是否合理;這樣的開發模式在應用還小的時候沒什麼問題,不過,隨着業務的發展和應用的升級,這些模塊之間的引用關係會愈來愈複雜而沒法管理(這時候應用也就成爲了一個「大泥球」),當某一天須要對應用進行服務化拆分的時候,就須要花很大的精力去理清不一樣模塊之間的耦合和引用關係。SOFA的模塊化特性就是爲了解決這個問題而出現的,這種特性能夠強制開發者在增長兩個模塊之間的引用關係的時候進行仔細的設計和思考。spring
SOFA的模塊,是一種可運行的模塊;普通的Spring項目中的模塊,則是普通的Jar。一個完整的 SOFA模塊和一個普通的Jar包有兩點區別:編程
sofa-module.properties
文件,這份文件裏面定義了SOFA模塊的名稱以及模塊之間的依賴關係。META-INF/spring
目錄下,能夠放置任意多的Spring配置文件,SOFA會自動把它們做爲本模塊的Spring配置加載起來。使用SOFA模塊化特性後,兩個模塊之間的bean沒法直接通訊,須要使用SOFA的通訊協議進行通訊,SOFA支持兩種通訊協議:後端
SOFA爲開發人員提供了三種形式的發佈和引用服務的方式:xml方式、註解方式、編程方式。我如今用的比較多的仍是xml方式,緣由在於SofaService和SofaReference都是隻支持jvm服務的發佈和引用,而xml方式則能夠支持兩種形式的調用。安全
SOFA提供的模塊化解決方案,既實現了真正的、運行時的模塊化,又沒有過分引入OSGI的複雜度,是一種有效的折衷方案。接觸SOFA到熟悉SOFA的過程對個人開發思路影響很大,可是在熟悉了SOFA的模塊化思想以後,我發現這個特性對於我日常的開發工做有幾個好處。網絡
爲了下降服務端的壓力,咱們須要提供一個SDK供業務方使用,在以前Spring體系下,這種架構也是能夠執行的,可是有個弊端——SDK中應用的類和JAR包對於業務方的應用來講也是可見的,在某些狀況下會出現衝突或引入潛在的BUG。架構
使用SOFA的模塊化特性,咱們提供的近端包雖然仍是跟業務方的應用共享一個JVM,可是在類加載器層面實現了隔離,對於業務方來講,他們只須要知道是使用了咱們的哪些接口,而不須要關注咱們這個SDK引入了多少三方JAR包。
利用SOFA模塊化,要實現代碼共享,可沒有Spring體系下那麼簡單——直接引用給一個模塊就能夠。在SOFA中,要進行代碼共享,一般有兩種狀況:(1)近遠端代碼共享(2)管理時和運行時代碼共享。
以第(1)種狀況爲例,某個組件近遠端都是同樣的,爲了不代碼重複,咱們如何實現代碼共享呢?我如今的作法是:在一個公共的test-core模塊中定義須要共享的接口和實現類;這個test-core模塊不能定義爲SOFA的模塊,只能定義爲一個普通的JAR包;而後在須要使用該接口的SOFA模塊(近端模塊和遠端模塊)中,分別聲明和引用那個共享的bean,示例圖以下所示。
這裏的重點在於:
本文主要介紹了SOFA開發框架與Spring體系區別最明顯的一個特性:SOFA模塊化,經過每一個模塊一個Spring上下文的形式,實現了真正的運行時隔離。
基於我我的的使用經驗,SOFA模塊化對服務端開發的影響優大於劣:在維護代碼中的過程當中會仔細斟酌當前應用的模塊依賴結構是否合理;能夠更安全得提供SDK給業務方使用;在實現代碼共享的時候,也須要仔細考慮哪些代碼值得共享,哪些不須要。
本號專一於後端技術、JVM問題排查和優化、Java面試題、我的成長和自我管理等主題,爲讀者提供一線開發者的工做和成長經驗,期待你能在這裏有所收穫。