前言
在上一篇文章淺析springboot自動配置原理中，我們已經清楚知道關于springboot自動配置的實現原理，但是上一篇并沒有花筆墨去講解如何實現自定義的starter，原因有兩個，第一個是本來代碼已經貼太多了，強迫癥的我不愿意再加那么多實現細節(jié)的代碼，第二個是因為我覺得比較簡單，各位看官自行google吧。這一篇，咱們來好好討論自定義springboot-starter的應用場景。
應用場景
場景一：簡化多服務公用框架集成。眾所周知，springboot或者其他第三方所提供的starter，都是做框架集成，通過簡化配置，提高開發(fā)效率，所以我們自定義starter的第一個應用場景也是基于這個思路。那我們日常開發(fā)工作中，有哪些框架是多個服務共用的，并且springboot或者其他第三方暫未提供，或者嫌棄第三方寫的太爛，想自己重新實現的，都可以通過編寫自定義starter來簡化工作。我們公司采用微服務架構，每個服務都會使用swagger來生成在線接口文檔。未封裝swagger-starter之前，那么在每個服務里邊，都需要增加swagger的配置類。而封裝swagger-starter之后，可以省去這一步的操作，還可以通過增加自定義配置來實現一些自定義的功能。比如我們公司安全部門要求生產環(huán)境不能對外開放swagger接口文檔地址，那么我們就可以添加一個enabled的參數來代表swagger是否啟用，默認啟用，在生產環(huán)境的配置中將enabled設為false即可達到這個目的。類似的額外功能還有很多，比如增加請求頭等等，其他的讀者自行發(fā)掘。
上面提到的是業(yè)務無關性的starter應用場景，那么我們拋出一個問題，是否有業(yè)務相關且多個業(yè)務場景或者多個服務會使用的應用場景？根據這個問題的描述，我們至少可以列出以下幾個業(yè)務相關場景。
場景二：服務間調用的鑒權。我們公司服務之間互相調用需要進行鑒權（還是安全部門的要求），由于服務間是通過feign來實現相互調用，所以無法通過網關來進行統一鑒權。實現方案是通過新增feign攔截器，在源頭服務發(fā)起調用之前增加鑒權參數，請求到達目標服務后通過鑒權參數進行鑒權。這兩步操作很明顯是每個服務都需要的，那么這種情況下，我們就可以把這兩步操作封裝成starter，達到簡化開發(fā)的目的。同時，我們還可以通過增加配置，實現更細粒度的調用權限控制，比如訂單服務只能調用庫存服務的查詢商品庫存接口，而無法調用更新商品庫存的接口。
場景三：郵件，短信，驗證碼功能。這些功能，在某些公司可能會放在common包里，但是這樣其實會導致common包的臃腫，因為并不是所有服務都會使用到。有些公司（還是我們公司）可能對郵件服務器的訪問有嚴格權限控制的，而且權限開通流程比較繁復的，那么會考慮做成服務，部署在已經具有訪問權限的主機上，減去重復申請權限工作。如果除去這些限制，那么將這些功能封裝成starter還是挺不錯的，可以避免common包的臃腫。
場景四：大愛無疆場景。看到這個場景，大家是不是很懵逼，哈哈哈。是這樣的，我們小組有位同事特別貼心，不僅編寫接口，還提供調用接口的feignclient-starter給需要調用該接口的同事，starter還包含了相關請求類以及響應類。這已經不是可以通過有沒有必要來理性分析的場景了，雖然我覺得不是很必要，但是我是很支持他這樣做的，特別是給我提供接口的時候，哈哈哈。
總結
其實需不需要封裝starter，最終還是根據技術架構而定，這里只是對我遇到的一些場景做一些描述，讀者如果有別的場景，非常歡迎留言。
