博客园_冬眠的蛤蟆

WMI .NET开发资源

2011-10-24T10:01:00Z

最近想开发一款监控软件，WMI很符合要求，网上搜了一圈，资料真少，把有用的资料罗列一下搁这，需要时再参考下。

WMI 数据访问入门

http://technet.microsoft.com/zh-cn/office/ms186120(v=VS.80)

Performance Counter Classes

http://msdn.microsoft.com/zh-cn/aa392738

WQL分析器.rar

http://files.cnblogs.com/netflu/WQL%E5%88%86%E6%9E%90%E5%99%A8.rar

本文链接

网站架构方案全解析

2011-10-18T10:27:00Z

1、HTML静态化其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、图片服务器分离大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群和库表散列大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。

5、镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如 ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

7、硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

8、软件四层交换大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。

用squid做web cache server，而apache在squid的后面提供真正的web服务。当然使用这样的架构必须要保证主页上大部分都是静态页面。这就需要程序员的配合将页面在反馈给客户端之前将页面全部转换成静态页面。

基本看出sina和sohu对于频道等栏目都用了相同的技术，即squid来监听这些IP的80端口，而真正的web server来监听另外一个端口。从用户的感觉上来说不会有任何的区别，而相对于将web server直接和客户端连在一起的方式，这样的方式明显的节省的带宽和服务器。用户访问的速度感觉也会更快。

实例：Yupoo! 的网站技术架构

带宽：4000M/S

服务器数量：60 台左右

Web服务器：Lighttpd, Apache, nginx

应用服务器：Tomcat

其他：Python, Java, MogileFS 、ImageMagick 等

首先看一下网站的架构图：

498)this.width=498;" height=493>

该架构图给出了很好的概览(点击可以查看在 Yupoo! 上的大图和原图，请注意该图版权信息)。

关于 Squid 与 Tomcat

Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了"

对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。

名次解释：

YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
YPFS--Yupoo File System 与 YPWS 类似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

【Updated: 有网友留言质疑 Python 的效率，Yupoo 老大刘平阳在 del.icio.us 上写到 "YPWS用Python自己写的，每台机器每秒可以处理294个请求, 现在压力几乎都在10%以下"】

图片处理层

接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。

我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权原因而不用了(?);EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是非常建议 Yupoo! 针对 EXIF 做些文章，这也是潜在产生受益的一个重点。

图片存储层

原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS 方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo! 今后发展需要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB 计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在 MogileFS 中。

对于其他部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。

非常感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?

--EOF--

lighttpd+squid这套缓存是放在另外一个机房作为cdn的一个节点使用的，图中没描绘清楚，给大家带来不便了。

squid前端用lighttpd没用nginx，主要是用了这么久，没出啥大问题，所以就没想其他的了。

URL Hash的扩展性的确不好，能做的就是不轻易去增减服务器，我们目前是5台服务器做一组hash.

我们现在用Python写的Web Server，在效率方面，我可以给个测试数据，根据目前的访问日志模拟访问测试的结果是1台ypws,平均每秒处理294个请求(加载所有的逻辑判断)。

在可靠性上，还不没具体的数据，目前运行1个多月还没有任何异常。

lvs每个节点上都装nginx，主要是为了反向代理及处理静态内容，不过apache已显得不是那么必需，准备逐渐去掉。

我们处理图片都是即时的，我们目前半数以上的服务器都装了magickd服务，用来分担图片处理请求。

实例：Tailrank 网站架构

每天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。

专门爆料网站架构的 Todd Hoff 对 Kevin Burton 进行了采访。于是我们能了解一下 Tailrank 架构的一些信息。每小时索引 2400 万的 Blog 与 Feed，内容处理能力为 160-200Mbps，IO 写入大约在10-15MBps。每个月要处理 52T 之多的原始数据。Tailrank 所用的爬虫现在已经成为一个独立产品：spinn3r。

服务器硬件

目前大约 15 台服务器，CPU 是 64 位的 Opteron。每台主机上挂两个 SATA 盘，做 RAID 0。据我所知，国内很多 Web 2.0 公司也用的是类似的方式，SATA 盘容量达，低廉价格，堪称不二之选。操作系统用的是 Debian Linux 。Web 服务器用 Apache 2.0，Squid 做反向代理服务器。

数据库

Tailrank 用 MySQL 数据库，联邦数据库形式。存储引擎用 InnoDB，数据量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些多核模式下互斥锁的问题(This Bug?)。到数据库的JDBC 驱动连接池用 lbpool 做负载均衡。MySQL Slave 或者 Master的复制用 MySQLSlaveSync 来轻松完成。不过即使这样，还要花费 20%的时间来折腾 DB。

其他开放的软件

任何一套系统都离不开合适的 Profiling 工具，Tailrank 也不利外，针对 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是开放的。

Tailrank 的一个比较大的竞争对手是 Techmeme，虽然二者暂时看面向内容的侧重点有所不同。其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。从现在来看，Tailrank 离预期目标还差的很远。期待罗马早日建成

YouTube架构学习

原文: YouTube Architecture

YouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。

平台

Apache
Python
Linux(SuSe)
MySQL
psyco，一个动态的Python到C的编译器
lighttpd代替Apache做视频查看

状态

支持每天超过1亿的视频点击量
成立于2005年2月
于2006年3月达到每天3千万的视频点击量
于2006年7月达到每天1亿的视频点击量
2个系统管理员，2个伸缩性软件架构师
2个软件开发工程师，2个网络工程师，1个DBA
处理飞速增长的流量

Java代码

1. while (true)
2. {
3. identify_and_fix_bottlenecks();
4. drink();
5. sleep();
6. notice_new_bottleneck();
7. }
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}

每天运行该循环多次

Web服务器

NetScaler用于负载均衡和静态内容缓存
使用mod_fast_cgi运行Apache
使用一个Python应用服务器来处理请求的路由
应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面
一般可以通过添加更多的机器来在Web层提高伸缩性
Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC
Python允许快速而灵活的开发和部署
通常每个页面服务少于100毫秒的时间
使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环
对于像加密等密集型CPU活动，使用C扩展
对于一些开销昂贵的块使用预先生成并缓存的html
数据库里使用行级缓存
缓存完整的Python对象
有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。

视频服务

1，花费包括带宽，硬件和能源消耗

2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有

3，使用一个集群意味着：

-更多的硬盘来持有内容意味着更快的速度

-failover。如果一台机器出故障了，另外的机器可以继续服务

-在线备份

4，使用lighttpd作为Web服务器来提供视频服务：

-Apache开销太大

-使用epoll来等待多个fds

-从单进程配置转变为多进程配置来处理更多的连接

5，大部分流行的内容移到CDN：

-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高

-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸

6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器

-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问

-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。

-调节RAID控制并注意其他低级问题

-调节每台机器上的内存，不要太多也不要太少

视频服务关键点

1，保持简单和廉价

2，保持简单网络路径，在内容和用户间不要有太多设备

3，使用常用硬件，昂贵的硬件很难找到帮助文档

4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具

5，很好的处理随机查找(SATA，tweaks)

缩略图服务

1，做到高效令人惊奇的难

2，每个视频大概4张缩略图，所以缩略图比视频多很多

3，缩略图仅仅host在几个机器上

4，持有一些小东西所遇到的问题：

-OS级别的大量的硬盘查找和inode和页面缓存问题

-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意

-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图

-在这种高负载下Apache表现的非常糟糕

-在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个

-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存

-如此多的图片以致一台新机器只能接管24小时

-重启机器需要6-10小时来缓存

5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：

-避免小文件问题，因为它将文件收集到一起

-快，错误容忍

-更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作

-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable

数据库

1，早期

-使用MySQL来存储元数据，如用户，tags和描述

-使用一整个10硬盘的RAID 10来存储数据

-依赖于信用卡所以YouTube租用硬件

-YouTube经过一个常见的革命：单服务器，然后单master和多read slaves，然后数据库分区，然后sharding方式

-痛苦与备份延迟。master数据库是多线程的并且运行在一个大机器上所以它可以处理许多工作，slaves是单线程的并且通常运行在小一些的服务器上并且备份是异步的，所以slaves会远远落后于master

-更新引起缓存失效，硬盘的慢I/O导致慢备份

-使用备份架构需要花费大量的money来获得增加的写性能

-YouTube的一个解决方案是通过把数据分成两个集群来将传输分出优先次序：一个视频查看池和一个一般的集群

2，后期

-数据库分区

-分成shards，不同的用户指定到不同的shards

-扩散读写

-更好的缓存位置意味着更少的IO

-导致硬件减少30%

-备份延迟降低到0

-现在可以任意提升数据库的伸缩性

数据中心策略

1，依赖于信用卡，所以最初只能使用受管主机提供商

2，受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议

3，YouTube改为使用colocation arrangement。现在YouTube可以自定义所有东西并且协定自己的契约

4，使用5到6个数据中心加CDN

5，视频来自任意的数据中心，不是最近的匹配或其他什么。如果一个视频足够流行则移到CDN

6，依赖于视频带宽而不是真正的延迟。可以来自任何colo

7，图片延迟很严重，特别是当一个页面有60张图片时

8，使用BigTable将图片备份到不同的数据中心，代码查看谁是最近的

学到的东西

1，Stall for time。创造性和风险性的技巧让你在短期内解决问题而同时你会发现长期的解决方案

2，Proioritize。找出你的服务中核心的东西并对你的资源分出优先级别

3，Pick your battles。别怕将你的核心服务分出去。YouTube使用CDN来分布它们最流行的内容。创建自己的网络将花费太多时间和太多money

4，Keep it simple!简单允许你更快的重新架构来回应问题

5，Shard。Sharding帮助隔离存储，CPU，内存和IO，不仅仅是获得更多的写性能

6，Constant iteration on bottlenecks：

-软件：DB，缓存

-OS：硬盘I/O

-硬件：内存，RAID

7，You succeed as a team。拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队，如安装打印机，安装机器，安装网络等等的人。With a good team all things are possible。

实例：Google架构学习

Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。

平台

Linux

大量语言：Python，Java，C++

状态

在2006年大约有450,000台廉价服务器

在2005年Google索引了80亿Web页面，现在没有人知道数目

目前在Google有超过200个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节

目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序

BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择

堆栈

Google形象化它们的基础组织为三层架构：

1，产品：搜索，广告，email，地图，视频，聊天，博客

2，分布式系统基础组织：GFS，MapReduce和BigTable

3，计算平台：一群不同的数据中心里的机器

4，确保公司里的人们部署起来开销很小

5，花费更多的钱在避免丢失日志数据的硬件上，其他类型的数据则花费较少

可信赖的存储机制GFS(Google File System)

1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台

2，Google File System - 大型分布式结构化日志文件系统，Google在里面扔了大量的数据

3，为什么构建GFS而不是利用已有的东西?因为可以自己控制一切并且这个平台与别的不一样，Google需要：

-跨数据中心的高可靠性

-成千上万的网络节点的伸缩性

-大读写带宽的需求

-支持大块的数据，可能为上千兆字节

-高效的跨节点操作分发来减少瓶颈

4，系统有Master和Chunk服务器

-Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器

-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件

6，一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群

7，关键点在于有足够的基础组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求

使用MapReduce来处理数据

1，现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢?比如你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因

2，MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源

3，为什么使用MapReduce?

-跨越大量机器分割任务的好方式

-处理机器失败

-可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等

4，MapReduce系统有三种不同类型的服务器

-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态

-Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件

-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作

5，例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成

-步骤类似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS

-在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数

-Shuffling操作聚集键类型

-Reduction操作计算所有键值对的综合并产生最终的结果

6，Google索引操作管道有大约20个不同的map和reduction。

7，程序可以非常小，如20到50行代码

8，一个问题是掉队者。掉队者是一个比其他程序慢的计算，它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的

9，数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。

在BigTable里存储结构化数据

1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写

2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询

3，它提供查询机制来通过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据

4，商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作

5，通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它

6，系统运行时机器可以自由的增删而整个系统保持工作

7，每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问

8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable

9，BigTable有三种类型的服务器：

-Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务

-Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。

-Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥

10，一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择

11，tablet尽可能的缓存在RAM里

硬件

1，当你有很多机器时你怎样组织它们来使得使用和花费有效?

2，使用非常廉价的硬件

3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.

4，Linux，in-house rack design，PC主板，低端存储

5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues

6，使用一些collocation和Google自己的数据中心

其他

1，迅速更改而不是等待QA

2，库是构建程序的卓越方式

3，一些程序作为服务提供

4，一个基础组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西

Google将来的方向

1，支持地理位置分布的集群

2，为所有数据创建一个单独的全局名字空间。当前的数据由集群分离

3，更多和更好的自动化数据迁移和计算

4，解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)

学到的东西

1，基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务，并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式

2，跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的

3，如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hadoop是这里很多同样的主意的一个开源实现

4，平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境因为知道怎样完成这项工作的人相对较少

5，协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进

6，构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级

7，创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案

8，不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.

9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。

实例：Lighttpd+Squid+Apache搭建高效率Web服务器

架构原理

Apache通常是开源界的首选Web服务器，因为它的强大和可靠，已经具有了品牌效应，可以适用于绝大部分的应用场合。但是它的强大有时候却显得笨重，配置文件得让人望而生畏，高并发情况下效率不太高。而轻量级的Web服务器Lighttpd却是后起之秀，其静态文件的响应能力远高于 Apache，据说是Apache的2-3倍。Lighttpd的高性能和易用性，足以打动我们，在它能够胜任的领域，尽量用它。Lighttpd对 PHP的支持也很好，还可以通过Fastcgi方式支持其他的语言，比如Python。

毕竟Lighttpd是轻量级的服务器，功能上不能跟Apache比，某些应用无法胜任。比如Lighttpd还不支持缓存，而现在的绝大部分站点都是用程序生成动态内容，没有缓存的话即使程序的效率再高也很难满足大访问量的需求，而且让程序不停的去做同一件事情也实在没有意义。首先，Web程序是需要做缓存处理的，即把反复使用的数据做缓存。即使这样也还不够，单单是启动Web处理程序的代价就不少，缓存最后生成的静态页面是必不可少的。而做这个是 Squid的强项，它本是做代理的，支持高效的缓存，可以用来给站点做反向代理加速。把Squid放在Apache或者Lighttpd的前端来缓存 Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。

即使是大部分内容动态生成的网站，仍免不了会有一些静态元素，比如图片、JS脚本、CSS等等，将Squid放在Apache或者Lighttp 前端后，反而会使性能下降，毕竟处理HTTP请求是Web服务器的强项。而且已经存在于文件系统中的静态内容再在Squid中缓存一下，浪费内存和硬盘空间。因此可以考虑将Lighttpd再放在Squid的前面，构成 Lighttpd+Squid+Apache的一条处理链，Lighttpd在最前面，专门用来处理静态内容的请求，把动态内容请求通过proxy模块转发给Squid，如果Squid中有该请求的内容且没有过期，则直接返回给Lighttpd。新请求或者过期的页面请求交由Apache中Web程序来处理。经过Lighttpd和Squid的两级过滤，Apache需要处理的请求将大大减少，减少了Web应用程序的压力。同时这样的构架，便于把不同的处理分散到多台计算机上进行，由Lighttpd在前面统一把关。

在这种架构下，每一级都是可以进行单独优化的，比如Lighttpd可以采用异步IO方式，Squid可以启用内存来缓存，Apache可以启用MPM 等，并且每一级都可以使用多台机器来均衡负载，伸缩性很好。

原文：http://jythoner.iteye.com/blog/562567

本文链接

浏览器缓存机制

2011-09-16T07:20:00Z

Cache-Control

Cache-Control 是最重要的规则。这个字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令。这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。这些指令通常覆盖默认缓存算法。缓存指令是单向的，即请求中存在一个指令并不意味着响应中将存在同一个指令。

cache-control 定义是：Cache-Control = “Cache-Control” “:” cache-directive。表 1 展示了适用的值。

表 1. 常用 cache-directive 值
Cache-directive	说明
public	所有内容都将被缓存
private	内容只缓存到私有缓存中
no-cache	所有内容都不会被缓存
no-store	所有内容都不会被缓存到缓存或 Internet 临时文件中
must-revalidation/proxy-revalidation	如果缓存的内容失效，请求必须发送到服务器/代理以进行重新验证
max-age=xxx (xxx is numeric)	缓存的内容将在 xxx 秒后失效, 这个选项只在HTTP 1.1可用, 并如果和Last-Modified一起使用时, 优先级较高

表 2 表明在不同的情形下，浏览器是将请求重新发送到服务器还是使用缓存的内容。

表 2. 对 cache-directive 值的浏览器响应
Cache-directive	打开一个新的浏览器窗口	在原窗口中单击 Enter 按钮	刷新	单击 Back 按钮
public	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器	浏览器呈现来自缓存的页面
private	浏览器重新发送请求到服务器	第一次，浏览器重新发送请求到服务器；此后，浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器	浏览器呈现来自缓存的页面
no-cache/no-store	浏览器重新发送请求到服务器	浏览器重新发送请求到服务器	浏览器重新发送请求到服务器	浏览器重新发送请求到服务器
must-revalidation/proxy-revalidation	浏览器重新发送请求到服务器	第一次，浏览器重新发送请求到服务器；此后，浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器	浏览器呈现来自缓存的页面
max-age=xxx (xxx is numeric)	在 xxx 秒后，浏览器重新发送请求到服务器	在 xxx 秒后，浏览器重新发送请求到服务器	浏览器重新发送请求到服务器	在 xxx 秒后，浏览器重新发送请求到服务器

Cache-Control是关于浏览器缓存的最重要的设置，因为它覆盖其他设置，比如 Expires 和 Last-Modified。另外，由于浏览器的行为基本相同，这个属性是处理跨浏览器缓存问题的最有效的方法。

失效

Expires 头部字段提供一个日期和时间，响应在该日期和时间后被认为失效。失效的缓存条目通常不会被缓存（无论是代理缓存还是用户代理缓存）返回，除非首先通过原始服务器（或者拥有该实体的最新副本的中介缓存）验证。（注意：cache-control max-age 和 s-maxage 将覆盖 Expires 头部。）

Expires 字段接收以下格式的值：“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。如果查看内容时的日期在给定的日期之前，则认为该内容没有失效并从缓存中提取出来。反之，则认为该内容失效，缓存将采取一些措施。表 3-6 表明针对不同用户操作的不同浏览器的行为。

表 3. 当用户打开一个新的浏览器窗口时的失效操作
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面
内容失效	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 4. 当用户在原始浏览器窗口中单击 Enter 按钮时的失效操作
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容失效	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 5. 当用户按 F5 键刷新页面时的失效操作
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容失效	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 6. 当用户单击 Back 或 Forward 按钮时的失效操作
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面
内容失效	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200

注意：所有浏览器都假定为使用默认设置运行。

Last-Modified/E-Tag

Last-Modified 实体头部字段值通常用作一个缓存验证器。简单来说，如果实体值在 Last-Modified 值之后没有被更改，则认为该缓存条目有效。ETag 响应头部字段值是一个实体标记，它提供一个 “不透明” 的缓存验证器。这可能在以下几种情况下提供更可靠的验证：不方便存储修改日期；HTTP 日期值的 one-second 解决方案不够用；或者原始服务器希望避免由于使用修改日期而导致的某些冲突。

不同的浏览器有不同的配置行为。表 7-10 表明针对不同用户操作的不同浏览器的行为。

表 7. 当用户打开一个新的浏览器窗口时的 Last-Modified E-Tag 操作
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 8. 当用户在原始浏览器窗口中单击 Enter 按钮时的 Last-Modified E-Tag 操作
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 9. 当用户按 F5 键刷新页面时的 Last-Modified E-Tag 操作
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 10. 没有缓存设置且用户单击 Back 或 Forward 按钮
	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面
内容自上次访问以来已经被修改	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200

注意：所有浏览器都假定使用默认设置运行。

不进行任何缓存相关设置

如果您不定义任何缓存相关设置，则不同的浏览器有不同的行为。有时，同一个浏览器在相同的情形下每次运行时的行为都是不同的。情况可能很复杂。另外，有些不该缓存的内容如果被缓存，将会导致安全问题。
不同的浏览器有不同的行为。表 11 展示了不同的浏览器行为。

表 11. 没有缓存设置且用户打开一个新的浏览器窗口
	Firefox 3.5	IE 8	Chrome 3	Safari 4
打开一个新页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200
在原始窗口中单击 Enter 按钮	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面。	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200
按 F5 键刷新	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200
单击 Back 或 Forward 按钮	浏览器呈现来自缓存的页面。	浏览器呈现来自缓存的页面。	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

注意：所有浏览器都假定使用默认设置运行。

最后, 概括下关键的结论:

关键结论
打开新窗口	如果指定cache-control的值为private、no-cache、must-revalidate,那么打开新窗口访问时都会重新访问服务器。而如果指定了max-age值,那么在此值内的时间里就不会重新访问服务器,例如：Cache-control: max-age=5 表示当访问此网页后的5秒内再次访问不会去服务器.
在地址栏回车	如果值为private或must-revalidate,则只有第一次访问时会访问服务器,以后就不再访问。如果值为no-cache,那么每次都会访问。如果值为max-age,则在过期之前不会重复访问。
按后退按扭	如果值为private、must-revalidate、max-age,则不会重访问,而如果为no-cache,则每次都重复访问.
按刷新按扭	无论为何值,都会重复访问.

本文链接

浏览器加载和渲染html的顺序

2011-09-16T07:19:00Z

前阵子，在组内给大家做了一次关于“浏览器加载和渲染HTML的顺序”的分享，这里再总结一下吧。
1.浏览器加载和渲染html的顺序

1、IE下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的。
2、在渲染到页面的某一部分时，其上面的所有部分都已经下载完成（并不是说所有相关联的元素都已经下载完）
3、如果遇到语义解释性的标签嵌入文件（JS脚本，CSS样式），那么此时IE的下载过程会启用单独连接进行下载。
4、并且在下载后进行解析，解析过程中，停止页面所有往下元素的下载。阻塞加载
5、样式表在下载完成后，将和以前下载的所有样式表一起进行解析，解析完成后，将对此前所有元素（含以前已经渲染的）重新进行渲染。
6、JS、CSS中如有重定义，后定义函数将覆盖前定义函数

2. JS的加载

2.1 不能并行下载和解析（阻塞下载）
2.2 当引用了JS的时候，浏览器发送1个js request就会一直等待该request的返回。因为浏览器需要1个稳定的DOM树结构，而JS中很有可能有代码直接改变了DOM树结构，比如使用 document.write 或 appendChild,甚至是直接使用的location.href进行跳转，浏览器为了防止出现JS修改DOM树，需要重新构建DOM树的情况，所以就会阻塞其他的下载和呈现.

3.如何加快HTML页面加载速度

1，页面减肥
页面的肥瘦是影响加载速度最重要的因素
删除不必要的空格、注释
将inline的script和css移到外部文件
可以使用HTML Tidy来给HTML减肥，还可以使用一些压缩工具来给JavaScript减肥
2，减少文件数量
减少页面上引用的文件数量可以减少HTTP连接数
许多JavaScript、CSS文件可以合并最好合并，人家财帮子都把自己的JavaScript. functions和Prototype.js合并到一个base.js文件里去了
3，减少域名查询
DNS查询和解析域名也是消耗时间的，所以要减少对外部JavaScript、CSS、图片等资源的引用，不同域名的使用越少越好
4，缓存重用数据
使用缓存吧
5，优化页面元素加载顺序
首先加载页面最初显示的内容和与之相关的JavaScript和CSS
然后加载DHTML相关的东西
像什么不是最初显示相关的图片、flash、视频等很肥的资源就最后加载
6，减少inline JavaScript的数量
浏览器parser会假设inline JavaScript会改变页面结构，所以使用inline JavaScript开销较大
不要使用document.write()这种输出内容的方法，使用现代W3C DOM方法来为现代浏览器处理页面内容
7，使用现代CSS和合法的标签
使用现代CSS来减少标签和图像，例如使用现代CSS+文字完全可以替代一些只有文字的图片
使用合法的标签避免浏览器解析HTML时做“error correction”等操作，还可以被HTML Tidy来给HTML减肥
8，Chunk your content
不要使用嵌套tables

<table>
  <table>
    <table>
      ..
    <table>
  <table>
<table>

而使用非嵌套tables或者divs

<table>...</table>
<table>...</table>
<table>...</table>

将基于大块嵌套的tables的layout分解成小tables，这样显示时不用加载整个页面(或大table)的内容
9，指定图像和tables的大小
如果浏览器可以立即决定图像或tables的大小，那么它就可以马上显示页面而不要重新做一些布局安排的工作
这不仅加快了页面的显示，也预防了页面完成加载后布局的一些不当的改变
image使用height和width
table使用table-layout: fixed并使用col和colgroup标签指定columns的width
10，根据用户浏览器明智的选择策略
IE、Firefox、Safari等等等等
11，页面结构的例子

· HTML

    · HEAD

        · LINK ...
        CSS files required for page appearance. Minimize the number of files for performance while keeping unrelated CSS in separate files for maintenance.

        · SCRIPT. ...
        JavaScript. files for functions required during the loading of the page, but not any DHTML that can only run after page loads.
        Minimize the number of files for performance while keeping unrelated JavaScript. in separate files for maintenance.

    · BODY
    · User visible page content in small chunks (tables / divs) that can be displayed without waiting for the full page to download.

        · SCRIPT. ...
        Any scripts which will be used to perform. DHTML. DHTML script. typically can only run after the page has completely loaded and all necessary objects have been initialized. There is no need to load these scripts before the page content. That only slows down the initial appearance of the page load.
        Minimize the number of files for performance while keeping unrelated JavaScript. in separate files for maintenance.
        If any images are used for rollover effects, you should preload them here after the page content has downloaded.

4.HTML页面加载和解析流程

1.用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
2.浏览器开始载入html代码，发现＜head＞标签内有一个＜link＞标签引用外部CSS文件；
3.浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
4.浏览器继续载入html中＜body＞部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
5.浏览器在代码中发现一个＜img＞标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
6.服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
7.浏览器发现了一个包含一行Javascript代码的＜script＞标签，赶快运行它；
8.Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个＜div＞（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
9.终于等到了＜/html＞的到来，浏览器泪流满面……
10.等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下＜link＞标签的CSS路径；
11.浏览器召集了在座的各位＜div＞＜span＞＜ul＞＜li＞们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。

5.Yahoo对网页设计性能的建议，个人感觉是说得非常好的。
英文版：http://developer.yahoo.com/performance/rules.html
中文翻译：http://www.cnblogs.com/smjack/archive/2009/02/24/1396895.html

参考资料：
http://hideto.javaeye.com/blog/133384
http://blog.chinaacc.com/liuzhantao/blog/20100430-3015241029081.html

本文链接

微软SaaS、PaaS到IaaS的全面云计算服务

2011-09-05T10:59:00Z

微软在云计算领域的野心勃勃从未掩饰，让亚马逊一家独唱也不是微软甘心眼睁睁看着的。因此从2010年1月开始，Azure开始投入商用，并在二月份的时候增加了远程桌面和虚拟机的支持，这使得该平台看起来像一个IaaS平台的同时，也算是微软在云计算领域巩固地位的一种手段。

鲍尔默看云计算

在2010年中的时候，Azure的定价模型开始受到业界的一些抱怨，认为其定价模型不仅让人难以理解，而且Azure的虚拟化也没有发到其他云服务的水平。但是我们相信微软的动作远不会仅止于此。

微软云计算参考架构

基于以上架构，微软能为企业提供两种云计算部署类型，即公共云和私有云。

公共云：由微软自己运营，为客户提供部署和应用服务。在公共云中，WindowsAzurePlatform是一个高度可扩展的服务平台，提供基于微软数据中心随用随付费的灵活的服务模式。

私有云：部署在客户的数据中心内部，基于客户个性化的性能和成本要求、面向服务的内部应用环境。这个云平台基于成熟的WindowsServer和SystemCenter等系列产品，并且能够与现有应用程序兼容。

首先，针对SaaS需求的用户，微软云提供了以WindowsLive、OfficeLive、Bing组成的Live解决方案，以及由ExchangeOnline、SharePointOnline、DynamicCRMOnline等服务组成的Online解决方案。

面向选择PaaS模式的用户，微软云提供了WindowsAzurePlatform云计算平台。这是一个运行在微软数据中心的云计算平台。用户既可以针对该平台来创建自己的应用，又可以将创建的应用直接部署在该平台上。

这个WindowsAzureplatform包括三大部分：WindowsAzure是操作系统，SQLAzure是数据库，AppFabric则是应用服务平台。而微软特有的AppFabric能够使现有应用和服务与云平台的连接和互操作变得更为简单和安全。让用户把精力专注于应用逻辑，而不是在部署和管理云服务的基础架构上。

而针对面向IaaS服务的用户的需求，微软云计算则是提供了数据中心提供的优化和管理方案DDTK(DynamicDataCenterToolkit)，用户能利用该方案，快速构建面向内部使用的私有云平台，而且服务提供商也可以基于该方案在短时间内搭建云计算服务平台对外提供服务。

本文链接

阮志敏谈平台即服务PaaS

2011-09-05T10:24:00Z

云计算的三种服务模式是SaaS(Software as a Service)，PaaS(Platform as a service)和IaaS(Infrastructure as a service)。相对于SaaS和IaaS，PaaS最难被理解，人们对PaaS的解读往往也不尽相同。这是我继“云计算与SOA之我见”之后的又一篇文章，希望通过这篇文章来分享我对PaaS的理解，并阐述为什么PaaS在云计算中处于战略核心地位。

一、 PaaS是云环境下的应用基础设施

有些人认为PaaS的核心就是分布式技术，如分布式计算、分布式存储、分布式数据库等，目的是把多台计算机虚拟成一台性能极强的超级计算机。有些人认为PaaS是一种云服务，能提供由提供者托管于硬件基础设施上的软件和产品开发工具，是面向开发人员的，开发人员可直接在上面创建和运行新的应用程序。

持有上述第一种观点的人受互联网技术(如Google)的影响很深，我认为分布式技术(类Hadoop技术)仅是PaaS的enabling technology之一，并不是PaaS的全部。上述第二种观点把PaaS局限在APaaS(application platform as service，如GAE和Heroku)上，APaaS主要提供开发SDK和应用运行环境。完整的PaaS平台除了提供APaaS功能外，还应提供IPaaS（Integration platform as a service）,IPaaS提供集成、编排和互操作的功能。

从传统角度来看，PaaS实际上就是云环境下的应用基础设施，也可理解成中间件即服务，如下图所示：

PaaS的功能

PaaS为部署和运行应用系统提供所需的基础设施资源应用基础设施，所以应用开发人员无需关心应用的底层硬件和应用基础设施，并且可以根据应用需求动态扩展应用系统所需的资源。完整的PaaS平台应提供如下功能：

应用运行环境
- 分布式运行环境
- 多种类型的数据存储
- 动态资源伸缩
应用全生命周期支持
- 提供开发SDK、IDE等加快应用的开发、测试和部署。
- 公共服务：以API形式提供公共服务，如队列服务、存储服务和缓存服务等。
- 监控、管理和计量：提供资源池、应用系统的管理和监控功能，精确计量。应用使用所消耗的计算资源。
集成、复合应用构建能力：
除了提供应用运行环境外，还需要提供连通性服务、整合服务、消息服务和流程服务等用于构建SOA架构风格的复合应用。

PaaS的全局功能视图如下：

多租户弹性是PaaS的核心特性

PaaS的特性有多租户、弹性(资源动态伸缩)、统一运维、自愈、细粒度资源计量、SLA保障等。这些特性基本也都是云计算的特性。多租户弹性是PaaS区别于传统应用平台的本质特性，其实现方式也是用来区别各类PaaS的最重要标志，因此我认为多租户弹性是PaaS的最核心特性。

多租户(Multi-tenancy)是指一个软件系统可以同时被多个实体所使用，每个实体之间是逻辑隔离、互不影响的。一个租户可以是一个应用，也可以是一个组织。弹性(Elasticity)是指一个软件系统可以根据自身需求动态的增加、释放其所使用的计算资源。

多租户弹性(Multi-tenancy elastic)是指租户或者租户的应用可以根据自身需求动态的增加、释放其所使用的计算资源。

技术上来说，多租户有如下几种实现方式：

Shared-Nothing：为每一个租户或提供一套和On-premise一样的应用系统，包括应用、应用基础设施和基础设施。Shared-Nothing仅在商业模式上其实现了多租户。Shared-Nothing的好处是整个应用系统栈都不需要改变、隔离非常彻底，但是技术上没有实现资源弹性分配，资源不能共享。
Shared-Hardware：共享物理机，虚拟机是弹性资源调度和隔离的最小单位，典型例子是Microsoft Azure。传统软件巨头如微软和IBM等拥有非常广的软件产品线，在On-premise时代占据主导地位后，他们在云时代的策略就是继续将on-premise软件stack装到虚拟机中并提供给用户。
Shared-OS：共享操作系统，进程是弹性资源调度和隔离的最小单位。相比于Shared-Hardware，Shared-OS能实现更小粒度的资源共享，但是安全性方面会差些。
Shared-Everything：基于元数据模型以共享一切资源，典型例子是force.com。Shared-Everything方式能够实现最高效的资源共享，但实现技术难度大，安全和可扩展性方面会面临很大的挑战。

二、 PaaS的战略核心地位

在云产业链中，如同传统中间件所起的作用一样，PaaS也将会是产业链的制高点。无论是在大型企业私有云中，还是在中小企业和ISV所关心的应用云中，PaaS都将起到核心的作用。

以PaaS为核心构建企业私有云

大型企业都有复杂的IT系统，甚至自己筹建了大型数据中心，其运行维护工作量非常大，同时资源的利用率又很低——据统计大部分企业数据中心的计算资源利用率都不超过30%。在这种情况下，企业迫切需要找到一种方法，整合全部IT资源，进行池化，并且以动态可调度的方式供应给业务部门。大型企业建设内部私有云有两种模式，一种是以IaaS为核心，另外一种是以PaaS为核心，如下图所示：

首先，企业会采用成熟的虚拟化技术首先实现基础设施的池化和自动化调度。当前，有大量电信运营商、制造企业和产业园区都在进行相关的试点。但是，私有云建设万不可局限于IaaS，因为IaaS只关注解决基础资源云化问题，解决的主要是IT问题。在IaaS的技术基础上进一步架构企业PaaS平台将能带来更多的业务价值。PaaS的核心价值是让应用及业务更敏捷、IT服务水平更高、并实现更高的资源利用率。

以PaaS为核心的私有云建设模式是在IaaS的资源池上进一步构建PaaS能力，提供内部云平台、外部SaaS运营平台和统一的开发、测试环境：

内部云平台：建立业务支撑平台
外部SaaS运营平台：向企业外部供应商或者客户提供SaaS应用
开发、测试环境：为开发人员提供统一的开发和测试环境平台

以某航空运输领域的集团为例。它正从单一的航空运输企业，转型为以航空旅游、现代物流、现代金融服务三大链条为支柱，涵盖“吃、住、行、游、购、娱”六大产业要素的现代服务业综合运营商，其产业覆盖航空运输、旅游服务、现代物流、金融服务、商贸零售、房地产开发与管理、机场管理。对于这么一个大型企业集团，当前信息化的挑战不仅在于如何高效整合、集中管控整个集团的IT资源，更重要的在于如何快速地、更好的满足客户的需求，如何更高效地整合外部供应商，使IT真正成为其创新的驱动力。云计算为该集团带来契机，以PaaS为核心构建其对内、对外云平台必将成为其最佳选择。

以PaaS为核心构建和运营下一代SaaS应用

对于中小企业来说，大部分缺乏专业的IT团队，并且难以承受高额的前期投入，他们往往很难通过自建IT的思路来实现信息化，所以SaaS是中小企业的天然选择。然而，SaaS这么多年来在国内的发展状况一直没有达到各方的预期。抛开安全问题不讲，最主要的其他两个原因是传统SaaS应用难以进行二次开发以满足企业个性需求，并缺少能够提供一站式的SaaS应用服务的运营商。

无论是Salesforce.com，还是国内的SaaS供应商都意识到SaaS的未来在于PaaS，需要以PaaS为核心来构建和运营新一代的SaaS应用。

在云计算时代，中小企业市场的机会比以往任何时候到大。在这个以PaaS为核心的生态链中，每个参与者都得到了价值的提升。

中小企业：一站式的SaaS应用服务；可定制的SaaS应用。
SaaS运营商：基于统一PaaS平台提供一站式的SaaS应用服务；实现规模效应。
应用开发商：基于PaaS平台，将已开发的成熟应用SaaS化、开发新的SaaS应用；为中小企业提供二次开发服务；开发效率得到提升。
基础设施提供商：专注于基础设施运维；实现资源更高效利用和回报。

三、 PaaS是未来软件开发的“银弹”之一

没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。即便没有银弹，人们仍会在不同的方向为提高软件交付的效率和质量做出不懈努力。PaaS毫无疑问是其中的方向之一，PaaS改变了传统的应用交付模式，促进了分工的进一步专业化，解耦了开发团队和运维团队，将极大地提高未来软件交付的效率。

PaaS改变传统的应用交付

PaaS是开发和运维团队之间的桥梁

四、结束语

Gartner的最新研究，所有重要软件企业厂商和大型的云计算专业公司将会在2011年推出新的平台即服务(PaaS)产品，这将使2011年成为平台即服务(PaaS)产品主导的一年。另一方面，PaaS已经渐渐变为PaaS + IaaS的融合，大型PaaS服务供应商不仅是能够让开发商或用户在其PaaS平台上面构建和运行应用，同时还负责供应并维护底层的基础架构，包括虚拟化、操作系统修补、安全问题等。

不论是大型企业，中小企业，软件开发商，软件供应商、运营商，还是开发和运维人员，都需充分认识到PaaS的战略核心地位和即将带来的变化，做好充分的准备，迎接PaaS时代的到来。

关于作者

阮志敏，企业级PaaS平台CloudTao创始人，长期专注于企业软件领域，同时深受互联网技术影响，曾在CORDYS中国、摩托罗拉和惠普中国任职。可通过个人博客、新浪微博与作者联系。

本文链接

开发人员如何提高工作效率一:找出低效的原因

2011-08-31T16:00:00Z

高效能工作系列开篇，就以这一篇开发人员如何提高工作效率作为第一篇内容，写这个高效能工作系列的目的很明显，寻找各种可行的方法来提高自己的工作效率，包括时间管理的方法，如何实现目标等

1. 今天这篇的内容是找出效率低下的原因，有低效的开发人员，反过来就是高效的开发人员，那么这两者的效率差体现在哪里呢，把自己的情况也放进去比较

十二个可让你效率提高的方面

比较方面	熟练人员	一般的开发人员
查找资料	经过多年的积累加上自己的 CodeSnip 的总结，基本不用额外再查找资料。	在开发过程中会花掉 10-20% 时间去查找资料。
代码复用	注意代码复用，并且时刻注意重构和抽取公用代码。	一般开发人员是代码拷来拷去完成功能。
对开发工具的熟悉程度	非常注意查找，定位，标签等各种快捷键的使用，定位查找方便快捷， IDE 环境也根据习惯定义到最方便状态。
编程习惯	编码前先思考清楚整个流程，在头脑或纸张上规划好整个实现方式和方法函数的划分。	想到哪里写到哪里。
Debug习惯	写了 50 行以上或更多代码才 Debug 一两次。	写了几行代码就要 Debug 多次，完全通过 Debug 来验证代码正确性。
代码质量	注重代码的质量，单元测试和可维护性，注重各种业务逻辑的验证和边界条件的校验。	只注重简单功能的简单完成。
代码质量	提交测试的代码 BUG 很少，返工工作量很小。	由于自测不完善 BUG 较多，造成大量的返工工作量。
时间管理	合理分配自己的时间，规划好每天工作任务，开发过程各位专注。	一心多用，边开发边聊 Q 。
自我总结	善于知识的总结和积累，形成自我的知识库和经验库。	则不善于这种总结。
责任感	善于发现问题，分析不足而自我持续改进。	在外力干预下被动改进。
思考	熟练开发人员开发重点已经专业到对业务的深刻理解。	考虑的是开发上编程的语言和工具。
时间管理	善于从各种影响自己开发效率的因素中挤时间，善于使用各种辅助开发工具。

本文链接

人人网的系统架构

2011-08-31T15:46:00Z

今天在网上看到人人网使用的开源软件列表，人人网的架构师写的，看完后，大概了解了人人网的架构信息

数据层

使用MySQL ,同时使用Tokyo Cabinet(Key-value的存储引擎，简称TC)做一个数据冗余，TC代替MySQL做存储，例如搜索结果页的用户资料,但Tokyo Cabinet没有网络处理能力，需要使用Tokyo Tyrant以提供网络接入能力，并调用Tokyo Cabinet的API进行持久化存储

Tokyo Tyrant其实也是Tokyo Cabinet的作者开发的，主要是支持Memcached传输协议的网络接口，可以理解为Tokyo Tyrant处理网络连接，协议解析，然后调用Tokyo Cabinet的API来完成持久化存储

服务端

Web Server : Nginx, 使用Nginx的代理能力，做跨IDC的请求代理，同时与Java Server–Resin搭配，解决Resin网络连接处理能力弱的问题

Java Server: Resin 替代Tomcat作为Java服务器

代理服务器 : Squid 做图片文件的反向代理缓存

Linux服务器集群系统: LVS（Linux Virtual Server）,使用它的4层的负载均衡，替代了很多硬件的负载均衡设备

框架

Java web框架： Struts，王兴同学一开始写校内网果然是用structs，现在的人人网开始慢慢舍弃原有的框架，并自己开发了一个web框架，传闻将来也会开源出来

搜索引擎框架: 基于Lucence提供搜索人的服务

网络框架：Netty，一个Java的网络框架，和apache的mina类似，但比mina更高效，用来提供一些小的服务

服务器系统监控

ganglia Ganglia是一个跨平台可扩展的，高性能计算系统下的分布式监控系统，如集群和网格

应用层缓存

Memcached 一个纯内存的key-value的cache系统，使用spymemcached作为java的Client

ICE : 一个跨语言的网络通讯框架，框架本身提供了强大的通讯能力，管理工具，负载均衡方案，其跨语言能力也是一个很大的亮点，基于这个框架之上，我们选用合适的语言来提供合适的服务，比如我们使用C++来开发Cache服务，使用Java来开发一些逻辑服务。框架本身可以很重，也可以很轻，具体要看你怎么用：）

Memcached和ICE的缓存服务区别

对Cache的操作粒度不一样，Memcached对Cache对象以binary byte作为一个整体来操作，需要频繁的序列化和反序列化，我们使用ICE提供的Cache服务，可以以Cache对象的一个或者多个字段来操作，比如一个用户对象，我们可以只更新它的姓名。
本文链接

程序员能力矩阵 Programmer Competency Matrix

2011-08-31T15:45:00Z

原文地址

注意:每个层次的知识都是渐增的，位于层次n，也蕴涵了你需了解所有低于层次n的知识。

计算机科学 Computer Science
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
数据结构	不知道数组和链表的差异	能够解释和使用数组，链表，字典等，并且能够用于实际的编程任务。	了解基本数据结构时间和空间的折中，比如数组vs 链表，能够解释如何实现哈希表和处理冲突，了解优先队列及其实现。	高等的数据结构的知识，比如B-树、二项堆、斐波那契堆、AVL树、红黑树、伸展树、跳跃表以及前缀树等。
算法	不能够找出一个数组各数的平均值(这令人难以置信，但是我的确在应聘者中遇到过)	基本的排序，搜索和数据的遍历和检索算法。	树，图，简单的贪婪算法和分而治之算法，能够适度了解矩阵该层的含义。	能够辨识和编写动态规划方案，良好的图算法知识，良好的数值估算的知识，能够辨别NP问题等。	Working with someone who has a good topcoder ranking would be an unbelievable piece of luck!
编程体系	不知道何为编译器、链接器和解释器。	对编译器、链接器、解释器有基本的了解。知道什么是汇编代码以及在硬件层如何工作。有一些虚拟内存和分页知识。	了解内核模式vs用户模式,多线程，同步原语以及它们如何实现，能够阅读汇编代码。了解网络如何工作，了解网络协议和socket级别编程。	了解整个程序堆栈、硬件(CPU+内存+中断+微码)、二进制代码、汇编、静态和动态链接、编码、解释、JIT（just-in-time）编译、内存碎片回收、堆、栈、存储器编址…
软件工程 Software Engineering
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
源码版本控制	通过日期备份文件夹	VSS和初级的CVS/SVN用户	熟练地使用CVS和SVN特性。知道如何分支和归并，使用程序库补丁安装特性等	有分布式VCS系统的知识。尝试过Bzr/Mercurial/Darcs/Git
自动化编译	只知道在IDE下编译	知道如何编译在命令行下编译系统	能够安装一个脚本构建基本的系统	能够安装一个脚本来构建系统并且归档，安装程序，生成发布记录和给源码控制中的代码分配标签。
自动化测试	认为所有的测试都是测试员的工作。	能够编写自动化的单元测试，能够为正在编写的代码提出良好的测试用例。	按照TDD （Test Driven Development）方式编写代码。	了解并且能够有效自动化安装，载入/性能和UI测试
程序设计 Programming
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
问题分解	只有直线式的代码，通过复制粘贴来复用	能够把问题分散到多个函数中	能够想出可复用的函数/对象来解决大题的问题	使用适宜的数据结构和算法，写出通用的/面向对象的代码来封装问题的易改变的层面。
系统分解	N想不出比单一的文件/类更好的层面	如果不在同一平台或没采用相同的技术，能够把问题空间和设计方案分解。	能够设计跨技术/平台的系统。	能够在多个产品线和与外部体系一体化中虚拟化和设计复制的系统。同时也能够设计支持系统监视、报告、故障恢复等。
交流	不能向同伴表达想法/主意。匮乏拼写和语法的能力。	同伴能了解你在说什么。有良好的拼写和语法能力。	能够和同伴进行高效的交流	能够使用清晰的方式了解和交流想法/设计/主意/细则，能适应每种环境的交流	This is an often under rated but very critical criteria for judging a programmer. With the increase in outsourcing of programming tasks to places where English is not the native tongue this issue has become more prominent. I know of several projects that failed because the programmers could not understand what the intent of the communication was.
同一文件中代码组织	同一文件中组织没有依据	按照逻辑性或者易接近的方法	代码分块和对于其他源文件来说是易于是释,引用其他源文件时有良好的注释	文档头部有许可声明，总结，良好的注释，一致的空格缩进。文档外观美观。
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
跨文件代码组织	没够想过给代码跨文件组织	相关文件按文件夹分组	每个物理文件都有独立的目的，比如一个类的定义，一个特性的实现等。	代码在物理层组织紧密，在文件名上与设计和外观相匹配，可以通过文件分布方式洞察设计理念。
源码树组织	一切都放在一个文件夹内	初步地将代码分散进对应逻辑的文件夹。	没有循环依赖，二进制文件，库，文档，构建，第三方的代码都组织进合适的文件夹内。	源码树的物理布局与逻辑层次、组织方式相匹配。可以通过目录名称和组织方式洞察设计理念。	The difference between this and the previous item is in the scale of organization, source tree organization relates to the entire set of artifacts that define the system.
代码可读性	单音节的名称（在国内应该是那些类似用汉语拼音命名的习惯）	对文件、变量、类、方法等，有良好的命名。	没有长函数、注释解释不常规的代码，bug修复,代码假设。	代码假设验证使用断言，自然的代码流，没有深层嵌套的条件和方法
防御性编码	不知道这个概念	检查代码中所有的参数，对关键的假设进行断言	确保检查了返回值和使代码失败的异常。	有自己的库来帮助防御性编程、编写单元测试模拟故障
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
错误处理	只给乐观的情形编码	基本的代码错误处理，抛出异常/生成错误	确保错误/异常留在程序中有良好的状态，资源，连接，内存都有被合适的清理。	在编码之前察觉可能出现的异常，在代码的所有层次中维持一致性的异常处理策略，提出整个系统的错误处理准则。
IDE	IDE大部分用来进行文本编辑	了解其周围的接口，能够高效地通过菜单来使用IDE	了解最常操作的键盘快捷键	编写自定义宏
API	需要频繁地查阅文档	把最频繁使用的API记在脑子里	广阔且深入的API知识。	为了使实际任务中常用API使用更加便捷，编写过API的上层库，填补API之间的缺口。	E.g. of API can be Java library, .net framework or the custom API for the application
框架	没有使用过主平台外的任何框架	听过但没用过平台下流行的可用框架	在专业的职位中使用过一个以上的框架，通晓各框架的特色。	某框架的作者
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
需求分析	接受给定的需求和代码规格	能对规格的遗漏提出疑问	了解全面情况，提出需要被规格化的整体范围。	能够提出更好的可选方案，根据经验的浮现给出需求
脚本	不具备脚本工具的知识	批处理文件/shell脚本	Perl/Python/Ruby/VBScript/Powershell	写过并且发表过可重用的代码
数据库	认为Excel就是数据库	知道基本的数据库概念，规范化、ACID（原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）、事务化，能够写简单的select语句	能够牢记在运行时必要查询中设计良好的规范化数据库模式，精通用户视图，存储过程，触发器和用户定义类型。知道聚集与非聚集索引之间的差异。精通使用ORM（Object Relational Mapping对象关系映射）工具	能做基本的数据库管理，性能优化，索引优化，编写高级的select查询，能够使用相关sql来替换游标，理解数据内部的存储，了解如何镜像、复制数据库。知道两段数据提交如何工作
经验 Experience
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
专业语言经验	命令式语言和面向对象语言	命令式语言,面向对象语言和说明型语言(SQL),如果了解静态类型vs动态类型，弱类型vs强类型则有加分	函数式语言,如果了解延缓求值，局部套用函数，延续则有加分	并发语言(Erlang, Oz) 逻辑语言(Prolog)
专业平台经验	1	2-3	4-5	6+
专业经验年龄	1	2-5	6-9	10+
领域知识	没有该领域的知识	在该领域中曾经至少为一个产品工作过	在同一领域中为多个产品工作过	领域专家。在该领域设计和实现数种产品/方案。精通该领域使用的标准条款和协议
学识 Knowledge
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
工具知识	仅限于主要的IDE(VS.Net, Eclipse等)	知道一些流行和标准工具的备选方案	对编辑器、调试器、IDE、开源的备选方案有很好的了解。比如某人了解大多数Scott Hanselman的威力工具列表中的工具，使用过ORM工具。	实际地编写过工具和脚本，如果这些被发布则有加分
语言接触	命令式语言和面向对象语言	命令式语言、面向对象语言和说明型语言(SQL),如果了解静态类型vs动态类型、弱类型vs强类型则有加分	函数式语言,如果了解延缓求值、局部套用函数、continuations （源于scheme中的一种高级控制结构）则有加分	并发语言(Erlang, Oz) 逻辑语言(Prolog)
代码库知识	从来没有查询过代码库	基本的代码层知识，了解如果构建系统	良好的代码库工作知识，实现过几次bug修复或者完成了一些细小的特性	实现了代码库中多个大型特性，能够轻松地将多数特性的需求变更具体化，从容地处理bug修复。
下一代技术知识	从来没听说过即将到来的技术	听说过某领域即将到来的技术	下载过alpha preview/CTP/beta版本，并且读过一些文章和手册	试用过预览版而且实际地构建过某物，如果共享给其他人的话则有加分
	2ⁿ (Level 0)	n² (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
平台内部	对平台内部毫无所知	有平台基本的内部工作的知识	深度的平台内部知识，能够设想平台如何将程序转换成可执行代码。	编写过增强平台或者为其平台内部提供信息的工具。比如，反汇编工具，反编译工具，调试工具等。
书籍	菜鸟系列，21天系列，24小时系列，蠢货系列...	《代码大全》，《别让我思考》, 《精通正则表达式》	《设计模式》，《人件》，《代码珠玑》，《算法设计手册》，《程序员修炼之道》，《人月神话》	《计算机程序设计与解释》，《事务处理:概念与技术》，《计算机程序设计模型》，《计算机程序设计艺术》，《数据库系统导论》 C.J Date版，《Thinking Forth》，《Little Schemer》（没找到其中译本）
博客	听过但是从来抽不出空去接触	阅读一些科技/编程/软件工程的博客，并且经常的收听一些播客	维护一些博客的链接，收集博主分享的有用的文章和工具	维护一个在编程方面，分享有个人见解和思考的博客

本文链接

惠普

2011-08-31T09:59:00Z

惠普旗下集团及业务比重

信息产品集团（PSG）收入同比下降1%，运营利润率为6.4%。该季度PSG达到了创纪录的运营利润，在出货、收入和利润上都处于PC市场领先地位。由于商用电脑更新换代周期的持续，惠普商用客户机收入比去年同比增长11%，而消费客户机收入下降12%。
打印及成像系统集团（IPG）收入同比增长7%，运营利润率为17.0%。该季度IPG整体业务表现强劲，所有打印业务类别均实现了股份盈利，商用打印硬件单元实现同比增长33%。IPG将在惠普云打印（ePrint）平台、图像艺术（Graphic Arts）和其他商用印刷方案方面继续推动创新、实现突破。
惠普服务收入同比下降2%，运营利润率为16.0%。由于在服务交付转型方面的努力，惠普服务运营毛利率同比增长了30个基点。第一财季，企业服务获得了稳固的长期签约。收入同比下降的部分原因是由于短期内的疲软签约、高附加值的服务和附加的IT外包项目。
企业服务器、存储和网络集团（ESSN）收入同比增长22%，运营利润率为14.7%。第一财季，ESSN实现坚实增长，由于ESSN通过融合式基础架构向混合云环境的迁移，实现了在服务器、存储和网络服务领域的创新，为客户提供了更多价值。
惠普软件收入同比增长5%，运营利润率为17.6%。第一财季，随着对Fortiry和ArcSight的整合，惠普软件扩大了安全领域业务。
惠普金融服务收入同比增长15%，运营利润率为9.6%。惠普金融服务的增长是由于租赁量的两位数增长及资产组合的健康发展。

惠普各业务的营收结构图

新闻跟踪：

剥离PC 惠普押注云计算胜算有多少？
惠普剥离PC业务后还剩下什么？

本文链接