"云"领天下（一）： 最近的云计算 - IaaS

前言

作为云计算的推崇者，我一直关注关于云计算的问题，从Iaas的技术实现到PaaS的迁移实践甚至SaaS的运营模式。不过因为个人的技术和见识都很有限，我更关注于作为应用程序提供者，该怎样设计一个对云计算友好的应用程序，这种应用程序不单可以在云计算平台上运行，更重要的是可以更好的享受云计算带来的优势。趁着微软主推Azure云计算的TechEd2010落幕不久，我将写四篇文章和大家分享一下关于云计算中一些问题的看法。这四篇文章分别为

• 《“云”领天下（一）： 最近的云计算-IaaS》
• 《“云”领天下（二）： 更远一点的云计算-PaaS》
• 《“云”领天下（三）： 云上的数据-反规范化》
• 《“云”领天下（四）： 云上的事务-BASE原则》

希望这些文章在您考虑向云计算迁移或基于云平台开发新的应用程序时有所参考。当然，我在这些文章不会用某一指定的开发语言来做完整示例——虽然我很喜欢C#——所以，所有的代码示例都是不保证运行的，请谅解。

 

IaaS

 

 

我们从一个故事说起，假设有这样一个软件公司，他的业务就是运营一个大的网站，因为公司经营这个领域的时间比较久了，网络管理员很清楚每年的四月份访问量会比平时大好几倍，一个月之后又会恢复正常。

 

几年前，公司按照当时用户在四月份的访问量峰值搭建了一套服务器环境，这是一个比较完整的数据中心，包含一台硬件负载均衡机器，四台应用服务器，一台数据库服务器和一个备份服务器。起初这看似是一个比较好的解决方案，除了在刚刚上线的时候因为负载均衡动态切换服务器导致会话状态不正常起效让开发团队发了若干个补丁。然而，一年又一年过去了，用户的需求，网站的范围越来越大，对计算量的要求也在逐渐加大，直到某一年的四月份用户访问峰值到来时，已经运行几年的数据中心开始力不从心，用户访问速度的下降甚至超时报错；加上随着服务器硬件的老化，几次出现的服务器网卡损坏，硬盘损坏等险情，现有数据中心的老迈终于引起了公司的重视。

 

系统管理员会同开发团队受命解决这个已经开始影响公司盈利水平的关键问题。根据对日志和监控数据的分析，性能的瓶颈出现在了数据库服务器上——相信多数应用都是这样的。在开发团队看来问题似乎并不难解决，更换数据库服务器的硬件，换更大的内存，更强悍的CPU和更快速硬盘组成的磁盘阵列就可以一举解决这个问题。不过这个方案在提交后得到的却是两个质疑，分别来自系统管理员和管理者。问题1： 如何可以快速，安全的将数据迁移到新的服务器？这次服务器告急执行了升级数据库服务器硬件的操作，下次再出现性能缺口，是不是还得重复一次迁移？问题2：除了访问高峰期的四月份，其他时候用户的请求靠现在的服务器性能完全可以得到满足，这种情况下升级服务器的硬件是不是一种资源的浪费？对于第一个问题，他们的疑问是无法快速的增加服务器的计算能力；对于第二个问题，他们的希望是能快速的通过减少服务器的计算能力来降低运行成本。

 

在传统的数据中心中，公司遇到的两个问题目前看是无解的，直到有一个概念随着高性能计算机集群技术和虚拟机技术的发展开始走进我们的视野——基础设施即服务（IaaS）。在IaaS中，服务提供商把硬件计算资源，网络，冗余，负载均衡等等设施打包成服务，我们可以直接购买这样的服务，而不需要自己去组建负载均衡来平衡用户请求的压力，不需要自己建立冗余服务器来保证无故障运行时间。更重要的是，这种服务可以按照自己的需要随时增加购买量，相比于自己更换服务器，简单到几乎修改配置后即时起效。更重要的是，在你的应用不需要那么高计算能力的时候，你“竟然”可以减少服务的购买量来节约成本。这个在自己搭建的数据中心方案里是不可能做到的，因为我们都知道如果卖掉一台服务器收回来的钱可能只有采购费用的一半多一点了。

 

值得庆幸的是当更新数据库服务器硬件的方案被无情的否决后，公司的开发团队和系统管理员发现了IaaS，于是他们展开了相关的评估。他们的评估结果是比较乐观的，因为在本次升级之前，开发团队已经为负载均衡机实现了状态转移等功能（如将ASP.Net的Session从默认的In-Proc切换为Sql Server，严格控制使用静态变量等），从现有的数据中心迁移到云端的IaaS没有技术难点，直接迁移时可以运行的。而对于管理层来说，仅仅“可以运行”是不够的，像所有的企业一样，最终决策的依据往往来自于商业的收益而不是技术。从云计算提供商（比如IIJ的GIO）获得的“单价”（购买一段时间的CPU，内存，磁盘空间和网络带宽等的费用）还是比较诱人的，剩下的问题就是 “我们需要买多少服务？”。被各种虚假广告已经产生了强大免疫力的开发团队选择不相信云计算提供商的技术参数，而使用实验的方式去计算每个计算单元的真实承载能力。当然，对于在国外“诚信社会”长大的管理层，这个方案又以浪费资源的理由无情的否决了。在往后就剩下来纯商务的谈判，这个过程中一系列参数将被确定下来，比如无故障运行时间，扩/减容（增加/减少计算能力）的响应时间等等。与此同时，开发团队将包含有测试用数据的网站架设在了IaaS平台开始进行测试。剩下的工作就只剩下找一个合适的时间，暂停网站服务并正式迁移到IaaS云计算平台了。

 

到此，故事讲完了，我们可以在这里小小总结一下。对于计算量需求随时间变化的应用系统而言，IaaS可以有效地处理服务器性能的扩展与紧缩，更方便的随着业务计算量的变化而改变服务器的计算能力，在提供优秀用户体验的同时降低运营成本。更关键的一点是，对于一个本身支持多点部署的应用系统而言，迁移到IaaS可以说不需要修改任何的代码，这无疑是开发人员的福音。

 

软件界有句名言“没有银弹”。诚然IaaS有着这么美妙的样子，但是不是说IaaS就拥有了“舍我其谁”的气势呢？答案当然是否定的，至少在管理层看来。在基础设施即服务之外，云计算还有一种形式的服务：平台即服务（PaaS），对于管理层而言，PaaS有着一样更诱人的特点，那就是价格更加低廉——这足以成为PaaS相对于IaaS的最大优势，虽然从传统数据中心迁移到PaaS的过程可能会让开发团队经历一场炼狱，虽然基于PaaS开发一套应用系统需要打掉开发团队心中“理所当然”的原则。那么，这个对管理者是“灵丹妙药”对开发者是“第一只螃蟹”的PaaS是什么呢，将传统的应用网站迁往PaaS需要做哪些事情呢？请期待本系列文章的下期《更远一点的云计算——PaaS》。