CAS服務管理實現原理

一般狀況下，咱們的單點登陸認證中心要支持多個服務的統一認證。咱們的實現步驟通常是先配置服務註冊中心方案、而後配置受權服務、最後重啓服務。

按以上步驟執行完，大部分均可以獲得預期的服務管理目的。而有時候在登陸的時候會遇到這種提示：未認證受權的服務。對於剛接觸CAS的人來講，看到這個提示每每不知道該如何處理。出現這個錯誤的緣由有不少，好比服務加載失敗、服務更新失敗、serviceID正則表達式寫錯等等，其實歸根結底是一個緣由：在登陸過程當中校驗受權服務時，沒有找到匹配的服務。

爲何沒有匹配到受權服務？

內部的服務管理機制是什麼樣的？

應該怎麼解決？

本文將深刻剖析CAS服務管理原理，包括服務管理總體架構、服務初始化過程、服務更新機制、服務校驗過程、以及服務管理工具等。經過本文至少能夠有如下收穫：

1. 全面深刻的理解CAS中的服務管理原理；
2. 能夠快速處理實操過程當中CAS服務管理相關問題；

CAS服務管理總體架構

如上圖所示，CAS服務管理的總體架構能夠分爲三層：

• 服務註冊中心
• 服務管理器
• 服務管理組件

服務註冊中心

服務註冊中心負責存儲受權服務，它支持多種存儲方案，如內存、JSON文件、JPA、Redis、MongoDb等等。

CAS中的服務註冊中心實現方案經過實現ServiceRegistry接口來實現：

服務管理器

服務管理器負責管理服務註冊中心。正是由於有了服務管理器，才實現了服務存儲的透明化，使調用方對服務存儲方式無感知。也使服務存儲更容易擴展，開發者能夠根據本身的需求來實現個性化存儲。

CAS中的服務管理器實現方案經過實現ServicesManager接口來實現：

服務管理組件

咱們在這裏將服務管理的調用方的統稱爲服務管理組件。如登陸組件在登陸過程當中須要經過服務管理器獲取受權來校驗服務、服務定時器定時更新受權服務、服務初始化組件須要在服務啓動時初始化受權服務等等。

服務初始化

啓用服務初始化功能後（cas.serviceRegistry.initFromJson=true），服務啓動的第一步就是進行服務初始化，其目的是將註冊中心中的受權服務加載到服務管理器中。

服務管理器充當訪問服務的緩存層，後續的服務訪問都要經過服務管理器。

服務的初始化過程包含如下幾步：

1. 服務啓動時，Spring會初始化服務初始化組件，並啓動初始化流程；
2. 服務初始化組件從配置的目錄中加載收取服務，並保存到loadedList中；
3. 再將loadedList中的受權服務逐個保存到服務註冊中心（已存在的不更新）；（這裏是開發人員配置的服務註冊中心方案，如redis、jpa等）
4. 將服務註冊中心中的服務加載到服務管理器中；完成服務初始化。

不一樣的服務管理器還會基於servicesMap將服務保存到本身的服務集合中，以實現個性化管理策略。

服務更新機制

CAS中的服務更新是經過定時調度來實現的，啓用或關閉此功能經過cas.serviceRegistry.schedule.enabled=true/false來控制。

服務的更新過程包含如下幾步：

1. 服務啓動時，Spring容器初始化服務更新定時調度器；
2. 服務更新定時調度器根據配置的策略，定時調用；
3. 從服務註冊中心加載受權服務集合，並將受權服務集合加載到服務管理器中；更新完成。

服務校驗過程

安全起見，CAS單點登陸的過程當中都要進行受權服務的校驗。

服務的校驗過程包含如下幾步:

1. 服務啓動時，Spring容器初始化服務校驗組件InitialFlowSetupAction，並將其添加到登陸流程裏；
2. 每次執行登陸流程時，都要先執行InitialFlowSetupAction，來校驗服務；
3. 首先從請求中解析出service；
4. 而後逐個匹配服務管理器中的受權服務；
5. 若是匹配到，當即返回受權服務，並將該受權服務帶入到上下文中，繼續執行登陸流程中的其餘動做；
6. 若是沒有匹配到服務，拋出異常，在頁面中出現未認證受權的服務提示。

經過以上的服務校驗過程，能夠獲得如下結論：

1. 服務正則表達式必定要拼寫正確，不然可能會匹配不到，或者匹配錯誤。建議配置前如今本地用Java正則表達式測試如下。
2. 若是頁面出現未認證受權的服務提示，必定是服務匹配問題，要從這方面找緣由和解決方案。

服務管理工具

CAS官方推出的服務管理工具是：CAS Management。咱們這裏主要介紹CAS Management的功能和實現原理。

瞭解完服務的加載、更新機制後，若是有個性化需求，咱們也能夠實現本身的服務管理工具。

CAS Management在實現了服務管理功能基礎上，還有兩個核心亮點：服務版本控制和委託用戶管理。

服務管理基礎功能就不介紹了，已經包含在了服務版本控制流程內。

服務版本控制

服務的版本控制是經過在本地創建一個git倉庫，而後經過操做這個git倉庫，發佈後同步到CAS Server服務註冊中心中，最後經過服務管理的更新機制，同步到CAS Server中。

服務的版本控制的好處顯而易見：

1. 保留了服務的歷史狀態，並能夠隨時回退到任意歷史版本；
2. 服務有了中間態，可有效控制服務的發佈狀態。

服務版本控制流程：

1. CAS Management啓動後會作兩件事情：
   • 在本地建立一個git倉庫，並以此做爲JSON註冊中心，建立VersionControlServicesManager；
   • 建立CAS Server服務管理器：DefaultServicesManager或DomainServicesManager;
2. 管理員增長或編輯服務後，經過操做界面中的提交按鈕提交本次變動；
3. 提交後就會點亮發佈按鈕，發佈後會將倉庫中的服務經過CAS Server服務管理器同步到CAS Server服務註冊中心；
4. 最後CAS Server經過更新機制，同步到CAS Server服務管理器中。

委託用戶管理

CAS Management的委託用戶管理功能相似github上的PR，在以上服務版本控制的前面多出了PR的步驟，即：

1. 委託用戶編輯服務並提交PR；
2. 管理員接受或拒絕委託用戶的PR；
3. 若是管理員接受，就會走以上的服務管理版本控制流程；
4. 若是管理員拒絕，則會打回到委託用戶，從新編輯。

原文地址

關於做者

馬軍偉，草根碼農一枚，jbone項目做者。

關注領域：微服務、高併發編程、單點登陸等。

Github：github.com/417511458

Gitee: gitee.com/majunwei201…

主頁：jbone.cn

QQ: 417511458

公衆號：writebugs

原創文章，歡迎轉載！但請務必保留全文，並說明出處