Spring Cloud構建微服務架構：服務網關（基礎）
通過之前幾篇Spring Cloud中幾個核心組件的介紹，我們已經可以構建一個簡略的(不夠完善)微服務架構了。比如下圖所示：
我們使用Spring Cloud Netflix中的Eureka實現了服務注冊中心以及服務注冊與發現;而服務間通過Ribbon或Feign實現服務的消費以及均衡負載;通過Spring Cloud Config實現了應用多環境的外部化配置以及版本管理。為了使得服務集群更為健壯，使用Hystrix的融斷機制來避免在微服務架構中個別服務出現異常時引起的故障蔓延。
在該架構中，我們的服務集群包含：內部服務Service A和Service B，他們都會注冊與訂閱服務至Eureka Server，而Open Service是一個對外的服務，通過均衡負載公開至服務調用方。本文我們把焦點聚集在對外服務這塊，這樣的實現是否合理，或者是否有更好的實現方式呢?
先來說說這樣架構需要做的一些事兒以及存在的不足：
- 首先，破壞了服務無狀態特點。為了保證對外服務的安全性，我們需要實現對服務訪問的權限控制，而開放服務的權限控制機制將會貫穿并污染整個開放服務的業務邏輯，這會帶來的最直接問題是，破壞了服務集群中REST API無狀態的特點。從具體開發和測試的角度來說，在工作中除了要考慮實際的業務邏輯之外，還需要額外可續對接口訪問的控制處理。
- 其次，無法直接復用既有接口。當我們需要對一個即有的集群內訪問接口，實現外部服務訪問時，我們不得不通過在原有接口上增加校驗邏輯，或增加一個代理調用來實現權限控制，無法直接復用原有的接口。
面對類似上面的問題，我們要如何解決呢?下面進入本文的正題：服務網關!
為了解決上面這些問題，我們需要將權限控制這樣的東西從我們的服務單元中抽離出去，而最適合這些邏輯的地方就是處于對外訪問最前端的地方，我們需要一個更強大一些的均衡負載器，它就是本文將來介紹的：服務網關。
服務網關是微服務架構中一個不可或缺的部分。通過服務網關統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，為微服務架構提供了前門保護的作用，同時將權限控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務集群主體能夠具備更高的可復用性和可測試性。
下面我們通過實例例子來使用一下Zuul來作為服務的路有功能。
準備工作
在構建服務網關之前，我們先準備一下網關內部的微服務，可以直接使用前幾篇編寫的內容，比如：
- eureka-client
- eureka-consumer
由于我們用了基于eureka的服務，所以我們可以使用我的公益注冊中心：http://eureka.didispace.com/
這些服務可從我的倉庫中直接獲取：
Github：https://github.com/dyc87112/SpringCloud-Learning
碼云：https://gitee.com/didispace/SpringCloud-Learning
在啟動了eureka-client和eureka-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-client和eureka-consumer，這時候Zuul就會創建兩個路由規則。每個路由規則都包含兩部分，一部分是外部請求的匹配規則，另一部分是路由的服務ID。針對當前示例的情況，Zuul會創建下面的兩個路由規則：
- 轉發到eureka-client服務的請求規則為：/eureka-client/**
- 轉發到eureka-consumer服務的請求規則為：/eureka-consumer/**
最后，我們可以通過訪問1101端口的服務網關來驗證上述路由的正確性：
- 比如訪問：http://localhost:1101/eureka-client/dc ，該請求將最終被路由到eureka-client的/dc接口上。
本篇小結
本篇，我們介紹了構建服務網關的基礎。通過上面的構建內容，我們已經為所有內部服務提供了一個統一的對外入口，同時對于服務的路由都是自動創建了，減少了傳統方式大量的運維配置工作。
【本文為51CTO專欄作者“翟永超”的原創稿件，轉載請通過51CTO聯系作者獲取授權】
