引言
在參與電商工作第一年,我從事客戶端開發工作。雖然團隊規模不大,但是對接的中間層團隊人數,卻相當於團隊近四分之一的規模。工作第四年,我又加入國內一家知名的電商公司。這家公司的主要業務形態是特賣,中間層團隊佔團隊的人數近三分之一。而現在,我所帶領的團隊,在發展初期,中間層團隊也是接近這個規模。
三個團隊都是電商團隊,用戶規模較大,在併發上要求較高,並且採用微服務架構,由中臺底層提供各種電商服務(如訂單、庫存)和通用服務(如搜索),所以中間層團隊需要經過各種授權和認證調用各個BU的服務,從而組裝出前端適配的接口。因爲對C端業務的接口繁多,所以中間層佔用着團隊寶貴的人力資源。而且團隊成立時間越久,累積的接口越多,管理如此繁多的接口是一個令人頭疼的問題。
中間層的問題
1.開發調試問題
中間層在Web網站上的部署偏前,一般部署於防火牆及Nginx之後,更多面向C端用戶服務,所以在性能併發量上有較高要求,大部分團隊在選型上會選擇異步框架。正因爲其直接面向C端,變化較多,大部分需要經常性地變更或者配置的代碼都會安排在這一層次,發佈非常頻繁。此外,很多團隊使用編譯型語言進行編碼,而非解釋型語言。這三個因素組合在一起,使得開發者調試與開發非常痛苦。
比如,我們曾經選擇Play2框架,這是一個異步Java框架,需要開發者能夠流暢地編寫異步,但是熟悉調試技巧的同事也不多。在代碼裏面配置了各種請求參數,以及結果處理,看似非常簡單,但是聯調、單元測試、或者配置文件修改之後等待Java編譯花費的時間和精力是巨大的。如果異步編碼規範也有問題,這對開發者來說無疑是一種折磨。
public F.Promise<BaseDto<List<Good>>> getGoodsByCondi(final StringBuilder searchParams, final GoodsQueryParam param) {
final Map<String, String> params = new TreeMap<String, String>();
final OutboundApiKey apiKey = OutboundApiKeyUtils.getApiKey("search.api");
params.put("apiKey", apiKey.getApiKey());
params.put("service", "Search.getMerchandiseBy");
if(StringUtils.isNotBlank(param.getSizeName())){
try {
searchParams.append("sizes:" + URLEncoder.encode(param.getSizeName(), "utf-8") + ";");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
}
if (param.getStock() != null) {
searchParams.append("hasStock:" + param.getStock() + ";");
}
if (param.getSort() != null && !param.getSort().isEmpty()) {
searchParams.append("orderBy:" + param.getSort() + ";");
}
searchParams.append("limit:" + param.getLimit() + ";page:" + param.getStart());
params.put("traceId", "open.api.vip.com");
ApiKeySignUtil.getApiSignMap(params,apiKey.getApiSecret(),"apiSign");
String url = RemoteServiceUrl.SEARCH_API_URL;
Promise<HttpResponse> promise = HttpInvoker.get(url, params);
final GoodListBaseDto retVal = new GoodListBaseDto();
Promise<BaseDto<List<Good>>> goodListPromise = promise.map(new Function<HttpResponse, BaseDto<List<Good>>>() {
@Override
public BaseDto<List<Good>> apply(HttpResponse httpResponse)throws Throwable {
JsonNode json = JsonUtil.toJsonNode(httpResponse.getBody());
if (json.get("code").asInt() != 200) {
Logger.error("Error :" + httpResponse.getBody());
return new BaseDto<List<Good>>(CommonError.SYS_ERROR);
}
JsonNode result = json.get("items");
Iterator<JsonNode> iterator = result.elements();
final List<Good> goods = new ArrayList<Good>();
while (iterator.hasNext()) {
final Good good = new Good();
JsonNode goodJson = iterator.next();
good.setGid(goodJson.get("id").asText());
good.setDiscount(String.format("%.2f", goodJson.get("discount").asDouble()));
good.setAgio(goodJson.get("setAgio").asText());
if (goodJson.get("brandStoreSn") != null) {
good.setBrandStoreSn(goodJson.get("brandStoreSn").asText());
}
Iterator<JsonNode> whIter = goodJson.get("warehouses").elements();
while (whIter.hasNext()) {
good.getWarehouses().add(whIter.next().asText());
}
if (goodJson.get("saleOut").asInt() == 1) {
good.setSaleOut(true);
} good.setVipPrice(goodJson.get("vipPrice").asText());
goods.add(good);
}
retVal.setData(goods);
return retVal;
}
});
if(param.getBrandId() != null && !param.getBrandId().isEmpty()))){
final Promise<List<ActiveTip>> pmsPromise = service.getActiveTipsByBrand(param.getBrandId());
return goodListPromise.flatMap(new Function<BaseDto<List<Good>>, Promise<BaseDto<List<Good>>>>() {
@Override
public Promise<BaseDto<List<Good>>> apply(BaseDto<List<Good>> listBaseDto) throws Throwable {
return pmsPromise.flatMap(new Function<List<ActiveTip>, Promise<BaseDto<List<Good>>>>() {
@Override
public Promise<BaseDto<List<Good>>> apply(List<ActiveTip> activeTips) throws Throwable {
retVal.setPmsList(activeTips);
BaseDto<List<Good>> baseDto = (BaseDto<List<Good>>)retVal;
return Promise.pure(baseDto);
}
});
}
});
}
return goodListPromise;
}
上述代碼只是摘抄了其中一個過程函數。如果我們將中間層的場景設置得更爲複雜一些,我們要解決的就不僅僅是編碼性能、編碼質量、編碼時間的問題。
2.“複雜”場景問題
微服務顆粒度較細,爲了實現簡潔的前端邏輯以及較少的服務調用次數,我們針對C端的大部分輸出是聚合的結果。比如,我們一個搜索的中間層邏輯,其服務是這樣一個過程:
- 獲取會員信息、會員卡列表、會員積分餘額,因爲不同級別的會員會有不同價格;
- 獲取用戶的優惠券信息,這部分會對計算出來的價格產生影響;
- 獲取搜索的結果信息,結果來自三部分,商旅商品的庫存價格,猜你喜歡的庫存價格,推薦位的庫存價格,海外商品的庫存價格。
這其中涉及到的服務有:中間層服務(聚合服務)、會員服務、優惠券服務、推薦服務、企業服務、海外搜索服務、搜索服務。此外,還有各種類型的緩存設施以及數據庫的配置服務。
public List<ExtenalProduct> searchProduct(String traceId, ExtenalProductQueryParam param, MemberAssetVO memberAssetVO, ProductInfoResultVO resultVO,boolean needAddPrice) {
// 用戶可用優惠券的configId
String configIds = memberAssetVO == null ? null : memberAssetVO.getConfigIds();
// 特殊項目,限制不能使用優惠券功能
if(customProperties.getIgnoreChannel().contains(param.getChannelCode())) {
configIds = null;
}
final String configIdConstant = configIds;
// 主搜索列表信息
Mono<List<ExtenalProduct>> innInfos = this.search(traceId, param, configIds, resultVO);
return innInfos.flatMap(inns -> {
// 商旅產品推薦
Mono<ExtenalProduct> busiProduct = this.recommendProductService.getBusiProduct(traceId, param, configIdConstant);
// 會員產品推薦(猜您喜歡)
Mono<ExtenalProduct> guessPref = this.recommendProductService.getGuessPref(traceId, param, configIdConstant);
// 業務相關查詢
String registChainId = memberAssetVO == null || memberAssetVO.getMember() == null ? null : memberAssetVO.getMember().getRegistChainId();
Mono<ExtenalProduct> registChain = this.recommendProductService.registChain(traceId, param, configIdConstant, registChainId);
// 店長熱推產品
Mono<ExtenalProduct> advert = this.recommendProductService.advert(traceId, param, configIdConstant);
return Mono.zip(busiProduct, guessPref, registChain, advert).flatMap(product -> {
// 推薦位(廣告位)包裝
List<ExtenalProduct> products = recommendProductService.setRecommend(inns, product.getT1(), product.getT2(), product.getT3(), product.getT4(), param);
// 設置其他參數
return this.setOtherParam(traceId, param, products, memberAssetVO);
});
}).block();
}
這個服務的Service層會經常性地根據產品需求和底層微服務接口的變更做出調整改變,而研發的接口調用時序圖卻因爲團隊的這些更改對應不上代碼。
除了上述問題外,該服務中的多個微服務異步調用聚合的編碼問題也未能被妥善處理,因爲其使用的Spring-MVC框架編碼風格是同步的,而Service層卻使用了異步的Mono,只能不合時宜地用block。這些代碼更改、文檔缺失、編碼質量共同組成了中間層的代碼管理問題。
3.野蠻發展問題
我參與過一個初創技術團隊建設。最開始,因爲快速開發的需要,我們傾向於做一個胖服務,但當團隊規模開始擴大時,我們卻需要逐步地將胖服務分拆爲微服務,開始產生中間層團隊,他們的主要目的是應用於底層服務的聚合。
但是,有一段時間,我們的招聘速度並不能完全趕上服務數量的增長速度,於是寫底層的同事就需要不斷地切換編碼思路。因爲除了要編寫分拆之後的底層微服務,還要編寫聚合的中間層服務。
當我停掉某一些項目時,開始整頓人手,我又發現一個殘酷事實:每個人手上都有數十個中間層服務,因此無法換掉任何一個人。因爲經過多次地換手,同事們已經搞不清中間服務的聯繫。
另外,還有各種授權方式,因爲團隊一直以來的野蠻成長,各種授權方式都混在一起,既有簡單的,又有複雜的,既有合理的,還有不合理的。總之,團隊沒有人能搞清楚。
經過一段時間的發展後,通過整理線上服務,我們發現很多資源浪費,比如有時候,僅僅一個接口就使用了一個微服務。在早起,這些微服務是有較大規模請求的,但是後來,項目被遺棄,也沒有了流量,但是運行的接口依然在線上。而作爲團隊管理人員的我甚至沒有任何書面上接口彙總的統計信息。
當老闆告訴我,把合作公司對接的服務暫停時,我無法做到邏輯上停機返回一個業務異常。作爲一個多渠道發展的上游庫存供應商,我們對接的渠道很多,提供給客戶的接口有很多特別定製的需求,這些需求一般就在中間的邏輯控制代碼裏面,渠道下線了,也不會做任何調整,因爲開發者需要根據需求來進行代碼更新。
而且,中間層團隊對外聯合調試也是長久以來存在的一個問題。經常有前端同事向我抱怨,後端的同事不肯增加數據處理邏輯的代碼,而作爲前端,他們不得不增加很多轉換數據的代碼來適配界面的邏輯。而像在小程序這種的對包大小進行限制的環境裏,這些代碼的移動在發展後期就成爲一個老大難問題。
網關的選型失敗
當時,市面上存在兩種類型的解決方案:
-
中間層的解決方案。中間層方案一般提供裸異步服務、其他插件以及功能根據需求自定義,部分中間層的服務經過改造後也具備網關的部分功能。
-
網關的解決方案。網關方案一般圍繞着微服務全家桶提供,或者自成一派,提供通用型的功能(如路由功能)。當然,部分網關經過自定義改造也能加入中間層的業務功能。
我們的業務發展變化非常快。如果市面上已有的網關方案能滿足需求,我們又有能力進行二次開發,我們非常樂意使用。
當時,Eolinker是我們的API 自動測試的供應商,提供了對應的管理型網關,但語言是Go。而我們團隊的技術棧主要以Java爲主,運維的部署方案也一直圍繞着Java,這意味我們的選型就偏窄,因此不得不放棄這一想法。
在之前,我們也選擇過Kong網關,但是引入一個新的複雜技術棧是一件成本不低的事情,比如,Lua的招聘與二次開發是難以避免的痛。
另外,Gravitee、Zuul、Vert.x 都是不同小規模團隊使用過的網關。談及最多的特性是:
-
支持熔斷、流量控制和過載保護
-
支持特別高的併發
-
秒殺
然而,對業務來說,熔斷、流量控制和過載保護應該是最後考慮的措施。而且,對一個成長中的團隊來說,服務的過載崩潰是需要經歷較長時間的業務沉澱。
另外,秒殺業務的流量更多是維持一個普通水平,其偶爾的高併發也是在我們團隊處理能力範圍之內。換句話說,選型時,更多的是需要結合實際,而不是考慮類似阿里巴巴的流量,我只需考慮中等水平以上並且具備集羣擴展性的方式即可。
此前,我們團隊使用比較廣的網關是Vert.x,編碼風格是這樣的,華麗酷炫。
private void dispatchRequests(RoutingContext context) {
int initialOffset = 5; // length of `/api/`
// run with circuit breaker in order to deal with failure
circuitBreaker.execute(future -> { // (1)
getAllEndpoints().setHandler(ar -> { // (2)
if (ar.succeeded()) {
List<Record> recordList = ar.result();
// get relative path and retrieve prefix to dispatch client
String path = context.request().uri();
if (path.length() <= initialOffset) {
notFound(context);
future.complete();
return;
}
String prefix = (path.substring(initialOffset)
.split("/"))[0];
// generate new relative path
String newPath = path.substring(initialOffset + prefix.length());
// get one relevant HTTP client, may not exist
Optional<Record> client = recordList.stream()
.filter(record -> record.getMetadata().getString("api.name") != null)
.filter(record -> record.getMetadata().getString("api.name").equals(prefix)) // (3)
.findAny(); // (4) simple load balance
if (client.isPresent()) {
doDispatch(context, newPath, discovery.getReference(client.get()).get(), future); // (5)
} else {
notFound(context); // (6)
future.complete();
}
} else {
future.fail(ar.cause());
}
});
}).setHandler(ar -> {
if (ar.failed()) {
badGateway(ar.cause(), context); // (7)
}
});
}
但是,Vert.x社區缺乏支持以及入門成本高的問題一直存在,而團隊甚至找不到更多合適的同事來維護代碼。
以上網關的選型失敗讓我們意識到,市面沒有完全符合我們公司的情況的“瑞士軍刀”,由此我們開始走上了自研之路,開始進行Fizz網關的設計。
走上自研網關之路
我們需要網關麼?網關層解決什麼問題?這兩個問題不言而喻。我們需要網關,因爲它可以幫我們解決負載均衡、聚合、授權、監控、限流、日誌、權限控制等一系列的問題。同時,我們也需要中間層,細化服務顆粒度的微服務讓我們不得不通過中間層聚合它們。
而我們不需要的是複雜的編碼、冗餘的膠水代碼,以及冗長的發佈流程。
Fizz的設計考量
爲解決這些問題,我們需要讓網關與中間層模糊界限,抹去網關和中間層隔閡,讓網關支持中間層動態編碼,儘可能少的發佈部署。爲實現這個目的,只需要用一個簡潔的網關模型並同時利用low-code特性儘可能地去覆蓋中間層的功能即可。
從原點出發的需求
在覆盤當初這個選擇時,我需要再強調下從原點出發的需求:
- Java技術棧,支持Spring全家桶;
- 方便易用,零培訓也能編排;
- 動態路由能力,隨時隨地能夠開啓新API;
- 高性能且集羣可橫向擴展;
- 強熱服務編排能力,支持前後端編碼,隨時隨地更新API;
- 線上編碼邏輯支持;
- 可擴展的安全認證能力,方便日誌記錄;
- API審覈功能,把控所有服務;
- 可擴展性,強大的插件開發機制;
Fizz 的技術選型
在選型Spring WebFlux後,因爲其單體較強的特性,同事建議命名爲Fizz(Fizz是競技遊戲《英雄聯盟》中的英雄角色之一,它是一個近戰法師,其擁有AP中數一數二的單體爆發,因此可以剋制大部分法師,可以作爲一個很好地反制英雄使用)。
WebFlux是一個典型非阻塞異步的框架,它的核心是基於Reactor的相關API實現的。 相對於傳統的web框架來說,它可以運行在諸如Netty、Undertow和支持Servlet3.1的容器上,因此它運行環境的可選擇性要比傳統web框架多很多。
而Spring WebFlux 是一個異步非阻塞式的 Web 框架,它能夠充分利用多核 CPU 的硬件資源去處理大量的併發請求。其依賴Spring的技術棧,代碼風格是這樣的:
public Mono<ServerResponse> getAll(ServerRequest serverRequest) {
printlnThread("獲取所有用戶");
Flux<User> userFlux = Flux.fromStream(userRepository.getUsers().entrySet().stream().map(Map.Entry::getValue));
return ServerResponse.ok()
.body(userFlux, User.class);
}
Fizz的核心實現
對我們而言,這是一個從零開始的項目,很多同事剛開始沒有信心。我爲這個服務寫了第一個服務編排代碼的核心包fizz,並把這個commit寫爲“開工大吉”。
我打算所有的服務聚合的定義就靠一個配置文件解決。那麼,就有這樣的模型:如果把用戶請求作爲輸入,那麼響應自然就是輸出,這就是一個管道Pipe;在一個Pipe中,會有不同的Step,對應不同的串聯的步驟;而在一個Step,至少有一個存在着一個Input接收上一個步驟處理的輸出,所有的Input都是並聯的,並且可以並行執行;貫穿於Pipe的生命週期中存在唯一的Context保存中間上下文。
而在每個Input的輸入與輸出,我增加了動態腳本的擴展能力,到現在已經支持JavaScript和groove兩種能力,支持JavaScript的前端邏輯可以在後端得到必要擴展。而我們的配置文件僅僅需要這樣一個腳本:
// 聚合接口配置
var aggrAPIConfig = {
name: "input name", // 自定義的聚合接口名
debug: false, // 是否爲調試模式,默認false
type: "REQUEST", // 類型,REQUEST/MYSQL
method: "GET/POST",
path: "/proxy/aggr-hotel/hotel/rates", // 格式:/aggr/+服務名+路徑, 分組名以aggr-開頭,表示聚合接口
langDef: { // 可選,提示語言定義,入參驗證失敗時依據配置提供不同語言的提示信息,目前支持中文、英文
langParam: "input.request.body.languageCode", // 入參語言字段
langMapping: { // 字段值與語言的映射關係
zh: "0", // 中文
en: "1" // 英文
}
},
headersDef: { // 可選,定義聚合接口header部分參數,使用JSON Schema規範(詳見:http://json-schema.org/specification.html),用於參數驗證,接口文檔生成
type:"object",
properties:{
appId:{
type:"string",
title:"應用ID",
description:"描述"
}
},
required: ["appId"]
},
paramsDef: { // 可選,定義聚合接口parameter部分參數,使用JSON Schema規範(詳見:http://json-schema.org/specification.html),用於參數驗證,接口文檔生成
type:"object",
properties:{
lang:{
type:"string",
title:"語言",
description:"描述"
}
}
},
bodyDef: { // 可選,定義聚合接口body部分參數,使用JSON Schema規範(詳見:http://json-schema.org/specification.html),用於參數驗證,接口文檔生成
type:"object",
properties:{
userId:{
type:"string",
title:"用戶名",
description:"描述"
}
},
required: ["userId"]
},
scriptValidate: { // 可選,用於headersDef、paramsDef、bodyDef無法覆蓋的入參驗證場景
type: "", // groovy
source: "" // 腳本返回List<String>對象,null:驗證通過,List:錯誤信息列表
},
validateResponse:{// 入參驗證失敗響應,處理方式同dataMapping.response
fixedBody: { // 固定的body
"code": -411
},
fixedHeaders: {// 固定header
"a":"b"
},
headers: { // 引用的header
},
body: { // 引用的header
"msg": "validateMsg"
},
script: {
type: "", // groovy
source: ""
}
},
dataMapping: {// 聚合接口數據轉換規則
response:{
fixedBody: { // 固定的body
"code":"b"
},
fixedHeaders: {// 固定header
"a":"b"
},
headers: { // 引用的header,默認爲源數據類型,如果要轉換類型則以目標類型+空格開頭,如:"int "
"abc": "int step1.requests.request1.headers.xyz"
},
body: { // 引用的header,默認爲源數據類型,如果要轉換類型則以目標類型+空格開頭,如:"int "
"abc": "int step1.requests.request1.response.id",
"inn.innName": "step1.requests.request2.response.hotelName",
"ddd": { // 腳本, 當腳本的返回對象裏包含有_stopAndResponse字段且值爲true時,會終請求並把腳本的返回結果響應給瀏覽器
"type": "groovy",
"source": ""
}
},
script: { // 腳本計算body的值
type: "", // groovy
source: ""
}
}
},
stepConfigs: [{ // step的配置
name: "step1", // 步驟名稱
stop: false, // 是否在執行完當前step就返回
dataMapping: {// step response數據轉換規則
response: {
fixedBody: { // 固定的body
"a":"b"
},
body: { // step result
"abc": "step1.requests.request1.response.id",
"inn.innName": "step1.requests.request2.response.hotelName"
},
script: {// 腳本計算body的值
type: "", // groovy
source: ""
}
}
},
requests:[ //每個step•可以調用多個接口
{ // 自定義的接口名
name: "request1", // 接口名,格式request+N
type: "REQUEST", // 類型,REQUEST/MYSQL
url: "", // 默認url,當環境url爲null時使用
devUrl: "http://baidu.com", //
testUrl: "http://baidu.com", //
preUrl: "http://baidu.com", //
prodUrl: "http://baidu.com", //
method: "GET", // GET/POST, default GET
timeout: 3000, // 超時時間 單位毫秒,允許1-10000秒之間的值,不填或小於1毫秒取默認值3秒,大於10秒取10秒
condition: {
type: "", // groovy
source: "return \"ABC\".equals(variables.get(\"param1\")) && variables.get(\"param2\") >= 10;" // 腳本執行結果返回TRUE執行該接口調用,FALSE不執行
},
fallback: {
mode: "stop|continue", // 當請求失敗時是否繼續執行
defaultResult: "" // 當mode=continue時,可設置默認的響應報文(json string)
},
dataMapping: { // 數據轉換規則
request:{
fixedBody: {
},
fixedHeaders: {
},
fixedParams: {
},
headers: {//默認爲源數據類型,如果要轉換類型則以目標類型+空格開頭,如:"int "
"abc": "step1.requests.request1.headers.xyz"
},
body:{
"*": "input.request.body.*", // * 用於透傳一個json對象
"inn.innId": "int step1.requests.request1.response.id" // 默認爲源數據類型,如果要轉換類型則以目標類型+空格開頭,如:"int "
},
params:{//默認爲源數據類型,如果要轉換類型則以目標類型+空格開頭,如:"int "
"userId": "input.requestBody.userId"
},
script: {// 腳本計算body的值
type: "", // groovy
source: ""
}
},
response: {
fixedBody: {
},
fixedHeaders: {
},
headers: {
"abc": "step1.requests.request1.headers.xyz"
},
body:{
"inn.innId": "step1.requests.request1.response.id"
},
script: {// 腳本計算body的值
//type: "", // groovy
source: ""
}
}
}
}
]
}]
}
運行的上下文格式爲:
// 運行時上下文,用於保存客戶輸入和每個步驟的輸入與輸出結果
var stepContext = {
// 是否DEBUG模式
debug:false,
// elapsed time
elapsedTimes: [{
[actionName]: 123, // 操作名稱:耗時
}],
// input data
input: {
request:{
path: "",
method: "GET/POST",
headers: {},
body: {},
params: {}
},
response: { // 聚合接口的響應
headers: {},
body: {}
}
},
// step name
stepName: {
// step request data
requests: {
request1: {
request:{
url: "",
method: "GET/POST",
headers: {},
body: {}
},
response: {
headers: {},
body: {}
}
},
request2: {
request:{
url: "",
method: "GET/POST",
headers: {},
body: {}
},
response: {
headers: {},
body: {}
}
}
//...
},
// step result
result: {}
}
}
當我把Input從僅僅看成一個輸入以及輸出,加上數據處理的中間過程,那麼,它就具備了很大的擴展可能性。比如,在代碼中,我們甚至可以編寫一個MysqlInput的類,其擴展Input
public class MySQLInput extends Input {
}
其僅僅需要定義Input的少量類方法,就能支持MySQL的輸入,甚至與動態解析MySQL腳本,並且做數據解析變換。
public class Input {
protected String name;
protected InputConfig config;
protected InputContext inputContext;
protected StepResponse lastStepResponse = null;
protected StepResponse stepResponse;
public void setConfig(InputConfig inputConfig) {
config = inputConfig;
}
public InputConfig getConfig() {
return config;
}
public void beforeRun(InputContext context) {
this.inputContext = context;
}
public String getName() {
if (name == null) {
return name = "input" + (int)(Math.random()*100);
}
return name;
}
/**
* 檢查該Input是否需要運行,默認都運行
* @stepContext Step上下文
* @return TRUE:運行
*/
public boolean needRun(StepContext<String, Object> stepContext) {
return Boolean.TRUE;
}
public Mono<Map> run() {
return null;
}
public void setName(String configName) {
this.name = configName;
}
public StepResponse getStepResponse() {
return stepResponse;
}
public void setStepResponse(StepResponse stepResponse) {
this.stepResponse = stepResponse;
}
}
而擴展編碼的內容並不會涉及異步處理問題。這樣,Fizz已經較爲友好地處理了異步邏輯。
Fizz的服務編排
可視化的後臺可以進行Fizz的服務編排功能,雖然以上的核心代碼並不是很複雜,但是其已經足夠將我們整個步驟抽象化。
現在,可視化的界面通過fizz-manager只需要生成對應的配置文件,並且讓其可以快速地更新加載即可。通過定義的Request Input中的請求頭、請求體和Query參數,以及校驗規則或者自定義腳本實現複雜的邏輯校驗,在定義其Fallback,我們實現了一個Request Input,通過一些的Step組裝,最終一個經過線上編排的服務就能實時投入使用。如果是隻讀接口,甚至我們建議直接在線實時測試,當然支持測試接口和正式接口隔離,支持返回上下文,可以查看整個執行過程中各個步驟和請求的輸入與輸出。
Fizz的腳本驗證
當內置的腳本驗證方式不足夠覆蓋場景時,Fizz還提供更靈活的腳本編程。
// javascript腳本函數名不能修改
function dyFunc(paramsJsonStr) {
// 上下文, 數據結構請參考 context.js
var context = JSON.parse(paramsJsonStr)['context'];
// common爲內置的上下文便捷操作工具類,詳情請參考common.js;例如:
// var data = common.getStepRespBody(context, 'step2', 'request1', 'data');
// do something
// 自定義•返回結果,如果返回的Object裏含有_stopAndResponse=true字段時將會終止請求並把腳本結果響應給客戶端(主要用於有異常情況要終止請求的場景)
var result = {
// _stopAndResponse: true,
msgCode: '0',
message: '',
data: null
};
// 返回結果爲Array或Object時要先轉爲json字符串
return JSON.stringify(result);
}
Fizz的數據處理
Fizz具備對請求的輸入和輸出進行數據變換的能力,它充分利用了json path的特性通過加載配置文件的定義對Input的輸入以及輸出進行變化以便得到合理結果。
Fizz的強大路由
Fizz的動態路由功能也設計得較爲實用。它有一套平滑替換網關的方案。在最初,Fizz是可以跟其他網關並存的,比如之前提到的基於Vert.x的網關。所以,Fizz就有一個類似Nginx的反向代理方案,純粹基於路由的實現。於是,在項目初期,通過Nginx的流量被原原本本的轉發到Fizz,然後再到Vert.x,其代理了Vert.x全部流量。之後,流量被逐步轉發到後端的微服務,Vert.x上有一部分特別定製的公用代碼被下沉到底層微服務端,Vert.x還有中間層服務被完全廢棄,服務器的數量減少50%。在我們做完調整後,原先困擾我的中間層人員以及服務器的問題終於得到解決,我們可以縮減每個同事手中的那一串服務列表清單,將工作落到更有價值的項目上去。當這一切變得清晰時,這個項目也就自然而然顯示了它的價值。
針對渠道,這裏的路由功能也有非常實用的功能。因爲Fizz服務組概念的存在,讓它能針對不同渠道設置不同的組,從而解決渠道差別的問題。實際上,線上可以存在多組不同版本的API,也同時變相的解決API版本管理的問題。
Fizz的可擴展鑑權
Fizz針對授權也有特別的解決方案。我們公司組建比較早,團隊裏有多年編寫的老舊代碼,所以在代碼上也會有多種鑑權方式。同時,另外也有外部平臺支持方面的問題,比如在App和在微信上的代碼,就需要使用不同的鑑權支持。
圖上圖顯示的是通過的配置方式的驗籤配置。實際上,Fizz提供了兩種方式:一種公用的內置驗籤,一種是自定義插件驗籤。用戶使用時通過下拉菜單就能進行方便選擇。
Fizz的插件化設計
在Fizz設計初期,我們就充分考慮到插件的重要性,因此設計了方便實現的插件標準。當然,這個需要開發者會對異步編程有很深的瞭解,這個特性適合有定製需求的團隊。插件僅僅需要繼承PluginFilter即可,並且只有兩個函數需要被實現:
public abstract class PluginFilter {
private static final Logger log = LoggerFactory.getLogger(PluginFilter.class);
public Mono<Void> filter(ServerWebExchange exchange, Map<String, Object> config, String fixedConfig) {
return Mono.empty();
}
public abstract Mono<Void> doFilter(ServerWebExchange exchange, Map<String, Object> config, String fixedConfig);
}
Fizz的管理功能
中大型企業的資源保護也是相當重要。一旦所有的流量通過Fizz,便需要在Fizz建立對應的路由功能,而對應的API審覈制度也是其一大特點,所有公司API接口的資源都被方便的保護起來,有嚴格的審覈機制保證每個API都是經過團隊的管理人員審覈。並且,它具備API快速下線功能以及降級響應功能。
Fizz的其他功能
當然,Fizz適配Spring的全家桶,使用配置中心Apollo,能夠進行均衡負載,訪問日誌、黑白名單等一系列我們認爲該有的網關功能。
Fizz的性能問題
雖然不以性能作爲賣點,但是這並不代表着Fizz的性能就很差。得益與WebFlux的加成,我們將Fizz與官方spring-cloud-gateway進行比較,使用相同的環境和條件,測試對象均爲單個節點。測試結果,我們的QPS比spring-cloud-gateway略高。當然,我們還有想當的想象空間可以優化。
Intel® Xeon® CPU X5675 @ 3.07GHz
Linux version 3.10.0-327.el7.x86_64
Fizz的應用與成績
在設計Fizz之初,我們就考慮到企業內部複雜的中間層情況:它可以截流所有的流量,能並行且逐步替換現有網關。所以在內部推行時,Fizz很順利。
最初研發時,我們選取了C端業務作爲目標業務,發佈上線時僅替換其中部分複雜的場景,經過一個季度的試用,我們解決了性能和內存等各種問題。
在版本穩定後,Fizz被推廣到整個BU的業務線替代原先繁多的應用網關,緊接着是整個公司的適用的業務都開始使用。原來我們C端、B端兩個中間層團隊研發能夠騰出手來從事底層業務的研發,中間層人員雖然減少了,但是研發效率卻有很大提升,比如原先需要多天開發的一組複製型服務研發時間縮短爲之前的七分之一。
藉助Fizz,我們開展進行服務合併工作,中間層的服務器減少50%,而服務的承載能力卻是上升的。
小結
前期,Fizz僅依靠配置就開始規模化的使用,但隨着使用人數的增加,配置文件編寫和管理需要讓我們開始擴展這個項目。現在,Fizz包含兩個主要的後端項目fizz-gateway、 fizz-manager。fizz-admin是作爲Fizz的前端配置界面,fizz-manager與fizz-admin爲Fizz提供圖形化的配置界面。所有的Pipe都能夠在操作界面進行編寫以及上線。
爲了能讓更多的中大型快速發展的團隊能夠應用上這個面向管理,解決實際問題的網關,Fizz提供了fizz-gateway-community社區版本的解決方案,而且作爲對外技術的交流,其技術的核心實現將會以GNU v3授權方式進行的開放。fizz-gateway-community的所有API將會公佈以便二次開發使用。因爲fizz-gateway-professional專業版本與團隊業務綁定,所以進行商業封閉。而對應的管理平臺代碼fizz-manger-professional作爲商業版本開放二進制包的免費下載,提供給使用了GNU v3開源協議的項目免費使用(如果您的項目是商業性質,請聯繫我們進行授權)。另外,Fizz已有的豐富插件我們也會選擇合適的時機與各位交流。
無論我們的項目交流是否能幫到各位,我們真誠希望能得到各位的反饋。不管項目技術是否牛逼,完善與否,我們始終不忘初心:Fizz,一個面向大中型企業的管理型網關。
作者簡介:
林育穎(linwaiwai):錦江WeHotel直銷研發部負責人,從事互聯網行業十年,先後服務過合生元、唯品會、鉑濤集團等公司。2017年和2018年被評爲廣州市產業發展和創新人才。