《架构师2014年7月：存储系统的那些事儿》—InfoQ中文站.pdf

2 卷首语 为什么会有DevOps ？ 前一阵子看到一篇文章，内容是一个开发者吐槽DevOps，吐槽大意是 说，你们这些运维们凭什么提倡让我们开发者做本来是你们应该做的维 护工作？事实上运维和DBA又无法做开发者能做的工作，但你们却让开 发者做本来应该是运维和DBA应该做的工作，这样岂不是对开发者很不 公平？ 当时我看了这篇文章后心想，DevOps 中的一部分的确是让开发做运维 的工作 （另一部分是让运维会开发），作者说DevOps让开发者被压上 了更多的担子，的确没错。但是还有一点作者没说，就是他笔下的那 些“很多除了维护系统之外其他事情都不会做的运维和DBA”，实际上要 面临更大更严重的挑战——失业。 作者觉得这事儿对开发者不公平，我倒觉得开发者已经是身在福中的一 批人了。 前两天一个朋友打电话过来，问我能不能介绍一些云计算运维做的比较 好的同学，想跟他们交流交流。他之前看到了Github那一套Hubot 的运 维工具，觉得很赞，未来云计算的运维就应该按照这种自动化机器人的 方式来做。我想了一下，忽然发现最近这两年自己接触的技术人当中， 关注运维的开发同学似乎越来越多了，而且也的确有越来越多的开发者 正在投入运维的工作当中去。 说到底，为什么会有DevOps这样的呼声出来呢？我感觉原因主要有两 点： 1、软件更新速度加快 （算是敏捷开发运动+互联网爆发式增长联合作用 下的一大成果。现在的时髦语叫做“唯快不破” ） 2、基于便宜的通用硬件+开源软件的集群系统越来越多、规模越来越大 （算是全球兴建云计算+全领域业务IT化的直接结果。云计算的口号 是“让普通人也用得起计算” ） 这两个都是不可避免的业务需求，我们的世界不可能再回到那种缓慢更 新软件、做什么都采购IOE那些昂贵机器的时代了。几乎所有人都不得 不面临“交付速度加快”和“系统趋于分布式、规模更大”这两件事。 而这两件事情的直接结果就是，我们很容易就把系统中的这里或那里搞 坏了。 3 运维的同学们呢，不得不去实现“快速部署的同时还不能把这个大系统 搞死”的目标。 事实上，每次软件更新，引入的bug往往比feature多；便宜的硬件本身 就容易坏，数量多了之后更加是天天坏。以前的很多系统，每一个环节 都是正常流程中的一部分：任何一个环节坏了，系统就跑不动了。如果 按照现在的部署频率，很难想象这套系统能活下来。 我们需要一套具备超强容错能力的系统：这个系统中任何一个部分甚至 几个部分坏掉了，系统还是能跑起来——可能服务质量会低一些，但不 要死。 换句话说，我们的计算机网络系统正在从“线性系统”成长为“复杂系 统” 。复杂系统是有生命的，能够在一定的阈值内维持自身的平衡。 这套复杂系统谁来实现呢？开发feature的同学们是不会care的，这不是 他们的领域。只懂得维护一台服务器和一个小集群的运维同学是做不到 的，因为他们不知道如何为一个死的系统注入生命。 这就是为什么会有DevOps，这就是为什么我们需要懂开发的同学们来 运维系统。 计算机网络系统就好像身体一样。身体是一个奇妙的系统，即使很多组 件不好用了或者坏掉了，身体仍然能够维持自身的机能运转。但是，如 果组件坏掉的太多，身体的性能就会严重下降 （大家应该都有那种生病 了躺在床上做啥都没力气的经验）；只有让身体里尽可能多的组件都运 转良好的情况下，整个机体才能够发挥最大的效能。 这也许就是DevOps运动的终极目标吧。 本期主编：杨赛 目录 卷首语 2 | 为什么会有DevOps ？ 人物 | People 6 | 郑晔谈Java开发：新工具、新框架、新思维 观点 | Opinion 4 10 | OWASP发布构建安全Web应用的十大控制措施 14 | 替代Objective-C ？Swift 尚不成熟 16 | 让我们再聊聊浏览器资源加载优化 专题 | Topic 39 | Apache Kafka ：下一代分布式消息系统 52 | SLIK ：高扩展、低延时的键值存储索引实现 （RAMCloud ） 62 | 存储系统的那些事 避开那些坑 | Void 68 | J.P.摩根运用LeSS框架实施大规模敏捷 76 | Node.js异步处理CPU密集型任务的新思路 82 | 分布式存储系统的雪崩效应 特别专栏 | Column 88 | 腾讯云的弹性、高可用与隔离 90 | AWS S3产品总监谈存储 94 | 搜狐云景Container