架構抽象化設計
業務研發，到了一定階段需要對設計進行抽象化進行，抽象化兩種方式一種是程式庫，通過呼叫庫形式實現程式碼重用，例如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然後基於註解方式定時器不起作用。
架構設計本質上還是降低複雜度，實現業務需要，架構本身需要不斷演進，不能期望一步到位，並且擴充套件性也是在一定範圍內，而不是無限制可擴充套件性。架構取決於設計者對於業務理解深度，以及對於各種基礎知識掌握以及熟練運用程度。
文章零散說了很多方面，其實說的就是一件事，架構設計到實現又一個巨大鴻溝以及一個漫長實現過程，需要對各個知識點以及庫體系有相當瞭解，才能很好去實現，不然會導致事倍功半。