应用架构设计“防火”经验分享

应用架构设计“防火”经验分享

Author : 岑文初(淘宝花名：放翁)

Email: fangweng@taobao.com

Blog: http://blog.csdn.net/cenwenchu79

Date: 2009-08-26

 

         刚从阿软到淘宝不久，现在主要负责TOP平台的技术框架设计，同时要肩负“救火”和“防火”的工作，也需要培养团队的同学能够有“防火”意识，减少“救火”次数，因此今天下午花了一点时间，也没于写任何的PPT，就直接将自己想的起来的一些自己认为应用架构设计“防火”知识做了一下事例分享，这里也想记录下来给更多的同学分享一下，当然很多都是老生常谈的常识，但是有时候不经意就会忘记一些血的教训。

 

资源是有限的

着火点：

系统设计的时候总是估摸不到会有大数据量从远端传输过来（例如处理Http请求时，对于大附件内容的处理，全部装载到内存，结果资源耗尽。从搜索引擎或者DB或者缓存里面拉数据，没有分页，结果内存被吃尽。Socket无限建立连接，结果linux的文件句柄被耗尽。）

防火点：

对业务场景中资源的分配与申请需要做到上限控制，以及达到上限以后的逻辑处理（排队，丢弃，告警）。可以采取一些滑动窗口设计来将不需要过多处理的内容分段直接送入下一个处理管道中。

 

依赖是未知的

着火点：

事务中嵌入对于第三方系统的请求（例如在数据库操作时去发送邮件或者缓存获取内容，结果连接池资源被Hold，导致系统不可用）。默认依赖系统会给出结果，如果出现异常就反复重试，结果对方被压垮，自己也牺牲。

         防火点：

         对于第三方系统的依赖能够异步的就采用异步方式，能够从主流程中剥离的就剥离。同时设计好容错的机制，采用本地时效性缓存减少对对方的压力和依赖。最重要的就是注意系统间的死锁，申请了一套资源处理业务逻辑，结果由于远端系统的不可用，导致本地资源的无法释放，最后击垮自己系统。

 

线程安全与性能

         着火点：

         对于线程不安全的对象处理一定要小心，否则业务出现异常的地方其实已经离设计出现问题的地方十万八千里，问题时常成为灵异问题，解决只有靠经验。

         防火点：

         首先对于自己设计的类和方法需要注释是否是线程安全的。同时明确类的使用场景，对线程安全及高性能作判断，因为采用线程安全的对象一定会有性能损耗。最近给同学写的一个Http消息的Lazy获取参数，就是线程不安全的类，但是这个类只会保存在ThreadLocal中，因此不存在问题。很直观的一点判断是否线程安全，就看看你设计的类里面的成员变量在多线程操作时候是否会有并发问题，例如一个普通的Map