Fizz中大型企业管理型网关 引言 无法适配的市面方案 Fizz的设计 Fizz的性能问题 Fizz的交流发展

引言

我在参与工作的第四年加入了一个国内知名的电商公司，因为公司的主要业务形态是特卖，用户量也不小，在并发这一块的要求比较高。公司使用的一直都是微服务的架构，这是我见到的比较大的一个中间层团队的规模，近三分之一的同事从事着中间层服务的开发。在此之前，我从事的是客户端的开发工作，对接的中间层团队虽然规模不大，也是相当于团队近四分之一的规模。而现今的团队初期的中间层团队也是接近这个规模的。

开发与调试之痛

在调试上与开发上显然是比较痛苦的，比如在并发量有要求的场景，当时选择的是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;
    }

『复杂』的中间层

在之后，我曾经查看过我们一个搜索的中间层逻辑，其服务大概是这么一个过程。
1、获取会员的信息，会员卡列表，会员积分余额，因为不同级别的会员会有不同价格；
2、获取用户的优惠券信息，这部分会对计算的出来的价格产生影响；
3、获取搜索的结果信息，结果来自三部分，商旅商品的库存价格，猜你喜欢的库存价格，推荐位的库存价格，海外商品的库存价格。
涉及到的服务有：中间层服务（聚合服务）、会员服务、优惠券服务，推荐服务、企业服务、海外搜索服务、搜索服务。还有各种类型的缓存设施以及数据库的配置服务。

    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();
    }

这个项目使用的是spring-mvc，但是项目内部的Service确使用了Mono，并且用了block，研发跟我讲这是异步编程，我明确指出block的关键字就是个中间的大问题。

野蛮的生长

当我开始一个初创技术团队的建设时候，我们最初做的是一个胖服务，但当我们的团队规模开始扩大的时候，我们需要逐步的分拆成为微服务，于是需要中间层的团队做底层服务的聚合，但是有一段时间我们团队的招聘速度并不能完全赶上我们的服务扩张速度，于是写底层的同事就比较分裂，因为他们除了要编写的分拆之后的底层微服务，还要编写的聚合的中间层服务。而当我停掉某一些项目的时候，我的团队开始整顿人手的时候，我又发现一个残酷的事实，每个人手上都有数十个中间层服务，我无法换掉任何一个人。因为经过多次的换手，同事们已经搞不清楚中间服务的联系了。另外还有各种的授权方式，因为团队的一直以来的野蛮成长，各种授权的方式都汇集了，简单的，复杂的，合理的，不合理的，团队也没有人能够讲得清楚。

团队在一段时间的发展之后，我们开始整理服务，发现有很多线上资源的浪费，有时候微服务仅仅是一个接口就使用了一个微服务，虽然在早期是有请求的，但是到了后面因为项目的废弃没有了流量，但是实际上运行的接口依然在线上。而作为团队的管理人员我甚至没有任何的书面上接口的汇总，统计信息。我无法做到：当我的业务老板告诉我，把合作公司对接服务暂停的时候，我无法做到仅仅是逻辑上的停机返回一个业务异常。而且作为一个多渠道发展的上游库存供应商，我们对接的渠道是非常的多，提供客户的接口有很多特别定制的需求，以前，这些需求一般就在中间的逻辑控制代码里面。而且中间层的团队对外联合调试也是一个长久以来存在的问题。另外经常有前端的同事跟我抱怨，后端不增加数据处理逻辑的代码而导致前端的代码很多时候是为了适配数据而存在的，而像在小程序这种的对包大小进行限制的环境里，这些代码在发展后期就成了一个难以解决的问题。

无法适配的市面方案

最初，我是想寻找直接购买市面上已有的针对我们这样的中大型的正在发展中快速变化业务团队网关方案。当时Eolinker也是我们的API 自动测试的供应商，也提供了对应管理型网关，但是语言是Go。我们团队技术栈主要是Java为主的，运维的部署方案也一直主要围绕着Java，这意味我们的选型就偏窄，在之前我们选择过Kong网关，但是引入一个新的复杂技术栈是一个成本不低的事情，Lua的招聘与二次开发确实是难以避免的痛。另外，Gravitee、Zuul、Vert.x 都是不同小规模团队使用过的网关。谈及最多的特性是：1、支持熔断、流量控制、过载保护；2、支持并发特别高；3、秒杀。

然而，对于生意来讲的，如果技术能够服务越大规模的流量，熔断、流量控制、过载保护应该是最后考虑的措施，但是技术上的硬件和软件的瓶颈使得我们不得不考虑服务有限的客户。而，对于一个成长中的团队来说，服务的过载崩溃是可望不可及的愿望，很多时候根本就没有那么大的流量，流量更多的时候支持维持一个的水平，其偶尔的最高并发也是在普通团队能力范围之内的。也就是说，选型的时候我更多的是需要结合实际，而不是阿里巴巴类似流量，我只需考虑中等水平以上并且具备集群扩展性的方式即可。

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的设计

从原点出发的需求

当来我来复盘当初这个选择的时候，需要再强调下从原点出发的需求：

1、Java技术栈，支持Spring全家桶；
2、方便易用，零陪训也能编排；
3、动态路由能力，随时随地能够开启新API；
4、高性能并且集群可横向扩展；
5、强热服务编排能力，支持前后端编码，随时随地更新API；
6、线上编码逻辑支持；
7、可扩展的安全认证能力，方便日志记录；
9、API审核功能，把握所有服务；
9、可扩展性，强大的插件开发机制；

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有一套平滑替换网关的方案。在最初，Fizz是可以跟其他网关并存的，比如之前提到的基于Vert.x的网关。所以Fizz就有一个类似nginx的反向代理方案，纯粹基于路由的实现。于是，在项目的进行的初期，过了Nginx的流量被原原本本的转发到Fizz然后再到Vert.x，其代理了Vert.x了全部流量。在之后，流量被逐步转发到后端的微服务，Vert.x上有一部分特别定制公用代码被下沉到底层微服务端，Vert.x还有中间层服务被完全废弃，服务器的数量减少三分之一。在我们做完调整之后，原先困扰我的中间层人员以及服务器的问题终于得到解决，我们可以缩少每个同事手中的那一串的服务列表清单，将劳动落实到更有价值的项目上去了。当这一切变得清晰的时候，这个项目也就自然而然显示了它的价值。

针对渠道，这里的路由功能也是非常实用的功能，因为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进行比较，使用相同的环境和条件，测试对象均为单个节点。

Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
Linux version 3.10.0-327.el7.x86_64

条件	QPS（/s）	90% Latency(ms)
直接访问后端	9087.46	10.76
fizz-gateway	5927.13	19.86
spring-cloud-gateway	5044.04	22.91

Fizz的交流发展

在前期Fizz仅仅依靠配置就是开始规模化的使用，但是随着使用的人数的增加的，配置文件编写以及管理的需要使得我们开始扩展这个项目。于是现在Fizz包含了两个主要的后端项目fizz-gateway, fizz-manager，而fizz-admin作为Fizz的前端配置界面。fizz-manger与fizz-admin为Fizz提供图形化的配置界面。所有的Pipe都能够在操作界面的进行编写以及上线。

为了能够让更多的中大型快速发展的团队能够应用上这个面向管理，解决实际问题的网关，Fizz接下来将会提供的fizz-gateway-community社区版本的解决方案，而且作为对外技术的交流，其技术的核心实现将会以GNU v3授权方式进行的开放。fizz-gateway-community的所有的API将会提供所有的对外API以便二次开发使用。fizz-gateway-professional专业版本其因为与团队的业务绑定进行商业封闭。而对应的fizz-manger升级为fizz-manger-professional，fizz-admin-professional作为商业版本开放二进制包的免费下载，提供使用了GNU v3开源协议的项目免费使用，而商业项目请联系我们进行授权。另外插件的提供我们也会选择合适的时机与各位交流。

无论我们的项目交流是否帮助到各位，我们真诚的希望能够得各位的任何批评反馈。无论项目技术是否牛逼，完善与否，我们始终不完初心，Fizz，做一个面向中大型企业好用的开放型面向实际拥抱生态的网关。