閱讀物件

傳統企業正在做微服務架構轉型的開發人員或者架構師，希望本文對您能起到一定的引導作用。

API閘道器介紹

閘道器一詞較早出現在網路裝置裡面，比如兩個相互獨立的區域網段之間通過路由器或者橋接裝置進行通訊，這中間的路由或者橋接裝置我們稱之為閘道器。

相應的API閘道器將各系統對外暴露的服務聚合起來，所有要呼叫這些服務的系統都需要通過API閘道器進行訪問，基於這種方式閘道器可以對API進行統一管控，例如：認證、鑑權、流量控制、協議轉換、監控等等。

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

如下是我們整理的API閘道器的幾種典型應用場景：

1、面向Web或者移動App

這類場景，在物理形態上類似前後端分離，前端應用通過API呼叫後端服務，需要閘道器具有認證、鑑權、快取、服務編排、監控告警等功能。

2、面向合作伙伴開放API

這類場景，主要為了滿足業務形態對外開放，與企業外部合作伙伴建立生態圈，此時的API 網關注重安全認證、許可權分級、流量管控、快取等功能的建設。

3、企業內部系統互聯互通

對於中大型的企業內部往往有幾十、甚至上百個系統，尤其是微服務架構的興起系統數量更是急劇增加。系統之間相互依賴，逐漸形成網狀呼叫關係不便於管理和維護，需要API閘道器進行統一的認證、鑑權、流量管控、超時熔斷、監控告警管理，從而提高系統的穩定性、降低重複建設、運維管理等成本。

設計目標

1、純Java實現；

2、支援外掛化，方便開發人員自定義元件；

3、支援橫向擴充套件，高效能；

4、避免單點故障，穩定性要高，不能因為某個API故障導致整個閘道器停止服務；

5、管理控制檯配置更新可自動生效，不需要重啟閘道器；

應用架構設計

整個平臺拆分成3個子系統，Gateway-Core（核心子系統）、Gateway-Admin（管理中心）、Gateway-Monitor（監控中心）。

Gateway-Core負責接收客戶端請求，排程、載入和執行元件，將請求路由到上游服務端，處理上游服務端返回的結果等；

Gateway-Monitor負責收集監控日誌、生成各種運維管理報表、自動告警等；

系統架構設計

說明：

1、閘道器核心子系統通過HAProxy或者Nginx進行負載均衡，為避免正好路由的LB節點服務不可用，可以考慮在此基礎上增加Keepalived來實現LB的失效備援，當LB Node1停止服務，Keepalived會將虛擬IP自動飄移到LB2，從而避免因為負載均衡器導致單點故障。DNS可以直接指向Keepalived的虛擬IP。

2、閘道器除了對效能要求很高外，對穩定性也有很高的要求，引入Zookeeper及時將Admin對API的配置更改同步重新整理到各閘道器節點。

3、管理中心和監控中心可以採用類似閘道器子系統的高可用策略，如果嫌麻煩管理中心可以省去Keepalived，相對來說管理中心沒有這麼高的可用性要求。

4、理論上監控中心需要承載很大的資料量，比如有1000個API，平均每個API一天呼叫10萬次，對於很多網際網路公司單個API的量遠遠大於10萬，如果將每次呼叫的資訊都儲存起來是不現實的，也沒有太大的必要。可以考慮將每個API每分鐘的呼叫情況彙總後進行儲存，比如1分鐘的平均響應時間、次數、流量、正確率等等。

5、資料庫選型可以靈活考慮，原則上閘道器在執行時要儘可能減少對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，具體參考如下程式碼：

1、構建一個單例的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());

2、初始化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請求。

3、通過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;
    }
...
}

上面例子看不懂沒關係，接下來會詳細闡述元件的設計思路。

1、元件介面定義

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;
}

2、元件型別定義

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

初步定義如下元件型別：

認證、鑑權、流量管控、快取、路由、日誌等。

其中路由型別的元件涵蓋了協議轉換的功能，其負責呼叫上游系統提供的服務，可以根據上游系統提供API的協議定製不同的路由元件，比如：Restful、WebService、Dubbo、EJB等等。

3、元件執行位置和優先順序設定

執行位置：Pre、Routing、After，分別代表後端服務呼叫前、後端服務呼叫中和後端服務呼叫完成後，相同位置的元件根據優先順序決定執行的先後順序。

4、元件釋出形式

元件打包成標準的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故障導致整個閘道器叢集服務中斷。

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

1、故障隔離

有兩種方式可以實現，一是為每個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秒後會嘗試閉合迴路

2、超時管控

API的超時控制是必須要做的，否則上游服務即便是間歇性響應緩慢也會堵塞大量執行緒（雖然通過訊號量隔離後不會導致整個閘道器執行緒堵塞）。

其次，每個API最好可以單獨配置超時時間，但不建議可以讓使用者隨意設定，還是要有個最大閾值。（API閘道器不適合需要長時間傳輸資料的場景，比如大檔案上傳或者下載、DB資料同步等）

實現上可以直接複用開源元件的功能，比如：HttpClient可以直接設定獲取連線和Socket響應的超時時間，Hystrix可以對整個呼叫進行超時控制等。

3、熔斷

熔斷類似電路中的保險絲，當超過負荷或者電阻被擊穿的時候自動斷開對裝置起到保護作用。在API閘道器中設定熔斷的目的是快速響應請求，避免不必要的等待，比如某個API後端服務正常情況下1s以內響應，但現在因為各種原因出現堵塞大部分請求20s才能響應，雖然設定了10s的超時控制，但讓請求執行緒等待10s超時不僅沒有意義，反而會增加服務提供方的負擔。

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

實現層面可以直接複用Hystrix。

執行時配置更新機制

前面章節提到過出於效能考慮閘道器在執行時要儘可能減小對DB的訪問，設計上可以將API、元件等關鍵內容進行快取，這樣一來效能是提升了，但也帶來了新的問題，比如Admin對API或者元件進行配置調整後如何及時更新到叢集的各個閘道器節點。

解決方案很多，比如引入訊息中介軟體，當Admin調整配置後就往訊息中心釋出一條訊息，各閘道器節點訂閱訊息，收到訊息後重新整理快取資料。

我們在具體實現過程中採用的是Zookeeper叢集資料同步機制，其實現原理跟訊息中介軟體很類似，只不過閘道器在啟動的時候就會向ZK節點進行註冊，也是被動更新機制。

效能考慮

效能是閘道器一項非常重要的衡量指標，尤其是響應時間，客戶端本來可以直連服務端的，現在增加了一個閘道器層，對於一個本身耗時幾百毫秒的服務接入閘道器後增加幾毫秒，影響倒是可以忽略不計；但如果服務本身只需要幾毫秒，因為接入閘道器再增加一倍的延時，使用者感受就會比較明顯。

建議在設計上需要遵循如下原則：

1、核心閘道器子系統必須是無狀態的，便於橫向擴充套件。

2、執行時不依賴本地儲存，儘量在記憶體裡面完成服務的處理和中轉。

3、減小對執行緒的依賴，採用非阻塞式IO和非同步事件響應機制。

4、後端服務如果是HTTP協議，儘量採用連線池或者Http2，測試連線複用和不復用效能有幾倍的差距。（TCP建立連線成本很高）

附-HttpClient連線池設定

PoolingHttpClientConnectionManager cmOfHttp = new PoolingHttpClientConnectionManager();
cmOfHttp.setMaxTotal(maxConn);
cmOfHttp.setDefaultMaxPerRoute(maxPerRoute);
httpClient = HttpClients.custom()
        .setConnectionManager(cmOfHttp)
        .setConnectionManagerShared(true)
        .build();

說明：

httpClient物件可以作為類的成員變數長期駐留記憶體，這個是連線池複用的前提。

結語

API閘道器作為企業API服務的匯聚中心，其良好的效能、穩定性和可擴充套件性是基礎，只有這個基礎打紮實了，我們才能在上面擴充套件更多的特性。

這篇文章主要介紹閘道器的總體架構設計， 後面的篇幅在詳細探討下各種元件的具體設計和實現。

有興趣的朋友可以加入QQ交流群：244054462，備註：API閘道器架構設計交流。

附-產品介紹