爲應對傳統單體架構的缺陷，微服務架構被企業廣泛應用。Spring Cloud 爲開發人員提供了快速構建微服務的系列工具，但是並沒有進行相關整合， vole 是在其基礎上搭建的一套可以快速實現微服務的基礎腳手架工具。
1、傳統單體架構的缺陷
傳統單體應用將所有功能的表示層、業務邏輯層、數據訪問層、包括靜態資源等全部糅合在一個工程內，編譯 打包 部署在單臺服務器上線，比如打成 war 包放在 Tomcat 的 webapp 目錄中部署。這樣的開發部署流程適合小型項目，系統功能不復雜，訪問量不大的情況下有絕對的優勢，開發速度快且運維方便。但是，當業務越來越複雜，功能越來越多，參與的開發人員越來越多，該流程就暴露出如下問題：
- 業務複雜，代碼量增大，代碼可讀性、可維護性、可擴展性下降。一旦要新同事接手代碼，需要花很多時間理解 ;
- 測試難度增大 ;
- 單體應用併發能力有限，訪問量高，用戶體驗差 ;
- 單體應用容錯率低，一旦出錯，可能導致整個項目崩虧 ;
- 將單體應用做集羣部署，添加負載均衡服務器（例如 Nginx 反向代理轉發請求）可略微緩解以上兩條條缺點，但不能完美解決問題。
2、微服務是什麼？
微服務架構：就是將原來的單體應用按義務範圍來，劃分爲多個小 model，每個微服務運行在自己的進程中，相互不產生影響，完全自動化獨立部署，並使用輕量級機制通信，通常是 HTTP RESTUFUL API，可對各微服務進行集中管理。這些小 model 可以使用不同的編程語言及存儲技術，微服務架構是分佈式架構。
2.1、微服務架構的優點
- 按業務劃分的微服務單元獨立部署，運行在獨立的進程中，服務之間沒有任何耦合，具備良好的擴展性和複用性；
- 服務之間通常採用 HTTP 通信，該通信機制與平臺和語言無關，可以使用不同的編程語言和存儲方法。也可以採用輕量級消息總線通信，如 RabbitMQ、Kafaka 消息隊列等，數據格式一般採用 JSON；
- 每個微服務都有自己的數據庫，服務間數據庫相互是獨立；
- 微服務一般採用自動化工具部署。Docker 容器技術是微服務最佳部署容器；
- 服務集中化管理（服務註冊與發現：Eureka、Zookeeper、Consul），監控（服務運行狀況監控：Spring-Boot-Admin-Server）；
- 微服務架構是分佈式架構。
3、微服務腳手架工具：vole
Spring Cloud 爲開發人員提供了快速構建微服務系統的系列工具，包括配置管理、服務發現、斷路器、路由、微代理、事件總線、分佈式會話等相關功能，但是並沒有進行相關整合， vole 是在 Spring Cloud 基礎上搭建的一套可以快速實現微服務架構的基礎腳手架工具，vole 基於 Spring Cloud Finchley 版本 的框架搭建，可以快速幫助項目組完成老系統微服務改造。蘇寧新廣告平臺原來大單體應用的基礎上使用 vole 對原來單體應用進行了快速改造，幫助業務系統快速搭建微服務化。
架構模型圖如下所示：
Github 相關鏈接 ：https://github.com/gavenwangcn/vole
主要包括以下功能模塊：
- 基礎核心工具包 common
- 微服務服務中心 eureka
- 微服務配置中心 config
- 微服務鑑權中心 auth
- 微服務登陸統一中心 passport
- 微服務後臺統一管理中心 portal
- 微服務邊緣網關管理中心 gateway
- 微服務其他相關模塊（監控，消息，job）
vole-common
vole-common 基礎核心工具包，主要負責如 請求切面、服務配置、異常處理、參數格式化、請求防護、redis、Db、基礎配置組件、以及其他相關如文件服務、基礎工具類等組件。這裏，重點要介紹 bean 包下組件 。
如上圖bean 包下主要是 aop Controller 增強切面，保證各微服務的接口返回值都基於基礎格式類 ® 。
config 包主要負責 請求忽略配置插件， api 文檔插件配置以及 - MVC 參數管理配置類。
handler 和 resolver 包 分別處理全局異常和用戶請求參數解析。
Xss 包處理請求攻擊過濾的 比如 xss 攻擊，sql 注入等。
基礎工具類爲整個腳手架提供了基本配置管理功能，爲其他相關組件提供了基礎功能。
vole- eureka
vole- eureka 微服務註冊中心 eureka 高可用配置方案，Eureka 通過運行多個實例，使其更具高可用性。事實上，這是它的默認屬性，用戶需要做的就是給對等實例一個合法的關聯 serviceUrl, 如下圖所示：
eureka 互備兩個節點 Eureka-eserver peer1 8761,Eureka-eserver peer2 8769 相互感應。當有服務註冊時，兩個 Eureka-eserver 是對等的，它們都存有相同的信息，這就是通過服務器的冗餘來增加可靠性，當有一臺服務器宕機了，服務並不會終止，因爲另一臺服務存有相同的數據。
vole-config 微服務配置中心
在分佈式系統中，由於服務數量巨多，爲了方便服務配置文件統一管理，實時更新，所以需要分佈式配置中心組件。在 Spring Cloud 中，有分佈式配置中心組件 spring cloud config ，支持配置服務放在配置服務內存中（即本地），也支持放在遠程 Git 倉庫中。在 spring cloud config 組件中，分兩個角色，一是 config server，二是 config client。
如上圖 vole-config 默認使用本地方式，也可以配置到 git 服務器上去。
當服務實例很多時，都從配置中心讀取文件，這時可以考慮將配置中心做成一個微服務，將其集羣化，從而達到高可用，架構圖如下：
配置中心高可用架構圖
vole-auth
vole-auth 是微服務鑑權中心。在微服務架構下，一個應用會被拆分成若干個微應用，每個微應用都需要對訪問進行鑑權，每個微應用都需要明確當前訪問用戶以及權限。尤其當訪問來源不只是瀏覽器，還包括其他服務調用時，單體應用架構下的鑑權方式就不是特別合適。在微服務架構下，要考慮外部應用接入的場景、用戶 - 服務鑑權、服務 - 服務鑑權等多種鑑權場景。vole-auth 是基於 spring cloud auth2 基礎上配置的鑑權中心，實現了服務與數據分離的方式，即用戶相關數據 都是通過服務獲取，vole-auth 負責相關鑑權功能。
如下圖所示：
鑑權關係圖
- auth 的 memberService 去掉用 mps 服務的相關會員基本信息來確認 用戶權限是否正常；
- Auth 服務內部有兩個重點服務包 :config 包 和 component 包；
- Config 包：主要負責 auth 服務的基本配置 ,- 包括安全配置方案，token 增強和存儲方案以及 JWT 配置；
- Component 包 ：主要負責自定義 token 使用方案，這裏主要是自定義手機號 token 方案。
vole-passport
vole-passport 是微服務登陸統一中心主要負責各系統後臺相關登陸服務管理，基於 springSecurity 改造使用 cookie 管理登陸信息的服務，vole-passport 支持各個服務註解式一鍵配置方式。
如下圖所示:
統一登錄配置中心圖
業務人員需要通過登陸相關業務系統進行查看或者添加相關數據先要經過 passport 進行認證和鑑權。Vole-passport 採用集中式服務管理模式，各個子業務系統的介入只需系統上配置相關客戶端信息。Passport 重點工模塊是 passport-common 負責 passport 所有功能服務組件。
如上圖所示包括：
- auth 用戶認證基本信息管理；
- config 服務配置管理包括服務端配置和客戶端配置；
- cookie 是負責寫入和讀取 cookie 基本信息；
- detail 是用戶基本配置信息寶庫用戶的密碼，登陸狀態，id 等等；
- Filter 是基於 springSecurity 改造的相關的客戶端和服務端的配置管理服務；
- Handler 是用戶正常登陸等處的成功或失敗處理；
- Permission 是負責用戶登錄後相關資源的鑑權服務；
- Token 用戶基本 token 操作管理。
相關係統配置 passport-config 如下所示：使用配置繼承 WebSecurityConfigurerAdapter 的配置類，並 @EnablePassportSso 開啓 sso 配置
在 springboot 啓動配置文件 (application.yml) 上配置相關統一登錄服務鏈接：
vole-portal
vole-portals 是分佈式統一管理後臺門戶，實現對各系統後臺的權限統一管理，包括 - 用戶管理、角色管理、菜單和權限管理以及系統管理，是相關係統後臺管理的基本功能集合體。
如下圖：
統一門戶管理分三個組件：門戶服務端 vole-portal、門戶數據端 vole-portal-data、和門戶基本組件 vole-portal-common，用微服務方式實現服務和數據分離。
- vole-portal: 主要負責門戶的基本配置功能 如菜單，權限，系統，用戶配置等；
- vole-portal-data: 負責對用戶，權限，菜單的基本數據讀取的管理。
服務和數據分離的好處是 - 對於任何前端程序都能接入相關 portal 服務，便於定製化管理界面。
如下圖：
前端業務系統可以使用任何服務進行集成，便於前後端分離。
vole-gateway
微服務邊緣網關 vole-gateway 是基於 zuul 改造的邊緣網關服務，在 zuul 基礎上添加了動態路由配置，服務鑑權，異常，安全等相關功能。
zuul 的服務方式如下圖：
微服務網關 zuul 架構
爲什麼要使用邊緣服務網關？
- 客戶端直接和微服務交互，增加了複雜度；
- 某些場景下可能存在跨域；
- 如果一個功能點需要調用多個微服務，每個服務都需要身份認證，使得身份驗證複雜冗餘；
- 客戶端直接和微服務交互，後期代碼重構難度大。
基於以上問題，使用邊緣網關使得整個微服務系統對外部服務的管理，尤其是移動端服務更加規範，簡單，清晰。
vole-modules
vole-modules 包括了微服務的其他功能，比如任務、消息、監控等相關組件，可以幫助快速搭建微服務相關基礎功能，提供基本骨架工程結合包。
如下圖所示：
vole-job 使用的是 Elastic-Job-Lite；定時任務一般都是使用 quartz 或者 spring-task（ScheduledExecutorService），無論是使用 quartz 還是 spring-task，我們都會至少遇到兩個痛點：
- 不敢輕易跟着應用服務多節點部署，可能會重複多次執行而引發系統邏輯錯誤；
- quartz 的集羣僅僅只是用來 HA，節點數量的增加並不能給我們的每次執行效率帶來提升，即不能實現水平擴展。
Elastic job 的主要功能有支持彈性擴容，通過 Zookepper 集中管理和監控 job，支持失效轉移等。
vole-message 對釘釘，阿里雲大魚短信平臺的基礎服務能夠快速的支持消息接入。
vole-mq 集成了對 kafka,rabbit,rocket 等主流 mq 客戶端的集合包。
vole-monitor 和 vole-turbine 分別是對容器基礎數據監控以及服務聚合熔斷監控的組合。
結束語
通過精簡或者重組 vole 微服務腳手架可以快速提煉出適應相關項目組的微服務腳手架工具，解決項目組大量的前期框架整合時間，提升開發效率和項目進度。
作者介紹
王一硼，蘇寧科技集團消費者平臺架構部技術專家，全面負責蘇寧易購相關核心系統的優化及大促保障工作。 曾經在阿里，惠普等大型互聯網和 IT 公司任職，有 10 多年的互聯網一線研發經驗，對高可用高併發及大規模分佈式系統有深刻的認識和實踐經驗。
黃小虎，蘇寧科技集團消費者平臺購物流程架構負責人，全面負責蘇寧易購商品詳情頁、購物車、大聚會等核心系統的優化及大促保障工作。對電商交易流程和業務有較深入的思考和研究，專注於高併發大型電商網站的架構設計、高可用的系統設計。曾主導和參與了 Commerce 系統拆分、商品詳情頁接入層優化、雲信客服系統重構等重大技術攻關項目。現致力於打造蘇寧易購新一代核心購物流程系統，希望將購物體驗做到極致。