zuihou-admin-cloud 2.1 發布,租戶模式支持動態新增數據源 - OS...

今日更新日誌:

新增：

1. 新增認證服務（zuihou-oauth-server：負責登錄、獲取用戶所有權限、資源、菜單等功能）
2. 參照SpringSecurity原理，調整 認證服務登錄、刷新token等 接口相關邏輯
3. 參照SpringSecurity原理，新增 zuihou-security-starter 模塊，實現 URI權限配置 和 鑑權
4. 新增 租戶模式 支持多數據源模式：動態增減數據源，一個租戶一個庫一個數據源
5. 多數據源模式相關代碼和配置，調整成一鍵切換模式
6. 新增多數據源模式完美支持分布式事務（seata 1.0.0） 
7. 新增刪除租戶時，刪除租戶數據和資料庫的接口,並刪除該租戶的數據源
8. 新增記錄在線用戶功能 & 主動T人下線功能

優化：

1. 重寫token生成規則和方法
2. 優化用戶登錄邏輯，根據配置決定是否限制用戶重複登錄、多端登錄。
3. 登錄日誌改成發布事件的方式。
4. 移除 zuihou-shiro-starter 和 zuihou-user-starter 模塊
5. 移除 zuihou-zuul-* 模塊中沒用的幾個模塊
6. 優化swagger配置，支持接口認證等參數
7. 配置文件調整：zuihou.database.bizDatabase -> zuihou.database.tenantDatabasePrefix
8. 將分散在各個服務的枚舉接口(/enums)合併到 Oauth 服務，前端在登錄之後，一次性拉取存放在前端緩存中。
9. 日誌統一存儲路徑： logging.file.path 移動到 src/main/filters/config-dev.properties 統一配置
10. 將租戶模塊相關代碼獨立到權限服務的 zuihou-tenant-** 模塊中，降低代碼耦合度，增強系統的獨立性。（有條件的朋友，完全可以將租戶模塊獨立成一個服務）
11. 將非租戶模式、欄位租戶模式、SCHEMA/數據源租戶模式的資料庫腳本區分開。
12. 簡化租戶後臺系統相關接口邏輯 (zuihou-admin-ui)
13. 廢除之前的配置在Controller層的聲明式事務配置，採用註解配置事務，調整事務控制到service層，通過註解來控制事務，原因是兼容多數據源模式。
14. SuperCacheServiceImpl 相關方法加上事務註解。
15. SuperCacheServiceImpl 相關操作緩存的方法去除@Cache註解，採用cacheChanel方式，防止子類this調用時，無法使用緩存的bug
16. 拆分上下文攔截器，將租戶信息、MDC分離到 攔截器TenantContextHandlerInterceptor(封裝租戶相關請求頭)、MdcHandlerInterceptor(封裝日誌相關線程變量)
17. 優化操作日誌相關配置，實現根據條件實例不同的bean
18. 簡化order和demo服務的分布式事務配置 
19. SpringUtils類增加發布事件的靜態方法
20. 廢棄IgnoreTokenConfig,調整為配置文件方式： IgnoreTokenProperties

修復:

1. 修復UserQuery構造方法報NPE的bug  # fix I1BXPW
2.修復個人中心修改資料的bug   # fix I1CIEN
3. 完善租戶模塊相關功能，並修復一個弱智bug

 

升級指南：

1. 更新 zuihou-admin-cloud， 待依賴更新完畢後，根據IDEA提示，刪除zuihou-zuul-base、zuihou-zuul-authentication、zuihou-zuul-ratelimit 等模塊
2. 若要更新zuihou-commons（該項目已經發布中央倉庫，若不想看源碼，可以不用管），待依賴更新完畢後，根據IDEA提示，刪除zuihou-user-starter、zuihou-shiro-starter等模塊
3. 編譯項目
4. 重新導入 資料庫腳本      (資料庫改動較大，請務必重新執行，執行時，看著： docs/sql/腳本說明.md 根據自身情況導入腳本)
5. 重新導入 nacos 配置文件  (配置文件改動很大，刪除合併了很多配置)
6. 啟動項目

租戶模式：

租戶模式	描述	優點	缺點	分布式事務
NONE（非租戶模式)	沒有租戶	簡單、適合獨立系統	缺少租戶系統的便利性	支持
COLUMN（欄位模式)	租戶共用一個資料庫，在業務表中增加欄位來區分	簡單、不複雜、開發無感知	數據隔離性差、安全性差、數據備份和恢復困難	支持
SCHEMA（獨立schema)	每個租戶獨立一個 資料庫(schema)，執行sql時，動態在表名前增加schema	簡單、開發無感知、數據隔離性好	配置文件中必須配置資料庫的root帳號、不支持複雜sql和 sql嵌套自定義函數	存在bug
DATASOURCE(獨立數據源)	每個租戶獨立一個 資料庫(數據源)，執行代碼時，動態切換數據源	可獨立部署資料庫，數據隔離性好、擴展性高、故障影響小	相對複雜、開發需要注意切換數據源時的事務問題、需要較多的資料庫	支持

簡介：

基於`SpringCloud(Hoxton.SR1)`  + `SpringBoot(2.2.5.RELEASE)` 的 SaaS型微服務腳手架，具備用戶管理、資源權限管理、網關統一鑑權、Xss防跨站攻擊、自動代碼生成、多存儲系統、分布式事務、分布式定時任務等多個模塊，支持多業務系統並行開發，支持多服務並行開發，可以作為後端服務的開發腳手架。代碼簡潔，架構清晰，非常適合學習使用。核心技術採用Nacos、Fegin、Ribbon、Zuul、Hystrix、JWT Token、Mybatis、SpringBoot、Seata、Nacos、Sentinel、RabbitMQ、FastDFS等主要框架和中間件。

希望能努力打造一套從 SaaS基礎框架 - 分布式微服務架構 - 自動化部署 - 系統監測 的解決方案。本項目旨在實現基礎能力，不涉及具體業務。
 

功能點介紹:

服務註冊與調用：

基於Eureka來實現的服務註冊與調用，在Spring Cloud中使用Feign, 我們可以做到使用HTTP請求遠程服務時能與調用本地方法一樣的編碼體驗，開發者完全感知不到這是遠程方法，更感知不到這是個HTTP請求。

 服務鑑權:

通過JWT的方式來加強服務之間調度的權限驗證，保證內部服務的安全性。

負載均衡：

將服務保留的rest進行代理和網關控制，除了平常經常使用的node.js、nginx外，Spring Cloud系列的zuul和ribbon，可以幫我們進行正常的網關管控和負載均衡。其中擴展和借鑑國外項目的擴展基於JWT的Zuul限流插件，方面進行限流。

 熔斷機制：

因為採取了服務的分布，為了避免服務之間的調用「雪崩」，採用了Hystrix的作為熔斷器，避免了服務之間的「雪崩」。

監控：

利用Spring Boot Admin 來監控各個獨立Service的運行狀態；利用turbine來實時查看接口的運行狀態和調用頻率；通過Zipkin來查看各個服務之間的調用鏈等。

數據權限：

利用基於Mybatis的DataScopeInterceptor攔截器實現了簡單的數據權限

SaaS的無感解決方案：

使用Mybatis攔截器實現對所有SQL的攔截，修改默認的Schema，從而實現多租戶數據隔離的目的。

二級緩存：

採用J2Cache操作緩存，第一級緩存使用內存(Caffeine)，第二級緩存使用 Redis。 由於大量的緩存讀取會導致 L2 的網絡成為整個系統的瓶頸，因此 L1 的目標是降低對 L2 的讀取次數。 該緩存框架主要用於集群環境中。單機也可使用，用於避免應用重啟導致的緩存冷啟動後對後端業務的衝擊。

優雅的Bean轉換：

採用Dozer組件來對 DTO、DO、PO等對象的優化轉換

前後端統一表單驗證：

嚴謹的表單驗證通常需要 前端+後端同時驗證， 但傳統的項目，均只能前後端各做一次檢驗， 後期規則變更，又得前後端同時修改。 故在hibernate-validator的基礎上封裝了zuihou-validator-starter起步依賴，提供一個通用接口，可以獲取需要校驗表單的規則，然後前端使用後端返回的規則， 以後若規則改變，只需要後端修改即可。

防跨站腳本攻擊（XSS）：

•      通過過濾器對所有請求中的 表單參數 進行過濾
•      通過Json反序列化器實現對所有 application/json 類型的參數 進行過濾

當前用戶信息注入器：

 通過註解實現用戶身份注入

在線API：

由於原生swagger-ui某些功能支持不夠友好，故採用了國內開源的 knife4j ，並製作了stater，方便springboot用戶使用。

代碼生成器：

基於Mybatis-plus-generator自定義了一套代碼生成器， 通過配置資料庫欄位的注釋，自動生成枚舉類、數據字典註解、SaveDTO、UpdateDTO、表單驗證規則註解、Swagger註解等。

定時任務調度器：

基於xxl-jobs進行了功能增強。（如：指定時間發送任務、執行器和調度器合併項目、多數據源）

漢化 Eureka 註冊中心頁面：

請切換分支進行查看

大文件/斷點/分片續傳：

前端採用webupload.js、後端採用NIO實現了大文件斷點分片續傳，啟動Eureka、Zuul、File服務後，直接打開docs/chunkUploadDemo/demo.html即可進行測試。 經測試，本地限制堆棧最大內存128M啟動File服務,5分鐘內能成功上傳4.6G+的大文件，正式服耗時則會受到用戶帶寬和伺服器帶寬的影響，時間比較長。

分布式事務：

集成了阿里的分布式事務中間件：seata，以 高效 並且對業務 0侵入 的方式，解決 微服務 場景下面臨的分布式事務問題。

灰度發布:
    
為了解決頻繁的服務更新上線，版本回退，快速迭代，公司內部協同開發，本項目採用修改ribbon的負載均衡策略來實現來灰度發布。     

關聯數據自動注入：

用於解決跨表、跨庫、跨服務分頁數據的屬性或單個對象的屬性 回顯關聯數據之痛, 支持對靜態數據屬性(數據字典)、動態主鍵數據進行自動注入。

項目代碼地址

演示地址 （演示帳號沒有寫權限，只能查詢）

項目	演示地址	管理員帳號	普通帳號
租戶後臺	http://tangyh.top:10000/zuihou-ui	zuihou/zuihou	test/zuiou
開發&運營後臺	http://tangyh.top:180/zuihou-admin-ui	demoAdmin/zuihou	無