概述
服务编排是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/
