其他分享
首页 > 其他分享> > 七. Go服务器--可用性总结

七. Go服务器--可用性总结

作者:互联网

目录

1. 限流对比

类型 实现 优点 缺点
单机限流 令牌桶 1. 稳定可靠,实现简单,性能高
2. 支持突发流量应对

1. 流量不均匀会导致误限制
2. 阈值设置较为困难,需要提前压测
漏桶 1. 稳定可靠,实现简单,性能高 1. 流量不均匀会导致误限制
2. 阈值设置较为困难,需要提前压测
3.不支持突发流量
自适应限流: BBR 1. 根据服务状态进行动态限流
2. 阈值设置简单,无需提前进行压测
3. 服务扩容无需手动调整阈值
1. 需要主动采集相关指标数据(cpu等)
2. 客户端善意限流
3.应用场景较小
全局限流 - 1. 应用场景丰富
2. 流量不均不会误触限流,有全局数据,可以合理进行分配
3. 服务扩容无需手动调整阈值

1. 实现较为复杂
2. 配置也较为复杂

2. 微服务可用性设计总结

如上图所示, 从一个简单的用户访问出发,用户访问到我们的服务一般是先通过我们的移动客户端或者是浏览器,然后请求再依次通过 CDN、防火墙、API网关、BFF以及各个后端服务,整条链路还是比较长的。

我们上图其实已经一部分体现了隔离设计,所以后面我就不再提了。

2.1. 移动客户端/浏览器

客户端是触及用户的第一线,所以这一层做的可用性优化尤为的重要

2.2. BFF/Client

当请求来到 BFF 层的时候,BFF 既是服务端,又是客户端,因为它一般需要请求很多其他的后端服务来完成数据的编排,提供客户端想要的数据

2.3. Serve

BFF 其实也是服务端,但是为了流畅的讲解,主要将其作为了客户端的角色。服务端主要的是限流的措施,当流量从 BFF 来到我们的服务之后,我们会使用令牌桶算法尝试获取 token,如果 token 不够就丢弃,如果 token 足够就完成请求逻辑。

我们的 token 是从哪里来的呢?

拦截器会定时的向 Token Server 上报心跳数据,包含了一些统计信息,同时从 Token Server 获取一定数量的 Token,当 Token Server 接受到请求之后会通过最大最小公平分享的算法,根据每个服务实例上报的统计信息进行 Token 的分配。

这个其实就是分布式限流的思路,在单个服务实例上又使用了单机限流的算法

3. 总结

面对一款百万级的应用,随着服务器组件的增多,微服务是首先的架构设计方案, 而如何设计微服务,首先就得考虑可用性了。包括隔离设计、限流(单机限流、自适应限流、分布式限流)、超时控制、降级、熔断、负载均衡、重试,这些关键点又是优化,改进,和设计微服务的主要思想。

4. 参考

  1. https://lailin.xyz/post/go-training-week6-7-summary.html

标签:服务,BFF,--,可用性,重试,限流,Go,超时,客户端
来源: https://www.cnblogs.com/failymao/p/15249760.html