Springboot: 2.1.6.RELEASESpringCloud: Greenwich.SR1html
如無特殊說明,本系列教程全採用以上版本前端
前面的文章咱們介紹了,Eureka用於服務的註冊於發現,Feign支持服務的調用以及均衡負載,Hystrix處理服務的熔斷防止故障擴散,Spring Cloud Config服務集羣配置中心,彷佛一個微服務框架已經完成了。java
咱們仍是少考慮了一個問題,外部的應用如何來訪問內部各類各樣的微服務呢?在微服務架構中,後端服務每每不直接開放給調用端,而是經過一個API網關根據請求的url,路由到相應的服務。當添加API網關後,在第三方調用端和服務提供方之間就建立了一面牆,這面牆直接與調用方通訊進行權限控制,後將請求均衡分發給後臺服務端。git
一個簡單的微服務架構已經躍然紙面:github
在Spring Cloud微服務系統中,一種常見的負載均衡方式是,客戶端的請求首先通過負載均衡(zuul、Ngnix、F5),再到達服務網關(zuul集羣),而後再到具體的服務,服務統一註冊到高可用的服務註冊中心集羣,服務的全部的配置文件由配置服務管理,配置服務的配置文件放在git倉庫,方便開發人員隨時改配置。
在微服務架構模式下後端服務的實例數通常是動態的,對於客戶端而言很難發現動態改變的服務實例的訪問地址信息。所以在基於微服務的項目中爲了簡化前端的調用邏輯,一般會引入API Gateway做爲輕量級網關,同時API Gateway中也會實現相關的認證邏輯從而簡化內部服務之間相互調用的複雜度。spring
一般而言不一樣的客戶端對於顯示時對於數據的需求是不一致的,好比手機端或者Web端又或者在低延遲的網絡環境或者高延遲的網絡環境。apache
所以爲了優化客戶端的使用體驗,API Gateway能夠對通用性的響應數據進行裁剪以適應不一樣客戶端的使用需求。同時還能夠將多個API調用邏輯進行聚合,從而減小客戶端的請求數,優化客戶端用戶體驗後端
固然咱們還能夠針對不一樣的渠道和客戶端提供不一樣的API Gateway,對於該模式的使用由另一個你們熟知的方式叫Backend for front-end, 在Backend for front-end模式當中,咱們能夠針對不一樣的客戶端分別建立其BFF,進一步瞭解BFF能夠參考這篇文章:Pattern: Backends For Frontendsapi
對於系統而言進行微服務改造一般是因爲原有的系統存在或多或少的問題,好比技術債務,代碼質量,可維護性,可擴展性等等。API Gateway的模式一樣適用於這一類遺留系統的改造,經過微服務化的改造逐步實現對原有系統中的問題的修復,從而提高對於原有業務響應力的提高。經過引入抽象層,逐步使用新的實現替換舊的實現。瀏覽器
在Spring Cloud體系中, Spring Cloud Zuul就是提供負載均衡、反向代理、權限認證的一個API gateway。在開始聊Zuul如何使用以前,先講一個比較有意思的事情,就是在springcloud組件中,服務網關這個組件,springcloud提供了兩種選擇,一個是netflix公司開源的Zuul,還有一個是springcloud本身開源的Spring Cloud Gateway,具體這兩個組件的恩怨情仇,在後面的Spring Cloud Gateway的文章中咱們再細聊:)
Spring Cloud Zuul路由是微服務架構的不可或缺的一部分,提供動態路由,監控,彈性,安全等的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。
下面咱們來看一下Zuul最簡單的使用方式,建立zuul-simple工程
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.6.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.springcloud</groupId> <artifactId>zuul-simple</artifactId> <version>0.0.1-SNAPSHOT</version> <name>zuul-simple</name> <description>Demo project for Spring Boot</description> <properties> <java.version>1.8</java.version> <spring-cloud.version>Greenwich.SR1</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>
引入spring-cloud-starter-netflix-zuul包
server: port: 8080 spring: application: name: spring-cloud-zuul zuul: routes: baidu: path: /baidu/** url: https://www.baidu.com/
這裏的配置表示,訪問/baidu/ 直接重定向到https://www.baidu.com/
若是直接訪問http://localhost:8080/baidu,則會直接跳轉到https://www.baidu.com/。
package com.springcloud.zuulsimple; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.zuul.EnableZuulProxy; @SpringBootApplication @EnableZuulProxy public class ZuulSimpleApplication { public static void main(String[] args) { SpringApplication.run(ZuulSimpleApplication.class, args); } }
啓動類添加@EnableZuulProxy,支持網關路由。
史上最簡單的zuul案例就配置完了
啓動項目,在瀏覽器訪問http://localhost:8080/baidu/,咱們能夠看到頁面已經跳轉到百度首頁。
再嘗試訪問http://localhost:8080/baidu/aa,咱們能夠看到頁面跳轉至:https://www.baidu.com/search/..., 由於https://www.baidu.com/aa 這個連接不存在, 因此百度幫咱們跳轉到的error頁面。
至此,Zuul簡單使用已經介紹完畢,下面咱們來聊一下服務化的方式。
經過url映射的方式來實現Zuul的轉發有侷限性,好比每增長一個服務就須要配置一條內容,另外後端的服務若是是動態來提供,就不能採用這種方案來配置了。實際上在實現微服務架構時,服務名與服務實例地址的關係在eureka server中已經存在了,因此只須要將Zuul註冊到eureka server上去發現其餘服務,就能夠實現對serviceId的映射。
咱們結合示例來講明,在上面示例項目基礎上來進行改造
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>
增長spring-cloud-starter-netflix-eureka-client包,添加對eureka的支持。
server: port: 8080 spring: application: name: spring-cloud-zuul zuul: routes: api-producer: path: /producer/** serviceId: spring-cloud-producer eureka: client: service-url: defaultZone: http://localhost:8761/eureka/
在這裏咱們增長了對服務的支持,這裏的Zuul配置的含義爲訪問/producer/**,轉向到eureka上面serviceId爲spring-cloud-producer的服務。
先從上一篇的項目中copy Eureka到本篇的文件夾中,再從第五篇的項目中copy一個producer到本篇的文件夾中。
依次啓動eureka,producer和Zuul.
咱們打開瀏覽器訪問:http://localhost:8080/producer/hello?name=spring, 能夠看到頁面正常顯示producer的響應:hello spring,producer is ready。說明經過zuul成功調用了producer服務。
這裏producer能夠啓動兩個服務,屢次刷新http://localhost:8080/producer/hello?name=spring, 能夠看到Zuul對服務的調用是負載均衡的。
可是若是後端服務多達十幾個的時候,每個都這樣配置也挺麻煩的,spring cloud zuul已經幫咱們作了默認配置。默認狀況下,Zuul會代理全部註冊到Eureka Server的微服務,而且Zuul的路由規則以下:http://ZUUL_HOST:ZUUL_PORT/微服務在Eureka上的serviceId/**會被轉發到serviceId對應的微服務。
咱們註銷掉zuul-simple配置文件中有關路由的配置。
#zuul: # routes: # api-producer: # path: /producer/** # serviceId: spring-cloud-producer
再次啓動Zuul。
咱們在瀏覽器中訪問http://localhost:8080/spring-cloud-producer/hello?name=spring,能夠看到和上面同樣的返回結果,說明Spring cloud zuul默認已經提供了轉發功能。
到此zuul的基本使用咱們就聊完了。關於zuul高級使用,咱們下篇再來介紹。
參考:
http://www.ityouknow.com/spri...
https://www.fangzhipeng.com/s...