Linux运维趋势_第14期_高性能电子商务网站

002《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:系统频道：目录人物·People003百度高级架构师乔梁：DevOps=Culture+Tools交流·Interact005架构师不可不知的十大可扩展架构八卦·News007Ubuntu11.10，Fedora16正式发布专题·Special009解密淘宝网的开源架构011淘宝软件基础设施近年发展情况013Hadoop在eBay的应用015NoSQL数据库笔谈——应用篇017构建高安全电子商务网站之自动备份019老板要省钱小公司如何部署实施Linux集群网站技巧·工具·脚本·DBA021一种MySQL主从同步加速方案023用SSHGuard免费工具帮你保护服务器025OpenStack实践之旅：安装配置篇027榨干服务器：让进程运行在指定的CPU出版方：51CTO系统频道（北京无忧创想信息技术有限公司）杂志主编：杨赛联系方法：[e-mail]010-68476606（分机8035）出版日期：2011年11月11日每月第2个星期五出版订阅：《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:系统频道：百度高级架构师乔梁：DevOps=Culture+Tools的：三个月之后，团队的交付周期就变成了三周一次，并在接下来的三个月里一直保持这种频率。实际上，乔梁说，三周交付并不是该团队的极限，还可以优化到两周或更少，不过，在一种工作方式产生变革并取得成功的结果后，乔梁认为，应该把这种结果持续一段时间以使之固化下来，然后才可以进入下一个阶段。转变的过程当然是痛苦的，乔梁说，“但是得到的收益也很大”——DevOps带给团队的“不仅是技术上的改变，还有行为上的改变”。很多与会者都关心这种工作方式的可行性，在会后的提问中，大家的焦点也集中在这一块：开发团队和运维团队真的能够那么协调的工作吗?他们是怎么解决一些工作和技术上的冲突的呢?在会后的交流中，乔梁向51CTO记者表示，目前DevOps这种方式尚没有在百度的整体技术团队中应用，但是他所负责的highlevel的团队使用这种方式取得了明显的效果。而且，把交付周期变更为三周一次，是这个团队的开发人员和运维人员共同提出的，对于KPI进行整体考核的要求，也是团队成员提出的。“你要培养一种文化，要建立一种机制。让运维人员参与到更早——只要项目开始，启动阶段就要把运维人员引入进来，一起开个会，让他们知道项目的进程”。同时，开发人员也需要了解到运维人员的工作状态，因为一文/苏慧“把交付周期变更为三周一次，是这个团队的开发人员和运维人员共同提出的。”传统的软件交付过程是通过架构、业务、技术运维、保障等团队之间一步一步把交付物交给下一个环节，最后产生交付软件的价值。这种交付方式的一个明显缺点是各角色仅关注于自己本身的工作，在中间的流通环节产生了很多不必要的浪费，如时间成本和沟通成本等;同时，这种阶段性的交付通常时间较长，一旦产生问题造成的影响也较大。敏捷开发是为解决这一问题而提出的解决方案。在这种方法里，业务人员也深入到开发当中，这样需求、开发、测试前面三个环节被打通了，但是，到部署的时候仍会出现问题：因为项目是直到最后才交给运维人员部署到线上，部署时经常出现比如IP问题、机器资源问题、与线上已有程序的冲突等，要花费大量时间解决。出现这种结果是因为，虽然整个团队共同的目标是项目的最终实施，但是作为两个不同角色的部门，开发团队和运维团队对具体的目标仍有不同的追求。那么如何解决开发团队和运维团队之间的这种隔阂?DevOps应运而生。10月22日，在“QCon杭州2011全球企业开发者大会”上，来自百度项目管理部的高级架构师乔梁与大家分享了百度的一个交付团队是如何利用DevOps，在半年的时间内让交付周期从每三个月一次提升到每三周一次的。“我改变了他们的工作方式”，乔梁说。新的制度的确影响到了团队的日常工作，在开始的三个月，团队的开发速度降了下来。不过这种代价是值得004《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:系统频道：旦他们了解到运维人员每天要处理多少条告警，再开发的时候就会注意。据乔梁介绍，有些公司是通过轮岗的方式来促成这种相互理解的。“最后一点也是最关键的一点”，乔梁说“任何一种产品的成功，不只是你开发团队的成功。我希望DevOps里能为同一件事情来鼓掌，来建立一种沟通协作的文化”。DevOps首先是一种文化转变改变交付团队各个环节各自为政的局面，建立一种全新的工作方式，这是DevOps的第一步。然后，我们需要检视开发运维过程中的每一个环节，减少不必要的浪费。这些浪费包括：一些容易造成高风险问题的不必要的多分支开发;问题被发现的时间推迟;基于流程平台的沟通;常规的例行工作上花费的大量人工等。为减少浪费，DevOps团队做了很多工作。首先，持续交付的一个前提是持续集成;其次，将大量的工作通过自动化手段来实现;部署脚本，所有的变更都走同样地流程;所有的事情都要做版本控制。DevOps要求所有的人都要做主干开发。提高工作效率，自动化是一个很重要的手段。乔梁在演讲中也多次提到“自动化”这个特点，那么自动化是不是DevOps的一个前提呢?在回答51CTO记者这个问题的时候，乔梁表示，“DevOps本身第一Culture(文化)是最重要的，你得让所有人都参与进来，至于自动化，它只是一种手段一种工具，因为当你用传统交付的方法你的人力的消耗会很大，会对运维、测试等造成很大的压力，如果你不解决这个问题的话，那你测试和运维都不会同意的”。至于实现自动化脚本的手段，乔梁介绍百度是有自己的一套管理运维平台，其他企业可能会通过puppet之类的工具去做。在不同的环节都有不同的自动化工具可以选择。“你不用这些工具没关系，但是比如环境准备，还有应用度等等你必然要有一套自己的方式。”乔梁说。针对目前DevOps在国内外的发展情况，乔梁说，DevOps本身还是比较新的东西，国内外并没有很大的差距，“我觉得还是意识层面的差距。因为DevOps里面很多技术很多国内的公司也在用，但是他还是把我只把我自己运维的这一部分做了，他连不起来，大家还有隔离。”正如乔梁在一张演讲PPT中所写道的：“DevOps=Culture+Tools”，它是工作思路的转变辅以适当工具的结果，首要的还是文化转变——“包括我们之前提到的敏捷开发，基本上也是一种文化的变化，而不是一种工具的变化。”乔梁说。原文：“首先，持续交付的一个前提是持续集成。其次，将大量的工作通过自动化手段来实现。005《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:系统频道：架构师不可不知的十大可扩展架构对于大多数架构师而言，“可扩展性”在软件架构方面是最虚无缥缈的说法。这毫不奇怪，因为可扩展性正是如今软件设计领域最值得优先考虑的要素。然而，计算机科学家们还无法了解一套单独的架构如何才能扩展至各类应用环境当中。相反，我们在数量繁多的方案中所设计出的可扩展性架构，往往以业界较为通用的已知可扩展模式及个人偏好为标准。简单来讲，打造一套具备可扩展性的系统已经变得更像是一门艺术而不单单是技术。我们常常会通过观摩杰作体会并学习艺术的精髓，而可扩展性也应该遵循同样的路线！在这篇文章中，我将列出数款为大家所耳熟能详的可扩展性架构。通常情况下，架构师们完全可以借鉴已知的可扩展架构模式，进而创造出新的可扩展架构。LB(负载平衡器)+无共享单位该模型中包含一系列单元，各单元彼此间不共享任何内容，且一致指向一个将输入文讯按一定条件发往单元处的负载平衡器（这构成一个循环，以负载等情况为基础）。每个单元可以是一个单独的节点或是紧密耦合的节点所构成的集群。用户可以使用DNS轮询、硬件负载平衡器或者软件负载平衡器达成负载平衡效果。创建一套负载均衡的层次结构，并在其中结合前面提到的各种负载平衡器也是可行的。在由MichaelStonebraker撰写的《无共享体系架构实例》一文中，专门讨论了此类架构。LB+无状态节点+可扩展存储传统的三层式Web架构使用的就是这种模型。该模型包括数个与可扩展存储交互的无状态节点以及一个分布于节点间负载中的负载平衡器。在这一模型中，存储通常作为限制因素存在，但NoSQL存储则可以利用这套模型创建出具备相当可扩展性的系统。点对点架构(分布式哈希表(DHT)以及内容寻址网络(CAN))这套模型提供了一些传统的可扩展算法，这些算法的各个方面几乎全部按对数进行了等比例增加。举例来说，像Chord、Pastry（特指免费版）以及CAN都属于此类。而以Cassandra为代表的、基于P2P架构的几款NoSQL系统也是其中的成员。《展望P2P系统中的数据》一文就深入探讨了这类模型的各种细节。分布式队列这种模型以将队列实施（即先进先出交付机制）作为网络服务处理为基础。该模型通过JMS队列而广泛得到采用。一般会遵循这种做法的有任务队列以及通过保持队列分级体系实现扩展性的任务队列版本，后者在负载无法及时处理时，任务会由低级层面向高级层面传递。文/Srinath编译/核子可乐“每个单元可以是一个单独的节点或是紧密耦合的节点所构成的集群。用户可以使用DNS轮询、硬件负载平衡器或者软件负载平衡器达成负载平衡效果。”006《Linux运维趋势》投稿信箱:[e-mail]杂志订阅:系统频道：发布/订阅模式一般用于通过网络向彼此发布订阅讯息。《发布与订阅的多面性》这一经典论文中详细的介绍这一模型，该模型方面最典型的例子即NaradaBroker与EventJava。小道消息与自然灵感式模型这种模型源自日常生活中小道消息的传播途径，也就是每个节点将随机选择后续节点以交换信息。正如现实生活中的实际反馈，这种八卦型算法在信息传播方面出奇地迅速。该模型的另一大分支则是受到生物学影响的启发式算法。自然世界中存在着大量协调及扩展方面极为卓越的固有算法。举例来说，蚂蚁、人类以及蜜蜂等等，都能够以最简洁的交流方式协调好扩展性方面的需要。模型中的算法正是借鉴了这些实际存在的现象。在论文《从流行病的蔓延到分布式计算》中对这种模型有着详尽的叙述。地图缩小/数据流这一概念首先由谷歌公司提出，地图缩小为工作的描述及执行提供了一套可扩展的模式。虽然内容简单，但它仍然成为联机分析处理方面的首要处理模式。数据流则是一种更先进的方式，用来表达执行信息；而像Dryad及Pig这样的项目为数据流的执行提供了可扩展的框架。论文《地图缩小：大型集群上的简化数据处理》中设置了专门的主题，详细讨论这一内容。Apache的Hadoop就是这种模型的代表性产品。责任树形图这种模型打破了递归问题的束缚，将整个流程以树状形式加以处理；每个父节点将工作下放至子节点。这种模型扩展性强，并已经被应用于数款可扩展性架构当中。流处理这种模型被用于处理源源不