![](https://img-blog.csdnimg.cn/20201014180756754.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
微服务
文章平均质量分 73
做技术的Pandaer
这个作者很懒,什么都没留下…
展开
-
微服务架构-第三方调用
但是在软件开发中,有一个基本原则,永远不要相信别人的东西,也就是我们提倡的防御性编程,在对接第三方平台也不例外,第三方平台终究是别人的,你没有办法要求第三方平台保证高可用性,所以一般对接第三方平台的时候,我们都会抽象出一个层,比如对接第三方支付平台的时候,我们通常会在我们的系统中抽象出一个单独的模块来负责对这些第三方支付平台的对接功能,这其实是我们最熟悉的分层架构,这种架构设计将关注点分离,将变化隔离,即使后期需求发生改变,我们需要改动的也只是这个模块而已。这是一个对接模块最最基本的功能。原创 2024-07-13 10:16:46 · 341 阅读 · 0 评论 -
微服务可用性-超时控制
当然你也可以结合时间戳,比如在协议头中记录了调用服务B时的时间戳,然后当服务B接收到的时候,根据自己的时间减去协议头中记录的时间就可以得出传输耗费的时间,但是这个策略多此一举,与其这样,不如直接使用超时时间戳,还是这个例子,服务A调用服务B,当服务A接收到用户的请求时,根据这个业务的超时时间,记录超时时间戳,比如当前时间为9:30:40,这个业务的超时时间为1s,那么超时时间戳为9:30:41,将这个时间戳传递给服务B,服务B在执行业务的时候判断当前时间是否超过了这个时间戳就可以了。根据被调服务响应时间。原创 2024-07-12 09:55:50 · 602 阅读 · 0 评论 -
微服务可用性-降级
唯一不同的就是,降级会针对整个系统的服务进行等级划分,比如有些服务价值高那么等级就高,当很多很多请求来到这个价值高的服务时,它自身承受不住了,但是奈何它价值高,它有权力让那些价值低的服务让出资源,给它用。这就是我眼中的降级,那你眼中的呢?这是目前主流的降级策略,但是还有一种降级策略比较有意思,不仅服务分个三六九等,就连用户请求也可以分为三六九等,针对某个服务而言,当负载较大的时候,我们可以只处理VIP请求,拒绝普通请求,毕竟白嫖用户肯定比付费用户多。我需要说明的是,无论是降级还是熔断,他们都在尽力的保证。原创 2024-07-02 09:00:35 · 356 阅读 · 0 评论