车联网服务non-RESTful架构改造实践

导读

在构建面向企业项目、多端的内容聚合类在线服务API设计的过程中，由于其定制特点，采用常规的restful开发模式，通常会导致大量雷同API重复开发的窘境，本文介绍一种GraphQL查询语言+网关编排联合的实践，解决大量重复定制的问题。

早期与车厂合作过程中，基于高德已有的数据、引擎能力和一些较为重要的相关CP服务（如停车场、加油站、天气等），形成的在线服务协作模式是针对客户需求，采用REST API提供针对每个车厂、每个项目以及每个终端提供不同的API实现，然而数据核心独立服务实际上就有十余种，然而由于车线业务维护周期长，定制多，2-3年下来，API规模已达几百个，而且持续发散级增长，这给持续开发和维护带来不小挑战。

分解业务开发过程，无非两类工作，业务需求能力数据的获取和非业务诉求但是必不可少的如鉴权等通用化能力，当前来看，其实这两个问题是几乎所有业务团队都会遇到的问题，因此解决方案也基本类似，如服务聚合、流程编排、API网关等。

本文简要介绍下车联网在线服务改造旧架构的一些实践。

有关名词

GraphQL：GraphQL既是一种用于API的查询语言也是一个满足数据查询的运行时。GraphQL对API中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让API更容易地随着时间推移而演进，还能用于构建强大的开发者工具。
DSL：指的是专注于某个应用程序领域的计算机语言。又译作领域专用语言。不同于普通的跨领域通用计算机语言(GPL)，领域特定语言只用在某些特定的领域。比如用来显示网页的HTML，以及Emacs所使用的Emac LISP语言。
API网关：API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。

存在的问题

车线业务在线服务旧架构如下：

面临以下问题：

改进

针对上述问题，主要从以下几个方面思考改进：

服务能力原子化：目标是做稳，让上层通过组合实现业务需求；
构建查询引擎：支持强大的查询组合能力，实现原子服务能力任意聚合和定制；
API网关：对非业务数据能力需求进行抽象提供插件，实现插件编排。

下面分别介绍。

实现稳定、独立演进的原子能力服务

对已有的服务进行梳理，抽象出不同应该独立开发、部署演进的核心能力，对于引擎能力没有什么工作，重点是对于一些历史对接的外部CP，主要实现以下目标：

向上提供稳定接口，向下屏蔽底层复杂性（数据访问，多源差异）；
以位置为中心有机整合，构建完备原子化能力集合。

这部分工作主要是解决历史遗留的一些服务组合不合理，跟随业务过度定制的问题。

定制代码开发转换为定义查询语句

这里主要目的就是将服务聚合、定制逻辑等原来需要的代码开发转换为编写查询语言的方式实现，只需要编写出声明式的查询语句即完成服务发布，特性如下：

向上提供标准化查询语言
向下实现原子能力组合
归纳业务共性，提炼定制模式，提升复用

本文选择GraphQL作为查询语言基础，然而，直接采用GraphQL有这样两个主要问题需要解决：

数据查询N+1放大问题，直接采用Fackbook提出的dataloader来解决，原理是批量加缓存；
GraphQL规范限制，一些定制难以实现，如：

入参定制：如参数关联，类型转换等；
输出格式：字段展现形式，如时间、经纬度等；
配置表定制：主要是部分业务逻辑需要根据配置表定制，如深度返回字段等；
模型连接：原子能力服务尽可能独立，同时也无法枚举定义模型关系，但是定制业务需求需要大量关联透出，减少业务请求降低延时，所以模型自由关联能力是必要的，由于本方案最终的查询控制在内部，对外暴露REST API，因此不会关联自由度造成的难理解性并不是一个问题。

需要通过嵌入简单的DSL实现：

内置和自定义函数功能；
模型动态关联查询，上下文参数获取；
可以方便扩展自定义函数。

这里嵌入DSL需要控制好度，因为DSL如果过于复杂，那么，使用者或者发布者无法快速写出查询的话，对比写代码提效就会打折扣，偏离本来的价值，所以基本原则是简单、可扩展。

业务无关功能通过API网关插件配置化

由于之前每个API的定制开发基本所有功能混合在一起，能复用部分就是鉴权提供装饰器，常规性的响应格式定制提供一些工具函数，任何需求变更都需要变更代码，走发布流程，有了上面第一步的改造，这个步骤期望将非业务数据部分的定制功能抽象出处理链，每个处理节点提供多实现（包含通用和定制），通过数据库存储插件链实现编排。