假设,我们一直有一个管理的金融理财的产品,这个产品是个单体应用,没有划分为微服务,后来,根据这个项目,我们开始进行了扩张,以此为基础,扩张了很多新的产品服务

对于新的产品,虽然长得不一样,但是很多功能和原有的金融理财产品一致,于是也是基于老产品的复制粘贴,在此基础上,修改,添加新的功能

这样只是简单的修改,方便,快速上线,一开始很好,但是时间一长,就开始出现开发效率低下的问题,因为多个团队维护的类似的代码,协作起来很麻烦,,每次发现新的Bug,都要同步到其他的团队做相同的处理,而且每个团队都对代码进行独立的迭代,添加一个通用的功能,也要基于自己的代码再重复开发

这样,不停的迭代,堆砌代码,时间一长,可能导致代码的可读性变差,维护成本变高

这时候怎么办呢?

可以将公共的功能,代码抽离出来,形成一个独立的项目,部署成公共的服务平台.然后对于公共的功能,远程的调用公共服务平台的接口来实现

这里提到的公共服务平台,类似比较火的中台或者微服务,不过而为了减少部署,维护多个微服务的成本,将公共的功能进行抽离,部署在一个应用中,然后在这个单一项目中进行良好的模块化划分,方便二次剥离称为单独的微服务

这样拆分后,我们只需要一个团队咱们的维护公共平台的代码,然后对于新开发的不同的金融产品,只需要更少的人来参与了,这样,整体的维护成本降低了,公共服务平台的代码集中到了一个团队中,方便重构,改善代码质量

然后根据这样的一个公共服务平台来说,会接收到不同的系统的调用请求,但是可能会因为调用方的bug,不正确的服务使用,业务上的突发流量, 导致某个暴露的接口的请求数量暴增,从而导致超时的现象

那么为此,我们就需要开发接口的限流功能,限制每个调用方对接口请求的频率,当超过预先设定的频率的时候,就触发限流熔断,比如,限制调用方app-1对公共服务平台的请求频率不超过1000个/s,超过了这个QPS,之后的接口请求都会被拒绝,而且还可以对单个接口的访问频率进行限制

不仅是这个公共服务平台,最好是可以做成一个通用的框架,能应用到各个不同的系统中,这样就体现了业务开发的抽象意识,框架意识

需求分析

我们已经有了需求,那么就要具体的详细的进行分析和整理

我们先说了诸如 画线框图,写用户示例,测试驱动开发,我们借助用户用力和测试驱动开发的事项,思考,这样的框架被开发出来,应该如何被使用,所以,可以先针对一个使用的场景,去确定这个框架长什么样

然后这个对应的应用场景,我们就需要设置针对什么app拦截多少,我们会把规则放在配置文件之中,XML YAML等,然后从配置文件中,解析出来规则放在内存中

configs:

– appId: app-1

limits:

– api: /v1/user

limit: 100

– api: /v1/order

limit: 50

– appId: app-2

limits:

– api: /v1/user

limit: 50

– api: /v1/order

limit: 50

接收到接口请求后,应用会将请求发送给限流框架,限流框架会告诉应用,这个接口是可以继续处理,还是触发限流熔断

String appId = “app-1”; // 调用方APP-ID

String url = “http://www.eudemon.com/v1/user/12345”;// 请求url

RateLimiter ratelimiter = new RateLimiter();

boolean passed = ratelimiter.limit(appId, url);

if (passed) {

// 放行接口请求,继续后续的处理。

} else {

// 接口请求被限流。

}

我们这样来看的话,框架整体就包含了两个部分功能,配置限流规则和提供编程接口验证是否被限流,同样,除了简单的功能性的需求,非功能性的需求也很重要,有时候会决定一个框架的成败,比如框架的易用性,框架的灵活性,性能,容错机制

非功能性的需求主要有

易用性的方面,可以更好,更快,更方便的配置限流规则,编程接口,基于内存的单机限流,基于Reids的分布式限流算法,让使用者自由的选择

扩展性,灵活性的方面,可以更好的扩展各种限流的算法,我们希望支持不同格式,不同数据源的限流规则的配置方式

性能方面,希望能够尽可能的低延迟,减少对接口本身响应时间的影响

容错性方面,接入限流框架为了提高可用性,稳定性,不能因为框架的异常而影响到服务本身的可用性,比如使用了Reids,Redis挂了,也不能影响到对正常服务的使用

本章重点

我们对整个限流框架进行了大的项目背景,需求背景的介绍,需求分析

对于这个限流框架来说,非功能的需求是大头,我们要做到易用,灵活,可扩展,低延迟,高容错

我们可以对需求进行需求分析,比如画线框图,用户用例,测试驱动等

课后思考

遇到哪些比较头疼的开发问题,如何解决的

短时间的代码重构,时间是真的紧,代码是真的烂

发表评论

邮箱地址不会被公开。 必填项已用*标注