云存储“有效”应用实例和云存储“有效”应用平台——2009-1-15 CTO俱乐部第一次聚会“云计算”后记

本文为博主（@胡争辉）原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/hu_zhenghui/article/details/3832075

云存储“有效”应用实例和云存储“有效”应用平台——2009-1-15 CTO俱乐部第一次聚会“云计算”后记

　　CTO俱乐部第一次聚会的主题是“云计算”，有幸认识了北京美地森科技创始人游峰先生，聆听游峰先生关于云存储方面进展的介绍。关于聚会的概述发表在：
　　2009-1-15 CTO俱乐部第一次聚会，http://blog.csdn.net/hu_zhenghui/archive/2009/01/16/3793180.aspx
　　其中关于云存储的讨论，有幸受到游峰先生的关注，因此我就该话题展开讨论，发表在：
　　云存储“有效”应用和云存储“无效”应用——2009-1-15 CTO俱乐部第一次聚会“云计算”后记，http://blog.csdn.net/hu_zhenghui/archive/2009/01/17/3808511.aspx
　　游峰先生又进一步指导我参考Google相关资料，就此问题，我继续展开说明我的观点，请各位前辈和专家斧正。
　　由于工作关系，我对于云存储的关注在于其在虚拟主机业务上的运用。经过和游峰先生指导我参考的相关资料对比后，我发现区别在于“应用”这个概念在上下文语境中的含义不尽相同，因此在本文中，我首先将“应用”这个概念分成两种情况，其一是“应用实例”，其二是“应用平台”。
　　应用实例这个概念对比应用程序实例，就可以很方便的理解了，一个应用程序在运行之前，只是一段脚本代码或二进制代码。只有在运行时，才能称之为实例。一个应用程序运行多次就可以产生多个实例。本文所使用的应用实例就是指类似于应用程序实例的一个具有云计算特征的应用实例。
　　应用平台这个概念对比于应用程序运行时平台，也可以很方便的理解了，一个应用程序运行时平台用于运行应用程序，每次运行应用程序都是增加一个运行于这个应用程序运行时平台的应用程序实例，本文下面所使用的应用平台就是指类似于应用程序运行时平台的一个能运行具有云计算特征的应用实例的平台。自然这个平台也应当具有云计算特征，也是一个应用实例，本文下面所使用的应用实例特指应用平台之外的应用实例。
　　从应用实例的角度看，邮件存储应用（包括POP3、IMAP或者其他借助于HTTP等通讯协议实现类似于IMAP的协议）和UGC应用（用户创造内容，包括文本、图片、视频和文件等）都可以在特定需求的情况下，使用云存储。而从应用平台的角度看，BigTable（例如Google的BigTable实现）可以使用云存储，而且能运行多种实例，但是这些实例仅能使用BigTable所提供的功能。
　　下面结合我目前工作中的虚拟主机业务解释一下我对于云存储“有效”应用平台的观点。虚拟主机业务是典型的平台，具有应用无关的特性。如果使用云存储应用于虚拟主机的无限扩容，需要依据虚拟主机的特性来逐项考察使用云存储的可能性。
　　首先是数据库，对于虚拟主机业务来说，如果提供数据库的话，则有两种情况，一种是使用文件型存储的关系型数据库，例如ACCESS或SQLite，使用云存储可以满足无限扩容的特性，但是需要考虑频繁读写的性能问题（没有实际测算过）。第二种是使用网络访问的关系型数据库，在虚拟主机业务中经常使用的是 SQL Server和MySQL，从这两个数据库的特性来看，虽然数据库的文件都是分实例单独存储的（MySQL在使用innoDB引擎时，默引情况下不分实例单独存储），但是在服务器间迁移数据库也需要借助于数据库本身的功能，不能直接移动数据库文件迁移数据库，也就不能直接使用云存储实现无限扩容。
　　其次是动态网页空间，对于虚拟主机业务来说，动态网页空间依据具体技术的不同，可能是ASP，PHP，JAVA，ASP.NET等等。可以按照运行环境分成两类，一类是以ASP和PHP为代表的脚本容器，另一类是以JAVA和ASP.NET为代表的应用程序容器。由于应用程序容器本身会维护大量的状态，因此在服务器间迁移实例时需要借助应用程序容器本身的功能，不能直接移动应用程序源代码迁移应用程序实例，也就不能直接使用云存储实现无限扩容。接下来考察脚本容器，由于脚本容器是无状态的，所以可以直接移动源代码迁移应用程序实例，也就可以直接使用云存储实现无限扩容，但是在实际应用环境中，还需要进一步考察细节。首先是动态网页空间需要允许脚本写入，写入以两种情况为主，一种是上传文件（例如UGC中的照片或者附件），这种情况是一次写入，多次读取，可以将云存储配置为读优化来提升性能。另一种情况是数据库的文件缓存，读写频繁，而且由于虚拟空间的应用无关特性，并不能对这些文件的存储进行约定，因此需要实际测算性能问题。脚本容器另一个需要考察的细节是第三方扩展，由于脚本本身的功能有限，很多功能需要通过第三方扩展实现（例如ASP空间的动易组件），这些第三方扩展运行于脚本容器中，因此并不会随着一个脚本执行结束而结束，所以常常会保存状态，如果借助云存储实现无限扩容，也需要考察第三方扩展中保存的状态是否有影响。
　　再次是网络路由。由于虚拟主机通过访问的DNS域名来区分具体的实例。因此在服务器间迁移时，也需要考虑到域名指向，如果服务器直接是互联网IP的话，那么依赖于访问位置的不同，修改域名指向后，所有访问位置更新DNS记录会有二小时到二十四小时不等的延迟，而且这个延迟并不是同时更新的，在修改记录后的一段时间里，会出现不同访问位置解析出不同IP的情况，因此如果服务器直接使用互联网IP的话，原服务器需要在这段时间内将访问代理到新服务器。即便如此，也需要考虑域名指向的修改策略，由于无限扩容是虚拟主机的特性，因此修改域名指向也应当是自动的，不应当由用户手动修改，所以可以借助将域名的CNAME记录重定向到虚拟主机为该应用提供的域名上，然后通过修改该域名实现，但是进一步分析会发现，注册商不为顶级域名提供CNAME记录，仅提供A记录，而目前A记录仅支持IPv4。通过以上分析可知，在实现无限扩容时，服务器不能直接使用互联网IP，而应当通过一个网关按域名代理到相应的服务器上。虽然网络路由与云存储并不直接相关，但也是借助云存储进行无限扩容时需要考虑的因素之一。
　　最后需要特别说明两点：
　　一，本文探讨的虚拟主机和具体业务关系密切。纯静态页面的虚拟主机完全可以使用云存储进行无限扩容，但是在实际业务中，比例较低。
　　二，本文探讨的“有效”是指使用云存储直接实现无限扩容，一些情况不能直接使用云存储无限扩容，但是通过附加额外的处理可以实现。