拨云见日
2011-07-22
知道这本书很偶然，是在豆瓣上看到的。看了书评，觉得挺好，又发现原来我曾经和书中的一位作者打过交道，于是更想拿来读一读了。读这本书带给我许多的“没想到”：我从来也没有想到过有那么一天，我会买一本中国移动的人写的书来看；拿到这本书的时候，我也没有想到这本书写的这么好；在读完全书，忽然灵机一闪，想到网上搜索一下作者的时候，我没想到作者曾经做过爱立信的项目经理和市场经理。一本能够让人期待，并且带给人意外惊喜的书，无论如何都应该算是一本好书。
经常会在工作中和移动的人打交道，当然，也包括研究院的人。可能是因为公事公办的缘故，工作中的研究院人留给我的印象，是聪明，反应快。这本书，让我看到了他们幽默，好学和渊博的另一面。
书中对于云计算“前世今生”的描写非常形象。虽然我也从两年前就开始“云”，但感觉读完全书，自己才开始真正了解了云计算的皮毛。以前的知识，不过盲人摸象而已。
首先，为啥云？是因为：1. Web2.0的时代，每个人都是互联网信息的提供者。人们通过各种各样的工具制造着海量的信息。2. 摩尔定律到达极限。再想每18个月翻一番很难了。于是，1和2的矛盾催生了新需求：如何利用现有的硬件能力来处理海量的信息？新需求催成了天才们的新创意：一朵云飘了过来。
其次，怎么云？在这一部分，有很多听上去很专业的名词，什么Xaas，虚拟化之类的。但是归根结底，我认为还是需要解决我琢磨了很久的两大问题：分解和聚合。最开始的时候，我理解云计算能做两件事：资源的聚合和分解。所谓聚合，是能够把很多小的、旧的机器整合起来，让人看着就好像是一台超级大机器，提供超强的计算和存储能力。所谓分解，是能够将一台比较强劲的物理的大机器分解成很多小的虚拟机，提供给不同的应用系统。在和VMWare、EMC交流的时候，我不停地求证这个问题，得到的结论都是否定的：分解是可以的，但是聚合不行。
看了这本书，我明白了：其实聚合是可行的。只不过聚合是比分解更进一步的技术。分解可以通过虚拟化的手段来实现，而聚合则需要通过编程的方式来解决。即：通过各种技术手段将计算、存储等任务分解。例如，对于计算密集型应用，需要通过MapReduce的编程模式，将超大的计算任务分解为小机器能够完成的小任务，进行并行计算得出结果。从这个角度说，“云计算是一种多粒度和变粒度计算”。书中还介绍了一个名叫“友友创新”的公司，能够提供整合计算资源的方案。
总结起来，如果物理机器很强大，那么就通过虚拟化的技术把物理机器分解掉。如果计算任务很繁重，那么就通过MapReduce等编程模式把计算任务分解掉。
这时候，我反思了一下当时我们的云计算方案：我们的方案其实是构建在虚拟化平台基础之上的。说白了，如果虚拟化平台做得好，我们其实不需要改变任何东西。直接将应用软件安装在虚拟化平台上就好了。再买一个虚拟化厂商提供的资源调度工具，测试、设定一下满足什么触发条件的时候，对虚拟机进行调度和分配。在国外展览的方案其实也就是基于这个思路。这其实只是云计算一个最表层的应用。甚至都不应该叫云计算，应该叫“虚拟化”就好了。
最后，云不云。首先说明一下，关于云不云的问题，我们只能够做自己的主，类似“我是不是喝从自来水管里面出来的水呢？”。我的答案是：先不云。
虽然我坚信云计算最后的结果，就会象是接入每家每户的自来水龙头一样，大家能够按需取用，按用量付费。但是就目前的发展看，云计算在推广和普及的路上，还有很长的路要走：
1. 一旦用户采用了云计算，就把自己数据访问和控制的主动权交给了云计算运营商。比如，当Google Doc不可访问的时候，我们怎样处理文档？
2. 数据安全性值得担忧：云计算运营商能够生存多久？怎样保证数据安全？在这个修个笔记本都能产生爆炸性新闻的时代，数据的安全不得不考虑。
3. 基础设施建设（例如互联网带宽）会直接地影响使用体验。
当然，长远地看，这些都不是问题。就像是我们每天都在喝自来水，而从来没有担心过自来水公司能够生存多久、水管里的水有没有毒一样。但是对于云计算，这些都需要时间。
总的来说，我觉得这是一本挺好的书。尤其是书中很多实例的描写，让人们觉得“云”并不神秘，离自己很近。比那些上来就说“资源共享”、“弹性扩容”什么的强多了。
查字典图书网
