tag:blogger.com,1999:blog-48591061681030964212023-06-21T12:40:31.019+08:00解语花园一个架构工程师的部落格解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-4859106168103096421.post-29043327029047953412008-05-20T09:33:00.004+08:002008-05-20T10:31:19.156+08:00不再更新blogspot上的blog内容由于blogspot一直受到GFW的封锁,blog更新和查看很不方便,现决定不再更新blogspot上的blog。<br /><br />以后blog将在国内的cnblogs上更新,在这边只通过RSS方式聚合最后5篇文档。<br /><br />新博客地址: <a href="http://www.blogjava.net/daviszhao">www.blogjava.net/daviszhao</a><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.comtag:blogger.com,1999:blog-4859106168103096421.post-40104032034503420992008-05-07T13:24:00.001+08:002008-05-07T13:24:14.968+08:00[转贴文章]关于云计算的五种观点云计算就和每一个IT趋势一样,包括面向服务的架构(soa)和Web服务。我们谈论的是关于云计算方面的,也许指的并不是同一个基本概念。 <p> 我最近加入了一个关于云计算方面的LinkedIn/Google组织,它们中的一个成员发了这样的一个贴,这个贴看上去是如此的简单。问题就 是:云计算和我们所了解的网格计算到底有什么区别?我当然有我自己关于这个问题的答案,但是整个晚上,有很多的回复者涌入,并且创建了一个e-mail 链,提供了一些关于这个术语的细微差别。</p> <p> 我希望我不会因此被该组织剔除之外,但是我认为它们中的一些观点非常有意思,并且可以拿出来供大家思考。出于隐私的考虑,我不会把任何人的名字附上,并且我把其中的一些观点重新整理一下,主要是为了更加地清楚和适合于文章的长度。以下是五个关于云计算的主要观点:</p> <p> <strong>1.厂商总是将新词汇的定义混淆化。</strong></p> <p> 在我和其它人的观点中,云计算是不同于效用计算的,同时和网格计算也不太相同。</p> <p> 网格计算通常是指一个用于计算任务(比如图像处理)的资源池环境,而不是那些长时间运行的进程(比如一个网站或者邮件服务器)。</p> <p> 而效用计算通常是指一个用于掌握长时间运行进程的资源池环境,并且趋向于专注满足服务的级别,通过优化一定量的必要资源。</p> <p> 云计算在很多情况下是指网络上提供的不同种类的服务,这些服务可以在服务提供商的架构上(比如谷歌的Apps或者Amazon EC2或者Salesforce.com)的计算功能上所提供。一个云计算的环境可以运行在一个网格计算环境下,或者在一个效用计算环境下,但是对被服务 的用户来讲并不关心。</p> <p> <strong>2.云计算 = 网格计算</strong></p> <p> 工作的负载被送往那些包含指派主机以及工作从节点的IT架构上。那些主机控制资源分配到这些工作负载之上(有多少从节点运行并行的工作负载)。 这对于客户来讲是完全透明的,用户只是看到工作负载被指派到云/网格上,并且结果被返回给它们。而从节点可以是,当然也可以不是虚拟主机。</p> <p> 云计算 = 软件即服务。这是一个谷歌的apps模型,而apps就放在云中,比如Web的某些地方。</p> <p> 云计算 = 平台即服务。 这是Amazon EC2 et al的模型,在该模型中,一个外部的实体维护着IT架构(主/从),并且客户在这个架构上购买时间/资源。这是在云当中,跨越整个Web,确是在那些租用这些服务的公司之外。</p> <p> <strong>3.云计算就是将本地服务转移到Web上</strong></p> <p> 把本地存储的文件转移到一个安全的可扩展的环境中。从那些受限于磁盘空间的应用转移到没有空间上限的应用中;从使用微软Office到使用基于 Web的Office。在2005年到2008年之间,在线存储变得更加便宜,并且在线的存储比起本地存储或者你自己服务器上的存储更加的安全。这就是云 计算。它包含了网格计算、像Bigtable这样的大型数据库、缓存、总是可以访问、失效恢复、冗余、可扩展以及其它的一些因素。可以把它看作进一步走入 Internet的步骤。它还包含大量的关联,比如静态和动态之间、RDBMS和BigTable以及平式数据观点之间的对比。依赖于IT架构的整体商务 结构都会改变,编程者会驱动整个云计算,并且最终将会产生很多编程者。这就像从大型机到个人计算机的一个转变过程。当前,你就拥有了一个云上的个人空间。</p> <p> 这非常的有意思,就像Web 2.0。但是,还是存在着很多的改变。市场都在围绕着整体的技术提升。</p><p> <strong>4.网格和云计算两个概念并不排斥</strong> </p><p> 我们的客户把它这样来看:</p> <p> 云计算就是对资源使用的一种付费(比如,你不必去拥有资源)。</p> <p> 网格就是你如何去安排你的工作——而不管你在哪里运行这些工作。</p> <p> 你可以在没有网格的情况下使用云,或者相反。同时,你也可以在一个云上使用一个网格。</p> <p> <strong>5.通常,我会把云计算的概念分成以下三个阵营:</strong></p> <p> 使能者——这些公司可以使能潜在的架构或者基本的模块。这些公司主要关注于数据中心自动化以及服务器虚拟化(VMware/EMC,Citrix,Blade Logic,RedHat,Intel,, Sun,IBM,Enomalism等等)。</p> <p> 提供者——(Amazon Web Services,Rackspace,Google, Microsoft)。这些公司拥有预算,并且知道如何来建立全局的计算环境,这通常会花费数百万甚至数十亿美元。云计算提供者通常会提供它们的架构或者 平台。通常,这些服务以付费方式提供,并且基于效用来使用。</p> <p> 客户——在整个云计算的另一端,我们看到一些客户公司。它们建立或者提升Web应用在已经存在的云计算环境之上,并且不需要对数据中心或者任何 的物理设施进行资金的投入。通常提供者和客户会是一家公司,比如Amazon(SQS,SDB等等)以及Google(Apps)以及Salesfore (Force)。但是,他们同样也可以重新开始,提供载云计算之上的工具和服务(云管理)。</p> <p> “云客户通常是一个相对广泛的组织,包括那些通过基于Web的服务提供的任意应用,比如Webmail, 博客,网络等等。从客户的观点来看,云计算已经成为一个你创建、主管并且部署一个可扩展Web应用的平台。 </p> <p> 至少现在,我们对于云计算的概念就更加清楚了。</p> <div class="flockcredit" style="text-align: right; color: #CCC; font-size: x-small;">Blogged with the <a href="http://www.flock.com/blogged-with-flock" style="color: #999; font-weight: bold;" target="_new" title="Flock Browser">Flock Browser</a></div><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-86126142954564737762008-05-06T12:09:00.001+08:002008-05-06T12:09:34.569+08:00[转贴文章]ERP实施最恐怖事件:需求变更辛辛苦苦熬了几个月的通宵,终于确立了ERP需求,规范了工作流程,系统配置也完成了,正准备按部就班ERP系统上线时,企业用户突然改变了需求, 不想这么做了,提出了新的需求。这对于ERP实施顾问来说,正如晴天惊雷,这也是所有ERP顾问最感到恐怖的事情。因为有时候,用户只是简单的一句话,但 是对于系统的调整来说工作量是非常大的。 <p><strong> 一.需求变更:迁就or拒绝?</strong></p> <p> 从ERP项目立项开始,需求就是ERP实施顾问的心头之痛。随着对ERP的深入认识、项目环境的变动,企业内外部多种因素都可能使客户对ERP 的需求不断改变。如果不能有效处理这些需求变更,项目实施进度必将一再调整,上线日期也会随之一再拖延,项目成员的士气也将越来越低落,严重的还会直接导 致ERP项目失败。</p> <p> 需求变更,本应是客户的权力,但也是实施顾问的为难之处。如果确需变更,当然要满足客户需要。问题是不能让变更权力滥用,把一些无关痛痒的变更 宠惯养成堂而皇之的变更。例如,我曾经在某ERP项目中属于“谦虚型”,对于客户提出的变更,无论大小都给予解决,客户对此非常满意。然而,项目进度却拖 得很长,项目一再延期。相比之下,在另一个项目上我显得稍有些“盛气凌人”,对于客户提出的需求变更,大多都不予理睬,客户对此不是很满意。不过,该项目 的进度控制得较好,基本能按期完成项目。</p> <p> 按后一种“盛气凌人”的做法,对客户的要求一概不理,自顾自地按照最初的需求和计划实施,很可能会由于没有用户的参与,使得ERP系统与用户的 需求相差甚远,导致验收通不过,收不回尾款而使公司利益受损。对于客户来说,达不到需求的满足也浪费了投资。事实上,客户不满意,则项目就不算成功,实施 顾问辛勤劳动最后就只能落得个“没有功劳,只有苦劳”的份。</p> <p> 但按前一种“谦虚型”做法,完全顺着客户的意见走,客户满意度就一定会高吗?其实也不一定。由于需求变更会带来工作量的大量增加,甚至可能会出 现大量的无效劳动。而且,频繁变动的需求也会导致实施质量下降,留下许多隐患。因此,一味的迁就用户将会使进度一拖再拖,实施方案一改再改,变更越来越 多,士气越来越疲,公司越来越不满意,用户越来越急。到最后,实施顾问会发现这个项目已经成为了一个“不可能完成的任务”。</p> <p><strong> 二.需求变更为什么总是做不完?</strong></p> <p> 在ERP实施过程中,实施顾问所要面对的将是一系列和多方面的考验。经常发生而又最令人头疼的恐怕就是需求变更了。客户变更需求是ERP项目与 生俱来的特性,也是一个无法避免的事实。需求变更的表现形式是多方面的,如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。它会导致 ERP实施过程中成本增加、进度拖延等风险,而且越往后的变更产生的风险将越大。</p> <p> 以笔者参与的多个ERP实施项目的实际经历来看:需求变更泛滥是非常可怕的事,尤其是到了项目实施后期,客户不断对移交的ERP系统提出修改意 见,甚至有时刚刚重新完成的更改,客户又要求改回去或改成另一种模式。需求变更越来越多,实施顾问只能疲于应付。“无底洞”是大部分实施顾问进行ERP项 目的共同感觉。</p> <p> 实施顾问作为项目的承担者,在规定时间内利用有限资源保质保量的完成项目,让客户和公司都满意是最终目标。但是让客户满意就是不断满足客户无穷无尽的需求吗?我们分析一下出现需求变更的根源。</p> <p><strong> (1)合同签订马虎,没有真正明白客户需求</strong></p> <p> 签订合同时缺乏对客户需求认真对待,导致需求描述不清,为后期的实施工作带来困惑。ERP销售顾问为使客户能够快速的签订合同,往往草率决定和 片面同意客户提出的需求。当客户提出新的需求时,往往是销售顾问一看“应该”只是一个小小的修改,没有太大的影响,所以直接答应能变更。</p> <p> 该问题的关键是合同签署的太烂,没有把需求明确再签合同,而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚,后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围,可以为以后各项实施工作的开展奠定深厚的基础。</p> <p><strong> (2)调研时没有深入理解客户需求</strong></p> <p> 在ERP上线前的需求调研分析阶段,项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进 行。更严重的是,实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案,没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导 一拍脑袋提出新的需求时,实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分,双方对需求的理解就会产生差异,就会 导致移交ERP系统时才使问题暴露出来,客户只能频繁的提出需求变更。</p><p><strong> (3)没有明确的需求变更管理流程</strong> </p><p> 没有明确的需求变更管理流程,就会使需求变更变得泛滥。并不是所有的变更都要修改,也不是所有变更都要立刻修改,需求变更管理的目的是为了决定 什么类型的变更需要修改和什么时候修改。比如ERP界面风格问题,就可以先不修改,或者规划一下修改的时间待到以后进行优化。另外,对于核心模块的修改没 有严格把关流程,有些小需求看起来工作量不大,但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。</p> <p><strong> (4)没有让客户知道需求变更的代价</strong></p> <p> 对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的,应该要评估变更的代价和对项目的影响,要让客户了解需求变更的后果。如果客 户不知道需求变更付出的代价,对实施顾问的辛苦就会难以体会。在评估代价过程中,可以请客户一起做判断:“我可以修改,但您能接受后果吗?”。</p> <p><strong> 三.如何有效控制需求变更?</strong></p> <p> 需求变更对项目成败有重要影响,既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以实施需求变更之前必须做好控制。例如授权、审核、评 估和确认,在实施过程还要进行跟踪和验证。有句通俗的话说得非常好:“需求变更控制的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。”</p> <p> 用户需求的变更总是不可避免的,所以我们要以积极的心态去接受和控制用户的需求,而不仅仅是埋怨。对待客户频繁的需求变更,应采取有效办法应对,避免事态蔓延,不让客户养成随意变更的毛病。</p> <p><strong> (1)合同约束</strong></p> <p> 需求变更给ERP实施带来的影响是有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝或部分接受,还可以规定发生需求变更时必须执行变更管理流程。</p> <p> 虽然ERP项目合同很难在签订之初就能够精确定义每项需求,单靠合同是帮不上忙的,但也不能忽视合同的约束力。有一个笑话,就是许多销售顾问都开玩笑说他们都是清政府。为什么是清政府?清政府的特点之一就是丧权辱国的条约太多。</p> <p><strong> (2)建立需求变更审批流程</strong></p> <p> 要明确需求变更审批环节、审批人员、审批事项、审批流程等。目的有两个:一是将客户下达变更的流程尽可能地规范化,减少张嘴就来的非必要、非紧 急、非合理、非高层领导意图的“无效变更”。二是留下书面依据,为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”,一律是无效变 更不予受理。</p> <p> 有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响,以及提交给双方高层进行评价以确定是否执行变更。变更请求必须有 书面材料,当用户发现由于业务变化而引起的需求变更,需要提出书面申请。这样对所有的变更,双方的项目负责人都能做到心里有数。而且用户在递交书面变更申 请时比较慎重,一般都在内部经过讨论后进行,这样减少了因用户内部看法不同导致的反复变更。</p> <p><strong> (3)对于零星变更,集中研究、批量处理</strong></p> <p> 每周或每两周甚至每月召开一次需求变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,尽量避免由于处理零碎变更而影响项目运行 的总体进度。例如向客户正式提交一份各阶段需求变更的完成计划,注明变更引起的时间、成本、工期的代价和增加的工作量。要求客户配合需求变更计划,确定变 更时限,控制变更规模,过时变更不候,离谱的变更不做,保大局弃小变。</p> <p><strong> (4)评估各种需求变更的影响</strong></p> <p> 客户的需求是永远不会满足的,可能一天一个样,为了达到控制频繁的需求变更。需要将需求变更后产生的成本进行评估与量化,形成分析报告提交双方 领导。否则,一味的妥协只会让项目进一步恶化,实施顾问需要掌控客户及公司的进度成本,把客户的每一次需求变更进行成本分析。确认哪些需要收费变更,哪些 可以免费配合客户。这样既可以维护客户关系,又不致造成公司无谓的损失。</p><p><strong>(5)确认客户是否接受变更的代价</strong> </p><p> 要让客户认识到变更都是有代价的,要和客户一起判断需求变更是否依然进行。例如,变更是没有问题的,但是要明确客户能否接受由此引起的如进度延 迟、费用增加、效率下降等问题。一般来说,如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果,通过与客户的协商,项目组可能会 得到回报或者即使没有回报也不会招致公司和客户双方的埋怨。</p> <p> 如果客户认为该变更虽然有必要但是可以暂缓,双方签署备忘录后留待以后解决。如果客户认为该变更可有可无,多数情况下会取消变更。这样即可防止 频繁变更,也让客户认识到不是所有的需求都需要变更,更不是所有的需求变更都需要立刻修改。客户一般对ERP不甚了解,他们认为很简单的事情,但可能解决 起来会很复杂。以笔者的经验来看,一般来说用户的镀金需求可以延期解决甚至不考虑。用户的新增需求如果不是影响到核心业务的实现,也可以安排在现有功能的 完善之后。</p> <p><strong> (6)每月变更记录上报双方领导</strong></p> <p> 最后,实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案,可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权,逐步让不合理 的随意频繁变更,成为客户不好意思开口的尴尬事件,尽快形成正常的项目执行氛围和良好的工作习惯,也为可能受到变更所带来的责任问题留下伏笔。</p> <p> 最后,要特别提醒,要在ERP项目开始就对项目组和客户进行宣传和培训,让所有成员都理解变更控制的重要意义。</p> <div class="flockcredit" style="text-align: right; color: #CCC; font-size: x-small;">Blogged with the <a href="http://www.flock.com/blogged-with-flock" style="color: #999; font-weight: bold;" target="_new" title="Flock Browser">Flock Browser</a></div><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-63014371231352301612008-05-05T15:42:00.003+08:002008-05-05T15:48:47.832+08:00[转贴文章]从玩具到游戏 看另类项目激励机制通过发奖金的形式来激励团队成员,本身就是一把双刃剑,弄得不好,可能就会破坏团结,导致彼此之间的矛盾与冲突,这对于一个团队而言是绝对致命的。然而,如果一个团队缺乏合理的激励方式,又无法调动成员的积极性。如何取舍,真是伤透脑筋。 <p> ......昨日阅读Larry L. Constantine的《人件集——人性化的软件开发》,才发现其实Constantine早已给出了答案,就在书中的第59章《受奖励的程序员》中。 原来,我们为什么要受限于发奖金这样一种形式呢?套用一句俗语说,“提到钱,就难免伤感情了。”要激励团队成员以及开发团队,我们还能够寻求到很好的方 式。</p> <p> 概括起来,Constantine提出的激励机制包括如下内容:</p> <p> 1、“技术玩具”。开发人员大多数都是技术型人才,一个通病就是对于技术的执著追求有时候甚至高于对金钱的追求(前题是他已经具有优裕的生活基础)。因 此,一套最新的正版软件工具,或者一件当前最酷的数字产品,都会让他们欣喜不已。这种“投其所好”的馈赠方式,既没有奖励金钱那么赤裸,又能够让开发人员 从内心深处激发对公司的认同与感激,真可谓两全其美。</p> <p> 2、小礼品。书中写道:“绝不要低估T恤衫的力量。各式各样的‘刺激’手段——团队夹克、特殊的领带、特别的杯子或者鼠标垫——都是可以使用的方法,这 些,能够告诉那些取胜的团队以及团队成员:他们与别人不太一样。最好的团队还可以获得自己设计团队徽章样式的机会,并有公司负责找人生产。”这种方式或许 是高层领导最愿意看到的,投入不多,却极尽蛊惑人心之能事,尤其是设计团队徽章的做法,既能够激发个人的集体荣誉感,又能够激励整个团队的战斗力。</p> <p> 3、自由控制的时间。这里提出的自由时间,并不是奖励成员出去旅游或者度假,而是对于那些按时交付了高质量软件的开发人员,奖励他们能够在公司的上班时间 内,自由支配自己的工作,做自己感兴趣的事情(当然是与技术相关的)。例如,你可以自由自在地在没有最后期限的压力之下研究网格运算,或者神经网络,人工 智能,哪怕你所在的公司实际上只是从事SAP二次开发。</p> <p> Rob Thomsett说,按照他的经验,如果你把时间和钱放在一起让程序员挑选,大多数都更喜欢前者。而这类由公司赞助的研究活动,反过来对公司也是有益的, 不但是获得了一位拥有新技能和新点子的快乐的开发者,而且,没准儿还能得到一个新的软件或者其他什么有用的技术。这种奖励方法对整个团队可能更有意义。如 果一个项目团队显示出他们的高超的开发执行能力,当他们超越了公司建立的最好实践之上时,那么就应该对这个团队进行奖励,让他们可以无拘无束地选择研究和 开发项目。</p> <p> 如果你的公司是一家研究型公司,或者从事产品开发,这样的奖励方式在激励成员以及团队工作热情的同时,或许还能得到意外的收获。最关键的是,这种做法无形中营造了公司的研究氛围,创造了一种良好的价值取向。</p><p> 4、教育与培训机会。特别对于具有进取心的开发人员而言,获得教育或培训的机会,绝对比获得奖金更加诱人。即使管理者担心教育与培训投入的成本太高,甚至 会造成人才流失的可能,那么,给团队人员一次参加技术大会的机会好了。这些大会往往都是免费的,开发人员需要获得的仅仅是你的一个许可而已。然而,已经足 见你的栽培之心了。Constantine还说道:“报销书籍和杂志费用也是一种低费用的激励方式”。管理者们,你们看到了吗?</p> <p> 5、选择团队成员的权利。权利也是一种奖励。例如让他主持一次会议,或者提供监督别人的机会,都是一种廉价的权利,但有可能得到的回报却很丰厚。最好的权 利就是允许团队成员能够挑选自己认可的合作者。书中提到:“一旦一个小组已经学会了如何协同工作,为什么要把他们分开呢?对于那些能够高效开发的团队,奖 励方法之一就是让他们在下一个项目中继续共同工作。对这个方法进行一个推广,那么,我们可以让他们自行挑选工作伙伴,这种行为可以有效地激励员工,使他们 能够达到最好的工作效果。同理,让那些在上一批项目中干得最好的团队,在下一批项目中自由选择员工,对他们来说,也是一种奖励。”还有什么比这个更加廉价 的奖励。</p> <p> 除了以上提到的五点之外,Cockburn在《敏捷软件开发》一书中,还提到了Darin Cummins发明的一种开发游戏的奖励方式,奖励一些类似于代金券之类的伪币,然后在项目结束后,利用这些伪币来竞拍一些真正适用的物品。关键不是这个 结果,而是开发中的过程,对于成员的奖励就像玩游戏一般轻松自在,不知不觉就剥去了成员的功利之心,有效地消除成员之间的恶性竞争。</p> <p> Darin写道:“开发人员会因为他们的代码被评审、评审其他人的代码、按照进度完成任务、重用代码以及创建单元测试等得到奖励”。要消除成员之间的恶性 竞争,这种方法一定要遵循两点。第一是将过程尽可能最小化,这样的度量会更加准确与透明,不会出现太大的分歧。第二则是给参与者反败为胜的机会。可以在开 发过程的结尾,设计一些额外的活动来让开发人员赚取更多的奖励。这样一来,即使开发人员在前面输得太多,他仍然有机会在后程发力,反败为胜。</p> <p> 适当的奖励可以让我们踢开刀刃,自在轻舞,但必须还要谨记如下两个原则:</p> <ul><li>在奖励优秀的开发人员的同时,不要忘记对优秀团队的奖励;</li><li>奖励方式应因人而异,必须最大程度地投合员工的喜好。</li></ul> <p> 因此,在对你的团队以及员工进行奖励之前,最好先询问他们究竟喜欢什么,也许你能够以最小的投入换来最大的回报。坦白说,有时候上级也需要好好考虑如何对下级“拍马屁”呢。</p> <div class="flockcredit" style="text-align: right; color: rgb(204, 204, 204); font-size: x-small;">Blogged with the <a href="http://www.flock.com/blogged-with-flock" style="color: rgb(153, 153, 153); font-weight: bold;" target="_new" title="Flock Browser">Flock Browser</a></div><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-26595568050025467052007-09-27T15:20:00.001+08:002007-09-27T15:20:21.105+08:00[转贴文章]使用memcached进行内存缓存: 一个藏袍<a href="http://www.example.net.cn/archives/2006/01/eoamemcachedoea.html">使用memcached进行内存缓存: 一个藏袍</a> <br /><br /><h3>使用memcached进行内存缓存</h3> <p>旧文重发<br />2005.8.9</p> <p>通常的网页缓存方式有动态缓存和静态缓存等几种,在ASP.NET中已经可以实现对页面局部进行缓存,而使用memcached的缓存比 ASP.NET的局部缓存更加灵活,可以缓存任意的对象,不管是否在页面上输出。而memcached最大的优点是可以分布式的部署,这对于大规模应用来 说也是必不可少的要求。<br />LiveJournal.com使用了memcached在前端进行缓存,取得了良好的效果,而像wikipedia,sourceforge等也采用了或即将采用memcached作为缓存工具。memcached可以大规模网站应用发挥巨大的作用。</p> <div id="a000041more"><div id="more"> <p><strong>Memcached是什么?</strong><br />Memcached是高性能的,分布式的内存对象缓存系统,用于在动态应用中减少数据库负载,提升访问速度。<br />Memcached由Danga Interactive开发,用于提升LiveJournal.com访问速度的。LJ每秒动态页面访问量几千次,用户700万。Memcached将数据库负载大幅度降低,更好的分配资源,更快速访问。</p> <p><strong>如何使用memcached-Server端?</strong><br />在服务端运行:<br /># ./memcached -d -m 2048 -l 10.0.0.40 -p 11211<br />这将会启动一个占用2G内存的进程,并打开11211端口用于接收请求。由于32位系统只能处理4G内存的寻址,所以在大于4G内存使用PAE的32位服务器上可以运行2-3个进程,并在不同端口进行监听。</p> <p><strong>如何使用memcached-Client端?</strong><br />在应用端包含一个用于描述Client的Class后,就可以直接使用,非常简单。<br />PHP Example:<br />$options["servers"] = array("192.168.1.41:11211", "192.168.1.42:11212");<br />$options["debug"] = false;<br />$memc = new MemCachedClient($options);<br />$myarr = array("one","two", 3);<br />$memc->set("key_one", $myarr);<br />$val = $memc->get("key_one");<br />print $val[0]."\n"; // prints 'one‘<br />print $val[1]."\n"; // prints 'two‘<br />print $val[2]."\n"; // prints 3</p> <p><strong>为什么不使用数据库做这些?</strong></p> <p>暂且不考虑使用什么样的数据库(MS-SQL, Oracle, Postgres, MysQL-InnoDB, etc..), 实现事务(ACID,Atomicity, Consistency, Isolation, and Durability )需要大量开销,特别当使用到硬盘的时候,这就意味着查询可能会阻塞。当使用不包含事务的数据库(例如Mysql-MyISAM),上面的开销不存在,但 读线程又可能会被写线程阻塞。<br />Memcached从不阻塞,速度非常快。</p> <p><strong>为什么不使用共享内存?</strong><br />最初的缓存做法是在线程内对对象进行缓存,但这样进程间就无法共享缓存,命中率非常低,导致缓存效率极低。后来出现了共享内存的缓存,多个进程或者线程共享同一块缓存,但毕竟还是只能局限在一台机器上,多台机器做相同的缓存同样是一种资源的浪费,而且命中率也比较低。<br />Memcached Server和Clients共同工作,实现跨服务器分布式的全局的缓存。并且可以与Web Server共同工作,Web Server对CPU要求高,对内存要求低,Memcached Server对CPU要求低,对内存要求高,所以可以搭配使用。</p> <p><strong>Mysql 4.x的缓存怎么样?</strong><br />Mysql查询缓存不是很理想,因为以下几点:<br />当指定的表发生更新后,查询缓存会被清空。在一个大负载的系统上这样的事情发生的非常频繁,导致查询缓存效率非常低,有的情况下甚至还不如不开,因为它对cache的管理还是会有开销。<br />在32位机器上,Mysql对内存的操作还是被限制在4G以内,但memcached可以分布开,内存规模理论上不受限制。<br />Mysql上的是查询缓存,而不是对象缓存,如果在查询后还需要大量其它操作,查询缓存就帮不上忙了。<br />如果要缓存的数据不大,并且查询的不是非常频繁,这样的情况下可以用Mysql 查询缓存,不然的话memcached更好。</p> <p><strong>数据库同步怎么样?</strong><br />这里的数据库同步是指的类似Mysql Master-Slave模式的靠日志同步实现数据库同步的机制。<br />你可以分布读操作,但无法分布写操作,但写操作的同步需要消耗大量的资源,而且这个开销是随着slave服务器的增长而不断增长的。<br />下一步是要对数据库进行水平切分,从而让不同的数据分布到不同的数据库服务器组上,从而实现分布的读写,这需要在应用中实现根据不同的数据连接不同的数据库。<br />当这一模式工作后(我们也推荐这样做),更多的数据库导致更多的让人头疼的硬件错误。<br />Memcached可以有效的降低对数据库的访问,让数据库用主要的精力来做不频繁的写操作,而这是数据库自己控制的,很少会自己阻塞 自己。</p> <p><strong>Memcached快吗?</strong></p> <p>非常快,它使用libevent,可以应付任意数量打开的连接(使用epoll,而非poll),使用非阻塞网络IO,分布式散列对象到不同的服务器,查询复杂度是O(1)。</p> <p>参考资料:<br /><a href="http://www.linuxjournal.com/article/7451">Distributed Caching with Memcached | Linux Journal</a><br /><a href="http://www.danga.com/">http://www.danga.com/</a><br /><a href="http://www.linuxjournal.com/article/7451">http://www.linuxjournal.com/article/7451</a></p> </div></div><br /><p style="text-align: right; font-size: 8px">Blogged with <a href="http://www.flock.com/blogged-with-flock" title="Flock" target="_new">Flock</a></p><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-51126297894393535422007-09-27T15:17:00.001+08:002007-09-27T15:17:14.611+08:00转贴文章 从LiveJournal后台发展看大规模网站性能优化方法: 一个藏袍<a href="http://www.example.net.cn/2006/03/livejournal_optimize_step_by_step.html">从LiveJournal后台发展看大规模网站性能优化方法: 一个藏袍</a> <br /><br /><h2>一、LiveJournal发展历程</h2><br /><a href="http://www.livejournal.com/"><br />LiveJournal</a>是99年始于校园中的项目,几个人出于爱好做了这样一个应用,以实现以下功能:<br /><ul><li>博客,论坛</li><li>社会性网络,找到朋友</li><li>聚合,把朋友的文章聚合在一起</li></ul><br />LiveJournal采用了大量的开源软件,甚至它本身也是一个开源软件。<br /><br /><p>在上线后,LiveJournal实现了非常快速的增长:</p><br /><br /><ul><li>2004年4月份:280万注册用户。</li><li>2005年4月份:680万注册用户。</li><li>2005年8月份:790万注册用户。</li><li>达到了每秒钟上千次的页面请求及处理。</li><li>使用了大量MySQL服务器。</li><li>使用了大量通用组件。</li></ul><br /><br /><h2>二、LiveJournal架构现状概况</h2><br /><br /><p><img src="http://www.example.net.cn/archives/livejournal_backend.png" alt="livejournal_backend.png" height="445" width="600" /><br /><br /> <br /><br /></p><h2>三、从LiveJournal发展中学习</h2><br /><br /><p>LiveJournal从1台服务器发展到100台服务器,这其中经历了无数的伤痛,但同时也摸索出了解决这些问题的方法,通过对LiveJournal的学习,可以让我们避免LJ曾经犯过的错误,并且从一开始就对系统进行良好的设计,以避免后期的痛苦。</p><br /><br /><p>下面我们一步一步看LJ发展的脚步。</p><br /><br /><br /><h2>1、一台服务器</h2><br /><br /><p>一台别人捐助的服务器,LJ最初就跑在上面,就像Google开始时候用的破服务器一样,值得我们尊敬。这个阶段,LJ的人以惊人的速度熟悉的<br />Unix的操作管理,服务器性能出现过问题,不过还好,可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。</p><br /><br /><p>最终问题出现了,网站越来越慢,已经无法通过优过化来解决的地步,需要更多的服务器,这时LJ开始提供付费服务,可能是想通过这些钱来购买新的服务器,以解决当时的困境。<br /><br />毫无疑问,当时LJ存在巨大的单点问题,所有的东西都在那台服务器的铁皮盒子里装着。</p><br /><br /><p> <img src="http://www.example.net.cn/archives/LJ-backend-7.png" alt="LJ-backend-7.png" height="187" width="500" /></p><br /><br /><h2>2、两台服务器</h2><br /><br /><p>用付费服务赚来的钱LJ买了两台服务器:一台叫做Kenny的Dell 6U机器用于提供Web服务,一台叫做Cartman的Dell 6U服务器用于提供数据库服务。</p><br /><br /><p> <img src="http://www.example.net.cn/archives/LJ-backend-8.png" alt="LJ-backend-8.png" height="279" width="218" /></p><br /><br /><p>LJ有了更大的磁盘,更多的计算资源。但同时网络结构还是非常简单,每台机器两块网卡,Cartman通过内网为Kenny提供MySQL数据库服务。<br /><br /> <br /><br />暂时解决了负载的问题,新的问题又出现了:</p><br /><br /><ul><li>原来的一个单点变成了两个单点。</li><li>没有冷备份或热备份。</li><li>网站速度慢的问题又开始出现了,没办法,增长太快了。</li><li>Web服务器上CPU达到上限,需要更多的Web服务器。</li></ul><br /><br /><h2>3、四台服务器</h2><br /><br /><p>又买了两台,Kyle和Stan,这次都是1U的,都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。</p><br /><br /><p> <img src="http://www.example.net.cn/archives/LJ-backend-9.png" alt="LJ-backend-9.png" height="241" width="499" /></p><br /><br /><p>LJ把Kenny用于外部的网关,使用mod_backhand进行负载均横。</p><br /><br /><p>然后问题又出现了:</p><br /><br /><ul><li>单点故障。数据库和用于做网关的Web服务器都是单点,一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持心跳同步迅速切换,但还是无法解决数据库的单点,LJ当时也没做这个。</li><li>网站又变慢了,这次是因为IO和数据库的问题,问题是怎么往应用里面添加数据库呢?</li></ul><br /><br /><h2>4、五台服务器</h2><br /><br /><p>又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式),写操作全部针对主数据库(通过Binlog,主服务器上的写操作可以迅速同步到从服务器上),读操作在两个数据库上同时进行(也算是负载均横的一种吧)。</p><br /><br /><p> <img src="http://www.example.net.cn/archives/LJ-backend-10.png" alt="LJ-backend-10.png" height="265" width="500" /></p><br /><br /><p>实现同步时要注意几个事项:</p><br /><br /><ul><li>读操作数据库选择算法处理,要选一个当前负载轻一点的数据库。</li><li>在从数据库服务器上只能进行读操作</li><li>准备好应对同步过程中的延迟,处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可,读操作不存在同步问题。</li></ul><br /><br /><h2>5、更多服务器</h2><br /><br /><p>有钱了,当然要多买些服务器。部署后快了没多久,又开始慢了。这次有更多的Web服务器,更多的数据库服务器,存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。</p><br /><br /><p> <img src="http://www.example.net.cn/archives/LJ-backend-11.png" alt="LJ-backend-11.png" height="483" width="453" /></p><br /><br /><h2>6、现在我们在哪里:</h2><br /><br /><p><img src="http://www.example.net.cn/archives/LJ-backend-1.png" alt="LJ-backend-1.png" height="357" width="600" /></p><br /><br /><p>现在服务器基本上够了,但性能还是有问题,原因出在架构上。</p><br /><br /><p>数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内,这样唯一的好处就是将读操作分布到了多台机器,但这样带来的后果就是写操作被大量分发,每台机器都要执行,服务器越多,浪费就越大,随着写操作的增加,用于服务读操作的资源越来越少。</p><br /><br /><p> <img src="http://www.example.net.cn/archives/LJ-backend-2.png" alt="LJ-backend-2.png" height="195" width="500" /></p><br /><br /><p>由一台分布到两台</p><br /><br /><p> <img src="http://www.example.net.cn/archives/LJ-backend-3.png" alt="LJ-backend-3.png" height="273" width="500" /></p><br /><br /><p>最终效果</p><br /><br /><p>现在我们发现,我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID,数据库也进行了备份,这么多的备份完全是对资源的浪费,属于冗余极端过度。那为什么不把数据分布存储呢?</p><br /><br /><p>问题发现了,开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储,以实现数据的分布式存储,让每台机器只为相对固定的用户服务,以实现平行的架构和良好的可扩展性。</p><br /><br /><p>为了实现用户分组,我们需要为每一个用户分配一个组标记,用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个<br />slave组成,并且slave的数量在2-3台,以实现系统资源的最合理分配,既保证数据读操作分布,又避免数据过度冗余以及同步操作对系统资源的过度<br />消耗。</p><br /><br /><p><img src="http://www.example.net.cn/archives/LJ-backend-4.png" alt="LJ-backend-4.png" height="324" width="500" /></p><br /><br /><p>由一台(一组)中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上,所有针对用户的操作需要先查询这台机器得到用户的组号,然后再到相应的数据库组中获取数据。</p><br /><br /><p>这样的用户架构与目前LJ的架构已经很相像了。</p><br /><br /><p>在具体的实现时需要注意几个问题:</p><br /><br /><ul><li>在数据库组内不要使用自增ID,以便于以后在数据库组之间迁移用户,以实现更合理的I/O,磁盘空间及负载分布。</li><li>将userid,postid存储在全局服务器上,可以使用自增,数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。</li><li>在数据库组之间迁移用户时要万分小心,当迁移时用户不能有写操作。</li></ul><br /><br /><h2>7、现在我们在哪里</h2><br /><br /><p><img src="http://www.example.net.cn/archives/LJ-backend-5.png" alt="LJ-backend-5.png" height="365" width="500" /></p><br /><br /><p>问题:</p><br /><br /><ul><li>一个全局主服务器,挂掉的话所有用户注册及写操作就挂掉。</li><li>每个数据库组一个主服务器,挂掉的话这组用户的写操作就挂掉。</li><li>数据库组从服务器挂掉的话会导致其它服务器负载过大。</li></ul><br /><br /><p>对于Master-Slave模式的单点问题,LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的,并不是由MySQL直接提供的,实际上也就是两台机器同时是Master,也同时是Slave,互相同步。</p><br /><br /><p>Master-Master实现时需要注意:</p><br /><br /><ul><li>一个Master出错后恢复同步,最好由服务器自动完成。</li><li>数字分配,由于同时在两台机器上写,有些ID可能会冲突。</li></ul><br /><br /><p>解决方案:<br /><br /></p><ul><li>奇偶数分配ID,一台机器上写奇数,一台机器上写偶数</li><li>通过全局服务器进行分配(LJ采用的做法)。</li></ul><br /><br /><p>Master-Master模式还有一种用法,这种方法与前一种相比,仍然保持两台机器的同步,但只有一台机器提供服务(读和写),在每天晚上的时候进行轮换,或者出现问题的时候进行切换。</p><br /><br /><h2>8、现在我们在哪里</h2><br /><br /><p><img src="http://www.example.net.cn/archives/LJ-backend-6.png" alt="LJ-backend-6.png" height="349" width="500" /></p><br /><br /><p>现在插播一条广告,MyISAM VS InnoDB。</p><br /><br /><p>使用InnoDB:</p><br /><br /><ul><li>支持事务</li><li>需要做更多的配置,不过值得,可以更安全的存储数据,以及得到更快的速度。</li></ul><br /><br /><p>使用MyISAM:</p><br /><br /><ul><li>记录日志(LJ用它来记网络访问日志)</li><li>存储只读静态数据,足够快。</li><li>并发性很差,无法同时读写数据(添加数据可以)</li><li>MySQL非正常关闭或死机时会导致索引错误,需要使用myisamchk修复,而且当访问量大时出现非常频繁。</li></ul><br /><br /><h2>9、缓存</h2><br /><br /><p>去年我写过<a href="http://www.example.net.cn/archives/2006/01/eoamemcachedoea.html">一篇文章介绍memcached</a>,它就是由LJ的团队开发的一款缓存工具,以key-value的方式将数据存储到分布的内存中。LJ缓存的数据:</p><br /><br /><ul><li>12台独立服务器(不是捐赠的)</li><li>28个实例</li><li>30GB总容量</li><li>90-93%的命中率(用过squid的人可能知道,squid内存加磁盘的命中率大概在70-80%)</li></ul><br /><br /><p>如何建立缓存策略?</p><br /><br /><p>想缓存所有的东西?那是不可能的,我们只需要缓存已经或者可能导致系统瓶颈的地方,最大程度的提交系统运行效率。通过对MySQL的日志的分析我们可以找到缓存的对象。</p><br /><br /><p>缓存的缺点?</p><br /><br /><ul><li>没有完美的事物,缓存也有缺点:</li><li>增大开发量,需要针对缓存处理编写特殊的代码。</li><li>管理难度增加,需要更多人参与系统维护。</li><li>当然大内存也需要钱。</li></ul><br /><br /><h2>10、Web访问负载均衡</h2><br /><br /><p>在数据包级别使用BIG-IP,但BIG-IP并不知道我们内部的处理机制,无法判断由哪台服务器对这些请求进行处理。反向代理并不能很好的起到作用,不是已经够快了,就是达不到我们想要的效果。</p><br /><br /><p>所以,LJ又开发了<a href="http://www.danga.com/perlbal/">Perlbal</a>。特点:</p><br /><br /><ul><li>快,小,可管理的http web 服务器/代理</li><li>可以在内部进行转发</li><li>使用Perl开发</li><li>单线程,异步,基于事件,使用epoll , kqueue</li><li>支持Console管理与http远程管理,支持动态配置加载</li><li>多种模式:web服务器,反向代理,插件</li><li>支持插件:GIF/PNG互换?</li></ul><br /><br /><h2>11、MogileFS</h2><br /><br /><p>LJ使用开源的<a href="http://www.danga.com/mogilefs/">MogileFS</a>作为分布式文件存储系统。MogileFS使用非常简单,它的主要设计思想是:</p><br /><br /><ul><li>文件属于类(类是最小的复制单位)</li><li>跟踪文件存储位置</li><li>在不同主机上存储</li><li>使用MySQL集群统一存储分布信息</li><li>大容易廉价磁盘</li></ul><br /><br /><p>到目前为止就这么多了,更多文档可以在<a href="http://www.danga.com/words/">http://www.danga.com/words/</a>找到。<a href="http://www.danga.com/">Danga.com</a>和<a href="http://www.livejournal.com/">LiveJournal.com</a>的<br />同学们拿这个文档参加了两次MySQL Con,两次OS<br />Con,以及众多的其它会议,无私的把他们的经验分享出来,值得我们学习。在web2.0时代快速开发得到大家越来越多的重视,但良好的设计仍是每一个应<br />用的基础,希望web2.0们在成长为Top500网站的路上,不要因为架构阻碍了网站的发展。</p><br /><br /><p>参考资料:<a href="http://www.danga.com/words/2005_oscon/oscon-2005.pdf">http://www.danga.com/words/2005_oscon/oscon-2005.pdf</a></p><br /><p style="text-align: right; font-size: 8px">Blogged with <a href="http://www.flock.com/blogged-with-flock" title="Flock" target="_new">Flock</a></p><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-7957256654868746052007-04-02T11:04:00.001+08:002007-04-02T11:34:13.247+08:00[转贴]IT业加班现象深度分析(下)<div xmlns='http://www.w3.org/1999/xhtml'><p>原文网站:http://blog.sina.com.cn/duki<br></br></p><p>被动加班者应该是一个更庞大的群体,他们不仅因加班劳其筋骨,而且更背负着沉重的怨恨和无奈(提倡、强迫员工加班的老板们,你们是不是经常觉得后脖颈子发凉啊?那就是员工的怨气啊!)</p>既然是被动加班,自然是被老板们(包括经理们及其他高管们)强迫的啦!那么老板们为什么喜欢强迫员工加班呢,原因当然也是多种多样了。<br></br><p><strong>剩余价值派</strong></p>这些老板初一政治课第一学期估计挺认真听讲,到了下学期就不认真学了,所以光记得延长劳动时间,能够获取更多剩余价值。全然没看到下一章写着,延长劳动时间的结果,就是工人消极怠工,破坏生产设备什么的,最终吃亏的还是老板。这类老板算帐很在行,同样2000元月薪,买8小时/日的劳动时间,比较亏,买16小时/日才赚!但是他忘了,劳动时间不等于产品,更不等于利润。开公司的目的是赚钱,不是占员工便宜。<strong><br></br><br></br>牧羊女派</strong><br></br><p>这些老板通常是外行,根本不知道设计一个界面需要多少时间,完成一个论坛功能需要多少时间,做出游戏的聊天系统需要多少时间……其实不知道没关系,公司里肯定有内行啊,问就好了,但是他们或者拉不下脸来问,或者根本不信任任何人,他们害怕手下怠工,又不知道怎么评估他们是否怠工,于是,他们只能让大家加班,多花时间拼命做,反正做就是了,只有员工一天到晚在他眼皮子底下忙忙碌碌,他们才能心安。至于员工在忙什么,他不懂,也不关心,就算想关心,也不知道从何入手。</p>他们就像牧羊女,只要羊在眼前,他们就很放心,羊到底有没有吃草,有没有长膘,他们的脑容量太小,没有那个判断力,至于里面有没有披着羊皮的狼,他们就更分辨不出了。<br></br><p><strong>光荣传统派</strong></p>这类老板通常很成功,但是不知道为什么很成功,一没技术,二没管理,只因为祖坟冒了青烟,天上掉下狗头金,他们成功了。既然成功了,就要总结经验,可他们思来想去,也没有从自己身上发现什么优点,只好认定,自己的成功都是努力拼命的结果,天道酬勤嘛!要不是当年拼命加班,哪有今天的成功?未来要守住成功,并获得更大成功,自然更要加班,不仅自己加班,全公司都要加班,不能让俺一个人战斗啊!这就是俺们的公司文化,光荣传统不能丢嘛!<strong><br></br><br></br>夜猫子派</strong><br></br><p>这类老板是属夜猫子的,一到晚上就精神,通常每天午饭后施施然来上班,下午处理上午积压的公事,到了下班的点儿,就跟打了鸡血似的,兴奋起来,开会、布置工作、检查成果……把员工指使得团团转,自然也就回不了家,到了半夜,再开个总结会,必胜客、星巴克伺候着!自以为非常体恤员工了,可后半夜他开着宝马回家睡觉到中午去了,员工打着摩的回家没睡一会,还得9点上班打卡,怎不让员工恨得牙根痒痒?</p><strong>苦劳派</strong><br></br><p>这类老板能力是没有的,事情是一搞就砸的,做开发是经常拖期的,做市场是经常没效果的,但是他们有一样本事,就是欺上瞒下,报喜不报忧,敷衍上头的本事还是一流的。但是纸包不住火,丑媳妇总要见公婆,上头迟早会知道事情根本没办好,怎么办?加班啊!咱是没办好事情,但是咱没有功劳还有苦劳呢!您没看我一周7天,一天24小时都待在公司吗?事情没办好,不是我能力问题,更不是我态度问题,而是天时、地利都没有,我已经尽了最大努力,这事情根本没法办啊,就是神仙来了也办不好啊,“你说我容易吗?上辈子欠你的,我都快累死了,还要硬挺着,还不依不饶啊,还嫌不够吗,真够可以的,就这样算了吧……”他是过关了,员工何处诉苦它就不管了。</p><strong>中华崛起派</strong><br></br><p>这类老板入错了行,如果混入党、政、军的圈子,肯定会取得更大成就。他们提倡加班、鼓励加班,决不是为了私欲、私利,而是为了中华IT业的崛起。什么起步晚、底子薄、基础差、技术落后啦,什么赶超世界先进水平啦,什么落后就要挨打啦,不把一天当两天用怎么可能超日赶美捏?虽然这个调调有点过时,但是说出来还是慷慨激昂,掷地有声的,员工们明知道这是大跃进,可以不信,但是不好辩驳,万一有个把脑子不太清楚的,相信了这个,老板们的政治宣传公司就算有效果了,《动物庄园》中不就是有一匹这样脑子不太清楚的老马吗?</p>Technorati Tags: <a rel='tag' href='http://technorati.com/tag/%E9%97%B2%E8%AF%9D' class='performancingtags'>闲话</a>, <a rel='tag' href='http://technorati.com/tag/%E5%8A%A0%E7%8F%AD' class='performancingtags'>加班</a><br></br><br></br><br></br><br></br><p class='poweredbyperformancing'>Powered by <a href='http://scribefire.com/'>ScribeFire</a>.</p></div><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-26663263409164636922007-04-02T11:03:00.001+08:002007-04-02T11:33:35.960+08:00[转贴]IT业加班现象深度分析(上)<div xmlns='http://www.w3.org/1999/xhtml'><a href='javascript:;' onclick='addClass('articleText537b30c4010008pw','A_font_change_big')'></a><div align='left' id='articleText537b30c4010008pw' class='sysBr500 text'><div><p>原文网站:http://blog.sina.com.cn/duki<br></br></p><p>IT业加班多,地球人都知道,但为什么加班多,未必地球人都知道。包括你!对!就是你!现在正在加班并且偷懒看这篇文章的你。</p>加班分为两种,一种是主动的,一种是被动的。其成因、发展、现状截然不同,必须分别论述。<br></br><p>在主动加班者当中,分为三个流派。</p><strong>少壮派</strong><br></br><p>既然是少壮派,当然岁数不大,职位不高,大学毕业没两年。多数独自在大城市打拼,属于典型的三无青年:无钱、无房、无女友(男友)。下班回家,租屋环境脏乱差,漫漫长夜不知道怎么打发。相比之下,公司的环境要好很多,上有冷气,下有地毯,中间有键盘,窗明几净,24小时热水供应。下班之后滞留公司不走也是正常,上上网,听听音乐,打打游戏,下载点东西,开个小店……反正用的都是公司的资源,业余生活也算丰富多彩。</p>少壮派最大的特征就是具有强烈的“公司-电脑依赖症”。如果公司强制不允许加班,一下班就锁门,他们会非常失落,而他们的业余生活,则转为上网吧或睡觉。总之一句话,他们需要电脑,需要网络,但是他们没有,而加班,可以免费提供给他们这些,所以他们加班着并快乐着。<br></br><p><strong>大叔派</strong></p>所谓大叔派,也没多老,一般是30左右或以上,大小是个主管,有家有口的IT精英。他们加班,也是比较之下的自主选择。这些大叔,多半家庭不那么幸福,回到家里,等待他的是漏了的马桶,待洗的衣服,老婆的唠叨,孩子的哭……在家上个网?玩个游戏?在老婆看来,那是对家庭天大的犯罪。同家务活比起来,加班当然是比较轻松,和让老婆满意比起来,让老板满意会比较轻松。而且,老婆比老板精明,保险丝换了就是换了,没换就是没换,老婆清楚的很,而老板常常只看人在不在公司,人在就是好同志,不管你是不是在干活。<br></br><p><br></br>就像《中国式离婚》中的那个丈夫,号称加班,其实是在单位玩《侍魂》,顺便跟单位的小红颜知己贫两句,意淫一下,也算“眼睛吃冰淇淋,灵魂做沙发椅”,给自己找个乐儿。</p>平心而论,加班的大叔们还算好丈夫,至少没有拿上工资卡,直奔风月场所去者,或者干脆来个狡兔三窟,金屋藏娇,养个小情人。<br></br><p><strong>无差别派</strong></p>以上两个派别,都是通过比较“加班”和“回家”两种行为的结果,判断出加班比较有利,千好万好,不如公司好,正所谓趋利避害,大家自然纷纷选择加班,而无差别派,更看重的则是加班带来的好处。<br></br><p>一个很明显的好处就是加班费,虽然很多公司加班纯属自愿,并无任何报酬,但是还有少部分公司,保留着加班能拿加班费或补贴的光荣传统。在多赚几个钱的利益趋势下,仗着自己年轻,身体好,反正回家也没什么有意思的事,自然能加班就加班,能多加班就多加班,赚得一文是一文了。这倒是跟血汗工厂的工人们的加班热情有异曲同工之妙。</p>有些公司,虽然没有加班费,公司也没有明文强迫加班,但是上头是按照加班多少评定绩效的,加班越多,工资涨得越多,职位升得越快。于是乎,广大胸怀大志的有为青年就纷纷走上了加班这条不归路。加班也是可以成瘾的,大家加啊加啊加习惯了,无形中为公司创造了更多价值,薪水也涨了些,但其实按工作时间一平均不涨反降,而且高阶职位却没有那么多,升上去的毕竟是少数。最终,身体垮了,人傻了,女友跑了……这些结果反而比当上中高层更容易获得。<br></br><p><br></br>其他自愿加班还有:老板爱加班,为了跟老板有更多接触,为了给老板一个好印象,而加班;利用办公用品,创造美好生活,以公司为家,将刷牙、洗脚等行为都在公司解决,节省生活成本而加班(此行为网上有专文详细论述);利用公司资源,经营自己的生意而加班……等等。</p><br></br></div></div>Powered by <a href='http://scribefire.com/'>ScribeFire</a>.</div><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-73577024705747071722006-12-25T14:35:00.000+08:002007-01-11T14:37:19.135+08:00面向对象设计的11原则<p> </p>面 向对象设计是什么?都包含了哪些内容?它所带来的好处是什么?需要你为之付出些什么?在如今这个年代,问这些问题似乎显得很愚蠢,因为这年头几乎每位软件 开发人员都知道如何使用某种面向对象编程语言。可是这个问题还是很重要,因为在我看来,绝大多数人在使用这些语言的时候并不知道为什么,而且也不知该如何 最充分的运用它们。<br /><br /> 软件业曾经爆发过的所有变革里,其中曾经有两个派系如此广泛的深入人心,它们就是结构化编程和面向对象编程。所有 主流的现代编程语言都被它们两个激烈的影响着。实际上,要想不像结构化和面向对象编程的样子来编写程序都是一件难事。我们的主流编程语言都没有goto, 因此它们服从了结构化编程中最重要的禁令。我们的大多数主流编程语言都是基于类的,而且不支持在类以外定义函数或是变量,因此也避免了面向对象编程中最容 易坠入的陷阱。<br /><br /> 用这些编程语言所编写的程序可能看起来是结构化的或是面向对象的,可是“看起来”是会欺骗人的。当今的编程语言经常不顾他们所从属那种派系的编程语言的基本原则。我会在另篇blog中再探讨结构化编程的原则,本篇,我想要谈论的是面向对象编程的基本原则。<br /><br /> 在1995年的三月,我写了一篇文章并发表在comp.object上,那是我第一次写OOD(译注 1)原则的文章,此后就一发不可收拾的写了很多。你可以在我的PPP一书(译注2)中看到它们,在object mentor的很多文章中也都有,其中就有那篇众所周知的纲要(近期会译为中文,请关注)。<br /><br /> 这些原则着重于OOD中的依赖管理方面,而淡化抽象与建模方面。这并不是说OO在抽象方面不够强大,或是OO不适合构建模型。当然有很多人都在使用OO的这些部分,只是这些原则集中关注于依赖管理。<br /><br /> 依赖管理是我们每个人都要面对的问题,每当我们在屏幕面前打开那些彼此纠结又令人作呕的代码,我们就会遭受不良的依赖管理所带来的恶果。不良的依赖管理 导致代码难以改变,易被破坏,而且不可重用。实际上,我在PPP一书中谈论过很多不同的设计坏味道,而这些都与依赖管理有关。从另一方面来说,如果依赖经 过了良性的管理,代码就可以保持灵活性、健壮性和重用性。所以依赖管理和这些相关原则是程序员们渴求的让软件保持优良架构的基石。<br /><br /> 头五项原则是关于类设计的,它们是:<br /><br /> ◆ SRP,单一职责原则,一个类应该有且只有一个改变的理由。<br /> ◆ OCP,开放封闭原则,你应该能够不用修改原有类就能扩展一个类的行为。<br /> ◆ LSP,Liskov替换原则,派生类要与其基类自相容。<br /> ◆ DIP,依赖倒置原则,依赖于抽象而不是实现。<br /> ◆ ISP,接口隔离原则,客户只要关注它们所需的接口。<br /><br /> 另外的六项是关于包的设计原则。在本文中,包是指一个二进制的可发布文件,比如.jar文件、或dll文件,而不是Java包或是C++的命名空间(译注3)。<br /><br /> 头三项包原则是关于包内聚性的,它们会告诉我们该把什么划分到包中:<br /><br /> ◆ REP,重用发布等价原则,重用的粒度就是发布的粒度。<br /> ◆ CCP,共同封闭原则,包中的所有类对于同一类性质的变化应该是共同封闭的。<br /> ◆ CRP,共同重用原则,一个包中的所有类应该是共同重用的。<br /><br /> 最后的三项原则是关于包之间的耦合性原则的,并且论述了评价系统中包结构优良与否的评判标准。<br /><br /> ◆ ADP,无环依赖原则,在包的依赖关系图中不允许存在环。<br /> ◆ SDP,稳定依赖原则,朝着稳定的方向进行依赖。<br /> ◆ SAP,稳定抽象原则,包的抽象程度应该和其稳定程度一致。<br /><br /><br />译注:<br /><br />1,OOD,全称Object Oriented Design,即面向对象设计。<br /><br />2,PPP,即Bob大叔的著作《敏捷软件开发 原则、模式与实践》一书以及其相关书籍,因都有“原则、模式与实践”,即Priciples, Patterns and Practices,故常简称为PPP。<br /><br />3, 命名空间,原文为namespace,也译作名字空间。它是一种特殊的作用域,它包含了处于该作用域内的所有标示符,且本身也用一个标示符来表示,这样便 于将一系列在逻辑上相关的标示符用一个标示符来组织。就Java编程语言来说,命名空间是通过java 包来表达的,所有代码都归属与一个包。来自其他包中的代码要通过指定包名来引用某项特定的标示符,例如,包java.lang中的String类要通过 java.lang.String的形式引用。在C++中,命名空间常用来避免命名冲突,尽管现今的C++语言对命名空间做出了扩展,但过去的C++代码 很少使用此项功能。<div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-39405872688491503632006-12-21T14:37:00.000+08:002007-01-11T14:38:33.328+08:00MPM优化你的Apache<h3 class="post-title"><br /> </h3> <p> </p>Apache 2.0在性能上的改善最吸引人。在支持POSIX线程的Unix系统上,Apache可以通过不同的MPM运行在一种多进程与多线程相混合的模式下,增强 部分配置的可扩充性能。相比于Apache 1.3,2.0版本做了大量的优化来提升处理能力和可伸缩性,并且大多数改进在默认状态下即可生效。但是在编译和运行时刻,2.0也有许多可以显著提高性 能的选择。<br /><br />MPM(Multi -Processing Modules,多道处理模块)是Apache2.0中影响性能的最核心特性。<br /><br />毫 不夸张地说,MPM的引入是Apache 2.0最重要的变化。大家知道,Apache是基于模块化的设计,而Apache 2.0更扩展了模块化设计到Web服务器的最基本功能。服务器装载了一种多道处理模块,负责绑定本机网络端口、接受请求,并调度子进程来处理请求。扩展模 块化设计有两个重要好处:<br /><br /> ◆ Apache可以更简洁、有效地支持多种操作系统;<br /><br /> ◆ 服务器可以按站点的特殊需要进行自定制。<br /><br />在用户级,MPM看起来和其它Apache模块非常类似。主要区别是在任意时刻只能有一种MPM被装载到服务器中。<br /><br />下面以Linux RedHat AS3为平台,演示一下在Apache 2.0中如何指定MPM。<br /><br /># wget http://archive.apache.org/dist/httpd/httpd-2.0.52.tar.bz2<br /># tar jxvf httpd-2.0.52.tar.bz2<br /># cd httpd-2.0.52<br /># ./configure --help|grep mpm<br /><br />显示如下: --with-mpm=MPM Choose the process model for Apache to use. MPM={beos|worker|prefork|mpmt_os2| perchild|leader|threadpool}<br /><br />上 述操作用来选择要使用的进程模型,即哪种MPM模块。Beos、mpmt_os2分别是BeOS和OS/2上缺省的MPM, perchild主要设计目的是以不同的用户和组的身份来运行不同的子进程。这在运行多个需要CGI的虚拟主机时特别有用,会比1.3版中的SuExec 机制做得更好。leader和threadpool都是基于worker的变体,还处于实验性阶段,某些情况下并不会按照预期设想的那样工作,所以 Apache官方也并不推荐使用。因此,我们主要阐述prefork和worker这两种和性能关系最大的产品级MPM。<br /><br />prefork的工作原理<br /> 如果不用“--with-mpm”显式指定某种MPM,prefork就是Unix平台上缺省的MPM。它所采用的预派生子进程方式也是 Apache 1.3中采用的模式。prefork本身并没有使用到线程,2.0版使用它是为了与1.3版保持兼容性;另一方面,prefork用单独的子进程来处理不 同的请求,进程之间是彼此独立的,这也使其成为最稳定的MPM之一。<br />prefork的工作原理是,控制进程在最初建立 “StartServers”个子进程后,为了满足MinSpareServers设置的需要创建一个进程,等待一秒钟,继续创建两个,再等待一秒钟,继 续创建四个……如此按指数级增加创建的进程数,最多达到每秒32个,直到满足 MinSpareServers设置的值为止。这就是预派生(prefork)的由来。这种模式可以不必在请求到来时再产生新的进程,从而减小了系统开销 以增加性能。<br /><br />worker的工作原理<br />相对于prefork,worker是2.0 版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理,所以可以处理相对海量的请求,而系统资源的开销要小于基于进程的服务器。但是, worker也使用了多进程,每个进程又生成多个线程,以获得基于进程服务器的稳定性。这种MPM的工作方式将是Apache 2.0的发展趋势。<br />worker 的工作原理是,由主控制进程生成“StartServers”个子进程,每个子进程中包含固定的ThreadsPerChild 线程数,各个线程独立地处理请求。同样,为了不在请求到来时再生成线程,MinSpareThreads和MaxSpareThreads设置了最少和最 多的空闲线程数;而MaxClients设置了所有子进程中的线程总数。如果现有子进程中的线程总数不能满足负载,控制进程将派生新的子进程。<br /><br /># 下面我以worker模式进行编译安装<br /># ./configure --prefix=/usr/local/apache --with-mpm=worker --enable-so(让它支持DSO功能,这样以后可以动态加载模块)<br /># make<br /># make install<br /># cd /usr/local/apache/conf<br /># vi httpd.conf<br />StartServers 2<br />MaxClients 150<br />ServerLimit 25<br />MinSpareThreads 25<br />MaxSpareThreads 75<br />ThreadLimit 25<br />ThreadsPerChild 25<br />MaxRequestsPerChild 0<br /><br />Worker 模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild值决定的,应该大于等于MaxClients。如果负载很大,现有的子进 程数不能满足时,控制进程会派生新的子进程。默认最大的子进程总数是16,加大时也需要显式声明ServerLimit(最大值是 20000)<br /><br />需 要注意的是,如果显式声明了ServerLimit,那么它乘以ThreadsPerChild的值必须大于等于MaxClients,而且 MaxClients必须是 ThreadsPerChild的整数倍,否则Apache将会自动调节到一个相应值(可能是个非期望值)。下面是笔者的 worker配置段:<br />StartServers 3<br />MaxClients 2000<br />ServerLimit 25<br />MinSpareThreads 50<br />MaxSpareThreads 200<br />ThreadLimit 200<br />ThreadsPerChild 100<br />MaxRequestsPerChild 0<br /># 保存退出。<br /># /usr/local/apache/bin/apachectl start<br /># 可根据实际情况来配置Apache相关的核心参数,以获得最大的性能和稳定性。<div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-6381978283396938022006-12-19T14:39:00.000+08:002007-01-11T14:40:45.793+08:00Apache+JK+Tomcat负载平衡配置<h3 class="post-title"><br /> </h3> <p> </p>网 上关于Apache + JK + Tomcat的集群配置例子很多,按着例子配置下来,基本都能运行,不过,在一些重要的地方却没有进一步的说明。这次公司一个产品就是采用Apache +JK+Tomcat集群,在整个配置、测试过程中,遇到了许多的问题,经过不断测试、摸索,最后总算是搞定了,性能也达到了预期的目标。针对网上的例 子,感觉有必要再详细的介绍一下我的配置过程,对一些要特别注意的地方进行补充。<br /><br />集群有别于分布式的解决方案,它采用的是每台服务器运行 相同应用的策略,由负责平衡的服务器进行分流,这对提高整个系统的并发量及吞吐量是更有效的办法。而集群对请求的处理又有两种不同的方式:负载平衡、状态 复制(即集群),状态复制需要在各服务器间复制应用状态,而负载平衡则不用,每台服务器都是独立的。实践证明,在各应用服务器之间不需要状态复制的情况 下,负载平衡可以达到性能的线性增长及更高的并发需求。<br /><br />对于集群的其它基础知识,在此就不再做累赘。以下就这次Apache + JK + Tomcat的负载平衡配置进行总结,重点关注整个配置及注意事项。<br /><br /><br />准备软件<br />1、 Tomcat或JBoss(本文档中采用的是JBoss4.0.2);<br /><br />2、 apache2.0.54是开源的Web服务器,下载地址为: http://www.apache.org/dist/httpd/binaries/ ;<br /><br />3、 mod_jk-1.2.14-apache-2.0.54.so模块,jk是mod_jserv的替代者,它是Tomcat-Apache插件,为 Apache和Tomcat的连接器,处理Tomcat和Apache之间的通信,在集群配置中充当负载均衡器的作用,当前的最新版本为1.2.15,不 过不同JK版本与不同的Apache版本之间的搭配有一些差异,有的甚至配不起来。JK2是符合apache2.x系列的新品,但由于其配置太过麻烦,使 用的人很少,所以目前已停止开发,所以我们采用了jk连接器,下载地址:http: //www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/。<br /><br /><br />集群与负载平衡<br />使用mod_jk默认的以轮循方式进行平衡负载,假设有四个服务器节点,有10个请求,则四个节点分别接受请求编号如下:<br /><br />而集群方式也是使用这种方法进行平衡。Tomcat中的集群原理是通过组播的方式进行节点的查找并使用TCP连接进行会话的复制。<br /><br /> 集群不同于负载平衡的是,由于集群服务需要在处理请求之间不断地进行会话复制,复制后的会话将会慢慢变得庞大,因此它的资源占用率是非常高的,如果在并发量大的应用中,复制的会话大小会变得相当大,而使用的总内存更是会迅速升高。<br /><br /> 但集群的会话复制,增加了系统的高可用性。由于在每台服务器都保存有用户的Session信息,如果服务器群中某台当机,应用可以自动切换到其它服务器上继续运行,而用户的信息不会丢失,这提高了应用的冗错性。<br /><br />具体采用负载平衡还是集群,这要看应用的需求了。<br /><br />安装配置Apache<br />1、下载Apache的安装程序apache_2.0.54-win32-x86-no_ssl.exe后,安装很简单,一路回车,就此略过。<br /><br />2、安装完毕后,将下载的mod_jk-1.2.14-apache-2.0.54.so复制到Apache安装目录下的modules子目录中。<br /><br />3、然后进入Apache安装目录下的conf子目录中,打开httpd.conf配置文件,在最后插入以下一行:<br /><br />Include conf/mod_jk.conf<br /><br />4、 在conf子目录下,建立一个新的配置文件:mod_jk.conf,此文件为Apache加载连接器的配置文件,文件名可修改,但要与httpd.conf中Include的文件名一致,内容如下:<br /><br /># Load mod_jk module. Specify the filename<br /># of the mod_jk lib you’ve downloaded and<br /># installed in the previous section<br /><br />#加载mod_jk模块<br /><strong style="color: rgb(0, 0, 153);" color="blue">LoadModule jk_module modules/mod_jk-1.2.14-apache-2.0.54.so</strong><br /><br /># Where to find workers.properties<br />JkWorkersFile conf/workers2.properties<br /><br /># Where to put jk logs<br />JkLogFile logs/mod_jk.log<br /><br /># Set the jk log level [debug/error/info]<br />JkLogLevel info<br /><br /># Select the log format<br />JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "<br /><br /># JkOptions indicate to send SSL KEY SIZE,<br />JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories<br /><br /># JkRequestLogFormat set the request format<br />JkRequestLogFormat "%w %V %T"<br /><br /># 请求分发配置,可以配置多项<br /><strong style="color: rgb(0, 0, 153);" color="blue">JkMount /* loadbalancer</strong><br /><br />#关掉主机Lookup,如果为on,很影响性能,可以有10多秒钟的延迟。<br />HostnameLookups Off<br /><br />注:蓝色加粗的两行是重点,第一句是Apache加载JK模块用的;第二句为配置哪些URL请求将由负载平衡器来处理。<br /><br /><br />5、 在conf子目录下,建立一个新的配置文件:workers2.properties,此文件为负载平衡的配置文件,文件名不能修改,这是JK默认的名字,内容如下:<br /><br /><span style="color: rgb(0, 0, 153);">worker.list=loadbalancer</span><br /><br /># Define the first node...<br /><span style="color: rgb(0, 0, 153);">worker.server99.port=8009</span><br /><span style="color: rgb(0, 0, 153);">worker.server99.host=192.168.11.99</span><br /><span style="color: rgb(0, 0, 153);">worker.server99.type=ajp13</span><br /><span style="color: rgb(0, 0, 153);">worker.server99.lbfactor=1 </span><br />worker.server99.local_worker=1<br />worker.server99.cachesize=1000<br />worker.server99.cache_timeout=600<br />worker.server99.socket_keepalive=1<br />worker.server99.socket_timeout=0<br />worker.server99.reclycle_timeout=300<br />worker.server99.retries=3<br /><br /># Define the second node...<br /><span style="color: rgb(0, 0, 153);">worker.server202.port=8009</span><br /><span style="color: rgb(0, 0, 153);">worker.server202.host=192.168.11.202</span><br /><span style="color: rgb(0, 0, 153);">worker.server202.type=ajp13</span><br />worker.server202.lbfactor=1<br />worker.server202.local_worker=1<br />worker.server202.cachesize=1000<br />worker.server202.cache_timeout=600<br />worker.server202.socket_keepalive=1<br />worker.server202.socket_timeout=0<br />worker.server202.reclycle_timeout=300<br />worker.server202.retries=3<br /><br /># Now we define the load-balancing behaviour<br /><span style="color: rgb(0, 0, 153);">worker.loadbalancer.type=lb</span><br />worker.retries=3<br /><span style="color: rgb(0, 0, 153);">worker.loadbalancer.balance_workers=server99 ,server202</span><br /><span style="color: rgb(0, 0, 153);">worker.loadbalancer.sticky_session=true</span><br /><span style="color: rgb(0, 0, 153);">worker.loadbalancer.sticky_session_force=true</span><br /><br /><br />注: 以上定义了两个worker,一个为server99,另一个为server202,定义了一个负载平衡服务器loadbalancer,其中标蓝色的为 重点配置项,相关的详细说明可以看官方的网站文档:http://tomcat.apache.org/connectors-doc/,其它节点的定义 可以直接Copy,修改一下节点名及IP就好了。<br />A、worker.list=loadbalancer<br />设定工作的负载平衡器,各Tomcat节点不能加入此列表。<br /><br /> B、worker.server99.lbfactor<br />负载平衡的权重比,如果此权重比越大,则分配到此节点的请求越多,如以上两个节点的权重比为1:1,则为平均分配。<br /><br />C、worker.loadbalancer.balance_workers=server99,server202<br /> 指定此负载平衡器负责的Tomcat应用节点。<br /><br />D、worker.loadbalancer.sticky_session=true<br /> 此处指定集群是否需要会话复制,如果设为true,则表明为会话粘性,不进行会话复制,当某用户的请求第一次分发到哪台Tomcat后,后继的请求会一直分发到此Tomcat服务器上处理;如果设为false,则表明需求会话复制。<br /><br />E、worker.loadbalancer.sticky_session_force=true<br />如果上面的sticky_session设为true时,建议此处也设为true,此参数表明如果集群中某台Tomcat服务器在多次请求没有响应后,是 否将当前的请求,转发到其它Tomcat服务器上处理;此参数在sticky_session=true时,影响比较大,会导致转发到其它Tomcat 服务器上的请求,找不到原来的session,所以如果此时请求中有读取session中某些信息的话,就会导致应用的null异常。<br /><br /><br />6、Apache服务器的配置文件httpd.conf中,默认有三个参数对性能的影响比较大,但根据不同的性能要求,参数的表现又不一样,太小并发提不上去,太大性能反而不好,建议根据项目的需要,实际做个测试,如并发要求800的话,可以设定为:<br /><br />#一个连接的最大请求数量<br />MaxKeepAliveRequests 1000(值为0,则不限制数量)<br /><br />#每个进程的线程数,最大1920。NT只启动父子两个进程,不能设置启动多个进程<br />ThreadsPerChild 1000(最大为1920)<br /><br />#每个子进程能够处理的最大请求数<br />MaxRequestsPerChild 1000(值为0,则不限制数量)<br /><br />这三个参数要根据不同的需求,不同的服务器进行调整。<br /><br /><br />安装配置Tomcat或JBoss<br />1、对于Tomcat或JBoss的安装,这里不做说明,目前我们是采用Apache+JBoss,不过,JBoss也是用的Tomcat,所以这里的配置也是适合Tomcat的;<br /><br />2、对于JBoss的配置,很简单,只需要改两个地方就可以了:<br /><br />第一个地方:进入jboss-4.0.2\server\default\deploy\jbossweb-tomcat55.sar,打开server.xml,大约在第32行左右,有,在其中加入一个参数,变为:<br /><br />第二个地方:进入jboss-4.0.2\server\default\deploy\jbossweb-tomcat55.sar\META-INF目录,打开jboss-service.xml,大约在110行,有false,将其改为:<br /><br />true<br /><br />这 里有一个需要特别注意的地方,JBoss的Tomcat中,关于AJP连接协议的默认配置,对于大并发量是不够用的,要做一些修改,进入jboss- 4.0.2\server\default\deploy\jbossweb-tomcat55.sar,打开server.xml,找到的地方,这里是 定义AJP连接器的地方,它的配置中没有maxThreads项,默认为200,我们可以做修改:<br /><br />emptySessionPath="true" enableLookups="false" redirectPort="8443"<br /><br />protocol="AJP/1.3" maxThreads="3000"/><br /><br />maxThreads的值要看你的并发量多大,设置太大也不好。<br /><br /><br />运行<br />至此,整个配置全部完成,注意一点是,在各JBoss节点,重启或新增加一个JBoss节点时,需要重新启动Apache,而对于服务器群中某个JBoss节点shutdown,Apache会自动侦测,不用重新启动。<br /><br />如果在运行过程中,群中的某个JBoss节点shutdown,则已登录到此服务器上的用户的请求将出错,此服务器负责的session将丢失,但Apache会自动侦测到此服务器已shutdown,后继的新请求将不会再引导到此节点。<br /><br />对 于负责请求分发的Apache服务器,需要消耗大量的CPU资源,因此如果在测试过程中出现一些Service Temporarily Unavailable或Server has shut down the connection prematurely这样的错误,这一般都是服务器配置不够好引起的,或者是Apache、Tomcat、及应用中的某些配置不够使用,这时候就要考虑 换更好的机器或优化应用中的配置。<br /><br />常见问题<br /><br />一、cannot connect to server:无法连接到服务器。这种情况是服务器的配置有问题,服务器无法承受过多的并发连接了,需要优化服务器的配置:<br /><br />如操作系统采用更高版本,如windows 2003 server,<br /><br />优化tomcat配置:maxThreads="500" minSpareThreads="400" maxSpareThreads="450"<br /><br />但是tomcat 最多支持500个并发访问<br /><br />优化apache配置:<br /><br />ThreadsPerChild 1900<br />MaxRequestsPerChild 10000<br /><br />二、 Action.c(10): Error -27791: Server has shut down the connection prematurely<br /><br />HTTP Status-Code=503 (Service Temporarily Unavailable)<br />一般都是由于服务器配置不够好引起的,需要优化硬件和调整程序了。<br /><br /><br />三、无法处理请求:<br /><br />当我们输入 ***.do 命令后,apache却返回错误信息,而连接tomcat却没有问题。原因是没有把.do命令转发给tomcat处理。解决方法如下:<br /><br />在apache配置文件中配置如下内容:<br /><br />JkMount /*.jsp loadbalancer<br />JkMount /*.do loadbalancer<div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-8039440339508139892006-12-15T14:42:00.000+08:002007-01-11T14:43:29.898+08:00RedHat 忘记了root密码,如何进入系统?<div xmlns="http://www.w3.org/1999/xhtml">您可以进入单用户模式或者援救模式来改变你的root密码.如何进入单用户模式取决你的引导加载程序:<br /><br />GRUB: 如果你的GRUB引导菜单没有使用密码保护或者你知道引导菜单的密码,就可以通过编辑引导加载程序配置菜单中的kernel所在行来完成。如果GRUB的 引导菜单被密码保护,你又不知道密码,你必须使用一个同样版本RHEL的启动光盘来引导系统。当从光盘启动时,在boot:后输入 linux resuce来以救援模式启动,根据启动过程中的指令进行按步骤的操作,然后使用chroot 来切换到你的系统镜像(通常使用chroot /mnt/sysimage).这样你就可以通过passwd 来改变你的root的密码了。在系统启动后,选择你希望启动的核心,然后输入'e' (代表edit).你就会进入编辑启动参数的屏幕。把光标移动到核心所在行然后再输入'e'. 在行尾输入'S',然后输入回车,再输入'b' (代表 boot).系统就会进入单用户模式,这样你就可以使用passwd命令来改变root的密码。<br /><br />LILO:如何你的系统使用的是 LILO,在LILO的提示符下,输入 linux single. 当启动完毕后,在#的提示符下输入passwd来输入一个新的密码。改变密码后,可以输入exit来重新启动你的系统。当然你可以通过shutdown -r now或者 reboot 命令来重新启动你的系统。系统正常启动后,你可以使用新的root密码登录系统。如果LILO被配置成没有引导菜单(/etc/lilo.conf中的 timeout值设为0),你仍然可以在LILO启动核心的一瞬间,通过按任何一个键使启动过程暂停。 </div><div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0tag:blogger.com,1999:blog-4859106168103096421.post-41104698809021854272006-12-01T16:43:00.001+08:002007-01-11T14:45:13.498+08:00项目最后验收阶段案例之一软件项目,特别是给企业用户的项目,实施过程大多辛苦,而且一部分问题不在于软件本身。<br /><br />总结一下项目最后验收阶段案例之一。<br /><br />案例:项目已经按照客户确认的调研文档完成实施工作。客户的一把手提出新需求。<br /><br />此 一把手H,H精通业务,对电脑一窍不通。H对手下电脑部负责人Z提出"要对业务进行风险管理,把风险大的业务提出来。",一句话令Z头大。Z苦恼H没有定 义什么是风险大,即使H说明风险大的条件,现有的软件架构,数据模型能否实现还是未知数。实现此功能成为不可完成的任务。持续下去Z和项目经理W(软件公 司负责人)都面临困境。<br /><br />Z会被认为没有完成领导安排的工作(实际上他忙的焦头烂额)。<br /><br />W进入两难,一方面客户要求的完成不了,另一方面面临公司的的项目要拖延。<br /><br />解决办法:1.按章办事,调研文档已经写清楚无此需求。直接拒绝。此为下策,没办法才用,但是关键时刻很有用。<br /><br />2. 引导+忽悠。对付H这种老总要从其公司内部出发。分析满足他需求所需要的条件。一般要牺牲部分工作人员的工作时间。然后把影响放大,吓唬他。如果可以的话 可以找他们的相关人员帮忙,让他听到不同的声音,让他放弃此念头。因为软件他是外行,谈论软件时心里没底气,有自己人反对,心虚。<br /><br />比如从财务着手比较有效。要满足H的需求改变了财务的核算体系,原有的数据都要加上某写核算项,不能保证数据准确性,而且大大增加了财务工作量,而且不符合会计制度(忽悠)。上策!<div class="blogger-post-footer"><script type="text/javascript"><!--
google_ad_client = "pub-8746128515678236";
/* blogspot文章页,468x60, 创建于 08-5-13 */
google_ad_slot = "2547743289";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script></div>解语花http://www.blogger.com/profile/02566092479734306279noreply@blogger.com0