基於Spring Cloud的微服務架構

關於基於Spring Cloud的微服務應用架構，網上已經有不少文章了，但我仍是以爲把本身的架構過程和經驗寫下來，對本身來講算是知識和技術的梳理，對於誤打誤撞進來看到這篇文章的讀者來講，或許也能起到一些借鑑做用。

Spring Cloud OSS相關概念能夠去官網看看，是Netflix公司貢獻給社區的一系列組件，經過組合這些組件能夠迅速設計出一個微服務應用架構，而這一套框架組件及其組合方式也已經成爲微服務事實上的標準。相對與阿里的開源框架dubbo，Spring Cloud的組件形態更爲豐富，社區更爲活躍，所以也是被不少公司採用的緣由之一。在咱們的項目中，使用到的組件包括Eureka、Config、Zipkin、Zuul和Ribbon，總體的應用架構圖大體以下，固然還有一些邏輯關係沒有在圖中體現，我將在架構解析部分進行更多說明。

基於Spring Cloud的微服務架構圖

上面的架構圖中，咱們先看左邊部分。Eureka-Server是註冊服務，全部其它服務都註冊到Eureka-Server，包括配置服務Config-Service，鏈路追蹤服務Zipkin-Service、監控服務Monitor-Service和右邊的業務邏輯所包含的各類服務(圖中省略了不少業務服務)。其中監控服務使用到的組件包括Hystrix和Turbine，配置服務的配置信息能夠來自相似於GitLab這種源碼/文件管理系統。配置服務做爲一箇中心管理服務，除了註冊服務，其它服務啓動時都須要從配置服務獲取到本身的配置文件來完成自身的正常啓動。

左邊這些服務能夠認爲是輔助業務系統或者運維相關的服務，右邊的服務包含了主要的業務邏輯。好比一個Pay-Service API調用的流程大體以下：

Client客戶端發起請求，請求先進入到Gateway-Service，也就是網關服務，網關服務有使用到Spring Cloud的Zuul和Ribbon組件，這兩組件分別提供路由和負載均衡服務。Gateway-Service在啓動後會從Eureka-Server中獲取到服務列表，列表裏包含全部註冊了而且狀態良好的服務所使用的IP地址和端口，這樣Zuul組件根據路由配置規則就知道將該請求路由到哪一個服務，好比這裏是Pay-Service。若是Pay-Service部署了多個服務實例，就會用到了Ribbon的負載均衡功能，根據必定規則將請求發送到後端其中一個Pay-Service服務實例。Pay-Service須要記錄日誌時，調用Log-Service服務接口，是經過Feign組件調用的，而後Log-Service將日誌信息寫入到MySQL數據庫。經過同步工具，咱們將MySQL數據實時或者按期同步到ElasticSearch，再使用其它的開源組件(好比Kibana)對ElasticSearch的數據進行處理展現。

咱們還能夠看到，微服務之間可能須要互相調用，咱們使用Feign組件來完成，Feign組件自動包含了Ribbon功能，也就是若是要調用的服務部署了多個實例，Feign調用時就使用了Ribbon的負載均衡功能。所以，爲方便調用其它服務，右邊全部的微服務基本都集成了Feign組件，這一點也是圖中沒有體現出來的。

圖中還有一個UAA-Service服務比較特殊，也是很關鍵的一個服務。UAA全稱爲User Authentication Authorization，即用戶認證和受權。項目中使用了JWT + Oauth2 + Spring Security來實現認證受權邏輯。UAA-Service負責JWT Token的生成，是一個受權服務器，而其它全部的業務服務都屬於資源服務，當客戶端要調用資源服務的接口時，須要攜帶一個Token，資源服務從Token解析出相應的用戶信息，存儲到Spring Security上下文，而後業務代碼裏面就能夠取出相應的用戶信息，判斷該用戶是否有權限訪問指定接口等等。認證受權的邏輯圖以下：

JWT+Oauth2+Spring Security 認證受權邏輯

從上面的邏輯圖中能夠看到，若是用戶訪問的不是登陸/註冊接口，則先看請求是否攜帶了Token，若是沒有攜帶，直接返回給客戶端相應的提示信息，好比「請求缺乏Token字段」，不然從Redis中查找是否存在客戶端傳過來的Token，若是沒有，則返回「無效Token」信息，不然解析Token，存儲到Spring Security上下文(這個邏輯是和業務代碼分開的，在進入到業務代碼以前就完成)，而後在業務代碼中可使用諸如@PreAuthorize(「hasRole(‘ADMIN’)」)來判斷當前用戶是否具備ADMIN權限，若是有則能夠訪問當前接口，不然給客戶端返回無訪問權限等信息。

綜上，咱們看到整個微服務架構包含了如下幾個主要部分：

註冊服務，用於管理其它服務； 配置服務，給各服務提供配置管理； 網關服務，給後端微服務提供路由和負載均衡； 用戶服務、認證受權服務，給微服務訪問提供保護機制； 監控、鏈路追蹤服務，輔助系統運維； 其它業務服務，提供真正的業務功能邏輯； 這六部分是一個微服務應用系統必不可少的，固然這裏展現的僅僅是一個最小的微服務系統所包含的模塊或服務，還有其它不少服務沒有畫出來，你們根據實際狀況，能夠在本身的項目中基於此進行各類擴展來真正知足您業務系統的功能、安全、性能等需求。

微信掃碼，進入【技術人成長】社羣逛逛。