分散式項目中，選型與依賴管理
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對象中程式碼，以及對象的使用。
工具型的組件，更傾向於在開發過程中明確規定使用哪一個，盡量避免混搭使用，並且要熟悉工具包提供的各種能力，減少不必要的重複封裝，對於類庫中的常用方法也可以多閱讀，被多數開發認可的程式碼，必然可以開闊自己的程式碼編寫思路。
最後，很多技術棧或者開源組件的不斷發展，都是為了可以更好的解決場景問題，這就需要開發人員定期關注技術的發展趨勢，具備技術視野和洞察能力。
六、參考源碼
應用倉庫：
//gitee.com/cicadasmile/butte-flyer-parent
組件封裝：
//gitee.com/cicadasmile/butte-frame-parent
