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