Spring Cloud架構教程 (三)服務網關(基礎)

經過以前幾篇Spring Cloud中幾個核心組件的介紹,咱們已經能夠構建一個簡略的(不夠完善)微服務架構了。好比下圖所示:html

altalt前端

咱們使用Spring Cloud Netflix中的Eureka實現了服務註冊中心以及服務註冊與發現;而服務間經過Ribbon或Feign實現服務的消費以及均衡負載;經過Spring Cloud Config實現了應用多環境的外部化配置以及版本管理。爲了使得服務集羣更爲健壯,使用Hystrix的融斷機制來避免在微服務架構中個別服務出現異常時引發的故障蔓延。web

在該架構中,咱們的服務集羣包含:內部服務Service A和Service B,他們都會註冊與訂閱服務至Eureka Server,而Open Service是一個對外的服務,經過均衡負載公開至服務調用方。本文咱們把焦點彙集在對外服務這塊,這樣的實現是否合理,或者是否有更好的實現方式呢?spring

先來講說這樣架構須要作的一些事兒以及存在的不足:api

  • 首先,破壞了服務無狀態特色。爲了保證對外服務的安全性,咱們須要實現對服務訪問的權限控制,而開放服務的權限控制機制將會貫穿並污染整個開放服務的業務邏輯,這會帶來的最直接問題是,破壞了服務集羣中REST API無狀態的特色。從具體開發和測試的角度來講,在工做中除了要考慮實際的業務邏輯以外,還須要額外可續對接口訪問的控制處理。
  • 其次,沒法直接複用既有接口。當咱們須要對一個即有的集羣內訪問接口,實現外部服務訪問時,咱們不得不經過在原有接口上增長校驗邏輯,或增長一個代理調用來實現權限控制,沒法直接複用原有的接口。

面對相似上面的問題,咱們要如何解決呢?下面進入本文的正題:服務網關!安全

爲了解決上面這些問題,咱們須要將權限控制這樣的東西從咱們的服務單元中抽離出去,而最適合這些邏輯的地方就是處於對外訪問最前端的地方,咱們須要一個更強大一些的均衡負載器,它就是本文未來介紹的:服務網關。架構

服務網關是微服務架構中一個不可或缺的部分。經過服務網關統一貫外系統提供REST API的過程當中,除了具有服務路由、均衡負載功能以外,它還具有了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色,爲微服務架構提供了前門保護的做用,同時將權限控制這些較重的非業務邏輯內容遷移到服務路由層面,使得服務集羣主體可以具有更高的可複用性和可測試性。app

下面咱們經過實例例子來使用一下Zuul來做爲服務的路有功能。spring-boot

準備工做

在構建服務網關以前,咱們先準備一下網關內部的微服務,能夠直接使用前幾篇編寫的內容,好比:微服務

  • eureka-client
  • eureka-consumer

 

在啓動了eureka-clienteureka-consumer的實例以後,全部的準備工做就以就緒,下面咱們來試試使用Spring Cloud Zuul來實現服務網關的功能。

構建服務網關

使用Spring Cloud Zuul來構建服務網關的基礎步驟很是簡單,只須要下面幾步:

  • 建立一個基礎的Spring Boot項目,命名爲:api-gateway。並在pom.xml中引入依賴:
<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>1.5.4.RELEASE</version>
  <relativePath/>
</parent>

<dependencies>
  <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zuul</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
  </dependency>
</dependencies>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-dependencies</artifactId>
      <version>Dalston.SR1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
  • 建立應用主類,並使用@EnableZuulProxy註解開啓Zuul的功能。
@EnableZuulProxy
@SpringCloudApplication
public class Application {
  
  public static void main(String[] args) {
    new SpringApplicationBuilder(Application.class).web(true).run(args);
  }
  
}
  • 建立配置文件application.yaml,並加入服務名、端口號、eureka註冊中心的地址:
spring:
  application:
    name: api-gateway

server:
  port: 1101

eureka:
  client:
    serviceUrl:
      defaultZone: http://eureka.didispace.com/eureka/

到這裏,一個基於Spring Cloud Zuul服務網關就已經構建完畢。啓動該應用,一個默認的服務網關就構建完畢了。因爲Spring Cloud Zuul在整合了Eureka以後,具有默認的服務路由功能,即:當咱們這裏構建的api-gateway應用啓動並註冊到eureka以後,服務網關會發現上面咱們啓動的兩個服務eureka-clienteureka-consumer,這時候Zuul就會建立兩個路由規則。每一個路由規則都包含兩部分,一部分是外部請求的匹配規則,另外一部分是路由的服務ID。針對當前示例的狀況,Zuul會建立下面的兩個路由規則:

  • 轉發到eureka-client服務的請求規則爲:/eureka-client/**
  • 轉發到eureka-consumer服務的請求規則爲:/eureka-consumer/**

最後,咱們能夠經過訪問1101端口的服務網關來驗證上述路由的正確性:

相關文章
相關標籤/搜索