Choerodon 的微服務之路（二）：Choerodon 的微服務網關

本文是 Choerodon 豬齒魚微服務系列文章的第二篇。在《Choerodon的微服務之路(一)：如何邁出關鍵的第一步》中，我們瞭解到在微服務架構中，一個完整的單體應用被拆分成多個有着獨立部署能力的業務服務，每個服務可以使用不同的編程語言，不同的存儲介質，來保持最低限度的集中式管理。本篇將介紹Choerodon在搭建微服務網關時考慮的一些問題以及兩種常見的微服務網關。

▌文章的主要內容包括：

• 爲什麼要使用API Gateway
• 兩種Gateway 模式
• Choerodon 的網關

對於Choerodon 而言，前端通過ReactJs實現，後端服務則通過Java，GoLang等多種語言實現。我們通過將後端拆分成許多個單獨的業務服務，選擇不同的語言切實地幫助我們來實現系統功能，這種面向服務的模式給我們帶來了開發的便捷性，但是也帶來了新的問題。服務之間如何做到相互通信，前端與後端又是如何進行通信的，是我們需要去解決的問題。

回到微服務架構的領域，如果要解決基本的通信問題，基本上只要解決下面三個問題就可以了。

• 服務網絡通信能力
• 服務間的數據交互格式
• 服務間如何相互發現與調用

除了這些基本的問題以外，因爲整個Choerodon是一個分佈式的系統，開始時看似清晰的服務拆分，實則雜亂無章，有時候完成一個業務邏輯需要到不同的服務區調取接口，這是一件很痛苦的事，同時我們又不得不面對分佈式的一些問題。包括負載均衡，鏈路追蹤，限流，熔斷，鏈路加密，服務鑑權等等一大堆的問題。於是一個面向服務治理、服務編排的組件——微服務網關，是我們首要考慮的解決方案。

爲什麼要使用API Gateway

我們回到文章開始時的三個問題，我們來考慮如何解決服務間的通信。

▌爲什麼使用HTTP？

HTTP是互聯網上應用最爲廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），無論在哪種語言中幾乎都有原生的支持，即使沒有，也有第三方庫來支持。通過HTTP 減少網絡傳輸，來解決服務間網絡的通信問題。

▌爲什麼選擇JSON 作爲數據交互格式？

因爲 JSON 本身輕量、簡潔，不管是編寫，傳輸，還是解析都更加高效，而且相對來說，每個語言支持地都比較好。通過對JSON 的序列化和反序列化來實現網絡請求中的數據交互。

▌爲什麼使用K8S 來進行服務發現？

對於負載均衡而言，業內已經有多種成熟的解決方案了，也大多是通過DNS 的方式去發現服務。不論是使用硬件F5 來解決，或者軟件nginx，甚至Spring Cloud 也提供了對Eureka、Consul 等多種服務發現的支持。不過由於Choerodon 使用K8s 來作爲服務編排引擎，基於K8s Client 來實現服務發現則更符合我們的切實需求。

當然對於Choerodon 而言，我們需要的不僅僅是一個簡單的通信方式，而是一個完整的微服務解決方案。

API Gateway（API 網關）作爲微服務體系裏面的一部分，其需要解決的問題和 Choerodon 需要解決的問題非常類似。顧名思義，是企業 IT 在系統邊界上提供給外部訪問內部接口服務的統一入口。在微服務概念的流行之前，API網關的實體就已經誕生了，例如銀行、證券等領域常見的前置機系統，它也是解決訪問認證、報文轉換、訪問統計等問題的。

API 網關是一個服務器，是系統的唯一入口。從面向對象設計的角度看，它與 Facade 模式類似。API 網關封裝了系統內部架構，爲每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。

如果沒有 API 網關，大家可能想到的一貫做法是通過前端客戶端與後端服務直接通信。這樣會存在以下一些問題：

• 客戶端直連各個服務，耦合度太高
• 所有的服務接口都需要暴露給客戶端，會存在安全隱患
• 當服務增多時，後端服務對於客戶端而言則是一個噩夢
• 多次訪問不同的服務，請求數量過多，影響效率
• 權限、身份校驗等需要每個服務都實現，重複造輪子

Choerodon 通過使用 Spring Cloud Zuul，將所有的後端都通過統一的網關接入微服務體系中，並在網關層處理所有的非業務功能，同時提供統一的REST/HTTP 方式對外提供API。

單節點Gateway 模式

所謂的單節點Gateway 模式，也就是提供一個單一的Gateway 來支持不同的客戶端訪問。

這種模式下，大家會使用一個自定義 API 網關服務面對多個不同客戶端應用程序。其中最大的好處就是所有的請求都受統一網關的控制，實現簡單。對於請求的身份認證、負載均衡、監控等都可以在統一的網關中實現。

伴隨這一好處的同時，也會帶來一定的風險。因爲隨着後端服務的增多，網關的API 將針對不同客戶端發展，越來越多。同時，由於接口權限、身份驗證等都在網關中實現，統一網關也會變得越來越龐大，類似於一個單獨的應用程序或者單體應用。

除此之外，也會引入一個新的問題，即資源隔離的問題。假設後端的一個服務突然變慢，由於所有的請求都使用同一個網關入口，可能會將網關拖垮，進而影響到其他服務接口的訪問。

要解決這個問題，有兩種方式可以去解決，一種是做線程池的隔離，可以給一些重要的業務一些單獨的線程池，不重要的業務再放到一個大的單獨的線程池裏面。另一種就是給不同的業務設置不同的網關。

Spring Cloud 可以通過修改 ZUUL 和 hystrix 的配置，將信號量隔離修改爲線程池隔離，提高性能。

zuul:
  ribbonIsolationStrategy: THREAD

hystrix:
  command:
    default:
      execution:
        isolation:
          strategy: THREAD #hystrix隔離策略，默認爲THREAD
          thread:
            timeoutInMilliseconds: 20000 #hystrix超時時間
  threadpool:
    default:
      coreSize: 100 #併發執行的最大線程數
      maximumSize: 5000 #最大線程池大小
      allowMaximumSizeToDivergeFromCoreSize: true #允許maximumSize 配置生效
      maxQueueSize: -1 #設置最大隊列大小，爲-1時，使用SynchronousQueue

線程池隔離僅僅做到了線程池的隔離，但是 CPU 和 Memory 之類資源的隔離其實並沒有做。如果想要更加徹底的隔離方式，可以採用和線程池隔離類似的方式，給重要的服務用獨立的網關來爲其服務，不重要的服務，再給一個獨立的網關來服務。這也就是多節點的Gateway 模式。

多節點Gateway 模式

多節點的Gateway 模式本身是一種BFF架構，即爲不同的設備提供不同的API接口，引申而來，也可以按照不同的業務類型劃分爲多種業務場景下的網關。

上面這張圖顯示了一個簡化版本的多API 網關。在這種情況下，每個API 的邊界是基於BFF 模式，因此只提供每個客戶端應用所有要的API。

這種模式帶來的好處是根據不同顆粒度的API網關，在性能上能夠做到更精確的控制。但是在服務網關中可以完成一系列的橫切功能，例如權限校驗、限流以及監控等，則需要在每個網關中重複實現。代碼開發比較冗餘。

可以說，這兩種模式各有利弊，並不能單純的比較其好壞，而應該根據實際的業務場景來選擇適合自己的解決方案。

Choerodon 的網關

結合Choerodon 自身的核心業務，我們在不考慮多終端的情況下，最終選擇了單一網關，並在此基礎上，做了插件化的開發。

Choerodon 認爲，一個網關應該包含兩部分。

服務網關 = 路由轉發 + 過濾器

路由轉發：將外部的請求，轉發到對應的微服務上 過濾器：包含一系列非功能的橫切需求。例如權限校驗、限流、監控等

我們在API 網關中保留了Spring Cloud Zuul 的路由轉發，然後將權限校驗等抽離到一個叫做gateway-helper 的服務中。如下圖所示。

請求到達api-gateway 後，根據當前的HttpContext 上下文封裝一個RibbonCommandContext 對象，該對象將包含了請求轉發的gateway-helper 對應的信息。再由RibbonCommandFactory 根據RibbonCommandContext 對象生成一個RibbonCommand，由RibbonCommand 完成HTTP 請求的發送並的得到響應結果ClientHttpResponse。核心代碼如下:

// GateWayHelperFilter.java
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws ServletException, IOException {
    HttpServletRequest req = (HttpServletRequest) request;
    HttpServletResponse res = (HttpServletResponse) response;
    RibbonCommandContext commandContext = buildCommandContext(req);
    try (ClientHttpResponse clientHttpResponse = forward(commandContext)) {
        if (clientHttpResponse.getStatusCode().is2xxSuccessful()) {
            request.setAttribute(HEADER_JWT, clientHttpResponse.getHeaders().getFirst(HEADER_JWT));
            chain.doFilter(request, res);
        } else {
            setGatewayHelperFailureResponse(clientHttpResponse, res);
        }
    } catch (ZuulException e) {
        res.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
        res.setCharacterEncoding("utf-8");
        try (PrintWriter out = res.getWriter()) {
            out.println(e.getMessage());
            out.flush();
        }
    }
}

private RibbonCommandContext buildCommandContext(HttpServletRequest req) {
    Boolean retryable = gatewayHelperProperties.isRetryable();
    String verb = getVerb(req);
    MultiValueMap<String, String> headers = buildZuulRequestHeaders(req);
    MultiValueMap<String, String> params = buildZuulRequestQueryParams(req);
    InputStream requestEntity;
    long contentLength;
    String requestService = gatewayHelperProperties.getServiceId();
    requestEntity = new ByteArrayInputStream("".getBytes());
    contentLength = 0L;
    return new RibbonCommandContext(requestService, verb, req.getRequestURI(), retryable,
            headers, params, requestEntity, this.requestCustomizers, contentLength);
}

private ClientHttpResponse forward(RibbonCommandContext context) throws ZuulException {
    RibbonCommand command = this.ribbonCommandFactory.create(context);
    try {
        return command.execute();
    } catch (HystrixRuntimeException ex) {
        throw new ZuulException(ex, "Forwarding gateway helper error", 500, ex.getMessage());
    }
}

可以看到，我們在api-gateway 服務中完成了對請求的首次轉發。請求到達gateway-helper。在gateway-helper 中，針對配置進行判斷，如果有自定義的helper，則會重定向到自定義的helper 上進行後續的處理。否則的話按照默認的邏輯進行權限校驗。核心代碼如下:

// RequestRootFilter.java
public boolean filter(final HttpServletRequest request) {
    String uri = RequestRibbonForwardUtils.buildZuulRequestUri(request);
    String service = RequestRibbonForwardUtils.getHelperServiceByUri(helperZuulRoutesProperties, uri);
    if (StringUtils.isEmpty(service)) {
        return requestPermissionFilter.permission(request) && requestRatelimitFilter.through(request);
    }
    return customGatewayHelperFilter(request, service, uri);
}

private boolean customGatewayHelperFilter(final HttpServletRequest request, final String service, final String uri) {
    ClientHttpResponse clientHttpResponse = null;
    try {
        RibbonCommandContext commandContext = RequestRibbonForwardUtils.buildCommandContext(request, requestCustomizers, service, uri);
        clientHttpResponse = RequestRibbonForwardUtils.forward(commandContext, ribbonCommandFactory);
        return clientHttpResponse.getStatusCode().is2xxSuccessful();
    } catch (Exception e) {
        LOGGER.warn("error.customGatewayHelperFilter");
        return false;
    } finally {
        if (clientHttpResponse != null) {
            clientHttpResponse.close();
        }
    }
}   

在RequestPermissionFilter 中，我們對請求進行權限校驗，來判斷該用戶是否有對應資源的操作權限。核心代碼如下：

//RequestPermissionFilterImpl.java
public boolean permission(final HttpServletRequest request) {
    if (!permissionProperties.isEnabled()) {
        return true;
    }
    //如果是文件上傳的url，以/zuul/開否，則去除了/zuul再進行校驗權限
    String requestURI = request.getRequestURI();
    if (requestURI.startsWith(ZUUL_SERVLET_PATH)) {
        requestURI = requestURI.substring(5, requestURI.length());
    }
    //skipPath直接返回true
    for (String skipPath : permissionProperties.getSkipPaths()) {
        if (matcher.match(skipPath, requestURI)) {
            return true;
        }
    }
    //如果獲取不到該服務的路由信息，則不允許通過
    ZuulRoute route = ZuulPathUtils.getRoute(requestURI, helperZuulRoutesProperties.getRoutes());
    if (route == null) {
        LOGGER.info("error.permissionVerifier.permission, can't find request service route, "
                + "request uri {}, zuulRoutes {}", request.getRequestURI(), helperZuulRoutesProperties.getRoutes());
        return false;
    }
    String requestTruePath = ZuulPathUtils.getRequestTruePath(requestURI, route.getPath());
    final RequestInfo requestInfo = new RequestInfo(requestURI, requestTruePath,
            route.getServiceId(), request.getMethod());
    final CustomUserDetails details = DetailsHelper.getUserDetails();
    //如果是超級管理員用戶，且接口非內部接口，則跳過權限校驗
    if (details != null && details.getAdmin() != null && details.getAdmin()) {
        return passWithinPermissionBySql(requestInfo);
    }
    //判斷是不是public接口獲取loginAccess接口
    if (passPublicOrLoginAccessPermissionByMap(requestInfo, details)
            || passPublicOrLoginAccessPermissionBySql(requestInfo, details)) {
        return true;
    }
    if (details == null || details.getUserId() == null) {
        LOGGER.info("error.permissionVerifier.permission, can't find userDetail {}", requestInfo);
        return false;
    }
    //其他接口權限權限審查
    if (passSourcePermission(requestInfo, details.getUserId())) {
        return true;
    }
    LOGGER.info("error.permissionVerifier.permission when passSourcePermission {}", requestInfo);
    return false;
}

通過上述的代碼片段可以看到。在Choerodon 中，可以自主實現自己的geteway-helper，來對請求進行更復雜的控制。

Choerodon 支持在頁面上對路由信息進行配置和修改，控制路由的動態調整。如下圖所示。

以看到，通過頁面對路由進行修改後，路由動態更新到 api-gateway及gateway-heler。通過配置中心實時生效，避免了修改代碼重新部署帶來的麻煩。

總結

回顧一下這篇文章，我們介紹了Choerodon 在搭建微服務網關時考慮的一些問題以及兩種常見的微服務網關，並且通過代碼介紹了Choerodon 的網關時如何實現的。這些都是我們實踐過程中的一些做法和體會，希望大家可以結合自己的業務來參考。

更多關於微服務系列的文章，歡迎點擊閱讀 ▼

• Choerodon的微服務之路(一)：如何邁出關鍵的第一步
• 視角 | 微服務的數據一致性解決方案

關於Choerodon豬齒魚

Choerodon豬齒魚是一個開源企業服務平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件，致力幫助企業聚焦於業務，加速數字化轉型。

大家也可以通過以下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：http://choerodon.io
• 論壇：http://forum.choerodon.io
• Github：https://github.com/choerodon
• 微信：Choerodon豬齒魚
• 微博：Choerodon豬齒魚

歡迎加入Choerodon豬齒魚社區，共同爲企業數字化服務打造一個開放的生態平臺。