设计稳健安全的应用系统

应用系统的定义是什么,怎样的应用系统才能算是稳健又安全,虽说可能仁者见仁智者见智,但有一些基本的东西应该大家都能认同,比如系统的健壮性、稳定性、可靠性、可用性等都是公认的指标。如何设计稳健安全的应用系统,其实这个命题非常宏大,但老夫我又不知道取一个怎样的名字更贴切,只能勉为其难了。

这篇文章提到的都是应用层的设计和性能优化思路,不包括像云计算平台那样的基础架构及其安全设计,如果想了解那方面的内容,建议读一下Google的安全架构白皮书,这里有个翻译版

很多年以前,我们总是听到三层架构的说法,其实可能是并没有细分,目前实际的应用系统中,一般会有四层或五层架构。那么谈到安全设计及性能优化时,不可避免的要逐层进行,从访问流程看,最前面的是APP或网站或桌面客户端,也就是产品层面,然后是API或者站点层面,再接着是服务层,可能还会有缓存层,最底下的是数据库。

1. 在产品层面,用户点击按钮后,按钮置灰,禁止重复提交请求,或者限制用户在一定时间之内只能提交一次请求;

2. 在API或站点层面,对uid进行请求计数和去重。比如一个uid,5秒只准透过1个请求其余的请求进行页面缓存,同一个uid,限制访问频度,x秒内到达站点层的请求,均返回同一页面。

3. 在服务层,对于写请求,放入请求队列,每次只透有限的写请求去数据层,比如有多少件商品就只透下去那么多个请求就好了。对于读请求,用Cache加速。根据实际业务需求,可能还会考虑分时段之类的,将流量摊匀。

4. 对于数据库层,现在一般的中小公司直接使用云数据库了,只要上面各层优化做的比较到位,数据库就不会有太大的压力,而且数据库的优化,我觉得还是留给云计算厂商来做,毕竟人家有专门的团队来折腾这个事情。

以上的总结起来,也就三点:

  1. 尽量将请求拦截在系统上游,这样无用或恶意请求,早点被打发走;
  2. 读多写少的使用缓存,写请求使用队列,只透有限的请求到数据库;
  3. 结合业务做优化,结合业务做优化,脱离业务的架构设计是耍流氓;

在安全方面,要使用https,密码不能明文保存在数据库中。这是应用层面能做的,而对于系统层面,使用云主机的话,遵循最小可见原则,关闭没有必要的端口及其对应的服务,及时打系统补丁,云主机的安全组设置得尽量严格,限制SYN半连接数目,缩短SYN半连接的超时时间,限制SYN/ICMP流量。系统日志、应用日志格式化,使得便于分析,经常观察日志的变化,有时候通过日志也能得到恶意访问或入侵的蛛丝马迹。然而即使这样,要应对DDOS这类攻击,还是非常难的,如业务非常关键,可考虑使用云厂商的DDOS防御服务,如阿里云的高防IP,其原理是将访问流量导到高防IP所在服务器(集群),清洗之后再转发到客户的云服务器(集群)。

目前老夫我能想到的就这些了,以后想到更多的话也许会补充进来。

严重参考了这篇文章:秒杀业务架构优化之路,感谢作者沈剑的分享!

发表评论

电子邮件地址不会被公开。