安利一個基於Spring Cloud 的面試刷題系統。面試、畢設、項目經驗一網打盡
- 2020 年 12 月 28 日
- 筆記
推薦👍：
今天給小夥伴們推薦一個朋友開源的面試刷題系統。
這篇文章我會從系統架構設計層面詳解介紹這個開源項目，並且會把微服務常用的一些技術都介紹一下。即使你對這個項目不感興趣，也能了解到很多微服務相關的知識。美滋滋！
昨晚肝了很久~原創不易，若有幫助，求贊求轉發啊！
不得不說，這個刷題系統確實是有點東西，你真的值得擁有！首先，這是一個微服務的項目，其次這個系統涵蓋了市面上常用的主流技術比如 SpringBoot、Spring Cloud 等等（後面會詳細介紹）。
不論是你想要學習分散式的技術，還是想找一個實戰項目練手或者作為自己的項目經驗，這個項目都非常適合你。
另外，因為項目作者提供了詳細的技術文檔，所以你不用擔心上手太難！
效果圖
我們先來看看這個面試刷題系統的效果圖。這裡我們只展示的是這個系統的前端（微信小程式），後台管理系統這裡就不展示了。
可以看到，除了少部分地方的顏色搭配比較難看之外，頁面整體 UI 還是比較美觀的。
技術棧
再聊聊大家最關心的問題：「這套系統的技術棧是什麼樣的呢?」。
這套系統採用了目前企業都在用的主流技術：SpringBoot（基礎框架）、Spring Cloud（微服務）、MyBatis（ORM框架）、Redis（快取）、MySql（關係型資料庫）、MongoDB（NoSQL）、RabbitMQ（消息隊列）、Elasticsearch（搜索引擎）。並且，這個系統是以 Docker 容器化的方式進行部署的。非常實用！
系統架構設計
了解了技術棧之後，那必然需要簡單了解一下整個 系統的架構設計 ，這是系統的靈魂所在了（圖源：PassJava 官方文檔）。
網關
網關負責認證授權、限流、熔斷、降級、請求分發、負載均衡等等操作。一般情況下，網關一般都會提供這些功能。
這裡使用的是 Spring Cloud Gateway 作為網關。Spring Cloud Gateway 是 Spring Cloud 官方推出的第二代網關框架，目的是取代 netflix 的 Zuul 網關。
註冊中心和配置中心
註冊中心和配置中心這塊使用的是阿里巴巴開源的 Nacos 。Nacos 目前屬於 Spring Cloud Alibaba 中的一員。主要用於發現、配置和管理微服務，類似於 Consul、Eureka。並且，提供了分散式配置管理功能。
Nacos 的基本介紹如下（圖源：官網文檔-什麼是 Nacos）：
詳解介紹一下 Nacos 在這個項目中提供的兩個核心功能：
- 註冊中心 ：API 網關通過註冊中心實時獲取到服務的路由地址,準確地將請求路由到各個服務。
- 配置中心 ：傳統的配置方式需要重新啟動服務。如果服務很多，則需要重啟所有服務，非常不方便。通過 Nacos，我們可以動態配置服務。並且，Nacos 提供了一個簡潔易用的 UI 幫助我們管理所有的服務和應用的配置。
關於配置中心，我們這裡再拓展一下，除了 Nacos ，還有 Apollo、SpringCloud Config、K8s ConfigMap 可供選擇。
分散式鏈路追蹤
不同於單體架構，在分散式架構下，請求需要在多個服務之間調用，排查問題會非常麻煩。我們需要分散式鏈路追蹤系統來解決這個痛點。
分散式鏈路追蹤這塊使用的是 Twitter 的 Zipkin ，並且結合了 Spring Cloud Sleuth 。
Spring Cloud Sleuth 只是做一些鏈路追蹤相關的數據記錄，我們可以使用 Zipkin Server 來處理這些數據。
相關閱讀：《40 張圖看懂分散式追蹤系統原理及實踐》 。
監控系統
監控系統可以幫助我們監控應用程式的狀態，並且能夠在風險發生前告警。
監控系統這塊使用的是 Prometheus + Grafana。Prometheus 負責收集監控數據，Grafana 用於展示監控數據。我們直接將 Grafana 的數據源選擇為 Prometheus 即可。
關於監控系統更詳細的技術選型，可以看這篇文章：《監控系統選型看這一篇夠了！選擇 Prometheus 還是 Zabbix ？》 。
消息隊列
我們知道，消息隊列主要能為系統帶來三點好處：
- 通過非同步處理提高系統性能（減少響應所需時間）。
- 削峰/限流
- 降低系統耦合性。
常用的消息隊列有：RabbitMQ（本系統所採用的方案）、Kafka、RocketMQ。
快取
快取這裡使用的是 Redis ，老生常談了，這裡就不再多做介紹。
另外， 為了保證快取服務的高可用，我們使用 Redis 官方提供了一種 Redis 集群的解決方案 Redis Sentinel 來管理 Redis 集群。
資料庫
資料庫這裡使用的是 MySQL ，並使用主從模式實現讀寫分離，以提高讀性能。
對象存儲
由於是分散式系統，傳統的將文件上傳到本機已經沒辦法滿足我們的需求了。
由於自己搭建分散式文件系統也比較麻煩，所以對象存儲這裡我們使用的是阿里雲 OSS，它主要用於存儲一些文件比如圖片。
快速開發腳手架
另外，為了後台的快速搭建這裡使用的是 renren-fast 快速開發腳手架。使用這個腳手架配合上程式碼生成器 renren-generator ，我們可以快速生成 70%左右的前後端程式碼。絕對是快速開發項目並交付以及接私活的利器了！
我在之前的也推薦過這個腳手架，詳情請看下面這兩篇文章：
總結
這篇文章我主要從架構設計層面分析了朋友開源的這個基於微服務的刷題系統。
當然了，朋友使用微服務開發這個項目的主要目的也是為了自己實踐微服務相關的知識，同時也是為了給需要微服務相關實戰項目經驗的小夥伴一個可以學習的項目。不然的話，直接用單體就完事了，完全可以支撐這個項目目前的並發量以及可預見的未來的並發量。
再來一次！昨晚肝了很久~原創不易，若有幫助，求贊求轉發啊！
我的Github地址：Snailclimb – Overview
