云主机初体验(盛大云和阿里云)

近来时常听到云计算、云主机的概念,它们一度挑战我的认知能力,在国外云主机已经非常流行,国内才刚刚兴起。近日,朋友给了个邀请码,卢松松这才有机会体验了把云主机,才算基本搞清楚是怎么回事。也希望为主机犯愁的朋友提供些思路。

亚马逊是云主机应用的开创者,在国内传统的IDC公司,如万网、华夏名网也有此业务,国内做云计算较快的也就是阿里和盛大了,所以我介绍的是盛大云和阿里云。这两个不仅有大公司的背景,而且用的人也很多。

云主机的一些优势

云主机实质是租用主机业务的一种,我所知道的优势有:

1:云主机没有单双线路之分,在全国有很多节点,线路包含网通、电信、移动等。

2:可扩展性强,用户可随时对硬盘、宽带扩容,而不需要改变服务器和网站的状态。

3:用户可以根据需要,选择按月、按年付费,盛大云甚至精确到按小时付费。

4:可快速克隆出一个新的云主机,再也不怕网站瘫了。

至于其他优势,诸如防APP、DDOS攻击,独占资源、独享宽带,这些需要长时间才能验证出来,我也无从验证,还有一些感觉不是很靠谱,但总的来说,云主机优势还是明显的。

盛大云和阿里云对比

硬件对比

盛大云:种类丰富,不到2000块钱就能拿下一个云主机。适合中小站长的有超微主机(417元/年、)、微型主机(834元/年),在加上最低2M宽带(1080元/年),而且还可以按月、按小时付费。

阿里云:套餐少,但服务器配置都很高,拿下最便宜一台云主机至少要5000元以上。

软件对比:

盛大云的系统有windows2003,Linux CentOS5.4,阿里云的系统有windows2008,centos,redhat,ubuntu,debian,遗憾的是两家只提供MYSQL数据库,MSSQL不提供怎么会选windows主机呢?

盛大云还包含云监控、云备份、网站云(一键建站)、数据库云等一系列适合中小站长的服务。而阿里云适合中小站长的服务较少,例如网站云(一键建站)、云盾(web漏洞检测)、负载均衡等。

两家不断挑战着我的认知能力,我就不多做介绍了。

带宽/价格对比:

除了租用云主机价格外,还有带宽的费用。盛大云的带宽是按流量计费的,比较灵活,如遇到突发的高流量足够应付,而阿里云的的标配是5M带宽,但对于图片较多的网站、下载站、或被盗链的网站5M带宽就显得明显不够用,增加带宽也许只能找客服了。

两家主机的带宽均能达到相应描述,阿里云主机可以稳定跑满5mb带宽,盛大云主机因为不限制带宽,跑满了我的10m光纤和阿里主机的5m带宽,再高无条件测试了。

硬盘实际测试:

这里引用一位网友alilab的测试结果,阿里云主机的硬盘是C盘独占一个虚拟盘,数据盘可以根据需要自行分区,盛大云超微和微型硬盘均只有一个C盘,测试使用的是最高级别的型号。测试的均是D盘,盘内无任何数据。

阿里云主机

基准测试

随机存取测试

C盘压缩 D盘测试 (此测试时D盘已经使用了7个G故开始部分有一定影响),开始对C盘数据压缩时,D盘的测试性能不但没有降低反而突然窜了个高。
盛大云主机硬盘测试
基准测试

这磁盘性能简直无语了,18m是神马速度?还不如我的U盘快,远不如之前使用的西数的VPS的磁盘性能,多次测试后发现,不同时间性 能略有不同,似乎是共享的物理磁盘资源,当其他用户使用时会影响我的磁盘性能,单从这方面看,盛大的云主机更像是大规模的vps主机。
随机存取

C盘压缩D盘测试

开始C盘压缩后D盘性能急剧下降,可以肯定云主机里的两块虚拟盘均在同一个物理硬盘下,这就像你使用自己的电脑在C盘压缩数据时,在使用D盘的数据会非常困难。

测 试过后,不得不说阿里云主机的磁盘性能绝对一流,比我自己省用的台式机硬盘性能还要高一些,而且最值得称赞的是,阿里云主机的系统盘和数据盘是独立的,此 处说的独立是指对C盘操作时不会影响D盘的速度,反观盛大云主机的磁盘性能,简直太无语了,评测下来甚至不如本人之前试用的西部数码的vps的磁盘性能, 而且对C盘操作时严重影响D盘的性能,推测盛大云主机应该是采用的类似vps技术,只是对单一硬盘的简单虚拟化,而且根据测试数据猜测其试用的很可能 是普通台式机使用的sata硬盘,而非服务器专用的sas硬盘。

解 释一下为何如此看重硬盘性能, sql数据库数据较多后,查询速度变得很慢,尤其是上网高峰时期,因为vps是共享资源,硬盘速度就很吃力了,一个页面执行时间甚至一度达到了秒记,这也 是此次更换云主机 的主要原因,也因为此最终选择了阿里云的主机,页面执行时间维持在0.01-0.05秒之间,10万数据量的sql2000数据库。

总结:
阿里云贵,比租个服务器价格都高,盛大云便宜,很适合小站用,用多少花多少,不会浪费,但一分钱一分货。盛大云给我的感觉是VPS升级版,而阿里云开始逐渐抛弃中小站长了。个人观点,仅供参考。

作者:卢松松

给开发维护大型项目开发者的建议

假设你是正在开发和维护一个包含2000个类并使用了很多框架的Java开发人员。你要如何理解这些代码?在一个典型的Java企业项目小组中,大 部分能够帮你的高级工程师看起来都很忙。文档也很少。你需要尽快交付成果,并向项目组证明自己的能力。你会如何处理这种状况?这篇文字为开始一个新项目的 Java开发者提供了一些建议。

0. 不要试图一下子搞懂整个项目

好好考虑一下,为什么理解项目代码是第一位的?大部分情况是你被要求修复一个bug或者加强系统已有功能。你要做的第一件事情不是理解整个项目的架构。当对项目进行维护时,这样(理解整个项目架构)可能会对你造成巨大的压力。

即便是有着10年可靠编程经验的Java开发者可能也没有理解项目的核心工作机制,尽管他们可能已经在这个项目工作超过一年(假设他们并非原始开发人员)。比如,对于认证机制或事务管理机制。

他们是怎么做的?他们对于自己负责的部分非常了解,并且能够交付价值给小组。每天的交付价值远比了解一些以后还不确定有没有的东西重要的多。

1. 关注于尽快交付价值

那我是否定了你对于项目架构理解的热情了么?完全不。我只是要求你尽早的交付价值,一旦你开始一个项目,搭建了开发环境,你就不应该花一两周时间才交付什么,无论他的规模大小。假如你是一个有经验的程序员却两周都没有任何交付,你的经理怎么会知道你是真的在工作还是在看新闻。

所以交付可以使大家都轻松起来。不要认为你能够做有价值的交付前必须理解整个项目。这是完全错误的。加一段javascript的验证代码对业务就很有价值,经理能够通过你的交付达到对你的信任。这样能够向上级领导证明你的贡献以及员工价值。

日复一日,在你不断修复bug及增强功能之后,就能够慢慢开始理解项目架构。不要低估对系统方方面面理解时需要花费的时间。花3-4天理解认证机 制,2-3天理解事物管理。这些都是依靠之前的相似项目的经历,但关键还是要花时间才能透彻的理解。要在日常工作中挤出时间,不要向经理要求特定的时间来 做这些。

找找项目是否有一些不断维护的单元测试用例。有效的单元测试用例是理解大型项目代码的很好途径。单元测试能够帮助理解代码片段,包括一个单元的外部接口(单元如何被调用以及返回内容)及其内部实现(调试单元测试比调试整个实际用例简单许多)。

你如果能够很好的理解一些内容,写一些笔记,或者画一些类图、时序图、数据模型图,以便你或日后其他的开发者维护。

2. 维护大型项目所必须的技能

你能从事当前的工作,必然已经具有良好的java技术。我们来谈谈能够让你在新项目中良好表现的其他技能。大部分时间,你在项目中的任务是修复bug和增强功能。

有两项很重要的技能能够协助你维护大型项目代码。

2.1 能够迅速发现需要的类

在任何维护活动中,无论是修复bug或增强功能,第一个动作就是识别出当前修复或增强的用例中调用的类。当你定位到需要修复或增强的类/方法,就已经完工了一半。

2.2 能够分析变更的影响

当你在完成必要的修改或增强工作后,最重要的就是要确认你的修改没有破坏代码的其他部分。你要用你的java技术及对其他框架的理解找出变更可能影响的部分。下面有两个简单的例子详细描述了最后提及的情况:

a)当类A的equals()方法变更后,调用一个保护A实例的List的contains()方法时就会被影响到。若Java知识不够,很难考虑到这样的影响。

b)在一个web项目中,我们假设“user id”保存在session中。一个新入程序员可能在“user id”中加入一些信息作为bug修复的方法,但是却不知道会影响到那些关联“user id”的用例。

当你提高了如上两个技能,尽管你对项目不是非常了解,但大部分的维护任务会变得简单很多。若你修复一个bug,你会定位并修复这个bug,并且保证变更不会破坏项目的其他部分。若你增强或加入一个特性,基本上你只需要模仿现有的特性使用相似的设计。

在一个在线银行项目中,为什么“查看账户摘要”和“查看交易历史”的设计需要巨大的差别呢?如果你理解了“查看账户摘要”的设计,完全可以模仿开发出“查看交易历史”的功能。

就修复bug和增强来说,你不必完全理解所有2000个类的工作内容和代码如何运行来推动系统。你若有上面的技能,就能很快定位需要修改的代码的部分,使用良好的java和框架技能修复,保证变更不会破坏项目的其他部分并交付,尽管你可能只知道一小部分项目的设计。

3. 使用工具找到需要的变更内容以及变更产生的影响

继续我们尽快交付的主题,你应当寻找那些能够通过尽量少的了解项目但能帮助你尽快实施交付的工具作为辅助。

3.1 迅速发现需要变更内容的工具

无论是修复bug还是系统增强,首先都要找到该用例调用的你需要修改的类及方法。基本有两种方式理解一个用例的工作方式,静态代码分析和运行时分析。

源码分析统计扫描所有代码并且展示类之间的关系。市场上有很多设备与工具。比如:Architexa, AgileJ, UModel, Poseidon等。

所有的静态代码分析工具缺点在于无法确切展示用例中类或方法的运行时调用情况。因此Java新加入了特性,如回调机制(callback patterns)。如静态分析工具无法推断出当页面提交按钮被点击时哪个Servlet被调用了。

运行时分析工具能够展示类和方法在用例运行时的状态。工具包括:MaintainJ, Diver,jSonde,Java Call Tracer等。这些工具可以捕获运行时的堆栈状态,并以此为一个用例生成序列图和类图。

序列图展示了该用例在运行时所有调用的方法。若你在修复一个bug,那这个bug很可能就是这些被调用的方法之一。

若你在增强已有功能,利用序列图理解调用流程然后再修改。可能是新增一个验证,修改DAO等。

若你在新增功能,找到一些相似的特性,利用序列图理解调用流程然后模仿开发新功能。

要小心挑选运行时分析工具。信息过多是这类工具的主要问题。选择一些提供简单过滤无效信息并能够方便的查看各种视图的工具。

3.2 迅速发现需要变更内容的工具

若单元测试有效,可以通过运行单元测试发现变更有没有破坏其他测试用例。有效维护并且覆盖大型企业应用的单元测试还是比较少的。下面有一些针对该情况的工具。

仍然是有两种技术静态代码分析和运行时分析可以使用。市场中有很多静态代码分析工具可用。如:Lattix, Structure101, Coverity, nWire and IntelliJ’s DSM。

给定一个变更后的类,上述工具均可识别对该类存在依赖的类的集合。开发者需要根据这些信息“猜测”可能产生影响的用例,因为这些工具无法展示运行时类之间的调用关系。

市场上的可以用于运行时影响分析的工具并不多,除了MaintainJ。MaintainJ先捕获在一个用例中调用的所有类和方法。当所有用例的上 述信息都被捕获之后,就很容易发现类的变更对用例的影响。MaintainJ能够有效工作的前置条件就是项目的所有用例都应当先运行一遍,以便能够获得运 行时的依赖关系。

总之,目前你在迅速准确分析变更影响方面,还是可以从工具中获得有限的帮助。首先根据需要实施一些影响分析,然后根据自己或小组其他高级成员评审来判断变更的影响。你可能需要上面提到的工具对你的判断进行反复确认。

4. 对上述内容的两个忠告

4.1 不要降低代码质量

为了快速交付,所以没有全盘理解架构,但绝不能以降低代码质量为条件。下面是一些你可能因为只考虑快速交付而引发的代码质量问题。

因为修改代码涉及到很多的依赖,所以新增代码相对而言风险较小。例如,有5个用例都调用了某个方法。为了改进某个用例,你需要修改这个方法的实现。 最简单的做法就是复制这个方法,重命名,然后在改进的用例中调用新方法。千万不要这么做。代码冗余绝对是非常有害的。尝试对方法进行包装或者重写,甚至是 直接修改,然后重新测试所有用例,通常停下来想一想,然后亲手去实施,是一个比较好的方式。

code quality
( 伯乐在线配图)

 

另一个例子是将“private”方法改为“public”,使得别的类也可以调用。尽量不要将非必须的部分暴露出来。假如为了更好的设计需要重构,就应当着手去做。

大部分应用都有确定的结构和模式来实施。修复或增强程序时,确认你没有偏离这样的模式。若对约定不确定,请其他的高级开发者来审核你的变更。若你必须做一些违背约定的实施,尽量放置于一个规模较小的类中(一个200行代码的类中的私有函数应当不会影响应用的整体设计)

4.2 不要停止深入理解项目架构

按照文章列出的方式,假设你能够在对项目了解较少的情况下进行交付并以此持续下去,可能你会停止对项目架构的深入了解。这样从长远角度来说对你的职 业生涯没有帮助。当你的经验增加时,你应当承担比较大的模块任务。如构建一个完整的新特性或者修改项目的一些基础设计等较大的改进。当你能够做这些改进 时,你对项目的整体架构应该相当了解。文中列举的方法是让你在最短的时间内提升自己,而不是阻止你完整理解整个项目。

5. 结论

整篇文章集中在对项目进行必要了解的前提下进行快速交付。你可以在不降低代码质量的前提下这么做。

若修复一个bug,迅速定位并修复。有必要可以使用运行时分析工具。若新增一个特写,可以寻找相似特写,理解流程(有必要使用工具)并编写。

或许这些听起来很简单,但是实用吗?当然。但前提是你有良好的java技术以及对框架足够了解才能先修改代码,然后对变更影响进行分析。对变更影响的分析比实施变更需要更多的技巧。你可能需要高级开发人员协助你分析变更影响。

大约有50%的IT可操作预算用于简单的bug修复和功能增强。根据文中的建议,对于维护活动中的经费的节省应当还是很有帮助的。

作者 Choudary Kothapalli 也是 MaintainJ 项目的建立者。

Oracle 提供免费 Oracle Linux 更新源

Oracle 正在使 Red Hat Enterprise Linux 的克隆版本 Oracle Linux 可以免费从他们的公共源中获取更新。在此前,只有购买了支持服务的 Oracle 的客户才能获取 BUG 修复与安全补丁,没有购买的用户只能获取 ISO 文件,其中包含的源代码与 RPM 包是自由的,但没有提供安全与错误更新使得用户需要自己维护系统的安全健康。现在所有用户都可以获取这些安全与错误更新了,尽管仍需要注册一个账号用于下 载 ISO 文件。

Oracle 公告了新的产品 Database 11g R2 和 Oracle Fusion Middleware 11g R1 将可以使用在 Oracle Linux 和 RHEL6 中。

根据 Oracle 公司的 Lenz Grimmer 的博文,除了 Oracle 的更新支持外,付费成为 Oracle 客户还可以享受额外的好处,例如使用 Unbreakable Linux Network 上的软件频道,使用 Enterprise Manager 12c for Linux 或 Enterprise Manager OpsCenter 配置、管理、监控 Oracle Linux。

而 Oracle 公司的 Wim Coekaerts 通过博文介绍了如何添加这个免费的源。

这意味着,Oracle Linux 现在开始提供了接近 CentOS 和 Scientific Linux 在过去几年提供的免费服务:克隆 RHEL 的软件包更新并发布。

Oracle 公司正在努力提升 Oracle Linux 的价值,例如最近在它的 Unbreakable Enterprise Kernel(也是免费提供)加入的 BTRFS 支持。

最近 Oracle 公司还倾向于以比 CentOS 和 Scientific Linux 更快的速度发布出 RHEL 次要版本(minor releases)的克隆。

RedHat 在其商业模块中提供了付费的更新服务,最便宜的版本(Desktop 出问题自己解决)是每年 50 美元。

PHP 对程序员的要求更高

今天是愚人节, 但我这个文章标题可不是和大家开玩笑. :)

首先, 大家都知道, PHP也是一种编译型脚本语言, 和其他的预编译型语言不同, 它不是编译成中间代码, 然后发布.. 而是每次运行都需要编译..

为此, 也就有了一些Opcode Cacche, 比如开源的APC, eacc. 还有商业的Zend O+等.

那么为什么PHP不把编译/执行分开呢?

PHP虽然是一种编译型脚本语言, 但是它的编译速度非常快, 它的编译不做任何优化, 就是简单的忠实的把你所写的代码翻译成对应的Opcodes. 而其他语言因为在编译器做很多的优化工作, 会造成编译比较重, 也一定程度上要求它们分离.

所以, 理论上来说, 通过编译执行分离, 想达到源码加密, 是不会有什么太大收效的, 因为它很容易被方向.

另外, 编译直接分离, 并不会带来特别大的收益, 反而会降低调试部署的效率(想想, 修改, 编译, 发布, 看效果), 并且APC等优化工具, 已经很成熟了..

到这里, 请大家注意这句:”它的编译不做任何优化”….

这也就是我为什么说, PHP对程序员的要求更高, 不同于其他的编译型语言, PHP在编译的时候不会帮你做一些优化, 比如对于如下的代码:

  1. for ($i=0;$i<strlen($j);$i++) {
  2. }

如果对于C或者Java等其他语言, 它也许会帮你做优化, 把strlen提取到前面去, 只做一次就够了. 而对于PHP来说, 它在编译的时候不做任何优化, 也就是说, 你的strlen, 会被调用很多次.

再比如:

  1. $table = "table";
  2. while(++$i < 1000) {
  3.   $sql = "select * from" . $table . "where id = " . $i;
  4. }

没错, “select * from ” . $table会被concat 1000次..

可见, PHP的程序员, 需要认真的想好, 你的代码会怎么被执行, 你怎么写代码, 最终的执行效率才最高. 而不像其他的语言, 程序员可以把一部分优化工作交给编译器.

这也就是我为什么说:”PHP对程序员的要求更高” 的原因.

// 本文转载自 @雪候鸟博客

fool.js:整人专用的 jQuery 插件

fool.js 是一个 jQuery 插件,包含了几种页面特效,可以用来在愚人节的时候整人:

  • 消失的滚动条
  • 莫名其妙播放的音乐
  • 随机消失的页面元素
  • 不间断的弹出傻x的问题
  • 页面颠倒
  • 页面扭曲
  • 页面闪烁
  • 无限循环 -> 浏览器崩溃
  • 页面突然变纯黑
  • 无法点击
  • 整个页面可编辑