电子商务&互联网
Amazon AWS使用体验
近几个月来简单体验了Amazon AWS大部分服务，现在分享一下使用感受。
Amazon EC2
从各方面来看，EC2应该算是Amazon的王牌产品。EC2功能全面，它可以在数分钟内launch一个实例，可以（理论上）自动提升/降低机器性能配置，可以绑定EBS成为具有高可用性特质的计算核心，可以摇身一变成为ELB成为一个load balancer。这些功能非常实用，特别适合针对国外市场且快速增长的小网站，可以在前期完全不受机器约束。
EC2机器的内核在申请时指定，有很多选择，如果有闲心，还可以做一个自己专用的，我们没用这个功能，实在太繁琐了。EC2提供了完全的root权限，可以随意安装软件，由于EC2一般带有足够的硬盘空间（Large Instance就自带850GB磁盘空间），装个mysql当数据库机器也完全没有问题。
EC2最大优势是灵活，最大劣势则是性能。EC2的IO性能欠佳，当EC2机器作为mysql数据库时，系统吞吐量只能到3~10 MB/s，相比而言，在同样数据同样程序条件下，使用真实机器则能轻松达到30MB/s。EC2的CPU是多个实例共享的，一般stolen的CPU都在10%左右，对于nginx+php-cgi这样的组合，EC2高端配置也不太能撑住压力，总是CPU吃紧。
虽说EC2劣势明显，但由于互联网应用一般都很容易做到水平扩展，它的灵活性可以很大程度缓解这个劣势，不会有太大问题。不过最终我们还是放弃了EC2，主要因为今年5月Amazon云计算服务出了大量的事故，仅5月头两周，在同一个机房就出了5起大事故，我们在3起事故中受影响，每次都很不幸的都是单点EC2出问题，最长的一次在高峰期中断了6个小时服务，损失巨大。最郁闷的是，到了5月下旬，有一台跑数据库的EC2机器莫名奇妙磁盘损坏，还有一台莫名其妙的无法ssh，让我们感觉越来越不靠谱，于是决定逃离。云计算的可用性始终值得担心。
EC2的价格相对传统IDC要贵不少，按高端机器High-Memory Double Extra Large每小时1.2US$来算，每月就要花864US$，再加上流量费，很容易达到每台服务器1000US$的水平。
Amazon RDS
RDS是一种数据库托管服务，通过RDS toolkit可以很方便的创建RDS实例并立即使用。据Amazon帮助文档说，RDS的数据库软件维护、升级、优化的工作全部由Amazon负责，用户只需要使用功能即可。
可惜，RDS纯粹是一个看起来很美的东西。首先是RDS为了同时支持异构的数据库，牺牲了很多灵活性，例如，因为无法访问RDS的物理机器或存储空间，使得跑着mysql的RDS实例连记录slow log都成了难事，更别说什么err log，出了问题只能一抹瞎。如果要获取bi/bo这样的数据需要使用专用的RDS toolkit完成，很难集成到现成的监控工具里去。其次，RDS底层使用的是类似于EBS的网络存储，其IO性能差到一个令人发指的地步。一个很感性的数据是：使用RDS Double Extra Large DB Instance跑mysql时慢查询占1%，同样数据转到EC2 High-Memory Double Extra Large实例后慢查询降为0.01%。最让人无语的是RDS价格高于同等配置的EC2+EBS价格，每小时都贵超过0.3US$，相当于贵25%，省下来的钱用来雇专业运维人员绰绰有余，而且RDS功能和灵活性还远弱于后者，不怕折腾但怕花钱的人不建议选择RDS。
如果执意要使用RDS，那么一定要注意RDS没有固定IP，每次重启实例（或过一段时间）都会变，程序连接的时候最好写域名，当然，这会损失性能。此外，RDS可用性也没宣传的那么高，我们5月最先挂的就是RDS实例，一挂就是好几个小时。
Amazon S3
S3是少有的看上去物美价廉的东西，只需要花几美元就可以拿到几十GB空间，对一般的互联网应用来说绰绰有余。
S3提供丰富的API和工具上传文件。对firefox用户来说，有一个专门的S3扩展可用，可直接上传本地文件。还有一个s3curl.pl工具，可以用命令行传任意文件，可以方便的做到自动化。
S3存储的文件可以直接通过域名从外网访问，不过比较郁闷的是文件尾部不能带“?“，一切基于文件名后面加随机串的避免缓存的做法都会失效。
Amazon CloudFront
CloudFront是一种CDN，它的访问速度据称不错，我们并没有实际使用过。
我们不使用CloudFront主要是因为很难控制文件在CloudFront中失效。根据我们的程序结构，我们需要在静态文件后面加version信息强制用户在必要时更新到最新版，现在由于CloudFront既不能手动invalidate某个文件，也不能保证CloudFront上缓存的文件及时更新（可能更新会花24小时），我们需要修改现在的策略才能使用到它。
CloudFront是根据用户所在网络来收费的，对于国内，CloudFront使用的是香港价格，贵于美洲和欧洲，不太划算。对于欧美市场，我也不清楚欧美CDN的价格究竟如何，无法比较。CloudFront在欧美的流量费用与EC2相同，不过由于没有按小时计的租费，总体价格会比EC2提供静态文件服务便宜很多。
Amazon CloudWatch
CloudWatch是一个性能数据监视器，对于这个东西我只能说太小儿科了，没看出来有什么实际的用处。一旦开启CloudWatch，Amazon就会帮忙收集开启了这个服务的instance数据，包括CPU和IO信息等。可惜，数据精度不高（大概是几分钟一次统计），数字也只是个大概值，能看的数据也很少，无论对入门者还是高手来说，都不能带来太多价值。
CloudWatch看上去比较好的是可以配合EC2/EBS/Load Balancer toolkit做一些auto scale的事情，自动提升/降低EC2/EBS参数，还可以（理论上）自动launch新实例。这些东西我们都没尝试过，有兴趣的同学可以试试。
CloudWatch价格不贵，一台机器就只用0.1US$而已，不过一般还是不建议开，装一个其他监控软件更靠谱。
Amazon Premiun Support
Premiun Support包括即时的电话支持和一个专有的提案系统。从服务质量上来说，Amazon的客服总是很热心，响应速度也很快，专业素质也不错，很不错。
Premium Support非常贵，简直是抢钱。它是按照每月总花费来算价格的，最多增加总花费的16%，最少为无限接近于10%，代价十分明显。
结语
Amazon AWS提供丰富功能，还有不少toolkit和API，适合小应用使用。对于要求较高性能或较低成本的应用来说则不太适合，折腾一下IDC应该达到更好效果。
amazon云计算服务初体验
本周第一次实际使用amazon的云计算服务，主要包括Amazon Elastic Compute Cloud (EC2) 和Amazon Relational Database Service (RDS) ，有一些感受先记在这里。
先说说EC2。它很类似网上的虚拟主机服务，拥有root权限，可以完全控制上面的服务，默认拥有一个对外的dns地址，并可以开放80和22端口。
从性能上来说，EC2的表现很不错。从功能上来说，EC2最大的限制就是端口和ip。对于端口，80和22只能满足最基本的web应用，如果要使用自定义端口/协议的socket方式提供服务，恐怕就比较麻烦了。对于ip，默认每个EC2服务器都是动态ip，最安全的方法是用自己的域名做CNAME转发来对外提供服务。有一点需要注意，EC2服务器的外部dns和ip是绑定的，一旦给它换ip，例如为它花钱绑定一个固定ip，它的外部dns也会变，这就需要修改自己域名的CNAME记录。可麻烦就麻烦在EC2实例换了ip后立即就换外部dns，而普通dns缓存则可能会很长，这将造成在换ip的这段时间内服务可能不稳定。为了长治久安，还是一开始就申请一个固定ip会比较稳妥呢。
EC2对外部流量收费，内部不收费，或者在跨区的内部服务器通信时收非常少的费用。EC2服务器单机流量上数十MB/s不成问题，不过随着提供服务的EC2服务多了起来，我们自己搭的load balancer服务器已经有点力不从心，看到EC2有专门的load balancer服务，并且还挺便宜，下周一定试一试。
相比EC2，RDS则非常的不自由，它不能用ssh登录，数据库程序也不能控制版本，还有不少数据库配置不能改。如果在RDS上使用mysql+innodb，那么有不少不爽的地方：
innodb_data_file_path配置不能自己控制。RDS会将这个设置为ibdata:10M:autoextend，且不能改，这对高并发的读写会造成问题。
没法在本地以文件方式保存slow log。
无法直观的监控机器性能，只有一些RDS专用的命令行工具能得到一些实时的数据。
无法对操作系统进行进一步调优，甚至都不知道底层跑的是什么操作系统。
不过RDS也有一些好处：
存储空间可以无限增长。就像flickr的相册一样，每月都有一定的增长额度，总存储空间可以无限增加。
数据安全性可以保证，可以方便的制作snapshot和完整备份，备份所花的存储空间只要不大于每月增长额度就完全免费。
amazon会负责数据库软件的安全性，给它及时打补丁。
综合来说，RDS提供的控制手段有限，不太适合对性能有较高要求的应用。从实际是用来看，同样的程序和网络环境之下，Double Extra Large DB Instance上的mysql+innodb明显慢于Double Extra Large EC2上自己安装并优化的mysql+innodb，一个典型的数据是：使用前者，慢查询比例是1%，使用后者，这个比例立即降为0.01%。
放弃RDS也就意味着放弃RDS的各种好处，为了弥补这个不足，可以为EC2申请Amazon Elastic Block Store (EBS) 。EC2+EBS就和RDS没什么两样了，只是管理起来还是有点费神，综合的价格应该和RDS差不多。我这里还没有真正尝试过EC2+EBS的方案，以后等存储出现瓶颈了再说了，现在EC2自带的850G存储绰绰有余。
amazon的服务还是挺让我满意，特别是phone support反应很快速，服务人员也挺专业，挺好。不过我并没有其他云计算服务的使用经验，没有比较，也不清楚amazon云计算在业界究竟出于何种地位，这个以后再慢慢去了解吧。
淘宝视频和淘宝电子杂志：这葫芦里卖的什么药
淘宝最近推出了两个网站，淘宝视频和淘宝电子杂志，很有点不务正业的样子。
通过这两个网站的内部链接可以发现，它们都是淘宝与其他网站合作的结果，并不是淘宝自己提供的内容和技术。淘宝视频的内容来自激动网，淘宝电子杂志的内容来自ZCOM。淘宝只是提供一个整合的首页，在内容旁边放一些淘宝的牛皮癣广告，真正的流量则直接让给了上述两个网站。从现实好处来说，这两个本不著名的网站占了大便宜。
激动网和ZCOM为淘宝定制的网页都可以用淘宝账户登录并发表评论，这实际上意味着淘宝在变相的拓展产品线。对普通用户来说，打开淘宝视频或电子杂志首页之后，只要网页风格和登录方式统一，那么就相当于没有离开这个网站，他们不会管域名是否已经改变。未来如果淘宝真的想涉足这两个领域将变得非常自然，现在的做法只是在布局，在树立口碑。
毫无疑问，淘宝视频和电子杂志可以增加用户黏度，让用户不用离开淘宝就能找到所需要的东西，不知道这是否也是大淘宝战略中的一部分。之前淘浆糊出来的时候，就已经可以看出淘宝想利用SNS增加用户黏度的想法，现在再加上这些娱乐元素，将会继续朝这个方向发展。
从某种意义上来说，做这两个网站是淘宝的悲哀，也是中国互联网的悲哀。中国网站鲜有专注者，阿里巴巴集团一直都不专注，但如果单看淘宝网或许还算好，至少都在围绕着购物这件事情不断发展。但随着这两个网站的加入，纯粹为吸引用户的娱乐元素越来越多，淘宝越来越像门户，不知是否会变成第二个QQ.com。莫非是淘宝内部已经觉得自己在购物平台方面已经无事可做了？大概是他们的产品和研发都没空看淘宝社区吧。
究竟淘宝在这两个网站上能玩出什么花样还需要时间来证明，我等着。
Twitter Lists：Twitter新玩法
Twitter最近大规模的公测Lists功能非常有趣，跟其他平台中tag、好友分组等功能类似又不相同。
Twitter里面本没有好友的概念，所谓的follower和following也只是一种订阅关系。这个lists功能并不限于在自己的follower和following之中使用，可用于任何一个用户而不用建立关系。
Lists也可以被follow，follow之后就可以看到list里面所有用户的更新。
在这里我有一个有趣的想法，有了lists还要follower和following关系干什么？特别现在twitter用户数不断疯狂增长，对于一个twitter新人来说，该follow谁是一件非常头痛的事情。有了lists之后，新人只需要关注名人和名人创建的list就可以开始twitter生活了，这比原来好上很多。
想必twitter以后会推出热门lists，甚至于对lists进行评价和打分，增加lists的用户参与度，把lists变成一个新媒体的入口，赋予那些有话语权的著名twitter用户更多舆论导向的权利。从此以后，@Fenng大概也不用再来推友推荐计划了，只需要创建一个list然后宣传这个list就可以了。
从体验上来说，管理list里面的用户是非常困难的事情。
点击list的edit链接之后得到的是这个浮动层，不过并没有管理用户的选项。
如果只是删除用户那还好，只需要点击following链接，然后把用户从list中去掉。不过如果要新增用户就必须从find people或者其他用户的首页点击，在list界面上却完全找不到类似于add的链接。其实twitter只需要把find people包装一个接口放在list管理界面就很好了，只可以他们还没想到。
最后说说怎么推销自己的list。Twitter提供了一个Tweet about it的入口操作，同时还可以简单的使用@功能引用list，这个很赞。例如这个百付宝员工的list：@baifubao_news/staff
最后的最后，请不要问我怎么顺利的上twitter，我不知道，我只是机缘巧合的得到了twitter的信息并找到了上面的图而已。:P
体验为先
一般的想法似乎是：产品部负责体验，技术部负责实现细节，这两者虽相辅相成，但终究关注点不同。不过我觉得其实技术部也应该关注体验，这种体验是开发体验、运维体验和用户体验，至于实现细节，反倒是最后需要关注的。这样提的原因是，确实有一些技术的人一见到好的新奇的技术就像应用到项目中去（本身没什么不好），却没把体验这件事情做好（这个有点不好）。
现在来说说我对体验的理解。作为开发者，最大的目标绝不只是开发符合需求的产品。产品的开发、实施、上线、维护等过程都涉及大量不同的人，每一个相关的人对这个产品都有自己的体验，都会对这个产品在某一方面上是否好用有自己的看法。就像体验不好的产品会被用户弃用一样，过程体验不好的产品也会被开发者抛弃，只是迟早的事。
开发体验好也就是代码具有很好的观赏性、架构容易懂、代码质量高、具有可伸缩性等，它是开发过程中最需要注意的事情。
代码是开发者之间的交互工具，一个开发者写出来的代码其实就是其他人未来将用到的“界面”，它的体验直接影响到它的用户（所有与它相关的开发者，包括作者）对它的看法。开发体验不好的代码，在完成自己的当前使命之后很可能会很快被开发者厌倦，甚至废弃，如果一个组织不断在废弃旧代码，做重复造轮子的事情，这种开发成本当然很大，其中明显有问题。
这里有一个很有趣的问题，如果牛人写出来的精致无比的代码是否就一定是具有好的开发体验的代码？这还真不一定。如果确实周围的人一个都看不懂这代码，要么就不要把代码写那么好，浅显一点会更好，要么就多找一点能看懂这种代码的牛人。过于美妙而难以理解的代码是定时炸弹，一旦牛人离开就会面临难以维护或者必须重写的风险，这对于公司而言是不可接受的。说到底，体验是人的主观感受，不同的受众就有不同的体验，好的体验的定义也不同。
做好了开发体验，其次要做的是运维体验。运维体验主要包括更新服务、排错、监控的复杂程度等，主要的用户是运维人员。现在搭建一个大容量的网络应用至少需要几十台机器，机器之间的互相依赖如果管理不好就会变成网状，有点牵一发动全身的味道。有些时候开发者相比运维体验，更关心功能是否能实现，这是有问题的。对于互联网企业，不变的是变化，任何一个服务上线之后都会有用户不满意的地方，如果升级的运维成本比较大，开发者/产品负责人就会惧怕改变，这将直接影响服务质量和用户体验，最终还是害了产品。
此外，作为开发者应该时常思考如何量化服务的质量。是不是满足了一定的服务质量指标就好了？还有没有其他指标？在不同阶段这些问题的答案都不一样，比如已有服务基本稳定之后，开发者可能会从最初的服务质量转而关注如何发现服务性能瓶颈上，这时，难以运维（或者说“监控”）的服务就会显示出弊端，甚至变得没法满足运维体验方面的需求，导致重新开发。
所以在代码设计完了之后就开始考虑如何运维它是一个很值得建议的做法。
最后，好用的产品要落实到用户身上，他们的用户体验是绝对产品成败的关键。在这个时候，开发者可能有的误区是追求完美，希望在项目结束的时候就解决所有已经发现的问题，这其实完全没必要。很多大软件（例如微软的各种软件）遗留一堆bug就敢发布，为什么，就是因为开发者应该追求的是用户体验，而不是那些完全不影响用户体验、只有geek可以发现的微小缺陷。
另外，有这种追求完美思想的另一个原因是惧怕变化，希望一次性做完之后再也不去碰这份完美的代码，实际上这也是不切实际的。保持重构才是我们应该追求的目标，无论是针对代码本身，还是各种体验。
我们在某些时候或许可以追求快而放弃一个或两个体验而直接追求用户体验，但最后还是要补课，欠下的总要还。同时，不要一次性就把三种体验追求到极致，它们应该是迭代完成的。
要想一开始就能做到较好的开发体验、运维体验直到用户体验其实并不难，难就难在有没有这样去理解这些事情。说白了，就是有没有在各个环节为他人着想、为未来打基础，这才是一种做产品的开发者。
C2C卖家和个体户
我总是很自然的把C2C卖家和个体户联系起来。
我还记得90年代初，个体户遍布大街的景象。当时不少没文化也没资本的小户人家“下海”变成个体户，在大街上免费占道，做起买卖。武汉现在最繁华的江汉路步行街，在当时就是个体户一条街，一到晚上，不知道从哪里冒出来的个体户们搭起小棚子卖一些便宜的日用品。
有了个体户，实际上也就是有了另一种消费渠道。原来必须去商场或者杂货铺买的东西，如果门口的个体户可以解决，自然就近买了。原来在大商场买不到的杂牌小玩意也因为个体户的出现变得普及，使得消费有了更多的选择。
这些小商贩之所以被称作“个体户”是因为他们一般都是一个人或一家人支撑一个小店，没有雇员，一般也不去缴税。经过不断发展，少数个体户抓住一些机遇变成了大户，慢慢成了合法的公司，也不再流浪街头，有了自己的地盘。还有不少个体户，因为利润薄、自己又没什么文化不懂经商，一直只能保本经营，没太大起色。
随着时代的发展，那些保本的个体户越发活不下去了。首先是马路不再免费，警察/城管把不愿意交钱的个体户赶走，断了他们的财路。其次，现代的商城和超市出现了，在那里有质量得以保证的商品，而且明码实价，不再需要考虑怎么砍价，省心放心。再次，老城区被开发成商业区，满街都是住在房子里、证照齐全、按时缴税的固定卖家，他们既可能是原来的大商家的分店，也可能是发达了的个体户，他们经营的东西与个体户重叠，直接抢走了个体户的客源。最后，由于商业规则越来越完善，通过个体户方式发迹的可能性越来越小，走向成功需要的知识积累越来越多，明眼的个体户渐渐主动放弃这一行。
现在，个体户这个词已经几乎听不到，他们的后辈，摆着路边摊的小商贩，也经常和假货、骗子、穷人等不太好的词汇绑定在一起，怕是有意踏足商界的人不会再以这种方式打天下了吧。可以说，个体户经过短短十几年的发展到如今已经名存实亡。
当今最受欢迎的卖家是国美、各种Shopping Mall、洋百货，他们为什么会成功我不知道，但我大概可以确定个体户包括与他们类似的C2C卖家不会再卷土重来了。面对大商家，那些小鱼小虾们无论在资金还是渠道还是物流方面都处于劣势，他们还要面对很大的政策风险（以后会出现网络城管么？）。他们一定会存在，因为有需求，但很难成为主流。显然，想从他们身上捞取运营费用将极为困难，有钱的话还是自己做商场比较好。
Opera Unite：怎么看这个玩意也不会成功
标题说的是直白了点，不过是心里话。使用Opera Unite以后，真的觉得这个公司的努力怕是又要打水漂了。
首先，Opera Unite还在玩Web 2.0概念，这其实已经有点过时，粘度有限。特别是Opera的用户还属于小众、互动的圈子不够大的情况下，Unite的新鲜劲过去以后，使用者的孤独感会逐渐产生，最后就会使得Unite的互动圈子进一步萎缩、甚至死亡。
其次，Unite本身其实与浏览器关系不大，它更像是Opera的插件平台，能帮用户完成很多与浏览器无关的事情，如果Opera把这个当作它的killer feature，那恐怕就押错宝了。从Unite的扩展性上看，它无法与Firefox的插件体系相比。从功能上看，Flock这样的社会化浏览器就能在功能上轻松仿制Unite。
最后，Opera Unite与手机和其它设备互动的想法很好但很难实现。技术难度是显而易见的，在客户端上面动脑筋实在比Web App难很多。Opera这个公司能有这么大的号召力去推动大家在Unite平台上写应用么？如果没有，他们自己有实力搞定那么多个平台么、写出那么多引人入胜的应用？这个非常值得怀疑。同时，Unite在前期是不会有什么盈利模式的，Opera必须持续砸钱供养整个团队，并且做很多必要的宣传，这种运营成本肯定不低。那么困难同时还得不断花钱，Opera公司是否能够一直坚持也值得观察。
Opera公司10年来占有率一直在1%上下徘徊，他们的营销能力实在令人怀疑。我对他们这次放的这颗卫星不抱太多希望，静观其变，静观其慢慢消亡。
