本文详尽的描述了工作中遇到的问题及一步步解决问题的思考方式,特记录在此,客官将就一下
背景
智能辅助驾驶的发展,图商在其中的角色举足轻重;即使作为行业的一颗螺丝钉,也要有自己的想法,优秀的士兵应该具备较强的执行力,老板说对接一个平台我就(zhineng)说——好的
现状
由于前期缺少规划,很多端(前端直连、后端各业务系统、算法端、大数据部门)都接入了高德开放平台,但本着能不花钱就不花钱的原则,这些请求携带的密钥(key)都是同一个。作为一个合格的对外服务,key作为请求凭证的同时也用作限流,那么问题就来了,同一个key的情况下随着业务的发展、胡乱的请求、各部门间的业务隔离,自然就暴露出请求被限制的问题。
上图为当前高德给出的接口调用配额,以前个人认证是30000次,后来调整了我都不知道,直到有段时间打开注册时的认证邮箱才发现。
当初为了灵活还把这个30000写到了配置文件,请求一次缓存增加一次,直到达标。查问题查的头发都白了,也问候了高的团队,看到邮件我发现我格局小了,这里一并道歉与反思(其实以企业身份认证就会没这些问题了,但你懂的)
需求整理
作为对接过很多外部系统(微信公众号、微信网页授权、连连、贝付、汇付、富友)的过来人,我知道对接不是一件难事儿;如何在短时间搞一个系统,把杂乱的多端请求高德API统一起来、统一管理key、各环境key隔离互不影响、多端切换时最小改动、如何发一版就是绝版等,这些问题都一个都不能少。
Feign的影子
我记得当初是在排查一个问题,看堆栈是loadbalance找服务失败,当前我们系统的架构使用到了feign作为服务间的通信方式,在搜索的时候眼睛看到的和鼠标操作的不一致误点到推荐的openfeign上,本着划水摸鱼的想法刷完资料,印象深刻的就是 —— 动态Url配置。
解题思路
独立一个系统专门用于处理对接的外部API,所有请求通过被系统转发、key的维护在本系统内动态分配、各环境(dev、test、uat、prod)间配置不同key,即使量大用完了影响范围也在本环境内、增加缓存让相同请求的命中减少调用次数。
接二连三的问题
按照官网定义,每个接口都有必填参数和可选参数,我无法知道当前各端都携带了哪些参数,如果我按照官网定义,光接口定义我就得死,我去看了当前后端代码中存在的接口定义如下(有改动):
public interface AliMapClient {
//逆地理编码API服务地址
JsonNode regeo( String key,
String location);
//驾车路线规划 API 服务地址
JsonNode driving( String key,
String origin,
String destination,
Integer strategy);
//坐标转换API服务地址
JsonNode convert( String key,
String locations);
}
上述代码的缺点是很明显只定义了必填参数,业务扩展(增加参数或增加接口)就得改代码、测试、上线,浪费时间;这个时候我的第一个想法是要把这些接口管理起来,我想到了枚举——用一个简单的code就知道对方要的请求的接口,我收到后内部转:
public enum APIEnum {
CONVERT("assistant/coordinate/convert","坐标转换"),
REGEO("geocode/regeo","逆地理编码"),
DRIVING("direction/driving","驾车路线规划"),
DISTANCE("distance","距离测量");
//get set constructor removed
private String route;
private String desc;
}
上述方式可以说能解决一个问题,但没有考虑各端的改动成本,再去刷一下资料openfeign到底如何实现动态URL。
P.S:写到这里我看已经有很多篇幅了,为了避免看客太累,我准备分成上、下2篇,且听下回分解……
最近打算看看新机会,如果有坑,方便的话,给我留一个可好