Posts Tagged ‘programing’

转载:消除小型 Web 站点单点故障(Single Point of Failure)

Friday, November 27th, 2009

转自:http://www.dbanotes.net/web/web_single_point_of_failure.html

我还没有仔细看完,没时间了,所以转过来,留以后查看。

针对小型站点的技术普及信息,中大型网站的牛人不用看,耽误您的时间我负不起这责任。
用 Windows 做网站的也别看了,不适合。

说起单点故障(Single Point of Failure,SPOF),倒是可以想起电影 《2012》中,一把焊枪把齿轮卡住,从而导致整个舱门无法关闭,进而整个引擎无法发动。这是个有点生动的例子–如此庞大的一个系统,居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability),这是致命的事情。

大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够 :)

一般来说,只要系统能够比较清楚的分出层次来,要消除单点故障还是有章可循的事情。比如,一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效的消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,而随着架构的变化,定期审查系统潜在单点也是有必要的。

有人或许会问,假设一个起步中的站点,只有一台服务器,什么东西都在一个盒子里,到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些,首先必须考虑硬盘(存储层)的问题,如果机器只有一块硬盘,即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的),还是建议你起码再弄一块。做镜像,让出错的概率降低,这是划算的投入,当然消除单点,成本几乎不可避免的要增加。如果硬盘多,或者有其他备份机制,可选的方法就更多,别刻舟求剑。

第二个要考虑网卡与网线的单点问题。先说网线,如果要问一个系统里面最容易物理损坏的是哪个组件,答案恐怕非网线莫属,对于网线这样多数时候因为距离需要定制的东西,总是购买成品还是有成本的,从我观察到的情况来看,各个 IDC 的网线使用手工制作的比例不小,这个质量几乎很难控制,一根线,两个水晶头,哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了,网卡绑定 (NIC bonding)一个很简单很通用的办法(refer),但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡,如果是自己攒服务器,记得网卡多一块成本没多大,但是用处会有很多。如果耐着性子看到这里,先别急着去 Google,还有问题呢,两根网线如何接到上行交换机,什么样的交换机支持绑定,如何确定绑定是真正生效的? 答案是,尝试一下。

然后是什么? 是跑多个数据库,还是跑两个 Web 服务器,一个不行用另一个顶? 对于单台服务器,其它能消除单点的地方恐怕收效也不会特别大,现在少做无用功,或许要重点考虑如何备份,如何优化,以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是,除了SSH 登录之外,要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿,如果 IDC 距离较远,需要斟酌一下。好吧,网站有了一点发展,用户量也增加了,感觉需要增加服务器了。再增加一台服务器,抗风险能力一下子加强了许多,毕竟一台机器质量再好,也有出错的时候。现在,Web 服务器、DB 服务器可以考虑引入 HA 的方案,如果单台服务能力够,主备模式也不错。随着网站的发展,服务器数量继续增加…

随着服务器数量的增加,到了必须要自己购买网络设备的时候了。同样的设备,一买恐怕就要买双份,原因无它–一台总要出错,哪怕是电源被拔错–而这样的情况实际上并不少见。如果预算不够,那就再等等,但是要记住,定期审查,有可能的话,进行弥补总不会错。

到现在,所有的服务器都还在一个 IDC 呢,IDC 本身也是个单点啊,服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧,”南北互通”怎么样…或许在选择第一个机房的时候已经遇到了类似的问题,或许现在正在受到这个问题的困扰。选好 IDC 之后,首先计划一下数据如何备份过来,然后,网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击,对自己的网站影响能承受么?

更多的服务器,提供更多的应用,更多的用户,更多的收入… 接下来该怎么办呢? 现在,您所面对的已经不是一个小型 Web 站点了,可以不用看这篇文章了。

到现在,我还没说人的问题,如果这些信息只有一个人知道,万一这个人出了点事情怎么办? 作为老板,还要考虑人的单点问题。

–EOF–

Related posts

给nginx和haproxy负载均衡集群里添加backup服务器

Wednesday, October 21st, 2009

场景很简单:一个前端负载均衡器(lb),两个应用服务器(s1,s2),一个备用应用服务器(s3)。

希望实现:正常情况下是s1和s2提供服务,但这两个服务器都down掉的时候由备用服务器s3提供服务。

作为负载均衡器的选择,我测试了nginx、haproxy和apache,nginx和haproxy都非常容易就实现了上面的需求,apache也有文档说可以,但没有测试成功。

nginx的配置文件如下(配置文件里是一个工作的app服务器,一个backup):

upstream mycluster {
server 192.168.1.240:8888;
server 192.168.1.222:8888 backup;
}

haproxy的配置文件如下(配置文件里是一个工作的app服务器,一个backup):

listen  appli4-backup 0.0.0.0:10004
option  httpchk
#option  httpchk /index.html
option  persist
balance roundrobin
server  inst1 192.168.1.240:8888 check inter 2000 fall 3
server  inst2 192.168.1.222:8888 check inter 2000 fall 3 backup

当然,其实最后我可能haproxy和nginx都不选,而选LVS,如果LVS提供这种支持。有空继续测试LVS。

Related posts

Spring MVC的No parameter specified for @RequestParam异常

Tuesday, October 20th, 2009

今天测试一个程序发现No parameter specified for @RequestParam argument异常。程序是以annotation的方式使用spring mvc开发的。程序在eclipse开发环境下没有问题,但到了正式环境就出错。

问题的解决:正式环境使用ant编译,给ant的compile命令加上debug=true参数。

原因:ant模式是debug=false,所以编译出来的函数声明里的变量名会改变,例如:public String kill(String pid)编译后成为public String kill(String s1)。

这样spring的绑定参数名就不work了。

Related posts

《硝烟中Scrum和XP》读书笔记

Thursday, October 15th, 2009

昨天写一个新项目的开发过程计划,xinbo向我推荐了《硝烟中的Scrum和XP》(Scrum and XP from Trenches)这本书。开始阅读之后就没有停下来,一口气读完,读的非常开心,所以今天写写读书笔记。并推荐大家阅读,理由有三:

  1. 可以让人读的非常开心。全书净是下面这样风格的话语:“听起来不错?呵,纯粹扯淡。更糟的是,团队一般都是到了会议结束前才发现他们一直在扯淡,到最后还没把故事看上一遍呢!”
  2. 非常实际。这本书就是作者在一个4、50个研发人员的团队中1、2年(2005年下半年到2007年初)的时间实践Scrum和XP的总结,所以其中有很多实际的经验、教训、建议,很细节。

好了,下面是读书笔记,同样如果对于XP或者Scrum的基本名词没有概念的,简单Google一下就好了,了解一下名词和概念就好,别读太多理论读物。

“Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。。。。一年过去了,我们在公司里从上到下都实现了Scrum。我们试过多种团队尺寸(3-12人)、sprint长度(2-6个星期);定义“完成”的不同方式;不同形式的产品backlog和sprint backlog(Excel、Jira、索引卡);多种测试策略、演示方式、多个Scrum团队的信息同步方式……。我们还试验了XP实践——各种各样的每日构建,结对编程,测试驱动开发,等等;还试过把XP和Scrum进行结合。”

– 我深信“持续改进”“自我完善”这是任何一个开发过程中最重要的理念。幸运的是Scrum把过程持续改进作为了其执行的一个内在环节。

“产品backlog是Scrum的核心,也是一切的起源。我们叫它故事(story),有时候也叫做backlog条目。我们的故事包括这样一些字段:ID、Name、Importance、Initial Estimate、How to demo、Note。我们曾试过很多字段,但最后发现,只有上面提到的六个字段我们会一直使用下去。”

– 很简单是吧?简单就对了。把那么多功夫花在这些事情干什么,有空编码去好不好!

“Sprint计划会议非常关键,应该算是Scrum中最重要的活动(这当然是我的主观意见)。要是它执行的不好,整个sprint甚至都会被毁掉。”

– 在Scrum开发过程中“项目会”是那么的少,所以我也相信“Sprint计划会”是Scrum中最重要的活动。

“Sprint计划会议会产生一些实实在在的成果:

  • sprint目标。
  • 团队成员名单(以及他们的投入程度,如果不是100%的话)。
  • sprint backlog(即sprint中包括的故事列表)。
  • 确定好sprint演示日期。
  • 确定好时间地点,供举行每日scrum会议”

– 我认为“确定好Sprint演示日期”这个最刺激,呵呵。

“假如sprint计划会议接近尾声,但仍然没有得出sprint目标或者sprint backlog,这时该怎么办?我们要打断它么?还是再延期一个小时?或者到时间就结束会议,然后明天继续?这种事情会一再发生,尤其是在新团队身上。你会怎么做?我不知道。但我们的做法是什么?嗯……我通常会直接打断会议,中止它。”

“几乎每次sprint计划会议都要确定sprint目标。Sprint目标需要回答这个根本的问题,“我们为什么要进行这个sprint?为什么我们不直接放假算了?””

“在大多数sprint 计划会议上,大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分,等等都会在会议上完成。
我们是怎样实际操作的呢?要想收到好的效果,不妨创建一些索引卡,把它们放到墙上(或一张大桌子上)。”

– 一个Backlog一张纸质卡片,听起来不错,很直观,又让大家获得几个小时离开电脑的时间。

“在sprint演示会议上,团队自豪地演示了一个新特性,但产品负责人却皱起眉头,“呃,看上去不错,但这不是我要的!”发生这种事情可真是糟透了!
怎样才能让产品负责人和团队对故事有同样的理解?或者保证所有的团队成员对每个故事都有同样的理解?嗯,这可没法做到。不过还是有些简单技术,可以识别出最明显的误解。最简单的办法就是确保每个故事的所有字段都被填满”

“注意——我们在实践TDD(测试驱动开发),所以几乎每个故事的第一个任务都是“编写一个失败的测试”,而最后一个任务是“重构”(提高代码的可读性,消除重复)。”

– 我们不做TDD,但把“重构”作为最后一个任务也是不错的哈。

“这有个很复杂的问题:技术故事。或者叫做非功能性条目,或者你想叫它什么都行。例如:安装持续构建服务器、重构DAO 层、升级 Jira”

– 这段太长了,但这个问题太重要,很多技术经理都非常关注,所以还是看原文去吧。在P54

“我们要让整个公司了解我们在做些什么,这件事情至关重要。否则其他人就会发出抱怨,甚或对我们的工作做出臆断。”

– 这段也太重要了!但是也太长,归纳一下就是:一个展示项目信息的网页、sprint开始和结束都群发邮件、将Sprint信息打印出来贴到开发团队墙上。

“我们发现管理sprint backlog最有效的形式——挂在墙上的任务板!
找一面尚未使用或者充满无用信息(如公司logo、陈旧图表或者丑陋的涂鸦)的大墙。清理墙壁(除非不得已才去请求别人许可)。在墙上贴上一张很大很大的纸(至少2×2平方米,大团队需要3×2平方米)。然后这样规划:。。。。。”

– 又是“纸质”的东西,嗯,我喜欢纸质的和写在白板上的。原因嘛,还是它可以让我远离电脑,呵呵。

“嘿,该怎样进行跟踪呢?在这种模型中,如果必须跟踪的话,那我能提供的最佳方式,就是每天给任务板拍一张数码照片。我有时也这样干,但一直没用到这些照片。如果你确实需要跟踪任务进度,任务板这种解决方案可能就不太适合你。
不过我建议你应该试着去评估一下,对sprint进行细节跟踪能带给你多大价值。Sprint完成以后,可以工作的代码已被交付,文档也被check in,那还有谁会真的关心sprint的第5天完成了多少故事呢?又有谁会真的关心“为Deposit编写失败测试”曾经的估算量是多少?”

– 我很同意。一个Sprint只有2、3周的时间,这期间的事情让项目组内部自己搞定吧,外部的人那么不放心干什么。

“在安排座位、布置桌椅这方面,有一件事情怎么强调也不为过。
让团队坐在一起!
说的更清楚一点,我说的是
让团队坐在一起!”

“我们的每日例会跟书中的几乎没啥两样。它们每天都会在同一个地方,同一个时间进行。一般我们都是开站立会议,以防止持续时间超过15分”

– 我也喜欢站着开会,可以活动一下身体。当然,也能远离电脑。

“一定要做Sprint演示。让演示关注于业务层次,不要管技术细节。注意力放在“我们做了什么”,而不是“我们怎么做的”。不要花太多时间准备演示,尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去,集中精力演示可以实际工作的代码。”

“在有关回顾的种种一切中,最重要的就是确保回顾能够进行。由于某些原因,团队常常都不太愿意做回顾。如果不给他们点温柔的刺激,我们的大多数团队都会跳过回顾。说句实话,我认为回顾是Scrum中第二重要的事件(最重要的是sprint计划会议),因为这是你做改进的最佳时机!”

“Sprint之间的休整。我们会力求保证不在同一天举行sprint回顾和下一个sprint计划会议。”

“在绝大多数层面上组合使用XP与Scrum,我们都已经尝试过了。有些XP实践直接被Scrum解决掉了,可以被视作二者的重叠。如“整体团队”,“坐在一起”,“故事”和“计划游戏”。在这些情况下我们就直接使用了Scrum。
我们近来开始在一个团队中实施结对编程。效果相当好。虽然其他团队大多数还没有进行太多尝试,但在一个团队中使用了几个sprint之后,我已经有了很高的热情去指导其他团队进行试用。”

“测试驱动开发(TDD)阿门!对我来说,它比Scrum和XP还要重要。你可以拿走我的房子、我的电视还有我的狗,但不要试着让我停止使用TDD!”

–嗯,我还真没做过TDD

“学到的一课:如果你深陷手工回归测试的泥潭,打算让它自动化执行,最好还是放弃吧(除非做起来特别简单)。首先还是应该想办法简化手工回归测试。然后再考虑将真正的测试变成自动化执行。”

“我们在实施Scrum的时候,所做的第一件事情就是打乱特定于组件的团队(方式1),创建跨组件的团队(方式2)。它减少了诸如“我们没法完成这个条目,因为我们在等server那帮家伙完成他们的工作”之类的情况发生。不过,要是有很强烈的需求,我们也会临时创建针对特定组件展开工作的团队。”

– 嗯,我也喜欢让一个团队内部搞定尽可能多的事情。跨团队沟通就是麻烦

“每周的全体(嗯,所有参与开发的人)会议。时长15分钟。
什么?15分钟?全体参加?每一个产品所包括的全部团队中的所有人都会参加?这能行么?
是的,能行。只要你(或是其他主持会议的人)严格限定会议的时间不要过长。”

– 开大会,挺好的。信息要在团队中充分共享嘛。

最后总结一下在实施scrum的团队中的会议有哪些:

  • Sprint计划会(4小时)
  • Sprint日例会(15分钟)
  • Sprint演示会(30分钟?)
  • Sprint回顾会(1、2小时)
  • 研发部周例会(大会)(15分钟)

Related posts

让Ultraledit成为python开发环境

Monday, July 13th, 2009

开始学习Python之后一直是用linux下的vi,周日在自己的pc也安装了python,本机也有开发环境了。下面讲一下如何配置自己的Ultraledit使它方便的开发python。

设置语法高亮显示

1、去http://www.ultraedit.com/downloads/extras.html下载wordfile,具体地址是:http://www.ultraedit.com/files/wf/python26.uew

2、编辑你的Ultraledit的wordfile,把上面文件的内容添加到wordfile的最后。你Ultraledit的wordfile通常在: C:\Program Files\IDM Computer Solutions\UltraEdit-32\WORDFILE.TXT

这样语法高亮就设置好了。

设置在Ultraledit中运行python

在Ultraledit的菜单:高级–》工具配置里配置运行python,我的配置如下(记住,可以用快捷键ctrl+shift+0直接执行,比点鼠标快):

ue

将.py文件关联到Ultraledit

如果你想双击.py文件就用Ultraledit打开的话你可以将.py文件关联到Ultraledit。

这样Ultraledit就被设置为python的开发环境了。

Related posts

开始学习Python

Thursday, July 9th, 2009

有道是,无志者常立志,有志者立志长!为了监督自己,今天公开宣布开始学习Python,作为Java的辅助开发语言。

和Java亲密接触10来年之后终有一些审美疲劳,加之对java的开发部署效率深感不满,所以决定挑选一个语言来学习,作为Java之外的补充。相对于Java这样的编译语言,那自然是挑选一个写起来爽利的脚本语言了。PHP、Ruby、Python是三个当红之选,最终挑选了Python。原因嘛,PHP写出来的程序太乱,Ruby是日本人写的,所以就剩下Python了。当然,最主要的是有同学用Python好几年了,遇到问题可以有人帮我搞定!

好了,从今天开始,抓空学习Python。

Related posts

软件开发很不同了

Wednesday, March 25th, 2009

接触软件开发也不算太久,刚过十年;不每天写代码也不算 太久,两年的事情,可软件开发的进展却还是让我时常吃惊。和我学习软件开发的时候,和我自己初次做软件开发的时候很不同了。

昨天技术团队技术交流会,王征介绍了CakePHP web框架,几行代码,没有配置,一个包含了增删改查功能而且不算太丑的页面(其实比我写的要好看很多)就可以用了。Web开发已经和写几个静态页就收费上万的时候不可同日而语了,而那其实也不过是10年前的事情。而各种CMS、BBS、Maillist、CRM等等等等开源软件,也让我们想不到什么东西是需要自己做的了,呵呵。

那么软件工程师们,IT业者们的价值在哪里?在降低吗?依我看没有。我们的价值在于两处:

  1. 新的技术都是要人去应用的。过去一直说国内的新技术使用至少比国外晚一年,这在改变。
  2. 相比于成型的软件系统,更大量的是变化万千特性各异的业务需求。没有被电子化和规范化的东西是主流,而且恐怕一直会是主流。

Related posts

推荐一个朋友写的Java开源数据库缓存系统

Wednesday, July 23rd, 2008

原文见:原创,可支持1亿pv/天的数据库缓存系统,首次开源啦!

这个系统的作者是我以前的同事,很好的朋友,很高兴他把自己研发的Java数据库缓存系统开源出来,也希望朋友们多多参考,多多宣传。

转一部分他介绍文章里的内容:

总结:这种缓存思路可以存储大规模的列表,缓存命中率极高,因此可以承受超大规模的应用,但是需要技术人员根据自身业务逻辑来配置需要做散列的字段,一般用一个表的索引键做散列(注意顺序,最散的字段放前面),假设以userId为例,可以存储N个用户的M种列表,如果某个用户的相关数据发生变化,其余N-1个用户的列表缓存纹丝不动。以上说明的都是如何缓存列表,缓存长度和缓存列表思路完全一样,如缓存象select count(*) from T where topicId=2008这样的长度,也是放到topicId=2008这个散列Map中。如果再配合好使用mysql的内存表和memcached,加上F5设备做分布式负载均衡,该系统对付像1000IP/天这种规模级的应用都足够了,除搜索引擎外一般的应用网站到不了这种规模。

 

再次申明:系统到底是不是强大不在系统本身而在于使用该系统的人!!!

 

这个缓存系统是我和同事几年经验的总结,看似简单,其实也没那么简单,把它作为开源有下面几个目的:第一,真的希望有很多人能用它;第二:希望更多的人能够完善和改进它;第三:希望大家能聚到一起为通用高效数据库缓存构架作出贡献,毕竟,数据库操作是各种应用最常用的操作,也是最容易产生性能瓶颈的地方。

 

Zip包中包含了配置方法和测试用的jsp,只要把它配置成一个web应用就可以快速调试并看到缓存的力量了,文档和下载地址是http://shedewang.com/akaladocs/api/com/akala/dbcache/core/BaseManager.html

 

配置说明文件在docs/开始配置.txt里有说明。

 

最后啰嗦一句,如果大家真想支持我、支持中国人开源项目,请把该文贴到自己的博客中,记得包含文档的下载链接,thank you and Good luck

Related posts

企业IT系统这回事儿

Friday, December 14th, 2007

分享我在开发和使用企业内部IT系统六年多以来的一些感受。

第一,在我们越来越了解IT系统所在来的好处的时候,我们更应该知道IT系统在大部分时候都不是最佳解决方案,大部分时候都不是。IT系统一般情况下只是将我们已经做好的事情做的更好,而不是将我们做的不好的事情做好。

第二,世界上开发出来的IT系统有一半以上在开发出来之后从来没有被使用过。这是投资者的悲哀,是设计者的悲哀,还是开发者的悲哀?所以我的目标就是:开发出来的每个东西都有用。

所以我就是一个砍开发需求的人。

上面的观点均来自于很有局限的个人经历和观察

Related posts