<![CDATA[振华博客]]> http://www.zhenhua.org/ UTF-8 LBS v2.0.313 Tue, 07 Sep 2010 20:45:44 +0800 60 <![CDATA[WEB性能提升规则 High Performance Web Sites]]> ]]> Tue, 27 Apr 2010 12:33:38 +0800
由谁提出的
来自Yahoo! Exceptional Performance team

什么时候开始发起的
2004年开始研究，2007年4月开始，陆续发布,(5月,7月,9月)

为什么
Yahoo希望对自己的产品性能做出一些测量和改善

成绩
总结出14条提升WEB产品性能的准则（后续21条）



第一条：最小化HTTP请求(Frontend)

将CSS文件和JS文件合并（可行性不高）
CSS Sprites
Image Maps(很久以前经常使用的“热区”)
Inline Images,data:URL（浏览器兼容问题）

每天大概有40-60%的访问者去到我们的站点的时候都是empty cache，所以，
我们如果能够使得他们在第一次访问时速度更快，那对他们来说将获得很好的体验。



第二条：使用内容分发网络 (Server)

将静态文件分发到其他独立的服务器上。
目的：使得用户可以就近获取到]]> <![CDATA[MVC模式已死]]> ]]> Wed, 21 Apr 2010 19:17:17 +0800
但是，随着时间推移，MVC模式也暴露出大量缺点，因为MVC模式本质上是一个结构型模式，结构模式相比行为模式而言，实际就是静止的，相对固定的，而随着B/S和互联网应用不断普及，Web 2.0和社会化媒体 以及游戏等大量频繁交互应用普及，相对静止的MVC模式已经不适合高度交互注重行为的应用了。

DDD领域建模本身比较重视结构，它的实体 值对象和服务器是也是一种结构划分，但是没有强调对象职责行为的重要性，而这是对象和数据库唯一的区别，当然其上下文场景概念的提出，也可以认为体现了对角色和场景的重视，但远远不够。

相反，对象设计：角色、责任和协作"(Object Design: Roles, Responsibilities, and Collaborations))一书提出职责驱动开发，将对象行为上升为重点，提出了对象其实是在扮演某种角色，而角色是有职责的，然后会在一定场景上下文环境中实施一定交互行为，这些已经在Jdon进行了充分讨论：
]]> <![CDATA[struts2 与 Spring MVC比较]]> ]]> Sat, 17 Apr 2010 21:26:51 +0800 struts2实际上是通过setter getter方法与request打交道的
struts2中，一个Action对象对应一个request上下文

spring3 mvc不同，spring3mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去
在spring3mvc中，一个方法对应一个request上下文

好了 我们来整理一下
struts2是类级别的拦截， 一个类对应一个request上下文，
springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应
所以说从架构本身上 spring3 mvc就容易实现restful url
而struts2的架构实现起来要费劲
因为struts2 action的一个方法可以对应一个url
而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了

===================================
]]> <![CDATA[SNS好友动态设计]]> ]]> Tue, 05 Jan 2010 20:43:36 +0800 http://www.javaeye.com/topic/176677?page=1

跨应用Session共享
http://oiote.blog.sohu.com/94812998.html]]> <![CDATA[开心网系统架构分析]]> ]]> Sat, 31 Oct 2009 17:04:10 +0800
关于开心网的系统架构分析

一．入口篇
从http://www.kaixin001.com/，从这个页面可以看到，开心网的图片，是放在http://img.kaixin001.com上的，做了程序与图片的分离（http://www.kaixin001.com/i...这个不知为什么没有分离）。
下面来看一下开心网前端的服务器情况，nslookup一下，可以看到，一共有下面的17个IP
220.181.66.138，123.103.12.24，123.103.12.25，123.103.12.26，123.103.12.27
123.103.12.28，123.103.12.36，123.103.12.37，123.103.12.38，123.103.12.39
123.103.101.98，123.103.101.107，12]]> <![CDATA[网站架构收集]]> ]]> Sat, 31 Oct 2009 00:11:22 +0800
来自sudone.com 服务器系统架构分析日志
csdn.net的系统架构研究 http://sudone.com/archie/csdn_archive.html
图片服务器的hash架构 http://sudone.com/archie/image_hash.html
天涯bbs系统架构分析 http://sudone.com/archie/tianya.cn.html
v.2008.163.com对新架构的尝试 http://sudone.com/archie/v.2008.163.com.html
nginx和squid配合搭建的web服务器前端系统 http://sudone.com/archie/app_nginx_squid.html
nginx作为最前端的web cache系统 http://sudone.com/archie/app-nginx-squid-nginx.html
新型的大型bbs架构（squid+nginx） http://sudone.com/archie/archi_bbs.html
当前比较适用的海量小文件系统架构方案 ]]> <![CDATA[页面加载对访问的影响]]> ]]> Fri, 30 Oct 2009 23:43:51 +0800
举个例子，某页面浏览到一个地方卡住了，至少要等十几秒才出来内容。排查原因，浏览其他网站页面很快，说明客户端网络带宽没问题；浏览同个服务器上其他网站页面都很快，说明服务器的处理速度和网络带宽也没问题。分析代码可能有好几种情况，在YUI官方加速网站的最佳办法提到了13条方法，对于普通产品来说，个人认为有几条应该强化注意，其他（灰色）从性价比上来说则成本有点高。
  • Make Fewer HTTP Requests 更少的HTTP请求
  • Use a Content Delivery Network 使用CDN
  • Add an Expires Header 指定过期时间
]]> <![CDATA[Struts 标签与JSP效率对比]]> ]]> Fri, 30 Oct 2009 23:40:12 +0800
1.JSP版本
 < % long s=System.currentTimeMillis();%>
< SPAN style="DISPLAY: none">

< % for(int i=0;i<10000;i++){%>

< %=theAction.getQueryString()%>

< %}%>

< /SPAN>

< % long e=System.currentTimeMillis();%>

< %=(e-s)%>
2.webwork (webwork版本，也可换成Struts标签)
 < % long s=System.currentTimeMillis();%>
< % for(int i=0;i<10000;i++){%>

< ?xml:namespace prefix = ww />< ?xml:namespace prefix = ww />

< %}%>

< /SPAN>

< % long e=System.currentTimeMillis();%>

< %=(e-s)%>
]]> <![CDATA[web架构设计经验分享]]> ]]> Wed, 21 Oct 2009 13:16:27 +0800

本人作为一位web工程师，着眼最多之处莫过于 性能与架构，本次幸得参与sd2.0大会，得以与同行广泛交流,于此二方面，有些心得，不敢独享，与众博友分享，本文是这次参会与众同撩交流的心得，有兴趣者可以查看视频
架构设计的几个心得：

一，不要过设计：never over design

这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最快最有效的响应。。
ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构
web开发，是个非常敏捷的过程，变]]> <![CDATA[数据库水平切分的实现原理解析－分库，分表，主从，集群，负载均衡器]]> ]]> Wed, 21 Oct 2009 13:05:04 +0800 关键字: 水平切分，分库，分表，主从，集群
第1章 引言
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的 互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层 已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台 机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取 （Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大 都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的 实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶 ]]>