系统架构
未读负载均衡
这里把多台nginx反向代理服务器顶在最前面，可以通过DNS简单轮循或绑定虚拟IP的方法来实现分流。之所以用nginx是因为它的稳定、强大、高性能、低开销、以及对高并发的支持。也可以换成LVS，从效率上来说肯定会比nginx高，因为工作在OSI的第四层(传输层)，可以修改目标IP。甚至可以在第二层(数据链路层)修改MAC地址(DR模式，相当于路由器)，让数据包直接到达目标服务器。不过工作在下层虽然效率提高了，但相应的控制能力也少了，比如无法根据http url来进行负载均衡，缓存页面执行结果等等。
应用层
这一层是web服务器，主要任务是从服务层获取需要的数据，然后渲染到模板，返回给前端服务器。可以理解为Controller-View，没有Model，因为Model被移到了一下层，用来单独提供服务。这么做的原因是方便分布式部署，单元测试，避免单点故障。所以这层是相对较轻松的。
服务层
这一层的任务是提供模块的接口，供上层调用。如相册模块，需要有创建相册/显示相册图片/删除图片等等功能。至于服务的形式就很灵活了，如REST/RPC/SOA ...
系统架构
未读这几天一直在关注和学习一些大型网站的架构，希望有一天自己也能设计一个高并发、高容错的系统并能应用在实践上。今天在网上找架构相关的资料时，看到一个被和谐的视频网站YouTube的架构分析，看了以后觉得自己又向架构走近了一步，于是赶快拿出来与大家一起分享。
YouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。这点和PlentyOfFish类似，少数人维护庞大系统。是什么原因呢？放心绝对不是靠人品，也不是靠寂寞，下面就来看看YouTube的整体技术架构吧。
平台
123456<strong>ApachePythonLinux(SuSe)MySQLpsyco，一个动态的Python到C的编译器lighttpd代替Apache做视频查看</strong>
状态
123456<strong>支持每天超过1亿的视频点击量成立于2005年2月于2006年3月达到每天3千万的视频点击量于2006年7月达到每天1亿的视频点击量2个系统管理员，2个伸缩性软件架构师2个软件开发工程师，2个网络工程师，1个DBA</strong> ...
在使用动态语言和.NET工作了若干年后，我又回到老本行–Java开发。在Ruby中，清除代码冗余是非常方便的，而在Java中则需要结合接口和泛型实现类似的功能。
原始代码
以下是这个类中的一些方法用于后续的阐述。为了使例子更简洁，我移除了些代码。
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152public V get(final K key) { Session s; try { s = oGrid.getSession(); ObjectMap map = s.getMap(cacheName); return (V) map.get(key); } catch (ObjectGridException oge) { throw new RuntimeException(&q ...
“菜鸟”和“大神”刚刚走出就业的程序员，技术是刚刚起步的基点。那下面我们就聊一聊有关技术的东西。首先请您先想想这几个问题。现在社会上有很多程序员，CSDN就是我们程序员的家，那您是否可想过程序员为什么会有不同的水平？你又是哪一类的程序员？“菜鸟”程序员和“大神”程序员差在哪里？真是差在技术上了吗？那不是差在技术上那差在了哪里？
上面很多一连串的问题，没有把你搞晕吧！那就听我一一给您分析这个问题背后的答案。确切的说程序员分为“菜鸟”程序员和“大神”程序员。
一个程序员有多优秀，就得看他写的代码！程序员自己的代码才是自己工作状态的真实体现。
“菜鸟”程序员和“大神”程序员到底有什么区别哪，那我们就来看看。
代码的展现，网络的应用展现题目：一个很小的功能，比如说一个当鼠标移动到一个标题下，在下面显示其可选菜单。
“菜鸟”程序员的代码是什么样子，自己想一下。“菜鸟”程序员的代码往往会会写的比较冗余，而且这些代码不是从书上找来的就是从网上找来的还有可能就是自己会这一部分代码（仅存记忆的提取，真正的原理似懂非懂，好像雾里看花）。
“大神”的代码会写成什么哪？“大神”程序员的代码，当你看的第一眼：简 ...
gzdd
未读我的同事朋友Chris Eargle写了一篇关于新年计划的有趣文章。他让我想到了，没有出现那场世界末日是我们多么大的幸运呀(还有其他我这45年中躲过的天灾)，于是，我也有了一些我自己的以程序员为主题的新年计划。
我的同事朋友Chris Eargle写了一篇关于新年计划的有趣文章。他让我想到了，没有出现那场世界末日是我们多么大的幸运呀(还有其他我这45年中躲过的天灾)，于是，我也有了一些我自己的以程序员为主题的新年计划。
找到一名导师/成为一名导师
在你的职业生涯中，你能做的会给你带来最多麻烦的事就是成为屋里最聪明的人。我说的并不是你坚信自己你就是屋里最聪明的人。我的意思是你成为团队里真正的万事通。问题终结者。终极疑难解答者。
于是，这就有了另外一个问题：你有疑问了去问谁呢？
如果你的回答是“谷歌”，那你是不思进取。去到那些你认识的(或不认识的)最聪明的人中间去。参加你们的本地社团。去你们本地的编程活动中发言，去和其他的讲演者一起喝酒聊天。找那些你可以接触到的人，让他们成为你的导师。
找到一名导师
我在生活中有好几位导师。他们是我尊敬的人和能让我轻松问问题的人。有些人甚至非常 ...
一、结构介绍高层结构图：
wrappers包：
handlers包（部分）:
二、功能介绍commons.dbutils是一个对JDBC操作进行封装的类集，其有如下几个优点：
（1）没有可能的资源泄漏，避免了繁锁的JDBC代码
（2）代码更整洁
（3）从ResultSet自动生成JavaBeans属性
（4）无其他依赖包
三、基本使用基本用到的类有：QueryRunner、ResultSetHandler及其子类等
QueryRunner – 执行查询的类，可以执行SELECT、INSERT、UPDATE、DELETE等语句，QueryRunner用ResultSetHandler的子类来处理ResultSet并返回结果；而包提供的ResultSetHandler子类使用RowProcessor的子类来处理ResultSet中的每一行；RowProcessor的默认实现为BasicRowProcessor；BeanProcessor不是RowProcessor，可以看作一个工具类
ResultHandler及其子类 – 实现了Object handle(ResultSet rs) ...
从上百幅架构图中学大型网站建设经验（上）
引言近段时间以来，通过接触有关海量数据处理和搜索引擎的诸多技术，常常见识到不少精妙绝伦的架构图。除了每每感叹于每幅图表面上的绘制的精细之外，更为架构图背后所隐藏的设计思想所叹服。个人这两天一直在搜集各大型网站的架构设计图，一为了一饱眼福，领略各类大型网站架构设计的精彩之外，二来也可供闲时反复琢磨体会，何乐而不为呢?特此，总结整理了诸如国外**wikipedia，Facebook，Yahoo！，YouTube，MySpace，Twitter**，国内如**优酷网**等大型网站的技术架构（本文重点分析优酷网的技术架构），以飨读者。
本文着重凸显每一幅图的精彩之处与其背后含义，而图的说明性文字则从简从略。ok，好好享受此番架构盛宴吧。当然，若有任何建议或问题，欢迎不吝指正。谢谢。
1、WikiPedia 技术架构
WikiPedia 技术架构图Copy @Mark Bergsma
来自wikipedia的数据：峰值每秒钟3万个 HTTP 请求 ...
java
未读Java 的性能有某种黑魔法之称。部分原因在于 Java 平台非常复杂，很多情况下问题难以定位。然而在历史上还有一种趋势，人们靠智慧和经验来研究 Java 性能，而不是靠应用统计和实证推理。在这篇文章中，我希望拆穿一些最荒谬的技术神话。
1.Java 很慢关于 Java 的性能有很多谬论，这一条是最过时的，可能也是最为明显的。
确实，在上世纪 90 年代和本世纪初处，Java 有时是很慢。
然而从那以后，虚拟机和 JIT 技术已经有了十多年的改进，Java 的整体性能现在已经非常好了。
在 6 个独立的 Web 性能基准测试中，Java 框架在 24 项测试中有 22 项位列前四。
尽管 JVM 利用性能剖析仅优化常用的代码路径，但这种优化效果很明显。很多情况下，JIT 编译的 Java 代码和 C++ 一样快，而且这样的情况越来越多了。
尽管如此，依然有人认为 Java 平台很慢，这或许源自体验过 Java 平台早期版本的人的历史偏见。
在下结论之前，我们建议保持客观的态度，并且评估一下最新的性能结果。
2. 可以孤立地看待单行 Java 代码考虑下面这行短小的代码：
MyObjec ...
gzdd
未读导读：本文是从《Great code is written twice (or more)》这篇文章翻译而来。
文章内容如下：
最近这些年，越来越多的人开始转向敏捷开发。各种敏捷开发技术并不新鲜，大多是在80和90年代发展形成。但只是在最近这些年，程序员和（更重要的是）一些商业顾问，架构师，客户开始变得喜欢和拥抱敏捷开发。
进化中的需求
现在的一种普遍的认识是，在开始编码前，你不可能把所有的需求都写完备。这些需求的确定是一个逐渐发展进化的过程。使用短开发周期/springts，我们一步步的开发程序，使用多次迭代的方式完成从客户方得到的最新需求。这些都是基于一个进化的思想。就像生活中，我们总是通过一步步的改进来达到最好一样。
进化中的代码！
可是，这就完事了吗？如今大部分的程序员都认识到了需求必定是一步步的挖掘出来的。但他们却忘了自己的工作！？他们仍然认为他们的框架和架构在项目开始之初就定型了。同样，代码一旦写成，程序就完成了…不是吗？
错。 以我的经验，所有好的程序都至少要写两遍。第一编是你过于仓促，不能很好的理解需求、实现需求。不错，当看到了某种业务模式，我们知道要提炼出方 ...
O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。通俗点讲，就是将对象与关系数据库绑定，用对象来表示关系数据。在O/R Mapping的世界里，有两个基本的也是重要的东东需要了解，即VO，PO。VO，值对象(Value Object)，PO，持久对象(Persisent Object)，它们是由一组属性和属性的get和set方法组成。从结构上看，它们并没有什么不同的地方。但从其意义和本质上来看是完全不同的。1．VO是用new关键字创建，由GC回收的。PO则是向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。2．VO是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的，它存活的目的就是为数据提供一个生存的地方。PO则是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。3．VO的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所 ...
