程慶華

（河南省水文水資源局）

1 引言

隨著信息化技術(shù)的不斷推進，水文數(shù)據(jù)也由以紙質(zhì)年鑒轉(zhuǎn)化為以國標(biāo)數(shù)據(jù)庫為主要成果形式。形式的改變，也促進了水文數(shù)據(jù)的廣泛應(yīng)用。面對各行各業(yè)對日益增漲的各種水文數(shù)據(jù)需求，亟待建立一套完善的水文數(shù)據(jù)共享系統(tǒng)，有序、安全和高可靠性的解決水文數(shù)據(jù)共享使用問題。文章采用基于API 網(wǎng)關(guān)技術(shù)，通過JWT 認證，建立安全高效的水文數(shù)據(jù)共性系統(tǒng)。

2 問題的提出

在面對各種水文數(shù)據(jù)使用需求時，采用完全開放的數(shù)據(jù)形式是不安全的，也是低效的，更遑論開放紙質(zhì)年鑒查詢形式，非常不利于水文數(shù)據(jù)使用，發(fā)揮其重要的國民經(jīng)濟建設(shè)作用。因此，要建立水文數(shù)據(jù)共性系統(tǒng)必須至少滿足以下三個條件：一是個性化使用。按照使用者的需求，在水文數(shù)據(jù)安全范圍內(nèi)按需使用水文數(shù)據(jù)；二是身份認證。根據(jù)不同的使用者，提供不同級別和深度的水文數(shù)據(jù)，需要由一個完善的身份認證體系；三是滿足海量數(shù)據(jù)需求。水文數(shù)據(jù)的使用涉及各行各業(yè)，任意時刻，因此需要建立一套滿足分布式各類用戶的數(shù)據(jù)需求。

3 解決思路

基于API 服務(wù)網(wǎng)關(guān)的水文數(shù)據(jù)共享系統(tǒng)就是把各種水文數(shù)據(jù)需求，按照API 服務(wù)模式，以JOSN 提供給數(shù)據(jù)獲取者。API 服務(wù)網(wǎng)關(guān)通過分布式服務(wù)，提供跨域數(shù)據(jù)安全訪問，利用JWT 認證技術(shù)提供身份認證，按需給各個數(shù)據(jù)獲取者提供數(shù)據(jù)服務(wù)。構(gòu)建的模型如圖1。

3.1 API服務(wù)網(wǎng)關(guān)

API服務(wù)網(wǎng)關(guān)是一個服務(wù)器，是系統(tǒng)的唯一入口。從面向?qū)ο笤O(shè)計的角度看，它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個客戶端提供一個定制的API。它可能還具有其它職責(zé)，如身份驗證、監(jiān)控、負載均衡、緩存、請求分片與管理、靜態(tài)響應(yīng)處理。API 網(wǎng)關(guān)方式的核心要點是，所有的客戶端和消費端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能。通常，網(wǎng)關(guān)也是提供REST/HTTP 的訪問API。服務(wù)端通過API-GW注冊和管理服務(wù)。

圖1 模型圖

3.1.1 API服務(wù)網(wǎng)關(guān)的組成

API 服務(wù)網(wǎng)關(guān)包括三大部分：API 網(wǎng)關(guān)、網(wǎng)關(guān)控制臺、度量數(shù)據(jù)采集分析。實際形態(tài)各異，可以按需搭建，但肯定少不了API 網(wǎng)關(guān)，網(wǎng)關(guān)控制臺的功能職責(zé)可能會放到服務(wù)注冊等地方而沒有單獨抽取出來，至于度量數(shù)據(jù)采集可能會在整個微服務(wù)架構(gòu)中存一個通用的度量數(shù)據(jù)采集應(yīng)用以監(jiān)控所有類型應(yīng)用。

對于大多數(shù)應(yīng)用程序而言，API 網(wǎng)關(guān)的性能和可擴展性通常都非常重要。因此，API 網(wǎng)關(guān)將構(gòu)建在一個支持異步、I/O 非阻塞的平臺上。Java 系可以使用一種基于NIO 的框架，比如Netty、Vertx、Spring Reactor ，還可以使用Node.js、NGINX Plus。

3.1.2 API服務(wù)網(wǎng)關(guān)的優(yōu)缺點

優(yōu)點：封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)?？蛻舳酥恍枰W(wǎng)關(guān)交互，而不必調(diào)用特定的服務(wù)。API 網(wǎng)關(guān)為每一類客戶端提供了特定的API，從而減少客戶端與應(yīng)用程序間的交互次數(shù)，簡化客戶端代碼的處理。

缺點：增加了一個必須開發(fā)、部署和維護的高可用組件。還有一個風(fēng)險是API 網(wǎng)關(guān)變成了開發(fā)瓶頸。為了暴露每個微服務(wù)，開發(fā)人員必須更新API 網(wǎng)關(guān)。API 網(wǎng)關(guān)的更新過程要盡可能地簡單，否則為了更新網(wǎng)關(guān)，開發(fā)人員將不得不排隊等待。不過，雖然有這些不足，但對于大多數(shù)現(xiàn)實世界的應(yīng)用程序而言使用API 網(wǎng)關(guān)是合理的。

3.2 JWT認證

3.2.1 JWT 的原理

JWT 有三部分組成：JWT 頭（header）、有效載荷（payload）和簽名哈希（signature）。JWT 的原理是，服務(wù)器認證以后，生成一個JSON對象，發(fā)回給用戶，如下JSON對象

{

"姓名":"張三"，

"角色":"管理員"，

"到期時間":"2018年7月1日0點0分"

}

以后，用戶與服務(wù)端通信的時候，都要發(fā)回這個JSON 對象。服務(wù)器完全只靠這個對象認定用戶身份。為了防止用戶篡改數(shù)據(jù)，服務(wù)器在生成這個對象的時候，會加上簽名。

服務(wù)器就不保存任何session 數(shù)據(jù)了，也就是說，服務(wù)器變成無狀態(tài)了，從而比較容易實現(xiàn)擴展。

3.2.1 JWT的流程

分布式服務(wù)離不開用戶認證。一般流程是下面這樣：①用戶向服務(wù)器發(fā)送用戶名和密碼。②服務(wù)器驗證通過后，在當(dāng)前對話（session）里面保存相關(guān)數(shù)據(jù)，比如：用戶角色、登錄時間等等。③服務(wù)器向用戶返回一個session_id，寫入用戶的Cookie。④用戶隨后的每一次請求，都會通過Cookie，將session_id 傳回服務(wù)器。⑤服務(wù)器收到session_id，找到前期保存的數(shù)據(jù)，由此得知用戶的身份。

這種模式的問題在于，擴展性（scaling）不好。單機當(dāng)然沒有問題，如果是服務(wù)器集群，或者是跨域的服務(wù)導(dǎo)向架構(gòu)，就要求session 數(shù)據(jù)共享，每臺服務(wù)器都能夠讀取session。一種解決方案是session 數(shù)據(jù)持久化，寫入數(shù)據(jù)庫或別的持久層。各種服務(wù)收到請求后，都向持久層請求數(shù)據(jù)。這種方案的優(yōu)點是架構(gòu)清晰，缺點是工程量比較大。另外，持久層萬一掛了，就會單點失敗。另一種方案是服務(wù)器索性不保存session 數(shù)據(jù)了，所有數(shù)據(jù)都保存在客戶端，每次請求都發(fā)回服務(wù)器。JWT 就是這種方案的一個代表。認證流程如圖2。

3.2.3 JWT的優(yōu)缺點

①JWT 默認不加密，但可以加密。生成原始令牌后，可以使用改令牌再次對其進行加密。②當(dāng)JWT未加密方法使一些私密數(shù)據(jù)無法通過JWT 傳輸。③JWT 不僅可用于認證，還可用于信息交換。善用JWT有助于減少服務(wù)器請求數(shù)據(jù)庫的次數(shù)。④JWT 的最大缺點是服務(wù)器不保存會話狀態(tài)，所以在使用期間不可能取消令牌或更改令牌的權(quán)限。也就是說，一旦JWT 簽發(fā)，在有效期內(nèi)將會一直有效。⑤JWT 本身包含認證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權(quán)限。為了減少盜用，JWT 的有效期不宜設(shè)置太長。對于某些重要操作，用戶在使用時應(yīng)該每次都進行身份驗證。⑥為了減少盜用和竊取，JWT 不建議使用HTTP 協(xié)議來傳輸代碼，而是使用加密的HTTPS協(xié)議進行傳輸。

圖2 認證流程如圖

4 水文數(shù)據(jù)共享系統(tǒng)的構(gòu)建

4.1 搭建API服務(wù)網(wǎng)關(guān)

Spring Cloud Gateway 是Spring Cloud 的一個全新項目，該項目是基于Spring 5.0，Spring Boot 2.0 和Project Reactor 等技術(shù)開發(fā)的網(wǎng)關(guān)，它旨在為微服務(wù)架構(gòu)提供一種簡單有效的統(tǒng)一的API 路由管理方式。Spring Cloud Gateway 作為Spring Cloud 生態(tài)系統(tǒng)中的網(wǎng)關(guān)，為了提升網(wǎng)關(guān)的性能，Spring Cloud Gateway 是基于Web Flux框架實現(xiàn)的，而Web Flux框架底層則使用了高性能的Reactor 模式通信框架Netty。并且基于Filter鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/指標(biāo)，和限流。搭建流程如下：一是引入依賴。主要引入Spring Cloud Gateway 相關(guān)依賴；在spring-cloud-starter-gateway 依賴中，會引入Web Flux、Reactor、Netty 等等依賴。二是建立配置文件。在配置文件主要添加Spring Cloud Gateway 相關(guān)配置；一是設(shè)置網(wǎng)關(guān)的服務(wù)器端口；二是設(shè)置路由配置項，對應(yīng)Route Definition 數(shù)組。路由（Route）是Gateway 中最基本的組件之一，由一個ID、URI、一組謂語（Predicate）、過濾器（Filter）組成。一個請求如果滿足某個路由的所有謂語，則匹配上該路由。三是創(chuàng)建Gateway Application 類，網(wǎng)關(guān)的啟動類。

4.2 建立JWT認證服務(wù)

首先在Spring Boot 引入依賴，主要引入JWT 依賴；然后編寫JWT生成與驗證代碼，最后封裝JWT類。通過POST實現(xiàn)跨域應(yīng)用，可以滿足分布式多種類型用戶的請求和響應(yīng)。

5 結(jié)語

基于API 服務(wù)網(wǎng)關(guān)的水文數(shù)據(jù)共享系統(tǒng)的建立，高效安全的解決了水文數(shù)據(jù)多種跨域訪問請求，使水文數(shù)據(jù)不再是“信息孤島”中的封閉數(shù)據(jù)，使其服務(wù)于各行各業(yè)的經(jīng)濟建設(shè)。但是在使用過程中，要求API 的封裝必須安全可靠，必要時應(yīng)該經(jīng)過Postman的測試才可以投入API網(wǎng)關(guān)服務(wù)中。