赞
踩
、
在每一个互联网总不会缺少统一的API接口平台,公司级、部门级等等。存在即是合理,那么一个接口平台诞生的背景是什么,为了解决什么问题?怎么解决?
系统A调用系统B,双方测试各种联调,终于有一天调通了。相约着一起上线,上线当晚量小看不出问题,第二天上量之后,一顿报错,大家都慌了,赶紧重新走流程,紧急回退。一个流程下来到结束,个把小时没了,可想而知,研发小哥的心是崩溃的。如果整个调用链能做到秒级回退想必是极好的。
重新联调测试,又准备上线了,领导被上次的问题搞怕了,来找测试小姐姐,问道:都测全了吧。小姐姐回复说,该测的功能都测了,典型的按理都跑通了,但是线上的参数各式各样的,不敢说100%没问题。领导一听,顿时脸就沉了下来,测半天还不是不知道接口有没有问题啊。领导心想,如果能有线上分量功能岂不美哉?
战战兢兢的上线了,好在老天保佑,接口运行正常,业务系统也没跳起来。研发小哥一颗悬着的心也放下来了,领导又来了,问道:如何?新上的接口没啥问题吧?研发小哥自信满满:没问题,各个业务系统都通知到了,没接收到异常反馈。领导一听,眉头一皱,自己系统上线的接口需要业务系统验证是否有问题,有点被动。看来,接口监控有必要提上日程了。
突然有一天,一个其他的业务部门跑来说:你们的接口有问题啊。数据各种异常,怎么回事?研发小哥一想:最近没作上线啊,怎么会有问题,是其他问题引起的吧。心里有底多了,反驳道:我们最近没变更,你们查下自己的问题吧。结果一顿排查,发现接口名太相似了,导致调错了。研发小哥长吁一口气,领导拉着研发小哥说:这次事件也反应了我们系统的潜在问题,接口想怎么调就怎么调,得有个接口授权功能啊。
又临近大促了,最近各个系统都在进行压测。研发小哥把需要压测的接口都进行了扩容,心想:应该没啥问题了吧。第二天起床一看,手机各种报警,各个业务线系统都找到了他,说接口调用失败/超时之类,赶紧起床排查问题,结果发现某一无压测需求的接口昨晚调用量异常巨大,影响了其他的接口。领导大发雷霆:接口限流和接口隔离怎么做的?
作为一个接口平台,接口降级也是必不可少的,主动降级/被动降级都是必须的,否则不管对业务系统还是自身系统都可能造成不可预估的影响。
有这样一场景,业务系统想先调用接口A,根据接口A的返回决定是调用接口B或接口C,研发小哥信誓旦旦说,这不很简单么?判断一下不就好了?如果后续要改逻辑了呢?调接口D了怎么办?你要更变代码再上一次线么?就为了改一下判断逻辑。如果能够将接口之前的调用逻辑封装在一个接口里,接口之间的调用逻辑实现可配置,对于业务系统而言无需每次都上线,还能做到和单个接口治理一样的功能,对业务的影响做到最小。
以上就是个人对于API接口平台的一点理解,至少得需要具备以下的功能
版本控制
版本控制顾名思义,就是针对同一个接口维护多个版本,增加上线状态,每个接口都只能有一个上线版本,针对有问题的版本可实现秒级回退。分量的功能,每个接口都维护着一个预发环境,针对接口可以选择在指定环境进行上线,开启分量后,将在指定环境进行验证接口的正确性。
监控/报警
记录接口的运行情况,包括耗时/成功率/失败率。 如果有报警设置,查看是否满足报警条件,有的则调用报警接口。(邮件/微信/短信/外呼)
授权
为每个接口添加token授权校验之类,没有或错误则调用拒绝
限流
一般大型系统都是分布式,所以用到的分布式限流,redis+lua等等,以接口为维度来进行限流。
隔离
以接口维度来进行分配服务器资源,各个接口调用互不干扰。
降级
主动降级:让API接口平台用户设置的一种降级方式,接口维度,一般如果注册在API接口平台上的接口需要维护窗口,在那个时间内接口往往是不可用的,可以在那个时间点进行接口降级,返回默认值之类。或者大促时间,某些接口是允许被降级的,那么为了增加系统的吞吐量,也是可以被适当降级的。
被动降级:没有不出问题的系统,那么在出问题的时候怎么去很好的避免呢。做到尽可能少的影响业务。使用熔断/降级不失为一种好方法,Hystrix可以是个较好的选择。在某段时间窗口内,失败率达到多少则进行降级返回默认值,过了一定时间后,尝试打开熔断,如果失败,继续降级,如果成功,则恢复调用。
编排
通过简单的脚本语言来编写条件,根据返回的结果调用脚本引擎执行条件(是/否),来选择下一个应该被执行的节点(接口)。最终实现多个接口组合编排的目的。
API接口平台远不止这么多功能,鄙人也是刚接触不久,对于其中使用的技术也是一知半解,此篇理论为主,后续还会写点技术点的深入理解。包括熔断/降级的使用、接口的泛化使用、接口限流的实现等等。希望能对读者有一点点的帮助吧。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。