月度归档:2014年07月

一周随记之 2014-07. 21-27

2014-07. 21-27

7.21-23

另一个项目组在搞动静分离,所有的静态资料由 Nginx 处理,动态资料由 JBoss 处理,域名不同,产生跨域问题(跨域请求和跨域 Cookie 传送)。其实访问量不大,没必要这么折腾,由 Nginx 做代理和处理静态资源完全够了。

域是浏览器的安全策略,可以说跟服务器端无关。可参考:

7.24

早上到办公室后,想从手机里拷点资料到电脑来看,发现了一个已被遗忘的好东西:《阿里巴巴集团web安全标准Ver1.4》,开发必备,码农普及安全编程的良药。

顺便推荐《白帽子讲web安全》,这本书买之前还犹豫值不值,看完第一章就觉得已经值回书价了。这个经历也改变了我对买书的看法:如果一本书能带来一点改变、甚至一点感触或启发就值回书价了。

继续阅读

《Java 虚拟机并发编程》笔记

并发

线程数 = CPU可用核心数 / ( 1 – 阻塞系数 )
阻塞系数的取值在 0 - 1 之间,计算密集型任务的阻塞系数是 0,IO 密集型任务的阻塞系数接近于 1。

构建计算密集型并发应用程序的几点经验:
* 子任务的划分数不少于处理器核心数;
* 线程数多于处理器核心数对性能提升毫无帮助;
* 在子任务划分超过一定数量之后,再增加子任务划分数对于性能的提升将十分有限。

保持一个合理的划分数,并使所有处理器核心都有足够的工作量才是关键。

应该尽可能地提供共享不可变性,否则就应该遵循隔离可变性原则,即保证总是只有一个线程访问可变变量。

开多少个线程以及如何拆分问题都会影响到你的并发应用程序的性能,还要权衡每个子任务的工作负载和划分开销。

继续阅读

Spring MVC 与 web开发

项目组用了 Spring MVC 进行开发,觉得对里面的使用方式不是很满意,就想,如果是我来搭建开发环境,我会怎么做?下面就是我的想法,只关注于 MVC 的 View 层。

一、统一的响应格式

现在基本上都是用 ajax 来调用后台接口,拿到 json格式的数据再展示,有的人直接返回数据,却没有考虑异常的情况,我觉得返回的报文里必须包含表示可能的异常信息的数据和业务响应数据。我定义了下面这个类来表示报文格式:

/**
 * 统一的 HTTP 响应格式。<br/>
 * code 为 "ok" 表示业务调用成功,否则是失败的错误码,如果有多个则以逗号分隔。<br/>
 * data 是业务数据,如果失败了则是 null。
 * 
 * @author http://coderbee.net
 *
 */
public class RespBody {
    public static final String OK_CODE = "ok";
    private final String code;
    private final Object data;

    private static final RespBody OK = new RespBody(OK_CODE, null);

    private RespBody(String code, Object data) {
        this.code = code;
        this.data = data;
    }

    public static RespBody ok() {
        return OK;
    }

    public static RespBody ok(Object data) {
        return new RespBody("ok", data);
    }

    public static RespBody error(String code) {
        return new RespBody(code, null);
    }

    public static RespBody error(String code, Object msg) {
        return new RespBody(code, msg);
    }

    public String getCode() {
        return code;
    }

    public Object getData() {
        return data;
    }
}

这个类提供了一些静态方法来快速构建响应报文,这也是很重要的一个设计:用静态工厂方法而不是构造函数。

这里的 code 不应该是直接的错误提示信息,应该只是简单的错误编码,这样不同的客户端都可以调用这个 API,然后再根据错误编码、客户端语言和自己的客户端特性选择合适的错误提示信息和提示方式。

继续阅读

《大型网站技术架构》 笔记 - 架构篇

第四章 瞬时响应:网站的高性能架构

4.1 网站性能测试

性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准。

性能测试的指标有:响应时间、并发数、吞吐量、性能计数器。

网站性能优化的目的,除了改善用户体验的响应时间,还要尽量提升系统吞吐量,最大限度利用服务器资源。

4.2 Web 前端性能优化

主要手段有优化浏览器访问、使用反向代理、CDN加速等。

继续阅读