平臺簡介
若依是一套全部開源的快速開發平臺,毫無保留給個人及企業免費使用。
採用前後端分離的模式,微服務版本前端(基於 RuoYi-Vue)。
後端採用Spring Boot、Spring Cloud & Alibaba。
註冊中心、配置中心選型Nacos,許可權認證使用Redis。
流量控制框架選型Sentinel,分散式事務選型Seata。
如需不分離應用,請移步 RuoYi,如需分離應用,請移步 RuoYi-Vue
系統模組
com。ruoyi ├── ruoyi-ui // 前端框架 [80]├── ruoyi-gateway // 閘道器模組 [8080]├── ruoyi-auth // 認證中心 [9200]├── ruoyi-api // 介面模組│ └── ruoyi-api-system // 系統介面├── ruoyi-common // 通用模組│ └── ruoyi-common-core // 核心模組│ └── ruoyi-common-datascope // 許可權範圍│ └── ruoyi-common-datasource // 多資料來源│ └── ruoyi-common-log // 日誌記錄│ └── ruoyi-common-redis // 快取服務│ └── ruoyi-common-security // 安全模組│ └── ruoyi-common-swagger // 系統介面├── ruoyi-modules // 業務模組│ └── ruoyi-system // 系統模組 [9201]│ └── ruoyi-gen // 程式碼生成 [9202]│ └── ruoyi-job // 定時任務 [9203]│ └── ruoyi-file // 檔案服務 [9300]├── ruoyi-visual // 圖形化管理模組│ └── ruoyi-visual-monitor // 監控中心 [9100]├──pom。xml // 公共依賴
架構圖
內建功能
使用者管理:使用者是系統操作者,該功能主要完成系統使用者配置。
部門管理:配置系統組織機構(公司、部門、小組),樹結構展現支援資料許可權。
崗位管理:配置系統使用者所屬擔任職務。
選單管理:配置系統選單,操作許可權,按鈕許可權標識等。
角色管理:角色選單許可權分配、設定角色按機構進行資料範圍許可權劃分。
字典管理:對系統中經常使用的一些較為固定的資料進行維護。
引數管理:對系統動態配置常用引數。
通知公告:系統通知公告資訊釋出維護。
操作日誌:系統正常操作日誌記錄和查詢;系統異常資訊日誌記錄和查詢。
登入日誌:系統登入日誌記錄查詢包含登入異常。
線上使用者:當前系統中活躍使用者狀態監控。
定時任務:線上(新增、修改、刪除)任務排程包含執行結果日誌。
程式碼生成:前後端程式碼的生成(java、html、xml、sql)支援CRUD下載 。
系統介面:根據業務程式碼自動生成相關的api介面文件。
服務監控:監視當前系統CPU、記憶體、磁碟、堆疊等相關資訊。
線上構建器:拖動表單元素生成相應的HTML程式碼。
連線池監視:監視當前系統資料庫連線池狀態,可進行分析SQL找出系統性能瓶頸。
線上體驗
admin/admin123
陸陸續續收到一些打賞,為了更好的體驗已用於演示伺服器升級。謝謝各位小夥伴。
演示圖
原始碼獲取方式:關注小編+轉發文章+私信【
666
】免費獲取
重要的事情說三遍,轉發+轉發+轉發,一定要記得點贊轉發哦!!!
談談幾個SpringCloud常見面試題及答案
全文目錄
什麼是微服務?
微服務之間如何獨立通訊的?
SpringCloud 和 Dubbo 有哪些區別?
SpringBoot 和 SpringCloud 之間關係?
什麼是熔斷?什麼是服務降級?
微服務的優缺點是什麼?說下你在專案中碰到的坑。
eureka和zookeeper都可以提供服務註冊與發現的功能,請說說兩個的區別?
你所知道微服務的技術棧有哪些?列舉一二。
什麼是微服務架構?
1。什麼是微服務?
單個輕量級服務一般為一個單獨微服務,微服務講究的是 專注某個功能的實現,比如登入系統只專注於使用者登入方面功能的實現,講究的是職責單一,開箱即用,可以獨立執行。微服務架構系統是一個分散式的系統,按照業務進行劃分服務單元模組,解決單個系統的不足,滿足越來越複雜的業務需求。
馬丁福勒(Martin Fowler):就目前而言,對於微服務業界並沒有一個統一的、標準的定義。但通常而言,微服務架構是一種架構模式或者說是架構風格,它提倡將單一應用程式劃分成一組小的服務。每個服務執行在其獨立的自己的程序中服務之間相互配合、相互協調,為使用者提供最終價值。服務之間採用輕量級通訊。每個服務都圍繞具體業務進行構建,並能夠獨立部署到生產環境等。另外應儘量避免統一的、集中的服務管理機制。
通俗的來講:
微服務就是一個獨立的職責單一的服務應用程式。在 intellij idea 工具裡面就是用maven開發的一個個獨立的module,具體就是使用springboot 開發的一個小的模組,處理單一專業的業務邏輯,一個模組只做一個事情。
微服務強調的是服務大小,關注的是某一個點,具體解決某一個問題/落地對應的一個服務應用,可以看做是idea 裡面一個 module。
比如你去醫院:你的牙齒不舒服,那麼你就去牙科。你的頭疼,那麼你就去腦科。一個個的科室,就是一個微服務,一個功能就是一個服務。
業界大牛 馬丁福勒(Martin Fowler)講解 :
https://martinfowler。com/bliki/
看不懂英文,這裡有中文部落格翻譯的:
https://blog。csdn。net/u013970991/article/details/53333921
2。微服務之間如何獨立通訊的?
同步通訊:dobbo透過 RPC 遠端過程呼叫、springcloud透過 REST 介面json呼叫 等。
非同步:訊息佇列,如:RabbitMq、ActiveM、Kafka 等。
3。SpringCloud 和 Dubbo 有哪些區別?
首先,他們都是分散式管理框架。
dubbo 是二進位制傳輸,佔用頻寬會少一點。SpringCloud是http 傳輸,頻寬會多一點,同時使用http協議一般會使用JSON報文,消耗會更大。
dubbo 開發難度較大,所依賴的 jar 包有很多問題大型工程無法解決。SpringCloud 對第三方的繼承可以一鍵式生成,天然整合。
SpringCloud 介面協議約定比較鬆散,需要強有力的行政措施來限制介面無序升級。
最大的區別:
Spring Cloud拋棄了Dubbo 的RPC通訊,採用的是基於HTTP的REST方式。
嚴格來說,這兩種方式各有優劣。雖然在一定程度上來說,後者犧牲了服務呼叫的效能,但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活,服務提供方和呼叫方的依賴只依靠一紙契約,不存在程式碼級別的強依賴,這在強調快速演化的微服務環境下,顯得更為合適。
4。SpringBoot 和 SpringCloud 之間關係?
SpringBoot:專注於快速方便的開發單個個體微服務(關注微觀);SpringCloud:關注全域性的微服務協調治理框架,將SpringBoot開發的一個個單體微服務組合並管理起來(關注宏觀);
SpringBoot可以離開SpringCloud獨立使用,但是SpringCloud不可以離開SpringBoot,屬於依賴關係。
參考:
https://blog。csdn。net/qq_41497111/article/details/91042405
5。什麼是熔斷?什麼是服務降級?
服務熔斷的作用類似於我們家用的保險絲,當某服務出現不可用或響應超時的情況時,為了防止整個系統出現雪崩,暫時停止對該服務的呼叫。
服務降級是從整個系統的負荷情況出發和考慮的,對某些負荷會比較高的情況,為了預防某些功能(業務場景)出現負荷過載或者響應慢的情況,在其內部暫時捨棄對一些非核心的介面和資料的請求,而直接返回一個提前準備好的fallback(退路)錯誤處理資訊。這樣,雖然提供的是一個有損的服務,但卻保證了整個系統的穩定性和可用性。
6。微服務的優缺點是什麼?說下你在專案中碰到的坑。
優點:松耦合,聚焦單一業務功能,無關開發語言,團隊規模降低。在開發中,不需要了解多有業務,只專注於當前功能,便利集中,功能小而精。微服務一個功能受損,對其他功能影響並不是太大,可以快速定位問題。微服務只專注於當前業務邏輯程式碼,不會和 html、css 或其他介面進行混合。可以靈活搭配技術,獨立性比較舒服。
缺點:隨著服務數量增加,管理複雜,部署複雜,伺服器需要增多,服務通訊和呼叫壓力增大,運維工程師壓力增大,人力資源增多,系統依賴增強,資料一致性,效能監控。
7。eureka和zookeeper都可以提供服務註冊與發現的功能,請說說兩個的區別?
zookeeper 是CP原則,強一致性和分割槽容錯性。
eureka 是AP 原則 可用性和分割槽容錯性。
zookeeper當主節點故障時,zk會在剩餘節點重新選擇主節點,耗時過長,雖然最終能夠恢復,但是選取主節點期間會導致服務不可用,這是不能容忍的。
eureka各個節點是平等的,一個節點掛掉,其他節點仍會正常保證服務。
8。你所知道微服務的技術棧有哪些?列舉一二。
9。什麼是微服務架構?
在前面你理解什麼是微服務,那麼對於微服務架構基本上就已經理解了。
微服務架構 就是 對微服務進行管理整合應用的。微服務架構 依賴於 微服務,是在微服務基礎之上的。
例如:上面已經列舉了什麼是微服務。在醫院裡,每一個科室都是一個獨立的微服務,那麼 這個醫院 就是 一個大型的微服務架構,就類似 院長 可以 對下面的 科室進行管理。微服務架構主要就是這種功能。