谁来拯救云计算.doc

谁来拯救云计算 云计算的技术路线探讨 by 康华 引言 当前的“云计算”一词已经被神话，似乎快成了放之四海皆准的时髦真理，就好比当初言必称“希腊”一般，表面光芒四射，但实际上却无比教条、且越来越令人生厌。 作为“云计算”的一个普通开发者和是推广者，很有必要通过亲身实践，以正视听，希望能让后来者（云计算系统的开发者）少走弯路——有所为、有所不为。 前言 我们所要谈论的不是商业领袖们所热衷的云计算概念、云计算市场，而是讨论技术人员眼中云计算具体形态和切实的实现办法。 我们将从需求分析入手、进而讨论设计理念、再具体化到子系统设计和实现中存在的难点问题、最后谈谈云计算对外服务的技术选择。 其中有些观点属于业界共识，也不少属于个人看法——难免有所偏颇——真诚欢迎从事云计算开发的朋友积极讨论和批评。 本文试图回答这么几么几问题： 技术人员理想的云计算是什么。 理想和现实的鸿沟是什么。 云计算到底需要什么样的基础架构。 云计算基础架构可能的组成部分。 虚拟机和App engine等云计算的关系。 强调一下——本文仅以开发人员视角出发！以大中型互联网公司、海量数据、多业务线运维为背景，围绕后台基础架构进行分析讨论。 另外借此机会王婆卖瓜式的推荐一下我个人发起的开源云计算相关的小项目：/p/cloudxy/。 我们到底要什么云 现在的麻烦 谈理想之前先回顾当前现实中RD（开发人员）和OP（运维人员）的工作场景。作为一个”过来人”，分析一下RD和OP在开发、测试、部署一个新应用时不得不做的那些麻烦事吧。 开发阶段面对的麻烦： 可用性问题 —— 互联网应用作为在线服务都希望能用永远在线；而从成本考虑，规模使用廉价PC SERVER、廉价硬盘、廉价路由器等必然有会出现相对较高的故障率，甚至可以说故障是常态，因此从应用设计上必须考虑故障切换，而且最好是自动透明的故障切换。 负载均衡问题 —— 无论存储集群或者是应用服务集群等都可能出现负载不均匀情况。同一集群中因种种原因总是会有热点（因为访问压力大而造成的或磁盘空间不够、或内存不足、或cpu负载太高、或网络带宽不足）出现，当热点出现时，就需要将热点的访问流量分流到比较冷的服务器上去。总之希望集群中的服务器冷热均匀，服务才能稳定、高效。 扩容缩容 —— 当你的应用用户越来越多时，就要有扩容要求（集群中补充新机器），扩容时最好能不停或者少停服务。 上面这些问题，其实是分布系统的普遍共性问题，解决办法无非是采用supervisor、主从热备、smart client、状态报告、一致性哈希、数据分区等等技术，兵来降挡，水来土掩的case by case的解决。 作为一个在线应用RD，很可能在处理上述问题花的功夫，比自己应用逻辑本身的还要多不少，这显然是一个不小的负担。 测试阶段面临的麻烦 测试首先在于搭建环境和系统部署。这点说起来简单，其实现实操作中可够你折腾一阵了。因为你不得不做： 抢到足够多的机器 —— 你很可能要排队、要求人、总之要费点点功夫。 搭建存储服务 —— 应用开发人员对存储系统各种配置参数和部署方式的理解和摸索过程，绝对是一个常犯错误，窝工活。 这个过程对很多RD和测试人员来说，绝对比写代码要费时费力。沟通成本（公司大了，很多沟通都是跨部门的）不容小视呀。 部署的麻烦 容量规划 ——个应用上线前肯定需要根据经验（或者拍脑袋）估算出未来一段时间内系统面临的负载。估算少了，肯定要面临扩容的风险，这无疑是自搬起石头砸自己脚。再加上一些好大喜功的人类天性，应用负责人肯定会满打满算的推算出最大可能的机器规模。 申请机器，搭建集群—— 申请机器意味着报计划、等审批、等机器、走麻烦的流程（这很多都是经理的事啦）。搭建集群则是RD和OP一起携手完成（RD出上线步骤等，OP 实施），这个过程要小心谨慎，需要不止一个人反复检查（差劲点的应用会是实例配置不统一，每个实例的配置都有所区别），还常常需要RD陪同实施，总之绝对是个体力活。 备机准备 —— 很多应用为了防止意外机器应硬件故障（硬盘、主板、网卡、电源等坏了）下，能快速进行故障恢复，还会搞一些备机，以防万一。这些机器纯粹是养兵千日用兵一时。 任何一个自认为重要的应用都希望自己单独占领一个集群，如果和别人混合部署，害怕资源征用，自己被拖累。鉴于此原因一个应用往往就意味者需要搭建1个以上集群（很可能存储、或者其他服务都要单独搭建一个集群为其使用）。应用RD人员还好说，为自己应用搭建一次就OK了、存储等基础服务RD就要多搭建几次，受点累了；而OP就更辛苦了，要不断重复这些体力劳动。 容量规划和备机准备多多少少会带来物理资源的闲置，容量规划意味着预先准备未来一定时期内都足以应付请求压力的足够机器，那也就是说初期用户规模还没上来前，