我們了解到在微服務架構中，一個完整的單體應用被拆分成多個有著獨立部署能力的業務服務，每個服務可以使用不同的編程語言，不同的存盤介質，來保持最低限度的集中式管理，本篇將介紹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 的網關時如何實作的，這些都是我們實踐程序中的一些做法和體會，希望大家可以結合自己的業務來參考，
本文由豬齒魚技術團隊原創，轉載請注明出處
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/390276.html
標籤：其他