JAR包：如果我依賴你，那勸你別依賴我。
一、技術視野
1、背景描述
在分散式系統搭建的初期，對於元件的選型是需要慎重考慮的，特別是對於同一個場景但是有多個不同元件可選項時，需要經過一定的調研再去確定最終選擇，從而儘量避免後期業務發展引起核心元件的替換問題。
不同的技術選型，意味著不同的依賴包和版本，作為工程的基礎，複雜的系統中管理龐大的依賴，需要具備體系化的思維。
2、開源體系
從個人習慣上來看，在核心的技術元件選型上，優先考慮從Spring和Apache兩個生態中尋找，所以要對這兩套開源體系下的元件有廣泛的瞭解，以及相關配套的整合工具，在開發過程中有很多複雜的技術實現都是有對應的封裝包來解決，更多的時候是不熟悉或沒注意到；
再者就是很多熱門的開源專案，這裡理解為針對某個場景可以提供更好的解決方案，比如快取或者任務排程等，在這個選擇中可以優先關注大廠的開源元件，經過複雜業務的考驗會相對成熟和穩定。
大部分情況下技術需求基於現有開源生態都是可以尋到相應的解決方案，所以定期關注開源元件的釋出更新，對於開闊思路和視野有極大的幫助。這裡從廣泛的角度看開源體系，實際的專案中是有很多輕量級的工具包，可以簡化程式碼和提升效率。
二、框架層面
1、JDK版本
對於核心框架的依賴，除了選型這個方面，還要考慮的就是版本問題，對於很多小廠來說更多的是處在一種"等待"的狀態，等待開源市場給出更合理的選擇。
就從JDK的選擇來看，作為Java工程中最底層的依賴，很多專案都是從JDK5直接跳躍到JDK8的，多數開源元件的最低依賴也需要JDK8，從版本的釋出上看也就算箇中間版。
所以在核心依賴上優先考慮使用最多的版本，至於後續要升級到什麼版本，稍微留心注意下就會知道。如果版本過舊會和大多陣列件衝突，如果版本過新要適配突發的問題，從選擇上看不算特別明智。
2、核心框架
核心框架依賴的選擇，需要遵守一個體系的原則，例如在Java工程中必選的Spring體系，在微服務的架構設計中，對於服務註冊發現，通訊請求，閘道器路由等功能元件，都可以圍繞SpringCloud的相關整合去做選擇，這樣可以有效減少技術帶來的負擔，並且具有活躍的社群和詳細的文件支撐。
三、單工程分層
微服務的架構中，針對單服務的工程程式碼也會分包管理，不同分層的包管理特定性質的程式碼檔案，除了各個服務依賴公共包core(常見命名)之外，通常至少劃分bean、feign、serve三層：
- core：各個服務依賴的基礎包，封裝技術層面的解決方法，或業務的複用功能；
- bean：工程物件(入參出參)和常量管理，一般不包括資料表的對映物件；
- feign：服務互動的介面層封裝，工程間通訊的核心依賴；
- serve：服務中具體業務實現層，控制層與feign介面層對應；
這樣分層分包管理工程，服務之間的依賴就會清晰許多，也極大的保證了程式碼的複用性，版本升級時棄用的程式碼標記為過期，同時指向新的程式碼路徑，其他服務升級時再跟隨升級，最終徹底剔除過時程式碼，以此避免業務發展導致程式碼工程的混亂。
四、中介軟體
中介軟體在服務中是必不可少的業務支撐，例如開發中最常用的幾個：快取管理、訊息佇列、任務排程等；
訊息佇列：可以通過模式封裝，實現訊息的統一匯流排管理，避免訊息混亂；例如之前總結過的訊息中介軟體改造方案：
快取管理：每個服務都或多或少存在快取需求，快取機制也具有一定的共性；
任務排程：通常會將任務排程的元件整合在單個服務中，實現排程管理的基本能力，然後採用服務間通訊機制（例如Feign介面），去觸發待任務執行；
中介軟體並不僅僅是引入依賴然後各種API的呼叫，基於什麼策略和設計模式去管理，會給工程帶來不同的影響。
五、輕量工具
許多專案下都會有一個util分包，用來存放常用的工具程式碼檔案，如果是在複雜的分散式專案中，通常打成獨立的jar包，後來這些基礎的工具類被匯聚到開源專案中，極大的降低維護成本，並且可以標準化的使用工具：
對於工具包中提供哪些核心能力，經常查閱相關文件即可，像一些：日期、字串、集合、JSON、Http、檔案流等常見功能，都會封裝相應的處理方法。lombok外掛可以高度簡化Java物件中程式碼，以及物件的使用。
工具型的元件，更傾向於在開發過程中明確規定使用哪一個，儘量避免混搭使用，並且要熟悉工具包提供的各種能力，減少不必要的重複封裝，對於類庫中的常用方法也可以多閱讀，被多數開發認可的程式碼，必然可以開闊自己的程式碼編寫思路。
最後，很多技術棧或者開源元件的不斷髮展，都是為了可以更好的解決場景問題，這就需要開發人員定期關注技術的發展趨勢，具備技術視野和洞察能力。
六、參考原始碼
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
元件封裝：
https://gitee.com/cicadasmile/butte-frame-parent