概述

服務編排是Fizz閘道器提供的一個強大的功能，能夠基於現有的業務微服務通過線上配置的方式快速的生成一個聚合介面，減少中間層膠水程式碼以及降低編碼投入。本文介紹服務編排三個常見場景的使用：單API結果裁剪、多API資料聚合、多API之間傳遞依賴。

服務編排架構

適用場景

前端

1、一個頁面呼叫多個介面時，可以編排好返回聚合結果，提高頁面資料的載入速度

2、移動裝置計算能力有限，可以把資料計算或業務處理邏輯放到服務端完成，加快頁面響應

後端

1、替換應用層的聚合介面，減少應用層的膠水程式碼

2、快速生成透傳資料型別的介面

3、資料轉換和對映

資料準備

Fizz閘道器安裝

可參考： https://www.fizzgate.com/fizz/guide/installation

底層服務介面

本文服務編排呼叫的底層服務介面原始碼可從github(https://github.com/wehotel/fizz-examples)獲取。從github克隆最新的fizz-examples原始碼，並啟動fizz-examples-rest-api服務。

管理後臺(選單位置：RPC管理->服務宣告)配置服務宣告，如圖所示。

新增編排介面

管理後臺，選單位置：服務編輯->介面列表，點選新增。

例子1：單API結果裁剪

本例子在編排介面中呼叫底層fizz-examples-rest-api服務的/user/detail介面(介面原始碼：UserController )來獲取使用者詳情資訊，並對該介面的響應進行裁剪以滿足我們想要的資料格式。

基礎資訊

配置輸入

在配置輸入tab可以定義介面的入參和請求頭等資訊，如果不配置入參或請求頭，閘道器會原樣接收呼叫方傳過來的所有入參或請求頭，但不會對接收到的引數做任何校驗。在本例子中查詢使用者詳情必須傳userId，配置如下圖所示。

配置步驟

新增1個步驟step1，然後在步驟step1裡新增1個請求request1，服務選擇我們預先準備好的fizz-examples-rest-api服務，請求/user/detail介面。入參我們使用input.request.params.userId來引用前端傳過來的userId引數，在這裡使用了引用值的方式來引用入參，相關引用值的使用方式可參考文件：

配置輸出

配置要返回給前端的響應報文，這裡配置了響應體有以下欄位：

msgCode：固定值字串型別，值為"100";

msg：引用型別，值為步驟step1中請求request1的響應的message欄位；

user.info.age：引用型別，值為步驟step1中請求request1的響應的data.age欄位。

測試

直接呼叫/user/detail介面得到的響應如圖所示。

測試介面得到響應如圖所示。

從測試介面的響應可以看出服務編排介面已完成了對/user/detail介面的請求並正確輸出了配置的結果，完成了對API結果的裁剪。

例子2：多API資料聚合

本例子在編排介面中併發呼叫底層fizz-examples-rest-api服務的/user/detail介面(介面原始碼：UserController )和/order/detail介面(介面原始碼：OrderController )來獲取使用者詳情資訊和訂單詳情資訊，並在訂單詳情資訊中加入我們想要的使用者名稱和手機號碼，將聚合後的訂單詳情資訊響應給客戶端。

基礎資訊

配置輸入

在本例子中查詢使用者訂單詳情必須傳userId和orderNo，配置如下圖所示。

配置步驟

新增1個步驟step1，然後在步驟step1裡新增1個請求request1，服務選擇fizz-examples-rest-api服務，請求/user/detail介面。入參我們使用input.request.params.userId來引用前端傳過來的userId引數。

在步驟step1裡新增1個請求request2，服務選擇fizz-examples-rest-api服務，請求/order/detail介面。入參我們使用input.request.params.userId來引用前端傳過來的userId引數，使用input.request.params.orderNo來引用前端傳過來的orderNo引數。

配置輸出

配置要返回給前端的響應報文，這裡配置了響應體有以下欄位：

msg：引用型別，值為步驟step1中請求request2的響應的message欄位；

code：引用型別，值為步驟step1中請求request2的響應的code欄位；

order：引用型別，值為步驟step1中請求request2的響應的data欄位；

order.userName：引用型別，值為步驟step1中請求request1的響應的data.userName欄位；該配置在order欄位中加入了從request1中獲取到的userName值；

order.mobile：引用型別，值為步驟step1中請求request1的響應的data.phone欄位；該配置在order欄位中加入了從request1中獲取到的phone值。

測試

直接呼叫/user/detail介面得到的響應如圖所示。

直接呼叫/order/detail介面得到的響應如圖所示。

測試介面得到響應如圖所示。

從測試介面的響應可以看出服務編排介面已完成了對/user/detail介面和/order/detail介面響應的聚合並正確輸出了配置的結果。

例子3：多API之間傳遞依賴

本例子在編排介面中序列呼叫底層fizz-examples-rest-api服務的/weather/getMobileCodeInfo介面和/weather/getWeatherbyCityName介面(介面原始碼：WeatherController )，/weather/getWeatherbyCityName介面的呼叫依賴於/weather/getMobileCodeInfo介面的響應，通過呼叫/weather/getMobileCodeInfo介面獲取查詢手機所在的城市後呼叫/weather/getWeatherbyCityName介面獲取該城市的天氣。

基礎資訊

配置輸入

在本例子中查詢手機所在地天氣資訊必須傳mobile，配置如下圖所示。

配置步驟

新增1個步驟step1，然後在步驟step1裡新增1個請求request1，服務選擇fizz-examples-rest-api服務，請求/weather/getMobileCodeInfo介面。入參我們使用input.request.params.mobile來引用前端傳過來的mobile引數。

新增1個步驟step2，然後在步驟step2裡新增1個請求request1，服務選擇fizz-examples-rest-api服務，請求/weather/getWeatherbyCityName介面。入參我們使用step1.request1.response.body.city來引用步驟step1的請求request1的響應city欄位。

配置輸出

配置要返回給前端的響應報文，這裡直接引用步驟step2裡的請求request1的響應結果。

測試

直接呼叫/weather/getMobileCodeInfo介面得到的響應如圖所示。

直接呼叫/weather/getWeatherbyCityName介面得到的響應如圖所示。

測試介面得到響應如圖所示。

從測試介面的響應可以看出服務編排介面已完成了對/weather/getMobileCodeInfo介面和/weather/getWeatherbyCityName介面的序列呼叫並正確輸出了配置的結果。

結束語

本文通過三個例子介紹了服務編排三個常見場景的使用：單API結果裁剪、多API資料聚合、多API之間傳遞依賴。使用服務編排能夠通過線上配置的方式快速的生成一個聚合介面，減少中間層膠水程式碼以及降低編碼投入，提高我們的生產效率。

Fizz閘道器介紹

Fizz Gateway 是一個基於 Java開發的微服務聚合閘道器，能夠實現熱服務編排聚合、自動授權選擇、線上服務指令碼編碼、線上測試、高效能路由、API稽核管理、回撥管理等目的，擁有強大的自定義外掛系統可以自行擴充套件，並且提供友好的圖形化配置介面，能夠快速幫助企業進行API服務治理、減少中間層膠水程式碼以及降低編碼投入、提高 API 服務的穩定性和安全性。

官網：https://www.fizzgate.com

GitHub: https://github.com/wehotel/fizz-gateway-community

碼雲：https://gitee.com/fizzgate/fizz-gateway

入門教程：https://www.fizzgate.com/fizz/guide/GettingStarted/

作者：ZHONG.J