设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
新⼈⾸单¥69.9
29839 人已学习
课程目录
已完结 113 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (12讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
25 | 实战二(上):针对非业务的通用框架开发,如何做需求分析和设计?
26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (11讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
29 | 理论三:什么是代码的可测试性?如何写出可测试性好的代码?
30 | 理论四:如何通过封装、抽象、模块化、中间层等解耦代码?
31 | 理论五:让你最快速地改善代码质量的20条编程规范(上)
32 | 理论五:让你最快速地改善代码质量的20条编程规范(中)
33 | 理论五:让你最快速地改善代码质量的20条编程规范(下)
34 | 实战一(上):通过一段ID生成器代码,学习如何发现代码质量问题
35 | 实战一(下):手把手带你将ID生成器代码从“能用”重构为“好用”
36 | 实战二(上):程序出错该返回啥?NULL、异常、错误码、空对象?
37 | 实战二(下):重构ID生成器项目中各函数的异常处理代码
设计原则与思想:总结课 (3讲)
38 | 总结回顾面向对象、设计原则、编程规范、重构技巧等知识点
免费
39 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(上)
40 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(下)
设计模式与范式:创建型 (7讲)
41 | 单例模式(上):为什么说支持懒加载的双重检测不比饿汉式更优?
42 | 单例模式(中):我为什么不推荐使用单例模式?又有何替代方案?
43 | 单例模式(下):如何设计实现一个集群环境下的分布式单例模式?
44 | 工厂模式(上):我为什么说没事不要随便用工厂模式创建对象?
45 | 工厂模式(下):如何设计实现一个Dependency Injection框架?
46 | 建造者模式:详解构造函数、set方法、建造者模式三种对象创建方式
47 | 原型模式:如何最快速地clone一个HashMap散列表?
设计模式与范式:结构型 (8讲)
48 | 代理模式:代理在RPC、缓存、监控等场景中的应用
49 | 桥接模式:如何实现支持不同类型和渠道的消息推送系统?
50 | 装饰器模式:通过剖析Java IO类库源码学习装饰器模式
51 | 适配器模式:代理、适配器、桥接、装饰,这四个模式有何区别?
52 | 门面模式:如何设计合理的接口粒度以兼顾接口的易用性和通用性?
53 | 组合模式:如何设计实现支持递归遍历的文件系统目录树结构?
54 | 享元模式(上):如何利用享元模式优化文本编辑器的内存占用?
55 | 享元模式(下):剖析享元模式在Java Integer、String中的应用
设计模式与范式:行为型 (18讲)
56 | 观察者模式(上):详解各种应用场景下观察者模式的不同实现方式
57 | 观察者模式(下):如何实现一个异步非阻塞的EventBus框架?
58 | 模板模式(上):剖析模板模式在JDK、Servlet、JUnit等中的应用
59 | 模板模式(下):模板模式与Callback回调函数有何区别和联系?
60 | 策略模式(上):如何避免冗长的if-else/switch分支判断代码?
61 | 策略模式(下):如何实现一个支持给不同大小文件排序的小程序?
62 | 职责链模式(上):如何实现可灵活扩展算法的敏感信息过滤框架?
63 | 职责链模式(下):框架中常用的过滤器、拦截器是如何实现的?
64 | 状态模式:游戏、工作流引擎中常用的状态机是如何实现的?
65 | 迭代器模式(上):相比直接遍历集合数据,使用迭代器有哪些优势?
66 | 迭代器模式(中):遍历集合的同时,为什么不能增删集合元素?
67 | 迭代器模式(下):如何设计实现一个支持“快照”功能的iterator?
68 | 访问者模式(上):手把手带你还原访问者模式诞生的思维过程
69 | 访问者模式(下):为什么支持双分派的语言不需要访问者模式?
70 | 备忘录模式:对于大对象的备份和恢复,如何优化内存和时间的消耗?
71 | 命令模式:如何利用命令模式实现一个手游后端架构?
72 | 解释器模式:如何设计实现一个自定义接口告警规则功能?
73 | 中介模式:什么时候用中介模式?什么时候用观察者模式?
设计模式与范式:总结课 (2讲)
74 | 总结回顾23种经典设计模式的原理、背后的思想、应用场景等
75 | 在实际的项目开发中,如何避免过度设计?又如何避免设计不足?
开源与项目实战:开源实战 (14讲)
76 | 开源实战一(上):通过剖析Java JDK源码学习灵活应用设计模式
77 | 开源实战一(下):通过剖析Java JDK源码学习灵活应用设计模式
78 | 开源实战二(上):从Unix开源开发学习应对大型复杂项目开发
79 | 开源实战二(中):从Unix开源开发学习应对大型复杂项目开发
80 | 开源实战二(下):从Unix开源开发学习应对大型复杂项目开发
81 | 开源实战三(上):借Google Guava学习发现和开发通用功能模块
82 | 开源实战三(中):剖析Google Guava中用到的几种设计模式
83 | 开源实战三(下):借Google Guava学习三大编程范式中的函数式编程
84 | 开源实战四(上):剖析Spring框架中蕴含的经典设计思想或原则
85 | 开源实战四(中):剖析Spring框架中用来支持扩展的两种设计模式
86 | 开源实战四(下):总结Spring框架用到的11种设计模式
87 | 开源实战五(上):MyBatis如何权衡易用性、性能和灵活性?
88 | 开源实战五(中):如何利用职责链与代理模式实现MyBatis Plugin?
89 | 开源实战五(下):总结MyBatis框架中用到的10种设计模式
开源与项目实战:项目实战 (9讲)
90 | 项目实战一:设计实现一个支持各种算法的限流框架(分析)
91 | 项目实战一:设计实现一个支持各种算法的限流框架(设计)
92 | 项目实战一:设计实现一个支持各种算法的限流框架(实现)
93 | 项目实战二:设计实现一个通用的接口幂等框架(分析)
94 | 项目实战二:设计实现一个通用的接口幂等框架(设计)
95 | 项目实战二:设计实现一个通用的接口幂等框架(实现)
96 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(分析)
97 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(设计)
98 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(实现)
开源与项目实战:总结课 (1讲)
99 | 总结回顾:在实际软件开发中常用的设计思想、原则和模式
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

91 | 项目实战一:设计实现一个支持各种算法的限流框架(设计)

文章 2020-06-01
上一节课,我们介绍了限流框架产生的项目背景,并且对需求做了分析,这其中包括功能性需求和非功能性需求,算是在正式开始设计之前的一个铺垫。
前面提到,我们把项目实战分为分析、设计、实现三部分来讲解。其中,分析环节跟之前讲过的面向对象分析很相似,都是做需求的梳理。但是,项目实战中的设计和实现,跟面向对象设计和实现就不是一回事儿了。这里的“设计”指的是系统设计,主要是划分模块,对模块进行设计。这里的“实现”实际上等于面向对象设计加实现。因为我们前面讲到,面向对象设计与实现是聚焦在代码层面的,主要产出的是类的设计和实现。
今天,我们分限流规则、限流算法、限流模式、集成使用这 4 个模块,来讲解限流框架的设计思路。上节课我们提到,限流框架的基本功能非常简单,复杂在于它的非功能性需求,所以,我们今天讲解的重点是,看如何通过合理的设计,实现一个满足易用、易扩展、灵活、低延时、高容错等非功能性需求的限流框架。
话不多说,让我们正式开始今天的学习吧!

限流规则

框架需要定义限流规则的语法格式,包括调用方、接口、限流阈值、时间粒度这几个元素。框架用户按照这个语法格式来配置限流规则。我举了一个例子来说明一下,如下所示。其中,unit 表示限流时间粒度,默认情况下是 1 秒。limit 表示在 unit 时间粒度内最大允许的请求次数。拿第一条规则来举例,它表示的意思就是:调用方 app-1 对接口 /v1/user 每分钟的最大请求次数不能超过 100 次。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥69.9
立即订阅
登录 后留言

精选留言(13)

  • 小晏子
    在不同的业务场景下,对于每个接口,时间粒度和限流值的选择都是不同的,比如在平时和大促(如618,11.11)时,因为服务器数量不同,所以选择也不同,比如在618时,流量可能都集中在几秒内,TPS 会非常大,几万甚至几十万,需要选择相对小的限流时间粒度,相反,如果接口 TPS 很小,则使用大一点的时间粒度,比如限制 1 分钟内接口的调用次数不超过 1000 。 对于限流值的选择,需要结合性能压测数据、业务预期流量、线上监控数据来综合设置,最大允许访问频率不大于压测 TPS,不小于业务预期流量,并且参考线上监控数据。
    如何验证设置的合理性?可以通过导流的方式将流量集中到一小组机器上做真实场景的测试,并记录下每个请求的对应接口,请求时间点,限流结果,进行分析。另外我们还需要时刻监控限流的工作情况,实时了解限流功能是否运行正常。一旦发生限流异常,能够在不重启服务的情况下,做到热更新限流配置。
    2020-06-01
    32
  • Jie
    以前在耗子叔专栏看到过动态流控的文章(左耳听风49节),可以借鉴了TCP使用RTT来探测网络延时和性能,从而设定相应滑动窗口,根据调用方一段时间内响应时间的P90或P99值,来作为限流的参考。这个一样可以用在限流框架上的。
    2020-06-01
    11
  • 马以
    限流框架文档哪里可以看到?

    作者回复: https://github.com/wangzheng0822

    2020-06-01
    4
    7
  • Jxin
    1.限流值的大小一般在预估流量~压测流量满足响应时长下的最大吞吐之间。
    2.时间力度的选择要看场景。首先明确一点,时间力度越小,流量峰值则越小。服务群能否正常提供服务,看的是流量峰值是否小于压测流量最大值(拐点)。那么在整点秒杀这种场景,时间力度就要尽可能小,结合人机检验和先抢购买权等策略降低并发度后,时间窗口应该也能使用。但如果是阿里京东这种大型电商公司的双11,时间窗口就不合适了,除非你的集群规模大于当前时间力度的最大峰值(并行度很可能真达到峰值),不然限流策略都很难保护服务群。而这样的规模服务,在serverless普及前,成本是接受不了的(请求上来时服务瞬间扩容,过去后又瞬间缩容)。这时采用类似均速发牌的算法就合适些。而在平时业务稳定期,时间力度就可以长一些,因为这个时候流量比较平缓,峰值一般都不会很高,只需要做粗力度的流量控制即可。

    3.验证是否合理:模拟或则镜像流量压测不能压垮服务,且尽量去减少计算资源。满足稳定服务的前提下,尽量减少计算成本。用合适的成本,提供稳定的服务才叫合理。
    2020-06-01
    5
  • 迷羊
    可以先测试自己的应用调用接口的次数,合理的使用。怎么验证合理性,主要还是看具体的应用调用次数,可以测出来的。
    2020-06-01
    2
  • test
    思考题:需要结合线上流量的情况,包括均值和峰值
    2020-06-01
    2
  • Heaven
    对于限流的框架使用,高流量不可怕,就怕暴涨击穿的问题,对于可以预测的平稳访问,设置的粒度大点无可厚非,对于可能出现的一些短时高流量服务,可以设置的粒度低些,当然,在实际开发中,我们还有各种缓存服务器,CDN帮助我们开发,避免流量过大问题
    2020-06-01
    1
  • Jackey
    实践一下吧,可以拿正常的线上流量回放保证不被限流。再用压测流量压一下,保证服务不down就ok
    2020-06-01
    1
  • Magic
    1 时间粒度:观察接口线上流量监控,如果存在流量尖刺(一秒内流量瞬间飙升),且尖刺会影响系统稳定性,那么时间粒度应该设置为秒。如果流量较均衡,且系统对请求量具有一定的宽容度,则可以适当调大限流粒度。
    2 限流值:模拟真实情况进行压测,当请求量到达某一个点时,系统失败率快速上升,则应该将该点设置为限流值,具体还可以参考线上监控
    2020-08-11
  • cricket1981
    背压等于限流吗?如果是的话,要如何实现基于HTTP的restful api背压?

    作者回复: 限流<你说的背压。如何做压力测试,你可以看下我github上的文章:https://github.com/wangzheng0822

    2020-06-25
  • cricket1981
    这种限流是不是应该结合物理资源监控动态调整比较好?

    作者回复: 太复杂了~效果并不一定好~

    2020-06-25
  • javaadu
    一般粒度都是选择秒级限流,限流值设置的事峰值流量的6倍左右,另外我们还设计了基于限流报错都自愈扩容系统,在大促洪峰到达时可以及时扩容增加容量
    2020-06-21
  • kylexy_0817
    好的框架的配置文件schema和说明也重要^_^
    2020-06-10
收起评论
13
返回
顶部