【金秋打卡】第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层的基础服务。