课程名称：海量数据高并发场景，构建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层的基础服务。