我們了解到在微服務架構中，一個完整的單體應用被拆分成多個有着獨立部署能力的業務服務，每個服務可以使用不同的編程語言，不同的存儲介質，來保持最低限度的集中式管理。本篇將介紹Choerodon在搭建微服務網關時考慮的一些問題以及兩種常見的微服務網關。
▌文章的主要內容包括：
* 為什么要使用API Gateway
* 兩種Gateway 模式
* 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 的網關時如何實現的。這些都是我們實踐過程中的一些做法和體會，希望大家可以結合自己的業務來參考。
本文由豬齒魚技術團隊原創，轉載請注明出處