在接口设计中,应该考虑什么接口的命名?
要求参数。
支持的协议。
TPS、并发行数、响应时间。
数据存储。 数据库选型、缓存选型。
是否需要依赖第三方。
是否分割接口。
接口是否需要乘方等。
防止刷子。
接口限制,降级。
负载平衡器支持。
如何配置?
是否需要服务治理。
是否有单点。
接口是资源包、预载还是内置?
是否需要本地缓存。
分布式缓存,是否需要缓存直通。
是否需要白名单。
在我们设计接口的时候,我们或多或少有上面提到的一些考虑。 我们必须多加思考才能使我们的接口更加完善。 我个人认为不存在100%完美的界面,只有合适才是最重要的。
接口设计原则原则一:必须符合rest风格,统一返回格式,约定业务层错误代码,每个代码都可以携带可选的错误信息。
原则二:命名必须规范优雅。
原则三:单一性。
单一性应该是相对单一的,例如,如果是登录界面,登录完成后应该会返回一些用户信息,但是很多人为了减少界面的交互
例如,一个人设计了一个用户列表界面,界面中他返回的所有数据包含很多用户与另一个无关的数据,最后一问,其他无关的数据是他接下来要获取的,数据的懒惰加载
原则四:可伸缩性。
界面可扩展性是指在设计界面时考虑各种情况,考虑各种方面。 其实,我觉得把可扩展性单独放在这里也是不方便的。 我觉得这是和单一性有点相反的意思,其实这不是那个意思。
这里的可扩展性是指我们的接口充分考虑了客户端,考虑他们如何调用,他如何使用我的代码,他如何扩展我的代码。 应该把更多的主动权交给客户端程序员,而不是把太多的工作写在你的界面上。
如果获取不同的列表数据接口,则不能将每个列表写入一个接口。 另一个我在这里特别想指出的是,为了省去很多开发者的麻烦,很多开发者只是将界面设计作为一个APP的页面进行展示。
这些人通过一个界面实现一页的展示。 这些数据是否属于不同的模块,是否属于不同的展示范畴,结果下次在视觉上发生变化时,整个界面将被改写,无法重用。
需要原则五:文档。
良好的界面设计,离不开清晰的界面文档表达。 文件的表达要十分详细
原则六:产品之心。
你为什么说需要产品的心? 因为我觉得很多人都无视它。 如果你开发了一个APP,但一开始你甚至没有交互式文档,你怎么设计界面?
所以,作为服务端的后台开发者,我认为应该有一颗产品的心。 我认为应该充分理解,特别是交互式文档。 因为这些对我们的接口设计有很大的影响。
我在设计界面的时候,经常发现很多交互文档一点也不好,产品没有充分考虑,缺少交互文档。 此时,作为开发必须积极推进和完善。
http://如果可以缓存www.Sina.com /第三方服务接口数据,则缓存。
原则七:第三方服务需要降级。
建议消除原则八:一点。
原则九:接口粒度很小。
原则十:客户端可以处理的逻辑不向服务端处理,以减少服务端压力。
原则十一:资源预加载。
原则十二:请勿过度设计。
原则十三:缓存尽量不要穿透。
原则十四:如果接口可以缓存,则缓存。
原则十五:思辨大于执行
关于如何保证接口的高可用性、高性能,列举了很多需要考虑的原则和需要设计的原则,但实际上有很多方面,我们也不是特别全面。
在上面提到的这些考虑中,其实我们服务更合适,可以做好上面提到的几点,其实接口也比较可靠,如何设计和保证接口的高可用性和高性能? 请考虑以下要点
高性能:如果发现这个接口tps和响应时间不满足我们的要求,怎么办?
a )关于数据存储)数据库是否有存储库、表和主数据库、读写隔离、是否对字段进行索引、是否有慢sql,数据库引擎选择适当的数据库
然后,考虑分布式缓存、缓存密钥大小是否合适、过期时间是否正确、大量缓存是否已贯通以及是否部署了本地缓存。
b )业务方面:是否有大量计算,能否异步处理? 是否需要部署线程池或MQ以异步处理任务? 有吗
有必要将接口进行垂直拆分和水平拆分、将接口粒度变小。C:其他方面:nginx 层面做缓存、加机器、用 ssd,资源放 cdn,多机房部署、资源文件预加载。
高可用:如何保证服务高可用,需要从几个维度来实现:
A:消除单点,基于高可用第二位。
B:能做集群的全部做集群。譬如 Redis 集群、mysql集群、MongoDB副本集。
C:能做读写分离的都做读写分离。
D:异地多机房部署,接入 GSLB
E:必须有限流、降级机制。
F:监控。高可用的保证,基于第一位。
下图是从一个基本的请求出发来梳理需要涉及到各个段,以及各个端能做的事情。谈谈接口服务,但不局限于接口本身。
客户端:资源预加载、限制请求、数据上报。我这边就拿客户端来举个例子。接口服务所依赖的资源包或者一些公共配置预加载在本地,减少接口的交互,通过请求配置文件是否更新,code是否是304等来;
接口做一些请求限制,比如抢红包、抢券等,单位时间内N次点击只请求一次等;接口失败数据上报来;这就是客户端可以做到的对接口有帮助的事情
GSLB/HttpDNS:多机房部署、流量切换、域名劫持,一般技术和业务比较成熟的公司这一层。
资源文件放CDN。
负载均衡器:lVS+Nginx是互联网常用的做负载均衡,可以实现四层/七层负载均衡;这里除了可以分流、转发以外,我们用的更多的基于令牌桶限流、缓存。
本地缓存。本地缓存能减少我们访问DB或者分布式缓存,本地缓存推荐使用guava,guava里面有很多特性很好用,例如基于令牌桶的限流;当缓存失效时只穿透一个请求去访问后端。
线程池。
模块拆分。将一个项目按功能模块拆分,一个接口也可以按业务粒度进行拆分。
数据中心。提供数据支撑,譬如黑名单。
数据库。加索引、分库、分表、读写分离
分布式缓存。数据分片、拆分大key,并做集群,采用分布式锁
MQ。做接口拆分利器,异步操作。
其他服务。限流、防刷以及降级(特别是第三方服务,保证第三方服务down掉不要影响我们自身的服务)。在这里也需要考虑做第三方数据的缓存或者持久化,譬如实名认证、身份证认证等。
监控。监控永远是必须的,能让你第一时间知道接口服务是否ok
个人小分享1)接口Restful,统一返回格式,约定业务层错误编码,每个编码可以携带可选的错误信息
在前司,客户端和服务之间是有统一的数据返回格式,约定各层的编码,可以通过编码位数以及编码就可以看出是那一层出问题。
我觉得这对我们定位问题以及维护来说具有莫大的意义,并对异常也进行捕捉,封装成对应的 code,我之前阅读一些人的代码发现其项目根本没有做这一层,因为简单而不做我觉得有失所望。
2)采用 hybird 模式
采用 hybird 模式涉及到资源预加载的问题,在很多项目里面都大量使用,譬如前司的生活服务,就采用了 hybird 模式,先将资源文件(包含图片、前端页面)打包放到服务器并通过版本号进行管理,并通过一个总的配置文件来管理,如果是H5页面可以进行模板预先设计,down到本地。
配置文件格式:
*文件1* name:xxx url:http:xxxx md5:xxxx *文件2* name:zzz url:http:zzzz md5:zzz
客户端每次启动应用或者定时请求总的配置文件,通过http code是否是304判断是否需要下载这个总的配置文件,如果code是200,那么下载这个配置,比较那个文件发生变化,并将其下载。这样的好处:
减少接口的交互;
资源预加载,节省流量,打开页面更加流畅,对于服务端来说字需要返回数据json串就行,而不需要其他,减少服务端压力;
方便开发人员,资源管理更加简洁,比如做活动需要的h5页面,只需要前端上传对应的h5资源包到服务端,不需要通过后端开发人员就可以搞定。
虽然这个原理很简单,但是现在很多app还是没有做这个,都是通过填写一个url,加载网页的方式去打开,体验性太不友好。
3)客户端
客户端跟服务端就是接口请求的关系,很多时候需要要求客户端做一些数据缓存的工作以及一些检验工作。在前司已经好几次给客户端的同学坑过了,客户端同学接口乱调用,死循环调用。
一次是做一个关于事件提醒的功能,需要每天定时调用调用服务端一个接口,结果客户端的同学写了一个 bug 导致请求每隔一两秒就调用一次,导致服务器这边此接口 pv 翻了N倍,而且这个 bug 通过测试同学很难测试出来;
还有一次发现服务端一段时间以后 UV 不见涨,但是PV却涨的很猛,定位发现是客户端同学A图省事在一个方法里面调用了N个接口,也就是模板方法。
因为版本更新,同学B需要做一个新的功能,然后也调用了A同学的接口导致,从而导致PV上升,其实B同学完全不需要调用这么多接口。这些都是真实案例,所以这里需要有一个监控接口异常的机制。
4)思辨大于执行
写到这里觉得这个非常重要,思辨大于执行,意味着我们不是一股脑就去干,也不是不去干,我们做事情需要思考、辨别;从而让事情更高效、更好、更有力的执行。接口设计也一样,需要我们去思辨。
5)本地缓存、分布式缓存以及异步
缓存在前司主要分为客户端缓存、CDN缓存、本地缓存(guava)、Redis缓存。
在MZ早期是接口是采用 DB+本地缓存的方式提供数据,但这种模式DB压力大,接口吞吐量小,本地缓存多机难一致性、更新不及时问题。
为了解决这些问题,引入分布式缓存,并通过 Task 将业务数据刷到 Redis,接口只访问 redis,不会访问 DB,及时 DB 故障也不会影响功能。
不同的业务系统系统通过 MQ 来解耦,多机房不是通过 MQ 来实现数据的一直。
比如,评论,先通过写 Redis,写 MQ 来实现数据在多机房同步,再通过 task 将 Redis 中评论同步到 DB 中。
接口设计涉及方方面面,这边也只谈到一个大概,虽然有点泛泛而谈,希望此拙文对你有所启示。
6)数据库
数据库分库分表,一般都是通过 userId 或者 imei 或者 mac 地址来分表,单表数据量控制在500w以内,这需要我们提前估算好数据量,尽量避免数据的迁移。
在前司,数据库一般都是采用 mysql+MongoDB 两种,MySQL存储用户的用户数据,MongoDB 存储业务数据,就像阅读和生活服务里面的业务数据就存储在 MongoDB 里面。
在数据库这层,我们主要也是通过主从模式、读写分离、分库、分表来实现数据的可用性。
7)业务
业务尽可能拆分、独立部署、将项目按业务划分、按功能划分等。譬如生活服务,我们当时主要拆分成管理后台 admin、任务 task、活动、web、数据展示模块。
8)数据中心
每个大一点的公司都有数据部门,我们这边可以通过数据中心的数据分析来达到我们需要的数据。
比如黑名单,推广效果、活动数据。我们可以通过这些完善我们的接口功能。之前在前司做了个数据处理后异步加载到 Redis 来实现数据利用的项目。