Spring cloud簡單學習總結

微服務簡介

1、spring boot和spring cloud 的關係

spring boot來寫各個拆分出來的微服務,spring  cloud把各個微服務聯繫起來,好比各個微服務經過eurke找到對方

spring cloud還提供不少微服務解決方案,好比網關、安全、熔斷降級

2、如何來設計微服務

1.服務拆分
2.服務註冊：一個單體架構拆分紅多個微服務以後,一個服務怎麼知道另外一個服務的存在呢,或者怎麼找到另外一個服務,就須要服務註冊
3.服務發現：須要找到另外一個服務的時候,能夠經過服務的名稱去調用另外一個服務
4.服務消費(feign或者ribbon實現)：A服務區調用B服務, A服務就是消費者,服務被稱爲提供者
5.統一入口(API網關實現)
    服務數量多起來以後確定難管理,不可能去獲知到每個服務,雖然能夠經過服務名稱來調用,這樣服務的消費者須要記住不少服務的名稱話 很麻煩
    這就須要一個統一的入口,只須要知道這個入口的名稱就能夠了,不須要具體的知道每個服務提供者的名稱
6.配置管理(config或者Apollo實現)：配置文件管理平臺
7.熔斷機制(hystrix實現)：
    系統在高併發的可能會響應不過來,這時候就須要熔斷機制,把全部請求都擋住,防止系統崩潰;
    經過熔斷系統,把請求擋住,返回一個默認的值
8.自動擴展：服務能自動擴容.

3、拆分方法

1.拆分方法

• 用戶界面層
• 應用層
• 領域層
• 基礎設施層

天氣預報系統架構設計

1.拆分後的每一個微服務的名稱

msa-weather-collection-server
msa-weather-data-server
msa-weather-city-server
msa-weather-report-server

2.天氣預報系統每一個微服務做用

1)天氣數據來自於第三方的數據接口,經過"天氣數據採集微服務"採集過來存儲到redis
2)全部城市數據列表存儲在xml文件,經過"城市數據API微服務"來解析,並提供相應接口給:

• 天氣數據採集微服務(根據"城市數據列表微服務"去採集該城市的數據,好比去採集廣州的數據)
• 天氣預報微服務,由於天氣預報微服務須要提供下拉框來選擇不一樣的城市,展現天氣狀況

3)"天氣數據API微服務"數據來源是從redis中獲取的,數據提供給"天氣預報微服務"來展示

3.天氣預報系統工做流程

1).天氣數據採集微服務 經過調用"城市數據API微服務"得到該城市的ID或者Name,去採集該城市的天氣數據存儲到redis
2).天氣預報微服務 經過調用"城市數據數據API"得到該城市ID或者Name,在調用"天氣數據API微服務"去採集該城市的天氣數據,而後展示在web頁面

4.天氣預報系統接口設計

第三放天氣接口
　　GET http://whther.etouch.cn/weather_mini?citykey={cityId} 參數:cityId
天氣數據接口
　　GET /weather/cityId/{cityId} 參數cityId爲城市ID
　　GET /weather/cityName/{cityName} 參數cityName爲城市名稱
天氣預報接口
　　GET /report/cityId{cityId} 參數:cityId爲城市ID
城市數據接口
　　GET /cities
系統存儲是redis和XML(城市的列表)

 

spring cloud簡介

1.spring cloud做用

• 提供配置管理
• 服務註冊,做爲服務的管理者,他要了解這些服務的情況,讓每一個服務都註冊到spring cloud中,跟它有交互
• 服務發現:不一樣服務之間可以互相發現對方,經過服務註冊表和服務註冊中心實現,發現以後才能調用對方
• 斷路器:當系統負載過大的時候它會掐斷訪問
• 負載均衡、智能路由、微代理、服務間調用、一次性令牌、控制總線、全局鎖、領導選舉、分佈式會話、集羣狀態、分佈式消息

2.spring cloud子項目介紹

1)spring cloud config
　　配置中心,把配置利用git來集中管理程序的配置,客戶端去讀git中的配置
2)spring cloud netflix
　　集羣衆多netflix的開源軟件,包括:Eureka、hystrix、zuul、archaius
3)spring cloud bus
　　消息總線,利用分佈式消息將服務和服務實例鏈接在一塊兒,用於在一個集羣中傳播狀態的變化,好比配置更改的事件.
　　可與spring cloud config聯合實現熱部署
　　其實就是通訊方式
4)spring cloud cluster
　　基於zookeeper、redis、hazelcast、consul等實現的領導選舉和平民狀態模式的實現
5)spring cloud consul
　　實現服務發現和配置管理
6)spring cloud security
　　在zuul代理中爲oauth2 rest客戶端和認證頭轉發,提供負載均衡
7)spring cloud sleuth
　　適用於spring cloud應用程序的分佈式跟蹤,與zipkin、htrace和基於日誌（例如ELK）的跟蹤相兼容.能夠作日誌收集
8)spring cloud data flow
　　雲本地編排服務.易於使用的DSL、拖放式GUI和REST API一塊兒簡化了基於微服務的數據管道的總體編排
9)spring cloud stream
　　一個輕量級的事件驅動的微服務框架來快速構建能夠鏈接到外部系統的應用程序.使用kafka或者rabbitmq在spring boot應用程序之間發送和接收消息的簡單聲明模型
10)spring cloud connectors
　　便於paas應用在各類平臺上鍊接到後端,例如數據可和消息服務

服務發現和註冊

1.微服務發現的意義

你發佈的服務要讓其餘的服務找到
2.如何發現服務
經過URI訪問訪問服務
經過服務名稱訪問
　　1)10.2.3.1:8080的java服務註冊到Eureka中 叫passport,10.2.3.2:8080的java服務註冊到Eureka中 叫passport
　　2)如今Eureka中passport服務後對應的是10.2.3.1:8080和10.2.3.2:8080的java的服務提供服務
　　3)而後10.2.3.3:8090服務經過訪問passport這個服務名訪問到10.2.3.1:8080或者10.2.3.2:8080,不用記IP地址+端口訪問了
　　4)假如把10.2.3.2:8080服務遷移到10.2.3.4中,那麼只須要將3.4註冊到Eureka的passport服務中, 10.2.3.3就不用更改代碼了

3.如何搭建Eureka server

1)建立一個spring cloud項目
2)pox.xml引入eureka-server包
3)在配置裏設置監聽端口,啓動server功能,關閉client功能

4.如何把服務註冊進Eureka

2)建立一個spring cloud項目
2)引入eureka-client包
3)在代碼里加上@EnableDisCoveryClient 就能夠被eureka自動發現了
4)在application.properties配置文件里加上以下內容
　　spring.application.name: passport #註冊到eureka server的服務名稱
　　eureka.client.serviceUrl.defaultZone: http://localhost:8761/eureka/ #eureka的server地址

微服務消費者

1.微服務消費模式

1)服務直連模式,直接經過域名或者路徑訪問
2)客戶端發現模式,服務實例啓動後,將本身的位置信息提交到註冊中心;客戶端從註冊中心查詢,來獲取可用的服務實例;客戶端自行使用負載均衡算法從多個實例中選擇出一個

 

 

3)服務端發現模式,跟客戶端發現模式惟一的區別,就是負載均衡不是客戶端來作的,是服務端作的 架構見圖

 

2.常見微服務消費者

1)httpClient
2)ribbon
　　基於客戶端的負載均衡,結合eureka,使用支持http和tcp來實現客戶端的負載均衡,Eureka爲微服務實例提供服務註冊,Robbon做爲服務消費的客戶端;
　　Ribbon使用方法
　　　　添加依賴
　　　　　　dependencies { compile('org.springframework.cloud:spring-clou-starter-netflix-ribbon') }
　　　　注入
　　　　　　加入:@RibbonClient(name="Ribbon-client",configuration = RibbonConfiguration.class)
　　　　配置
　　　　　　LB的算法等等
　　　　使用
　　　　　　restTemplate.getForEntity("http://passport/cities",String.class) #直接經過註冊到eureka的服務名+路徑調用.原來是10.2.3.1:8080/cities
3)feign #這個最經常使用
　　①pox. 中添加feign依賴

         

　　②在Application.java啓動類中添加@EnableFeignClients

        

 

 

API網關 

1.做用:統一服務入口,能夠方便的實現對平臺衆多服務接口進行管控,對訪問的用戶身份進行驗證,防止數據篡改,業務功能的鑑權,響應數據的脫敏,流量和併發的控制

2.API網關的意義

　　集合多個API,對多個API進行管理
　　統一API入口

       

 

 

   

 

　　

 

 

3.API網關的好處

• 避免將內部信息泄露給外部,可以將外部公共API跟內部的微服務的API區分開(外部就是給Android之類的調用,內部就是給微服務之間調用)
• 爲微服務添加額外的安全層:爲所有的微服務提供統一的入口,從而避免的外面客戶進行服務發現和版本控制時都沒有受權的API進行訪問
• 支持混合通訊協議
• 下降構建微服務的複雜性
• 微服務模擬與虛擬化,經過將微服務內部的API和外部的API加以區分

4.API網關弊端

• 路由邏輯配置要進行統一管理,這樣才能保證合理的路由鏈接
• API網關須要作高可用

5.常見API網關實現方法

• Nginx
• spring cloud zuul
• KONG

6.如何集成zuul

功能:認證、壓力測試、金絲雀測試、動態路由、負載削減、安全、靜態響應處理、主動交換管理
1)在controller中引入zuul,@EnableZuulProxy
2)在application.properties中寫方法,好比zuul.routes.path: /hi/**, zuul.routes.hi.serviceId:passport,就是訪問zuul的時候,只要是/hi這個路徑的,就將請求轉發給passport微服務處理

 

 

微服務的集中化配置

1、爲何須要集中化配置

• 微服務數量多,配置多；一個微服務須要部署到多臺機器,各自有不一樣的配置
• 手工管理配置繁瑣

2、集中化配置按什麼分類

1.按照配置的來源劃分
　　主要有源代碼、文件、數據庫鏈接、遠程調用等
2.按照配置的環境劃分
　　開發環境、測試環境、預發佈環境、生產環境
3.按照配置的集成階段劃分
　　編譯時:源代碼級別的配置;把源代碼和編譯文件一塊兒提交到代碼倉庫
　　打包時:打包階段經過某種形式將配置文件打入到最終的應用中
　　運行時:應用在啓動前不須要知道具體的配置,在啓動的時候就能夠在本地或者遠程獲取配置文件
4.按照配置的加載方式劃分
　　啓動加載: 應用在啓動時獲取配置,而且是隻獲取一次,在應用起來以後就不會再去加載配置了（好比端口號,線程池的信息,基本上一啓動就不會變）
　　動態加載: 應用在運行的各個過程當中隨時 均可以獲取到的一些配置;這些配置意味着在應用運行過程當中可能會被常常的修改(好比頁面中分頁的大小,好比從一頁20,改成一頁30,改完就會生效的)

3、配置中心的要求

1.面向可配置的編碼,提取出來,不能寫死
　　好比頁面分頁的大小,數據庫的鏈接池
2.隔離性
　　不能的部署環境,應用之間的配置要隔離,好比生產環境一個配置,測試環境一個配置
3.一致性
　　同個微服務,若是要部署在多臺機器上作分佈式,要使用同一個配置
4.集中化配置
　　在分佈式環境下應用的配置應該要具有可管理性;配置能夠被遠程管理

4、spring cloud  config架構

config server:基於git,因此能輕鬆的實現標記版本的配置環境(能夠實現環境+版本的區分),能夠訪問管理內容
config client:

5、如何集成spring cloud config

1.配置config server

添加依賴: dependencies {compile('org.springframe.cloud:spring-cloud-config-server')}
引入config server註解:@EnableConfigServer
修改application.properties
            spring.application.name: micro-weather-config-server  #服務名稱
            server.port=8888
            eureka.client.serviceUrl.defaultZone: http://localhost:8761/eureka #註冊到eureka-server
            spring.cloud.config.server.git.uri=https://github.com/waylau/spring-cloud-microservice-development #指定git地址
            spring.cloud.config.server.git.searchPaths=config-repo  #指定git下面的路徑,跟上面合起來就是https://github.com/waylau/spring-cloud-microservice-development/config-repo

2.配置config client

添加依賴 dependcies { compile('org.springframe.cloud:spring-cloud-config-client') }
修改application.properties
            spring.application.name: passport  #服務名稱
            eureka.client.serviceUrl.defaultZone: http://localhost:8761/eureka #註冊到eureka-server
            spring.cloud.config.profile=dev  #指定環境
            spring.cloud.config.uri= http://localhost:8888  #指定config server地址
            #### https://github.com/waylau/spring-cloud-microservice-development目錄下有個配置文件叫passport-dev.properties,內容以下
                auther=mayun  #指定一個做者名字

3.配置文件命名規則

{application—name}-{profile}.properties
好比:passport-dev.properties
那passport微服務怎麼找到這個配置文件呢
     就是經過application.properties中的服務名稱-環境(passport-dev)去config server中application.properties中定義的地址裏去找passport-dev.properties

4.讓passport去調用遠程配置文件

寫一個測試用例
            public class ApplicationTests {
                @Value("${auther}")
                
                @Test
                public void contextLoads() {
                    assertEquals("mayun",auther)  #若是配置文件中的auther的值跟我定義的"mayun"相等,那麼就是讀取到了
                }
            }

服務的熔斷降級

1.什麼是服務的熔斷機制

若是忽然間訪問量過大,超過咱們的承受能力,就須要熔斷機制,不至於讓咱們的資源耗盡,咱們又要作響又要作防禦,就靠熔斷機制 好比訪問量忽然過大，超過咱們的承受能力(設置閾值),就返回給用戶一個默認值(好比錯誤頁面之類的)