原薦 Choerodon 的微服務之路（二）：Choerodon 的微服務閘道器

閘道器微服務 · 發表 2018-10-29 15:28:30

摘要：本文是 Choerodon 豬齒魚微服務系列文章的第二篇。在《Choerodon的微服務之路(一)：如何邁出關鍵的第一步》中，我們瞭解到在微服務架構中，一個完整的單體應用被拆分成多個有著獨立部署能力的業務服務，每個服務可以使用不同的程式語言，不同的儲存介質，來保持最低限度的集中式管理。本...

本文是 Choerodon 豬齒魚微服務系列文章的第二篇。在 ofollow,noindex" target="_blank">《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豬齒魚是一個開源企業服務平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、資料、智慧洞察、企業應用市場等業務元件，致力幫助企業聚焦於業務，加速數字化轉型。

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

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

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

原 薦 Choerodon 的微服務之路（二）：Choerodon 的微服務閘道器