採用Gradle構建,基於SpringCloud體系實現的完整微服務架構,支援Java、Scala混編,包含大資料、區塊...
Lion 專案簡介
本專案已提託管至 Github ,請前往 https://github.com/micyo202/lion 檢視原始碼

logo
注:本專案是基於SpringCloud微服務架構的,若需要檢視基於Dubbo的RPC專案請檢視本人yan專案,前往地址: https://www.jianshu.com/p/6362ec32ecd9
本專案是使用Gradle構建,基於SpringBoot 2.1.2.RELEASE、SpringCloud Greenwich.RELEASE體系實現的一套完整微服務架構,採用Oauth2統一授權認證,支援 Java 、 Scala 混編,支援 Docker 容器化部署,規劃將包含 大資料 、 區塊鏈 等相關模組,專案孵化中...
利用Spring Boot Admin來監控各個獨立Service的執行狀態,利用Turbine來檢視近實時的介面執行狀態和呼叫頻率,利用Zipkin進行檢視鏈路跟蹤等。
基於Eureka來實現的服務註冊與呼叫,在SpringCloud中使用Feign, 我們可以做到使用HTTP請求遠端服務時能與呼叫本地方法一樣的編碼體驗,開發者完全感知不到這是遠端方法,更感知不到這是個HTTP請求。
因為採取了服務的分佈,為了避免服務之間的呼叫“雪崩”,採用了Hystrix的作為熔斷器,避免了服務之間的“雪崩”效應
專案整合了 spring-boot 2.1.2 + jpa + mybatis 框架
專案使用 travis-ci 進行持續性CI,保證了最新提交程式碼的 build passing ,使用 codecov 進行自動化測試程式碼的覆蓋率。
專案後期專案也會不斷更新與時俱進,敬請期待...
專案架構圖

專案架構圖
說明
網上有關SpringCloud的教程很多,相關的專案也很多,但很少有整合完整的好專案,即便有也是基於1.x的版本,在這個技術迭代更新發展速度很快的時代,這樣的專案不利於實際開發和落地。因此 lion 誕生了,它是一套完整的微服務體系框架,幾乎包含了微服務所有常用元件,為了讓中小型公司解決當下技術瓶頸,快速將現有技術架構拆分改造為微服務體系架構,只需在本框架上進行相關業務開發即可,大大減少了微服務架構的入門門檻,達到拿來就用,使架構師及開發人員不用過多的關注架構本身,只需專注業務開發即可,節省了大量時間。
引言
為了幫助初學者快速理解入門微服務,這裡簡單介紹一下微服務的基本概念及常用元件說明,希望能給初學者帶來幫助,如有解釋不當的地方還望及時指出,謝謝!(對微服務相關知識已有了解的可直接跳過引言部分)
系統架構設計
要知道什麼是微服務架構,你得先知道什麼系統架構設計。
系統架構設計描述了在應用系統的內部,如何根據業務、技術、組織、靈活性、可擴充套件性以及可維護性等多種因素,將應用系統劃分成不同的部分,並使這些部分彼此之間相互分工、相互協作,從而為使用者提供某種特定的價值方式。
什麼是微服務?
微服務是一個概念、一個專案開發的架構思想。
微服務架構
微服務架構是一種架構模式,它提倡將單一應用程式劃分成一組小的服務,服務之間互相協調、互相配合,為使用者提供最終價值。每個服務執行在其獨立的程序中,服務於服務間採用輕量級的通訊機制互相溝通(通常是基於 HTTP 的 RESTful API)。每個服務都圍繞著具體業務進行構建,並且能夠被獨立地部署到生產環境、類生產環境等。另外,應儘量避免統一的、集中式的服務管理機制,對具體的一個服務而言,應根據業務上下文,選擇合適的語言、工具對其進行構建。
微服務架構優勢?
複雜度可控、獨立部署、輕量級通訊、技術選型靈活、容錯、擴充套件
SOA與微服務架構區別
SOA實現 | 微服務架構實現 |
---|---|
企業級,自頂向下開展實施 | 團隊級,自底向上開展實施 |
服務由多個子系統組成,粒度大 | 一個系統被拆分成多個服務,粒度細 |
企業服務匯流排,幾種式的服務架構 | 無集中式匯流排,鬆散的服務架構 |
整合方式複製(ESB/WS/SOAP) | 整合方便簡單(HTTP/REST/JSON) |
單塊架構系統,相互依賴,部署複雜 | 服務能獨立部署 |
Dubbo VS Spring Cloud
核心要素 | Dubbo | Spring Cloud |
---|---|---|
服務註冊中心 | Zookeeper、Redis | Spring Cloud Netflix Eureka、Consul |
服務排程方式 | RPC | REST API |
服務閘道器 | 無 | Spring Cloud Netflix Zuul |
斷路器 | 不完善 | Spring Cloud Netflix Hystrix |
分散式配置 | 無 | Spring Cloud Config |
分散式追蹤系統 | 無 | Spring Cloud Sleuth |
訊息匯流排 | 無 | Spring Cloud Bus |
資料流 | 無 | Spring Cloud Stream(基於Redis、RabbitMQ、Kafka實現的訊息微服務) |
批量任務 | 無 | Spring Cloud Task |
為什麼選用Spring Cloud而不是Dubbo?
Dubbo只是實現了服務治理,而Spring Cloud子專案分別覆蓋了微服務架構下的眾多部件,而服務治理只是其中的一個方面。
Dubbo提供了各種Filter,可以通過擴充套件Filter來完善。
我們必須採用與一站式時代、泛 SOA 時代不同的技術棧,而 Spring Cloud 就是其中的佼佼者。
從核心要素來看,Spring Cloud 更勝一籌,在開發過程中只要整合Spring Cloud的子專案就可以順利的完成各種元件的融合,而Dubbo缺需要通過實現各種Filter來做定製,開發成本以及技術難度略高。
什麼是Spring Cloud?
Spring Cloud 是一系列框架的有序集合。
它利用 Spring Boot 的開發便利性巧妙地簡化了分散式系統基礎設施的開發,如服務發現註冊、配置中心、訊息匯流排、負載均衡、斷路器、資料監控等,都可以用 Spring Boot 的開發風格做到一鍵啟動和部署。
Spring 並沒有重複製造輪子,它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來,通過 Spring Boot 風格進行再封裝遮蔽掉了複雜的配置和實現原理,最終給開發者留出了一套簡單易懂、易部署和易維護的分散式系統開發工具包。
常用元件說明
Ribbon
Ribbon主要功能是為 REST 客戶端實現負載均衡。
工作時候做4件事:
- 優先選擇在同一個 Zone 且負載較少的 Eureka Server;
- 定期從 Eureka 更新並過濾服務例項列表;
- 根據使用者指定的策略,在從 Server 取到的服務註冊列表中選擇一個例項的地址;
- 通過 RestClient 進行服務呼叫。
Hystrix
Hystrix 庫, 實現了斷路器的模式。“斷路器” 本身是一種開關裝置,當某個服務單元發生故障之後,通過斷路器的故障監控(類似熔斷保險絲),向呼叫方返回一個符合預期的、可處理的備選響應(FallBack),而不是長時間的等待或者丟擲呼叫方無法處理的異常,這樣就保證了服務呼叫方的執行緒不會被長時間、不必要地佔用,從而避免了故障在分散式系統中的蔓延,乃至雪崩。
註解方式:
@EnableHystrix
相當於
@EnableCircuitBreaker
Feign
Feign 是一個宣告式的 Web Service 客戶端,它的目的就是讓 Web Service 呼叫更加簡單。它整合了 Ribbon 和 Hystrix,從而讓我們不再需要顯式地使用這兩個元件。Feign 還提供了 HTTP 請求的模板,通過編寫簡單的介面和插入註解,我們就可以定義好 HTTP 請求的引數、格式、地址等資訊。接下來,Feign 會完全代理 HTTP 的請求,我們只需要像呼叫方法一樣呼叫它就可以完成服務請求。
Feign 具有如下特性:
- 可插拔的註解支援,包括 Feign 註解和 JAX-RS 註解
- 支援可插拔的 HTTP 編碼器和解碼器
- 支援 Hystrix 和它的 Fallback
- 支援 Ribbon 的負載均衡
- 支援 HTTP 請求和響應的壓縮
Zuul
Zuul路由是微服務架構的不可或缺的一部分,提供動態路由、監控、彈性、安全等的邊緣服務。Zuul 是 Netflix 出品的一個基於 JVM 路由和服務端的負載均衡器。
Spring Cloud Config
在分散式系統中,由於服務數量巨多,為了方便服務配置檔案統一管理,實時更新,所以需要分散式配置中心元件。在Spring Cloud中,有分散式配置中心元件spring cloud config ,它支援配置服務放在配置服務的記憶體中(即本地),也支援放在遠端Git倉庫中。在spring cloud config 元件中,分兩個角色,一是config server,二是config client
Spring Cloud Bus
Spring Cloud Bus 通過輕量訊息代理連線各個分佈的節點。這會用在廣播狀態的變化(例如配置變化)或者其他的訊息指令。Spring Bus 的一個核心思想是通過分散式的啟動器對 Spring Boot 應用進行擴充套件,也可以用來建立一個多個應用之間的通訊頻道。目前唯一實現的方式是用 Amqp 訊息代理作為通道。
Spring Cloud Bus 被國內很多都翻譯為訊息匯流排,也挺形象的。大家可以將它理解為管理和傳播所有分散式專案中的訊息既可,其實本質是利用了 MQ 的廣播機制在分散式的系統中傳播訊息,目前常用的有 Kafka 和 RabbitMQ。利用 Bus 的機制可以做很多的事情,其中配置中心客戶端重新整理就是典型的應用場景之一。
一、專案開發環境&工具
- MacOS Mojave / Windows 10
- CentOS 7
- JDK 1.8
- Scala 2.11.12
- IntelliJ IDEA 2018.3 / Eclipse 2018-12
二、相關軟體
名稱 | 連結 | 使用 |
---|---|---|
MySql 8.0.13 | https://www.mysql.com | √ |
MongoDB 4.0.4 | http://www.mongodb.org | × |
Redis 5.0.2 | https://redis.io | √ |
Elasticsearch 6.5.2 | https://www.elastic.co/cn/ | √ |
Kibana 6.5.2 | https://www.elastic.co/cn/ | √ |
Logstash 6.5.2 | https://www.elastic.co/cn/ | √ |
Solr 7.5.0 | http://lucene.apache.org/solr/ | × |
RabbitMQ 3.7.9 | https://www.rabbitmq.com | √ |
Zookeeper 3.4.13 | https://zookeeper.apache.org | √ |
Kafka 2.1.0 | http://kafka.apache.org | × |
Hadoop 3.1.1 | http://hadoop.apache.org | √ |
Hbase 2.1.1 | https://hbase.apache.org | √ |
Hive 3.1.1 | http://hive.apache.org | × |
Spark 2.4.0 | http://spark.apache.org | √ |
Gradle 5.3.1 | https://gradle.org | √ |
三、元件說明
- 服務註冊、發現: eureka
- 服務監控:spring boot admin
- 配置中心:spring cloud config -> native / git
- 訊息匯流排:spring cloud bus -> amqp
- 負載均衡:feign / ribbon
- 斷路器: hystrix
- 路由閘道器:gateway / zuul
- 叢集監控:hystrix dashboard -> turbine
- 鏈路追蹤:spring cloud sletuh -> zipkin
- 安全認證:spring security -> oauth2
- ORM框架:mybatis + jpa
- 資料來源監控:druid
- api文件輸出:swagger2
- 分散式鎖:redis(待實現)
- 訊息佇列:rabbitmq
- 分散式事物:3PC+TCC(待實現)
四、專案樹結構
lion -- 根目錄 ├── lion-eureka-server -- 服務註冊/發現 ├── lion-admin-server -- 服務監控 ├── lion-config-server -- 配置中心 ├── lion-zuul-server -- 路由服務 ├── lion-zipkin-server -- 鏈路追蹤服務 ├── lion-gateway-server -- 二代路由服務(暫不使用) ├── lion-turbine-server -- 服務呼叫實時監控 ├── lion-common -- 通用工具類模組 ├── lion-upms -- 使用者許可權管理系統 ├── lion-auth -- 安全認證伺服器 ├── lion-bigdata -- 大資料模組 ├── lion-blockchain -- 區塊鏈模組 ├── lion-demo -- 示例程式碼模組 |├── lion-demo-provider -- 服務提供者 |├── lion-demo-consumer -- 服務消費者 |├── lion-demo-ribbon -- ribbon + hystrix示例模組 |├── lion-demo-sample -- 綜合案例包含灰度、許可權認證、scala混編等
五、專案準備
-
在執行該專案前,請確保先正常啟動:RabbitMQ 3.7.9、 MySql 8.0.13 、Redis 5.0.2這3個必備服務,否則專案無法執行
-
建議使用IntelliJ IDEA作為IDE開發工具(注:該工具需要購買,啟用步驟詳情可參考我個人簡書上的方法,請移步至 https://www.jianshu.com/p/3c87487e7121 )
六、專案部署
1.下載專案,並且匯入到IDE開發工具中
2.使用 Gradle 構建專案
3.建立2個數據庫分別為 lion、zipkin 並分別執行根目錄 database 中的 lion.sql、zipkin.sql 檔案,建立整個專案必要的表(如:使用者表、許可權表、選單資源表等...)
4.修改專案的 resources/application.yml 配置檔案中的datasource druid資料庫連線資訊
5.修改專案的 resources/log4j2.yml 配置檔案中的 -log.path value 日誌輸出路徑
6.完成以上步驟就可以正常部署啟動服務了
7.專案開發詳細程式碼,可參考lion-demo下的示例模組
七、服務啟動
以下服務請優先按順序啟動lion-eureka-server、lion-config-server服務,再啟動其他服務(注:帶
的服務為相關示例模組可根據需要選擇啟動)
- lion-eureka-server(埠:8101、8102...)
- lion-config-server(埠:8300, 啟動後請等待lion-config-server成功註冊到eureka後再啟動之後各服務,否則會找不到配置服務 )
- lion-admin-server(埠:8200)
- lion-zuul-server(埠:8400)
- lion-zipkin-server(埠:9411)
-
lion-gateway-server(埠:8450) - lion-turbine-server(埠:8500)
- lion-upms(埠:8800)
- lion-auth(埠:8888)
-
lion-bigdata(埠:8801) -
lion-blockchain (埠:8802) -
lion-demo(相關demo示例)-
lion-demo-provider(埠:8601、8602、8603...) -
lion-demo-consumer(埠:8701、8702、8703...) -
lion-demo-ribbon(埠:8781) -
lion-demo-sample(埠:8782)
-
八、效果預覽
服務監控

服務監控
鏈路追蹤

鏈路追蹤
服務呼叫情況

服務呼叫情況