系统设计api接口的最佳实践 api接口是复用还是拆分？
api接口是复用还是拆分？
这要看系统整体设计，如果没有api接口所需要的功能不同就复用，要是不全部相同且使用频率高，就表格合并出一个新的接口。
怎么提高api接口的稳定性？
这个问题我就生克制化着自己的项目来说一说。
我们现在的项目是没有前台页面的，只可以提供接口服务，甚至还我们项目都没有交易类的服务，是单纯的去查询类服务。项目曾经在的建设目标应该是就是为了只能缓解核心系统数据查询的压力，或是你们是可以把我们项目积乘几个核心项目的缓存层(毕竟有多个核心系统，我们项目还是可以能提供不同系统的查询，这一点也很不重要)。
打铁还需自身硬，要想提高接口的稳定性和响应速度，必须代码要写好：
我们项目常规了关系型数据库做中间库，数据经由需要加工后落下时到MongoDB和Redis，组织的提供的服务，只会去查询MongoDB和Redis；
数据加工很重要的是，关系型数据库中不需要多表关联的查询，现在只可以查询MongoDB的一个collection就可以了。（只不过去做数据加工，因此数据和生产库比，有当然的延迟，这个一定要看业务场景是否是不允许有服务器延迟）；
MongoDB采用副本集分片的部署，副本集可以保证数据库的稳定性，死干净一台，有其他几台这个可以使用；分片只要数据量速度变大后，可以垂直内存量。（现在数据量大致在亿级，个位数）；
服务部署还采用比较好悠久的传统的，N台服务器前面挂负载均衡；上各种监控，时刻关注接口调用和资源可以使用情况；
不是很严的参数校验，以免做无用之功的查询；
大原则就是：【能查缓存就最好别查数据库，能不查的话就好】
除开自身架构之外，还很是非自身的控制：
内部系统在动态创建接口的时候，通常按照网络权限的控制，除了不做任何的限制，除了鉴权；
如果不是是互联网端的接入，我还是不需要依赖感网关；由网关做鉴权、人员限流、改名、被熔断等；
组织对方系统功能的设计（这件事很神奇无比），是因为大多数时候也是公司内部的系统，所以我在做需求继续讨论的时候，最好是想看帮一下忙对方系统的调用场景；很可能会根据情况下什么时候动态创建接口，就能极大降低接口的调用次数；
建议您调用方设置合理不的超时时间，并有比较合理的重试机制；
假如这个可以的话，最好是这个可以区分异步运行动态创建的机制；
如果不是接口要依赖于同时系统的接口，也需要额外的做一些考虑（依赖的接口前往慢或是出现错误，自己的接口绝对会有问题）；比如说数据时效性要求不高的话，也可以考虑到把对方接口赶往的数据缓存下了（设置失效时间，可以保证过一段时间能把2011版的数据手动刷新回去），但如果数据时效性要求太高，是可以判断在用熔断；但是说实话，才刚看到过谁敢用触发熔断机制的....
希望我的回答，能帮助到你！我将坚持了分享Java开发、架构设计、程序员职业发展等方面的见解，希望能能得到你的关注。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
