企業API 網關

時間 2019-11-17

標籤企業 api 網關简体版

原文原文鏈接

網關一詞較早出如今網絡設備裏面，好比兩個相互獨立的局域網段之間經過路由器或者橋接設備進行通訊，這中間的路由或者橋接設備咱們稱之爲網關。前端

相應的API網關將各系統對外暴露的服務聚合起來，全部要調用這些服務的系統都須要經過API網關進行訪問，基於這種方式網關能夠對API進行統一管控，例如：認證、鑑權、流量控制、協議轉換、監控等等。數據庫

API網關的流行得益於近幾年微服務架構的興起，本來一個龐大的業務系統被拆分紅許多粒度更小的系統進行獨立部署和維護，這種模式勢必會帶來更多的跨系統交互，企業API的規模也會成倍增長，API網關（或者微服務網關）就逐漸成爲了微服務架構的標配組件。編程

以下是咱們整理的API網關的幾種典型應用場景：後端

一、面向Web或者移動App緩存

這類場景，在物理形態上相似先後端分離，前端應用經過API調用後端服務，須要網關具備認證、鑑權、緩存、服務編排、監控告警等功能。安全

二、面向合做夥伴開放API微信

這類場景，主要爲了知足業務形態對外開放，與企業外部合做夥伴創建生態圈，此時的API 網關注重安全認證、權限分級、流量管控、緩存等功能的建設。網絡

三、企業內部系統互聯互通session

對於中大型的企業內部每每有幾10、甚至上百個系統，尤爲是微服務架構的興起系統數量更是急劇增長。系統之間相互依賴，逐漸造成網狀調用關係不便於管理和維護，須要API網關進行統一的認證、鑑權、流量管控、超時熔斷、監控告警管理，從而提升系統的穩定性、下降重複建設、運維管理等成本。架構

設計目標

純Java實現；
支持插件化，方便開發人員自定義組件；
支持橫向擴展，高性能；
避免單點故障，穩定性要高，不能由於某個API故障致使整個網關中止服務；
管理控制檯配置更新可自動生效，不須要重啓網關；

應用架構設計

說明：

一、網關核心子系統經過HAProxy或者Nginx進行負載均衡，爲避免正好路由的LB節點服務不可用，能夠考慮在此基礎上增長Keepalived來實現LB的失效備援，當LB Node1中止服務，Keepalived會將虛擬IP自動飄移到LB Node2，從而避免由於負載均衡器致使單點故障。DNS能夠直接指向Keepalived的虛擬IP。

二、網關除了對性能要求很高外，對穩定性也有很高的要求，引入Zookeeper及時將Admin對API的配置更改同步刷新到各網關節點。

三、管理中心和監控中心能夠採用相似網關子系統的高可用策略，若是嫌麻煩管理中心能夠省去Keepalived，相對來講管理中心沒有這麼高的可用性要求。

四、理論上監控中心須要承載很大的數據量，好比有1000個API，平均每一個API一天調用10萬次，對於不少互聯網公司單個API的量遠遠大於10萬，若是將每次調用的信息都存儲起來太浪費，也沒有太大的必要。能夠考慮將API每分鐘的調用狀況彙總後進行存儲，好比1分鐘的平均響應時間、調用次數、流量、正確率等等。

五、數據庫選型能夠靈活考慮，原則上網關在運行時要儘量減小對DB的依賴，不然IO延時會嚴重影響網關性能。能夠考慮首次訪問後將API配置信息緩存，Admin對API配置更改後經過Zookeeper通知網關刷新，這樣一來DB的訪問量能夠忽略不計，團隊可根據自身偏好靈活選型。

非阻塞式HTTP服務

管理和監控中心能夠根據團隊的狀況採用本身熟悉的Servlet容器部署，網關核心子系統對性能的要求很是高，考慮採用NIO的網絡模型，實現純HTTP服務便可，不須要實現Servlet容器，推薦Netty框架（設計優雅，大名鼎鼎的Spring Webflux默認都是使用的Netty，更多的優點就不在此詳述了），內部測試在相同的機器上分別經過Tomcat和Netty生成UUID，Netty的性能大約有20%的提高，若是後端服務響應耗時較高的話吞吐量還有更大的提高。（補充：Netty4.x的版本便可，不要採用5以上的版本，有嚴重的缺陷沒有解決）

採用Netty做爲Http容器首先須要解決的是Http協議的解析和封裝，好在Netty自己提供了這樣的Handler，具體參考以下代碼：

一、構建一個單例的HttpServer，在SpringBoot啓動的時候同時加載並啓動Netty服務

int sobacklog = Integer.parseInt(AppConfigUtil.getValue("netty.sobacklog"));
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.localAddress(new InetSocketAddress(this.portHTTP))
.option(ChannelOption.SO\_BACKLOG, sobacklog)
.childHandler(new ChannelHandlerInitializer(null));
// 綁定端口
ChannelFuture f = b.bind(this.portHTTP).sync();
logger.info("HttpServer name is " + HttpServer.class.getName() + " started and listen on " + f.channel().localAddress());

二、初始化Handler

@Override
protected void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
p.addLast(new HttpRequestDecoder());
p.addLast(new HttpResponseEncoder());
int maxContentLength = 2000;
try {
maxContentLength = Integer.parseInt(AppConfigUtil.getValue("netty.maxContentLength"));
} catch (Exception e) {
logger.warn("netty.maxContentLength配置異常，系統默認爲：2000KB");
}
p.addLast(new HttpObjectAggregator(maxContentLength * 1024));// HTTP 消息的合併處理
p.addLast(new HttpServerInboundHandler());
}

HttpRequestDecoder和HttpResponseEncoder分別實現Http協議的解析和封裝，Http Post內容超過一個數據包大小會自動分組，經過HttpObjectAggregator能夠自動將這些數據粘合在一塊兒，對於上層收到是一個完整的Http請求。

三、經過HttpServerInboundHandler將網絡請求轉發給網關執行器

@Override
public void channelRead0(ChannelHandlerContext ctx, Object msg) throws Exception {
try {
if (msg instanceof HttpRequest && msg instanceof HttpContent) {
CmptRequest cmptRequest = CmptRequestUtil.convert(ctx, msg);
CmptResult cmptResult = this.gatewayExecutor.execute(cmptRequest);
FullHttpResponse response = encapsulateResponse(cmptResult);
ctx.write(response);
ctx.flush();
}
} catch (Exception e) {
logger.error("網關入口異常，" + e.getMessage());
e.printStackTrace();
}
}

設計上建議將Netty接入層代碼跟網關核心邏輯代碼分離，不要將Netty收到HttpRequest和HttpContent直接給到網關執行器，能夠考慮作一層轉換封裝成本身的Request給到執行器，方便後續能夠很容易的將Netty替換成其它Http容器。（如上代碼所示，CmptRequest即爲自定義的Http請求封裝類，CmptResult爲網關執行結果類）

組件化及自定義組件支持

組件是網關的核心，大部分功能特性均可以基於組件的形式提供，組件化能夠有效提升網關的擴展性。

先來看一個簡單的微信認證組件的例子：

以下實現的功能是對API請求傳入的Token進行校驗，其結果分別是認證經過、Token過時和無效Token，認證經過後再將微信OpenID攜帶給上游服務系統。

/**
* 微信token認證，token格式：
* {appID:'',openID:'',timestamp:132525144172,sessionKey: ''}
*/
public class WeixinAuthTokenCmpt extends AbstractCmpt {
private static Logger logger = LoggerFactory.getLogger(WeixinAuthTokenCmpt.class);
private final CmptResult SUCCESS_RESULT;
public WeixinAuthTokenCmpt() {
SUCCESS_RESULT = buildSuccessResult();
}
@Override
public CmptResult execute(CmptRequest request, Map<String, FieldDTO> config) {
if (logger.isDebugEnabled()) {
logger.debug("WeixinTokenCmpt ......");
}
CmptResult cmptResult = null;
//Token認證超時間(傳入單位:分)
long authTokenExpireTime = getAuthTokenExpireTime(config);
WeixinTokenDTO authTokenDTO = this.getAuthTokenDTO(request);
logger.debug("Token=" + authTokenDTO);
AuthTokenState authTokenState = validateToken(authTokenDTO, authTokenExpireTime);
switch (authTokenState) {
case ACCESS: {
cmptResult = SUCCESS_RESULT;
Map<String, String> header = new HashMap<>();
header.put(HeaderKeyConstants.HEADER_APP_ID_KEY, authTokenDTO.getAppID());
header.put(CmptHeaderKeyConstants.HEADER_WEIXIN_OPENID_KEY, authTokenDTO.getOpenID());
header.put(CmptHeaderKeyConstants.HEADER_WEIXIN_SESSION_KEY, authTokenDTO.getSessionKey());
cmptResult.setHeader(header);
break;
}
case EXPIRED: {
cmptResult = buildCmptResult(RespErrCode.AUTH_TOKEN_EXPIRED, "token過時,請從新獲取Token！");
break;
}
case INVALID: {
cmptResult = buildCmptResult(RespErrCode.AUTH_INVALID_TOKEN, "Token無效！");
break;
}
}
return cmptResult;
}
...
}

上面例子看不懂不要緊，接下來會詳細闡述組件的設計思路。

一、組件接口定義

public interface ICmpt {
/**
* 組件執行入口
*
* @param request
* @param config，組件實例的參數配置
* @return
*/
CmptResult execute(CmptRequest request, Map<String, FieldDTO> config);
/**
* 銷燬組件持有的特殊資源，好比線程。
*/
void destroy();
}

execute是組件執行的入口方法，request前面提到過是http請求的封裝，config是組件的特殊配置，好比上面例子提到的微信認證組件就有一個自定義配置-Token的有效期，不一樣的API使用該組件能夠設置不一樣的有效期。

FieldDTO定義以下：

public class FieldDTO {
private String title;
private String name;
private FieldType fieldType = FieldType.STRING;
private String defaultValue;
private boolean required;
private String regExp;
private String description;
}

CmptResult爲組件執行後的返回結果，其定義以下：

public class CmptResult {
RespErrMsg respErrMsg;//組件返回錯誤信息
private boolean passed;//組件過濾是否經過
private byte[] data;//組件返回數據
private Map<String, String> header = new HashMap<String, String>();//透傳後端服務響應頭信息
private MediaType mediaType;//返回響應數據類型
private Integer statusCode = 200;//默認返回狀態碼爲200
}

二、組件類型定義

執行器須要根據組件類型和組件執行結果判斷是要直接返回客戶端仍是繼續往下面執行，好比認證類型的組件，若是認證失敗是不能繼續往下執行的，但緩存類型的組件沒有命中才繼續往下執行。固然這樣設計存在一些缺陷，好比新增組件類型須要執行器配合調整處理邏輯。（Kong也提供了大量的功能組件，沒有研究過其網關框架是如何跟組件配合的，是否支持用戶自定義組件類型，知道的朋友詳細交流下。）

初步定義以下組件類型：

認證、鑑權、流量管控、緩存、路由、日誌等。

其中路由類型的組件涵蓋了協議轉換的功能，其負責調用上游系統提供的服務，能夠根據上游系統提供API的協議定製不一樣的路由組件，好比：Restful、WebService、Dubbo、EJB等等。

三、組件執行位置和優先級設定

執行位置：Pre、Routing、After，分別表明後端服務調用前、後端服務調用中和後端服務調用完成後，相同位置的組件根據優先級決定執行的前後順序。

四、組件發佈形式

組件打包成標準的Jar包，經過Admin管理界面上傳發布。

附-組件可視化選擇UI設計

組件熱插拔設計和實現

JVM中Class是經過類加載器+全限定名來惟一標識的，上面章節談到組件是以Jar包的形式發佈的，但相同組件的多個版本的入口類名須要保持不變，所以要實現組件的熱插拔和多版本並存就須要自定義類加載器來實現。

大體思路以下：

網關接收到API調用請求後根據請求參數從緩存裏拿到API配置的組件列表，而後再逐一參數從緩存裏獲取組件對應的類實例，若是找不到則嘗試經過自定義類加載器載入Jar包，並初始化組件實例及緩存。

附-參考示例

public static ICmpt newInstance(final CmptDef cmptDef) {
ICmpt cmpt = null;
try {
final String jarPath = getJarPath(cmptDef);
if (logger.isDebugEnabled()) {
logger.debug("嘗試載入jar包,jar包路徑: " + jarPath);
}
//加載依賴jar
CmptClassLoader cmptClassLoader = CmptClassLoaderManager.loadJar(jarPath, true);
// 建立實例
if (null != cmptClassLoader) {
cmpt = LoadClassUtil.newObject(cmptDef.getFullQualifiedName(), ICmpt.class, cmptClassLoader);
} else {
logger.error("加載組件jar包失敗! jarPath: " + jarPath);
}
} catch (Exception e) {
logger.error("組件類加載失敗，請檢查類名和版本是否正確。ClassName=" + cmptDef.getFullQualifiedName() + ", Version=" + cmptDef.getVersion());
e.printStackTrace();
}
return cmpt;
}

補充說明：

自定義類加載器可直接須要繼承至URLClassLoader，另外必須指定其父類加載器爲執行器的加載器，不然組件無法引用網關的其它類。

API故障隔離及超時、熔斷處理

在詳細闡述設計前先講個實際的案例，大概12年的時候某公司自研了一款ESB的中間件（企業服務總線跟API網關很相似，當年SOA理念大行其道的時候都推崇的是ESB，側重服務的編排和異構系統的整合。），剛開始用的還行，但隨着接入系統的增多，忽然某天運維發現大量API出現緩慢甚至超時，初步檢查發現ESB每一個節點的線程幾乎消耗殆盡，起初判斷是資源不夠，緊急擴容後仍是很快線程佔滿，最終致使上百個系統癱瘓。

最終找到問題的癥結是某個業務系統自身的緣由致使服務不可用，下游業務系統請求大量堆積到ESB中，從而致使大量線程堵塞。

以上案例說明了一個在企業應用架構設計裏面的經典原則-故障隔離，因爲全部的API請求都要通過網關，必須隔離API之間的相互影響，尤爲是個別API故障致使整個網關集羣服務中斷。

接下來分別介紹故障隔離、超時管控、熔斷的實現思路。

一、故障隔離

有兩種方式能夠實現，一是爲每一個API建立一個線程池，每一個線程分配10~20個線程，這也是經常使用的隔離策略，但這種方式有幾個明顯的缺點：

1）線程數會隨着API接入數量遞增，1000個API就須要2萬個線程，光線程切換對CPU就是不小的開銷，而其線程還須要佔用必定的內存資源；

2）平均分配線程池大小致使個別訪問量較大且響應時間相對較長的API吞吐量上不去；

3）Netty自己就有工做線程池了，再增長API的線程池，致使某些須要ThreadLocal特性的編程變得困難。

二是用信號量隔離，直接複用Netty的工做線程，上面線程池隔離提到的3個缺點均可以基本避免，建議設置單個API的信號量個數小於等於Netty工做線程池數量的1/3，這樣既兼顧了單個API的性能又不至於單個API的問題致使整個網關堵塞。

具體實現能夠考慮直接引用成熟的開源框架，推薦Hystrix，能夠同時解決超時控制和熔斷。

參考配置以下：

Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(groupKey))
.andCommandKey(HystrixCommandKey.Factory.asKey(commandKey ))
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter() // 艙壁隔離策略-信號量
.withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE) //設置每組command能夠申請的信號量最大數 .withExecutionIsolationSemaphoreMaxConcurrentRequests(CmptInvoker.maxSemaphore)
/*開啓超時設置*/
.withExecutionIsolationThreadInterruptOnTimeout(true)
/*超時時間設置*/
.withExecutionIsolationThreadTimeoutInMilliseconds(timeout)
.withCircuitBreakerEnabled(true)//開啓熔斷
.withCircuitBreakerSleepWindowInMilliseconds(Constants.DEFAULT_CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS)// 5秒後會嘗試閉合迴路

二、超時管控

API的超時控制是必需要作的，不然上游服務即使是間歇性響應緩慢也會堵塞大量線程（雖然經過信號量隔離後不會致使整個網關線程堵塞）。

其次，每一個API最好能夠單獨配置超時時間，但不建議可讓用戶隨意設置，仍是要有個最大閾值。（API網關不適合須要長時間傳輸數據的場景，好比大文件上傳或者下載、DB數據同步等）

實現上能夠直接複用開源組件的功能，好比：HttpClient能夠直接設置獲取鏈接和Socket響應的超時時間，Hystrix能夠對整個調用進行超時控制等。

三、熔斷

熔斷相似電路中的保險絲，當超過負荷或者電阻被擊穿的時候自動斷開對設備起到保護做用。在API網關中設置熔斷的目的是快速響應請求，避免沒必要要的等待，好比某個API後端服務正常狀況下1s之內響應，但如今由於各類緣由出現堵塞大部分請求20s才能響應，雖然設置了10s的超時控制，但讓請求線程等待10s超時不只沒有意義，反而會增長服務提供方的負擔。

爲此咱們能夠設置單位時間內超過多少比例的請求超時或者異常，則直接熔斷鏈路，等待一段時間後再次嘗試恢復鏈路。

實現層面能夠直接複用Hystrix。