车联网服务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规范限制，一些定制难以实现，如：

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

须要经过嵌入简单的DSL实现：

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

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

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

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

车线业务因为鉴权方式须要根据客户定制，所以存在多样性，实现上是经过Web中间件实现多种鉴权插件：

• HTTP签名，参考这里：主要面向ToB（车厂后台、合做方）的请求；
• JWT认证：主要面向车机、手机等终端；
• API Key。

对于API网关来讲，这些鉴权插件并无什么不一样之处，只是工程要处理一些定制场景，好比对于不一样车厂的JWK管理刷新策略，JWT验证策略等，具体须要根据业务诉求抽象建模，经过插件属性来实现配置控制。

另外，网关还实现了一些变换器，主要用于将GraphQL的输出变换为REST API接口透出，这一方面因为一些旧接口要作兼容支持，另外，一些重点客户的全球化架构背景下本身已经彻底定义好了接口式样，目前主要实现了：

• 入参变换：使用REST API参数填充GraphQL查询模板；
• Header变换：主要用于适配不一样客户规范；
• JSON变换，使用场景以下：

1. 可复用标准接口，可是不一样客户的响应结构规范不一致
2. 定制非标接口，须要对GraphQL输出进行转换

而插件的使用则经过控制台或API实现将插件配置信息存储于数据库中进行管理，使用时根据请求特征从DB中提取并缓存起来使用。

改造后的新架构以下：

小结

经过上述改造，将车联网在线服务开发模式进行了升级，实现API控制台动态发布，大幅提高定制开发效率：

• 提效开发：正交化原子能力编排，经过轻量级定义取代定制化代码开发：

1. 定制化开发占比降低60%；
2. 单接口开发从2-3人日→2-3人时。

• 协议兼容：混合REST方案，对外提供标准协议、支持既有适配协议。

原文连接 本文为云栖社区原创内容，未经容许不得转载。