本文详尽的描述了工作中遇到的问题及一步步解决问题的思考方式，特记录在此，客官将就一下
背景
智能辅助驾驶的发展，图商在其中的角色举足轻重；即使作为行业的一颗螺丝钉，也要有自己的想法，优秀的士兵应该具备较强的执行力，老板说对接一个平台我就（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 removedprivate String route;private String desc;}上述方式可以说能解决一个问题，但没有考虑各端的改动成本，再去刷一下资料openfeign到底如何实现动态URL。
P.S：写到这里我看已经有很多篇幅了，为了避免看客太累，我准备分成上、下2篇，且听下回分解……
最近打算看看新机会，如果有坑，方便的话，给我留一个可好
