架構抽象化設計
業務研發,到了一定階段需要對設計進行抽象化進行,抽象化兩種方式一種是程式庫,通過呼叫庫形式實現程式碼重用,例如dll、so、jar包,另一種形式是通過服務形式,比如web服務soa以及當下微服務形式對業務模組進行抽象化設計。
對於線上業務抽象化去實現,具體到實現方式上,在java語言上存在兩種方式,一種jar包形式,一種是服務方式。兩種方式各有優劣,兩種方式結合著用,用兩種方式優勢,能夠將架構實現更合理獲得更多形式上重用。
jar包形式,將邏輯進行抽象實現,能夠引入在業務服務中使用,使用jar包時要注意基於Spring jar,如果多執行緒使用時,要注意類引用方式,再多執行緒中單獨載入,然後在使用。
throwable異常機制,整個異常指責鏈,異常繼承體系要明確。避免異常捕獲不到情況,導致程式異常。異常框架以及異常體系結構:
thread local機制,thread local本身是繫結在每個執行緒上的物件,使用時需要thread local本身是靜態的,這樣才能保證變數是全域性的且唯一。使用樣例類似如下:
static ThreadLocal<XgBoostCompute> threadLocal = new ThreadLocal<XgBoostCompute>();
public void run() {
xgBoostCompute = threadLocal .get();
if ( xgBoostCompute == null ){
xgBoostCompute = new XgBoostCompute();
boolean bool = xgBoostCompute .load(Constants. MODEL_PATH );
if (bool) {
threadLocal .set( xgBoostCompute );
}
}
}
架構設計最終落到實現上,需要對使用到語言層面比如執行緒池、 synchronized 、countdownlatch 理解要深入,對於庫層面 Spring 也是, 類似整體載入機制要明確,不然整個實現會遇到各種問題,會因為點的卡殼而花費大量時間。
對於synchronized在作用於塊的時候,要鎖定唯一物件,物件唯一性很重要不然可能導致鎖不住,鎖住後的整個流程單執行緒模式,所以鎖住模組要儘量小,儘量小之後才能獲得更高效能。
在有就是版本,spring版本是4就要注意spring-conifg.xml中頭部head版本,版本不一致可能會導致整個個別功能起作用,部分功能不起作用,最近遇到4.0 spring配置檔案3.0然後基於註解方式定時器不起作用。
架構設計本質上還是降低複雜度,實現業務需要,架構本身需要不斷演進,不能期望一步到位,並且擴充套件性也是在一定範圍內,而不是無限制可擴充套件性。架構取決於設計者對於業務理解深度,以及對於各種基礎知識掌握以及熟練運用程度。
文章零散說了很多方面,其實說的就是一件事,架構設計到實現又一個巨大鴻溝以及一個漫長實現過程,需要對各個知識點以及庫體系有相當瞭解,才能很好去實現,不然會導致事倍功半。