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

時間 2020-04-01

標籤 choerodon 微服之路網關简体版

原文原文鏈接

咱們瞭解到在微服務架構中，一個完整的單體應用被拆分紅多個有着獨立部署能力的業務服務，每一個服務可使用不一樣的編程語言，不一樣的存儲介質，來保持最低限度的集中式管理。本篇將介紹Choerodon在搭建微服務網關時考慮的一些問題以及兩種常見的微服務網關。前端

▌文章的主要內容包括：java

爲何要使用API Gateway
兩種Gateway 模式
Choerodon 的網關

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

回到微服務架構的領域，若是要解決基本的通訊問題，基本上只要解決下面三個問題就能夠了。git

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

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

爲何要使用API Gateway

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

▌爲何使用HTTP？後端

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

▌爲何選擇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 豬齒魚做爲開源多雲應用敏捷全鏈路技術平臺，是基於開源技術Kubernetes，Istio，knative，Gitlab，Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺經過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

更加詳細的內容，請參閱Release Notes和官網。

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

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