Spring Cloud之網關

時間 2019-11-11

標籤 spring cloud 網關欄目 Spring 简体版

原文原文鏈接

接口的分類： git

開放接口：能夠受權一些接口口OAuth2.0協議方式第三方聯合登陸github

內部接口：通常只能在局域網中進行訪問，服務與服務之間關係都在同一個微服務系統中。目的是爲了保證安全問題spring

接口設計：json

接口權限開放 or 內部api

冪等性緩存

安全性 https安全

防止篡改數據（驗證簽名）服務器

網關攔截接口實現黑白名單微信

遵循restFul風格 http+json 爲了跨平臺架構

考慮高併發對接口服務實現服務降級熔斷隔離

最後使用同一的API管理平臺 swagger

網關概念：

至關於客戶端請求同一先請求到網關服務器上，再由網關服務器進行轉發到實際服務器地址相似 Nginx

過濾器和網關的區別？

過濾適合於攔截單個Tomcat服務器進行攔截請求

網關是攔整個微服務請求

Nginx與Zuul區別

相同點：

均可以實現負載均衡反向代理過濾請求實現網關效果

不一樣： Nginx C語言 Zuul Java

Zuul負載均衡實現：採用ribbon+eureka實現本地負載均衡

Nginx負載均衡實現：服務器端實現負負載均衡

Nginx比Zuul功能更強大，Nginx整合一些腳本語言（Nginx+Lua）

Nginx適合於服務器端負載均衡也能夠實現網關

Zuul適合微服務網關。使用Java就能夠開發

建議Nginx+zuul實現網關 Nginx實現反向代理 zuul對微服務實現網關攔截

網關分類

開放Api

開放api(openApi) 企業須要將自身數據、能力等做爲開發平臺向外開放，一般會以rest的方式向外提供，最好的例子就是淘寶開放平臺、騰訊公司的QQ開發平臺、微信開放平臺。 Open API開放平臺必然涉及到客戶應用的接入、API權限的管理、調用次數管理等，必然會有一個統一的入口進行管理，這正是API網關能夠發揮做用的時候。

微服務網關

微服務的概念最先在2012年提出，在Martin Fowler的大力推廣下，微服務在2014年後獲得了大力發展。在微服務架構中，有一個組件能夠說是必不可少的，那就是微服務網關，微服務網關處理了負載均衡，緩存，路由，訪問控制，服務代理，監控，日誌等。API網關在微服務架構中正是以微服務網關的身份存在。

API服務管理平臺

上述的微服務架構對企業來講有可能實施上是困難的，企業有不少遺留系統，要所有抽取爲微服務器改動太大，對企業來講成本過高。可是因爲不一樣系統間存在大量的API服務互相調用，所以須要對系統間服務調用進行管理，清晰地看到各系統調用關係，對系統間調用進行監控等。 API網關能夠解決這些問題，咱們能夠認爲若是沒有大規模的實施微服務架構，那麼對企業來講微服務網關就是企業的API服務管理平臺。

網關設計

開放API接口

一、對於OpenAPI使用的API網關來講，通常合做夥伴要以應用的形式接入到OpenAPI平臺，合做夥伴須要到 OpenAPI平臺申請應用。所以在OpenAPI網關以外，須要有一個面向合做夥伴的使用的平臺用於合做夥伴，這就要求OpenAPI網關須要提供API給這個用戶平臺進行訪問。以下架構:

固然若是是在簡單的場景下，可能並不須要提供一個面向合做夥伴的門戶，只須要由公司的運營人員直接添加合做夥伴應用id/密鑰等，這種狀況下也就不須要合做夥伴門戶子系統。

內網API接口

對於內網的API網關，在起到的做用上來講能夠認爲是微服務網關，也能夠認爲是內網的API服務治理平臺。當企業將全部的應用使用微服務的架構管理起來，那麼API網關就起到了微服務網關的做用。而當企業只是將系統與系統之間的調用使用rest api的方式進行訪問時使用API網關對調用進行管理，那麼API網關起到的就是API服務治理的做用。架構參考以下：

三、對於公司內部公網應用（如APP、公司的網站），若是管理上比較細緻，在架構上是可能由獨立的API網關來處理這部份內部公網應用，若是想比較簡單的處理，也能夠是使用面向合做夥伴的API網關。若是使用獨立的API網關，有如下的好處：

面向合做夥伴和麪向公司主體業務的優先級不同，不一樣的API網關能夠作到業務影響的隔離。

內部API使用的管理流程和麪向合做夥伴的管理流程可能不同。

內部的API在功能擴展等方面的需求通常會大於OpenAPI對於功能的要求。

基於以上的分析，若是公司有能力，那麼仍是建議分開使用合做夥伴OPEN API網關和內部公網應用網關。