云计算2009年仍然延续了它在2008年的热度，不难预料，运行在云上的应用(以下简称云应用)肯定会越来越多，随之而来的是，肯定会有越来越多的开发人员不得不考虑或者参与云应用的开发。

    云计算的本质是通过互联网访问应用和服务，这些应用或者服务通常不是运行在自己的服务器上而是由第三方提供。对云的开发者而言，在云计算模式下，尽管部署应用时无需关心基础设施方面的问题，但同时也带来了一些新的问题，比如开发员不能用以前熟悉的方式调用数据库、应用程序呈无状态特性以及必须采用不同的开发框架等。

    无状态应用和服务器宕机

    “开发云应用最大的挑战是，软件必须能根据应用的需求自己调整和提供所需要的资源。”Sun云计算部门CTO Lew Tucker说，幸运的是，借助云平台提供的API，云应用的开发人员可以从云的提供方申请更多的资源。

    开发人员还必须进行冗余设计，要认识到很有可能在“云”中的服务器只是普通的服务器，微软Azure云平台副总裁Amitabh Srivistava说，“很有可能服务器会出问题，因此，你必须在开发云应用时考虑冗余。”

    开发云应用时还必须考虑到Web应用的无状态特性(无状态性是指客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前请求，而不必了解所有的请求历史—编者注)，Srivistava说，“如果你的程序要求保留状态信息，程序在运行过程中肯定会出问题。云计算的模式是，如果什么地方出了问题就终止它，然后另外再启动一个程序。只有保证每个应用程序的运行都是相对独立的，也就是状态无关，才能达到这一目标。”

    Srivistava进一步解释说，例如，在云中没有本地磁盘这个概念，也没有注册，在无状态的应用中，这些参数都要被封装起来打包在调用的参数中。

    Sun公司Tucker提醒说：“无状态保证了应用程序简单，但是，要开发出真正有趣而且好用的应用又需要一些状态信息，比如我们必须保存用户的信息以免要求用户不停地登录，这就是为什么我们仍然需要数据库或者其他一些什么东西来保存状态的原因。”但是，有部分云上的应用(如Web的前端)需要根据访问量动态地进行调节，必须是无状态的。

    云应用的另外一个特点是：应用程序的不同部分可能分别运行在云的不同地方。例如，一个应用程序的表现层可能运行在Facebook，而其存储部分可能运行在亚马逊的弹性存储服务(S3)上，其应用程序的逻辑部分又可能运行在另外一个完全不同的地方。

    “而以前程序员开发的程序都运行在自己的服务器上。” Tucker说，“这就意味着，开发云应用时必须重新考虑系统的架构，特别是要考虑云应用的大规模特性，不仅是用户数量大，而且计算资源分布也很分散。”

    Tucker补充说：“也不要把云应用想得多么神秘。其实没有什么诀窍，要开发可扩展的云应用，需要仔细地设计和规划。”

    不过，云平台可以给我们提供一些帮助。在某些情况下，比如使用Google App Engine来开发某些特定的应用时，程序自然就具有了可扩展性，无需开发人员考虑。有时候，我们可以使用某些设计模式，这些设计模式可以用来为应用程序提供扩展能力。例如，亚马逊弹性计算云(EC2)的Multiple Availability Zones，开发人员在这里可以把一个应用部署到多个地方运行。

    “以前，只有大公司能做到这一点。” Kay Kinton公司的发言人说。EC2有一种称为弹性IP的功能，它能快速建立一个互联网地址的映射，把准备发送给失败的应用实例的请求转给一个有效的实例。

    不同类型的数据库

    在云应用中，抽象和无状态在对数据库的访问时也同样适用。“例如，Azure就给程序员开发人员提供了一种与访问标准的关系型数据库完全不同的方式。”Benjamin Day咨询公司总裁Ben Day说，“Azure的存储引擎也没有使用关系数据库，因此以前开发应用时所采用的很多方法在开发云应用时就行不通了。”

    他还以关系型数据库中的存储过程为例来说明，在关系型数据库中，查询逻辑与实际的数据位置很近，编程者可以明确知道数据在哪里、保存在哪些设备上，而在Azure云中，这个前提不再存在。

    “云应用在访问数据库时的困难在于，无法保证你要读取的数据库在某一指定的位置或者数据中心或者某一指定的设备上，”Day说，“因此，最终你只能使用最基本的SQL查询语句，而很多存储过程由于与数据库的具体类型密切相关而不能使用。”

    另外，Day补充说，Azure的存储引擎也与微软规划中的SQL Server的云版本SQL数据服务(SQL Data Services)有很大区别，因此，开发人员需要了解自己到底是在使用哪个数据库引擎。例如，Azure把一个1MB的文件作为一个Blob类型的数据保存，而SQL Server中会把这个文件保存在一张表(table)中。

    开发云应用与普通应用在访问数据库时有明显区别的并不仅仅只有Azure，使用Google App Engine时也有同样的问题。

    Google的App Engine产品经理Pete Koomen介绍说：“Google App Engine不仅对实际的物理硬件进行了抽象，而且对关于设备的所有概念都进行了抽象。”这保证了开发人员把代码上传到Google以后，Google可以把这些代码和数据库分开管理。“因为Google把其中的很多流程都实现了自动化，因此，开发人员必须遵循一定的规则，这些规则与我们以前在传统的SQL模式下的规则有很大区别。”

    在使用App Engine时，开发人员把那些要长期保存的数据存储在Google的大表(Big Talbe)。“大表不是SQL数据库。我们之所以使用大表而不用SQL数据库，原因在于SQL数据库要支持很多功能(例如Join功能),这使得我们要把一个数据库放到多台服务器上运行非常困难。”

    “在使用我们的系统开发云应用时，我们会提供一个编程模型，并从一开始就鼓励程序员们采用一些反常规的方式，比如，开发人员会在一次存储过程中把数据分散保存在多个位置。”他说，这样做的好处是保证应用程序在执行查询时效率非常高。

    Koomen对在云环境中使用关系型数据库持反对态度。他说:“我们发现在访问量很大的情况下，关系型数据库非常难于管理，为了解决高访问量带来的一系列问题，程序员不得不投入大量的时间和精力。”

    必须习惯于变化

    咨询公司Model Metrics曾帮助客户在Salesforce.com和其他一些平台上部署了云应用。它们发现云应用开发和B/S应用开发的一个主要区别是，“云上的应用改变要快得多。” Model Metrics的CTO John Barnes说，“例如，Salesforce.com一年要出好几次新的版本，每个新版本中很可能都会有值得一用的新功能和新特性。”

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。