【金秋打卡】第15天 构建微服务设计架构知识体系--超时控制和BFF
2022/11/8 3:23:58
本文主要是介绍【金秋打卡】第15天 构建微服务设计架构知识体系--超时控制和BFF,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
课程名称:海量数据高并发场景,构建Go+ES8企业级搜索微服务
课程章节:5-10
课程讲师:少林码僧
课程内容:
为什么要做超时控制
放任请求挂起,直到超时,会严重影响用户体验,用户会一直等待直到不耐烦为止,比直接告诉用户服务当前不可用还要糟糕
服务端超时和客户端超时不一致,比如,当出现一个大规模搜索和排序的请求时,需要耗费非常久的时间,客户端已经超时了,服务器还在持续查询和排序,然而即使得到最终结果,也没有客户端需要了,这就造成了资源的浪费
如何实现超时控制
在http或者RPC调用中避免不合理的默认超时策略,可以通过全局统一配置或者使用相同的公共组建,来约定相同的超时时间
通过调用链中传递超时时间来对超时进行控制
在上图中,如果整个链路的超时设置为800ms,当A服务调用B的时候消耗了200ms,那么留给B的时间只剩下600ms,然而B自己处理的时候就超过了600ms,就不用调用C服务,这就直接报超时了。如果B服务消耗了500ms,那么留给C服务的只剩下200ms了
超时后重试应该注意什么
限制重试次数和比例,并非所有的场景都需要重试
使用指数递增的方式重试,并限制重试时间
客户端讲重试次数传递给服务端,让服务端决定是否需要拒绝请求
BFF是什么?
BFF是(Backends For Frontends)单词的缩写,主要是用于服务前端的后台应用程序,来解决多访问终端业务耦合问题。就是一个后台,多套API,从web到APP都能调用该服务。当然,并非是直接调用,而是通过BFF来调用。
直接调用内部服务的问题
多端如果直接裸连服务,可能造成一个端需要修改,各个端都要重新适配和测试大问题。这是高耦合导致的。
过于通用的返回内容,会导致各个端都需要独立处理下逻辑,比如pc端,pad端,phone端屏幕大小不同,返回的东西可能有差别(非前端展示问题,而是指数据,比如排行榜展示偏好,不同端的用户群体不一样)
BFF优势
调用端发生非功能性变化,无需后端参与,直接在BFF完成
后端发生一些变化,经过BFF适配,调用端也不用跟着改
后端只需要提供一些基础服务接口给BFF组合实现功能,类似于早期MVC架构里,把C给拿出来做成BFF,后端只需要构建M层的基础服务。
这篇关于【金秋打卡】第15天 构建微服务设计架构知识体系--超时控制和BFF的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-05-13TiDB + ES:转转业财系统亿级数据存储优化实践
- 2024-05-09“2024鸿蒙零基础快速实战-仿抖音App开发(ArkTS版)”实战课程已上线
- 2024-05-09聊聊如何通过arthas-tunnel-server来远程管理所有需要arthas监控的应用
- 2024-05-09log4j2这么配就对了
- 2024-05-09nginx修改Content-Type
- 2024-05-09Redis多数据源,看这篇就够了
- 2024-05-09Google Chrome驱动程序 124.0.6367.62(正式版本)去哪下载?
- 2024-05-09有没有大佬知道这种数据应该怎么抓取呀?
- 2024-05-09这种运行结果里的10.100000001,怎么能最快改成10.1?
- 2024-05-09企业src漏洞挖掘-有意思的命令执行