zuihou-admin-cloud 1.1 發布 , 獨立Schema的多租戶微服務腳手架

2020-12-17 開源中國

# 更新日誌:

1， 刪除 原服務表以及相關代碼，重新思考系統中 API 接口的實現方案。
2，新增 系統api接口表、應用-系統api 關聯表 以及相關接口， 用於外部應用的api授權
3，修改 應用表相關欄位，並重新生成代碼
4，新增 zuihou-scan-starter 起步依賴模塊，實現自動掃描服務的所有api接口， 並提供2種遠程調用權限服務持久化的方式（feign or rabbitmq）
5，升級 swagger-bootstrap-ui 1.9.6 為 knife4j 2.0.0  
6，兄弟項目：zuihou-admin-boot 完成權限、消息、文件服務的代碼合併，並改在原來的攔截器，實現網關過濾器的解析token功能，並成功對接現有的前端項目。

# 功能點介紹:

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

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

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

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

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

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

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

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

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

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

  • 防跨站腳本攻擊（XSS）：
  • 當前用戶信息注入器：
  • 在線API：

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

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

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

請切換分支進行查看

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

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

 

# 項目代碼地址

微服務後端 代碼：

[gitee] https://gitee.com/zuihou111/zuihou-admin-cloud /[github] https://github.com/zuihou/zuihou-admin-cloud

租戶系統 代碼：

[gitee] https://gitee.com/zuihou111/zuihou-ui / [github] https://github.com/zuihou/zuihou-ui

開發&運營管理系統 代碼：

[gitee] https://gitee.com/zuihou111/zuihou-admin-ui / [github] https://github.com/zuihou/zuihou-admin-ui

[代碼生成器] https://github.com/zuihou/zuihou-generator

 

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

[租戶系統演示環境] http://tangyh.top:10000/zuihou-ui/

平臺管理員帳號/密碼： zuihou/zuihou

普通用戶帳號/密碼: test/zuiou

[開發&運營平臺演示環境] http://tangyh.top:180/zuihou-admin-ui/

帳號/密碼： demoAdmin/zuihou

相關焦點

  • zuihou-admin-cloud 1.8 發布,支持 Cloud Alibaba 2.2.0
    Order和Demo 服務中 seata 相關配置移動到 zuihou-order/demo-server.yml 配置文件中， 並通過參數控制是否啟用  簡介：基於`SpringCloud(Hoxton.SR1)`  + `SpringBoot(2.2.2.RELEASE)` 的 SaaS型微服務腳手架，具備用戶管理、資源權限管理、網關統一鑑權
  • zuihou-admin-cloud 1.9.1 發布,代碼生成器支持前後端和建項目
    修復定時任務重置租戶數據時，會誤刪除內置租戶數據的bug 簡介：基於`SpringCloud(Hoxton.SR1)`  + `SpringBoot(2.2.2.RELEASE)` 的 SaaS型微服務腳手架，具備用戶管理、資源權限管理、網關統一鑑權、Xss防跨站攻擊、自動代碼生成、多存儲系統、分布式事務、分布式定時任務等多個模塊
  • zuihou-admin-cloud 1.6 發布,支持自動生成前端頁面
    + `SpringBoot(2.2.2.RELEASE)` 的 SaaS型微服務腳手架，具備用戶管理、資源權限管理、網關統一鑑權、Xss防跨站攻擊、自動代碼生成、多存儲系統、分布式事務、分布式定時任務等多個模塊，支持多業務系統並行開發，支持多服務並行開發，可以作為後端服務的開發腳手架。
  • zuihou-admin-cloud 1.5 發布,跨庫跨服務數據聚合組件
    增加自定義表單校驗規則，使得能正常檢驗 RemoteData 類型的欄位的 @NotEmpty @NotNull @Length 等檢驗註解簡介：基於`SpringCloud(Hoxton.SR1)`  + `SpringBoot(2.2.2.RELEASE)` 的 SaaS型微服務腳手架，具備用戶管理、資源權限管理、網關統一鑑權
  • ...admin-cloud 2.3 發布,完美支持分布式事務 - OSCHINA - 中文...
    優化項目配置，使得任意租戶模式完美支持 seata 優化若干代碼 調整開發文檔兼容當前最新版本代碼   https://www.kancloud.cn/zuihou/zuihou-admin-cloud修復： 復刪除資源時執行刪除SQL的bug
  • ...2.1 發布,租戶模式支持動態新增數據源 - OSCHINA - 中文開源...
    將租戶模塊相關代碼獨立到權限服務的 zuihou-tenant-** 模塊中，降低代碼耦合度，增強系統的獨立性。（有條件的朋友，完全可以將租戶模塊獨立成一個服務）11. 將非租戶模式、欄位租戶模式、SCHEMA/數據源租戶模式的資料庫腳本區分開。12. 簡化租戶後臺系統相關接口邏輯 (zuihou-admin-ui)13.
  • zuihou-admin-cloud 升級 | 實現數據權限
    # 2019年11月26日00:11:56 升級日誌1，同步最新的sql腳本、nacos腳本到源碼相應文件中2，租戶運營後臺升級
  • kunlun-admin v1.0.5 發布,基於 SpringCloud 的後臺管理系統
    崑崙管理系統 v1.0.5 發布，更新日誌：1、調整首頁快捷導航布局，使其更加緊湊；2、修改用戶管理、角色管理、在線用戶等的查詢功能；3、調整首頁資源模塊顯示名
  • knife4j-admin v1.0發布,任意聚合 Swagger 文檔
    knife4j對Swagger的文檔進行動態聚合的管理平臺平臺特點：目前V1.0版本提供的功能：項目新增1、添加項目必須按照如下格式進行{    "name": "大數據測試平臺",    "code":"test1
  • Apache APISIX 發布 1.0 版本
    Apache APISIX 是微服務 API 網關，不僅可以幫你處理傳統的南北向流量，也可以處理服務間的東西向流量。
  • 厲害了,教你用 Spring Cloud 實現微服務
    Spring cloud子項目目前來說spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，我們從幾張圖著手理解，然後再具體介紹：1. 一些列的獨立的服務共同組成系統2. 單獨部署，跑在自己的進程裡3. 每個服務為獨立的業務開發4. 分布式的管理Martin自己也說了，每個人對微服務都可以有自己的理解，不過大概的標準還是有一些的。
  • 基於Spring Boot和Spring Cloud實現微服務架構
    Spring cloud子項目目前來說spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，我們從幾張圖著手理解，然後再具體介紹：1. 一些列的獨立的服務共同組成系統2. 單獨部署，跑在自己的進程裡3. 每個服務為獨立的業務開發4. 分布式的管理Martin自己也說了，每個人對微服務都可以有自己的理解，不過大概的標準還是有一些的。
  • pacebox-springboot 1.1.4 發布,Java 生態框架
    pacebox-springboot 融合封裝已發布，旨在提供快速開發腳手架、打造更好的開源生態環境。
  • 基於 Spring Boot 和 Spring Cloud 實現微服務架構
    Spring Scala：為Scala語言編程提供的spring框架的封裝（新的程式語言，Java平臺的Scala於2003年底/2004年初發布）。Spring cloud子項目目前來說spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，我們從幾張圖著手理解，然後再具體介紹：
  • Apache Pulsar 引入 Cloud Storage Sink 連接器:實現數據上雲
    步驟 1：安裝 Cloud Storage 連接器並運行 Pulsar Broker [下載](https://github.com/streamnative/pulsar-io-cloud-storage/releases) Cloud Storage 連接器的安裝包。
  • F版本SpringCloud1—大白話為啥要有微服務?啥是微服務?
    本文分為三個部分：架構的演變，即為什麼會出現微服務技術什麼是微服務，即微服務的標準概念微服務要解決什麼問題，即微服務中那麼多的組件都是幹嘛的從單體到微服務「小故事講解架構演變」可以根據需要獨立的部署在伺服器上，首頁模塊被訪問的比較多，就可以多部署幾個可以獨立的訪問資料庫，每個服務都可以有自己的資料庫 ......等等等，好處不要太多。這樣情況我們實際上也稱之為微服務。服務化要解決的問題？
  • 初識Spring Cloud Stream,什麼是消息驅動微服務框架
    Spring Cloud Stream 簡介官方定義Spring Cloud Stream 是一個用來為微服務應用構建消息驅動能力的框架。它為一些供應商的消息中間件產品提供了個性化的自動化配置實現，並且引入了發布-訂閱、消費組以及分區這三個核心概念。
  • 美團T9都說太「強」了,以微服務分布式的實戰詳解SpringCloud
    隨著微服務架構的興起，國內的IT企業特別是網際網路公司近年來都逐步引入了微服務技術並使其在實踐中落地，實施微服務架構最流行的方案非SpringCloud莫屬。從企業的真實需求出發，理論結合實際，深入講解SpringCloud微服務和分布式系統的知識。
  • 實現微服務架構最流行Style,Spring Boot+Spring Cloud
    Spring cloud子項目目前來說spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，我們從幾張圖著手理解，然後再具體介紹：1. 一些列的獨立的服務共同組成系統2. 單獨部署，跑在自己的進程裡3. 每個服務為獨立的業務開發4. 分布式的管理Martin自己也說了，每個人對微服務都可以有自己的理解，不過大概的標準還是有一些的。
  • 基於Spring Boot和Spring Cloud實現微服務架構學習
    Spring cloud子項目目前來說spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，我們從幾張圖著手理解，然後再具體介紹：1. 一些列的獨立的服務共同組成系統2. 單獨部署，跑在自己的進程裡3. 每個服務為獨立的業務開發4. 分布式的管理Martin自己也說了，每個人對微服務都可以有自己的理解，不過大概的標準還是有一些的。SOA vs Microservice除了Smart endpoints and dumb pipes都很容易理解對嗎？