高并发服务必须有一些紧急方案,比如服务熔断,降级,隔离,限流,异步RPC等。服务熔断,降级,隔离大家比较倾向于用netflix开源的分布式服务弹性框架Hystrix。Hystrix也可以限流。但是我们服务用的guava的RateLimiter这种成熟的令牌桶算法来实现。
服务限流是个很简单的事情。我们的代码也就几百行,但是里面有一套比较完整的设计思想,目的是根据一定的策略(如:url, 平台来源,url+平台来源)来做一个业务细粒度的限流。
所有的请求都要走这个拦截器,这个拦截器里定义了一个单例的限流持有者,这个限流持有者按照配置的策略和配置的每个或者每种请求的限额来构成的map来返回给拦截器请求对应的key和RateLimiter。拦截器里判断超限则直接返回错误不交给控制器处理。一个请求类型,如url一个RateLimiter细粒度限流。
当然,除了这种应用级别的限流,在nginx层面也可以做一些对IP的session空间,请求频率,并发量的限制。如果遇到网络攻击,尽量先从运维层面去解决问题,因为越往上层,对服务的影响能降到最低。
一个好的软件架构能够满足系统的品质,使受益人达成一致的目标,能够支持计划编制过程,对系统开发的指导性,能够有效的管理复杂性,为复用奠定了基础,能够降低维护费用,能够支持冲突分析。但是做到这些之前,先要从一些最基本的做起。比如我24岁就结婚了,不然怎么面向对象编程。然后刚结婚就生娃了,不然对象跑了咋办?new一个?创建销毁开销很大的,还是生个娃持续持有对象的引用的好。
绝大多数架构或者编程语言的产生都是来源于项目。比如C++的发明者Stroustrup设计这个语言的初衷是看到C语言由于不合理的初始化参数导致至关重要的编程问题,这种bug很难发现。这种问题在清理的时候同样出现。做了坚持了,确实就成功了。然而任何一个东西都有一个形成和发展的阶段。java在老一些的版本中一直被吐槽性能问题,而它的每一个版本都要伴随着性能的提升,所以升级JVM就能带来免费的性能福利。细节处想到final关键字,在早期的版本中,final关键字的部分会内联调用,直接将函数展开,而不用不断的参数入栈出栈而引起性能开销。但是这个在函数体大的时候会有空间上比较大的开销。JVM在1.5开始进行了优化,final关键字性能上的作用就不再那么大了。原来公司有个同事,人很好,也很有想法。他说:“我总是会将自己的一些想法记录在一个本子上,然后过一段时间再看就会发现,我那篇只坚持了当时的其中一个想法,去做了,都成功了。”我认为