“云计算”不等于“托管2.0”

2010-04-28 14:38:26

云计算我们要架构云应用程序，但不能让它变成空中楼阁。如果你采用“托管 2.0”的方式处理云计算，就会造成很严重的后果，不信请看：

我们要架构云应用程序，但不能让它变成空中楼阁。如果你采用“托管 2.0”的方式处理云计算，就会造成很严重的后果，不信请看下文分析。　　

HyperStratus咨询公司最近处理了几个相似的案例：企业部署在亚马逊云计算基础上的应用出现了一些问题。

问题一：应用程序能够安装于各系统分类总列表中，并且运行良好，但是如果亚马逊的弹性云(Elastic Compute Cloud，EC2)实例崩溃或是需要中止程序，该应用程序就会停止运行，直到新版的实例投入运行后才恢复。

问题二：在EC2实例超载的情况下，不能通过添加更多资源来改善应用程序的性能。

问题三：目前只有在完全脱机的状态下才能够对应用程序进行升级。

问题四：性能会在数据库方面遇到瓶颈，但不能通过任何便于管理的方式进行数据库的复制。

云计算安装过程中可能遇到的问题

在与这些客户沟通的过程中，HyperStratus遇到了一个相同的问题：“云计算具有灵活性、可用性。可扩展性等优势，怎么就解决不了这个问题？为什么应用程序会出现这么多问题？”

问题的根源在于，他们把云计算当做了“托管2.0”，因此吃到了苦头。

简单的说，云计算的扩展性与应用程序的扩展性是不同的，除非你架构了云应用程序，否则不可能享有云计算所带来的好处。HyperStratus的观点是“要构建云应用程序，但不能让程序成为空中楼阁。”

那么“构建云应用程序”究竟是什么意思，云与托管2.0究竟有什么不同？从下面这些架构云应用的关键原则中获悉可以找到答案。

要知道到个人计算资源发生什么事情都是可能的。在亚马逊的云计算中，某一个EC2实例偶尔会出现性能不佳、停止响应甚至崩溃。资源也会出现一定规模的故障。所有云供应商都面临着这个问题。Google因为它们超低成本的服务器理论而出名，在主板上直接连硬盘驱动器，并且没有金属外壳(Google的机器可以称之为裸身机器)；当一台机器当机了，Google将其迁移到另外一台机器上，并且再次做一个备份。因为有着成千上万台服务器在运行，失败是在所难免得，所以google的架构的解决方案时直面失败，在失败的时候以更强劲的资源应对。同样的，应当把个人应用程序运行在云环境中，因为个人的电脑资源更容易出现问题。所以应用程序必须能够实现在两个以上EC2实例中运行。

应用程序能够在两个以上EC2实例中运行，因此就存在一些潜在的危险。应用程序可能在多个虚拟机之间进行替换，或是设置在两台计算机都能够进入的共享区域。这不是说每个应用程序必须被分隔在它们自带的实例中，单一的EC2实例可以支持多个应用程序；比如说，在一个单一的实例下可以运行多个不同网站。这确实意味着每个应用程序必须经过编写才能跨越多个实例。

应用程序要根据云计算环境针对性编写。这既意味着类同性会话将通过应用程序之前的负载均衡器进行管理，也意味着该应用程序将其自身的会话信息保留在一个共享区域内。这一点可以通过将会话信息保留在由应用程序服务器共享的元数据服务器内来实现，尽管最终这种方法可能会在装载元数据服务器的过程中遭遇瓶颈。最普遍的解决方法就是将会话信息转移到性能更加完备的会话分层处理器中。无论如何，会话信息必须要以某种方式满足应用程序所需要的每个部分。

要确保计算资源具有可扩展性。用户选择使用云的一个主要原因是，它能够使应用程序动态获取他们想要的资源，根据装载情况改变资源数量。如果需要人为干扰来增加或减少资源，障碍物就会从计算资源转化至人类资源，这其实并不是理想状态。如果不编写应用程序，资源等级就不能进行动态变化，这时操作员就必须要指派一个固定的资源等级；最终又会回到原有状态，在实用性和投资之间反复权衡，也就是说，我应该牺牲掉经济利益还是失掉一部分客户群？

这些并不是想要阻止人们向“云应用程序”迈进的脚步。编写应用程序以实现其无需人类介入状态下的动态缩放并不是微不足道的小事。首先，大多数软件组件都会假定有人工操作，而不是自动的，你对它进行管理，随后出现一种“升级配置文件并重新启动服务器”的解决方案。这十分适合那些极端静态的应用程序拓扑结构，但却是动态转换应用程序拓扑结构的噩梦。

另一个问题就是需要决定如何处理一个应用程序中多版本复制所共享的文档和物体。它们可以放置在网页文件系统中，但是性能仍然是个大问题。对于在功能上支持SAN或是NAS的云环境而言，文件可以定位在中心区域，尽管这可能会强制增加一些潜在的危险。文档的复制版可以放在每个服务器内，尽管这可能会在分配和版本控制方面遇到一些挑战。最佳的方案就是将所有的文档全部放置在中心区域内(比如说，放在以Amazon为载体的应用程序S3中)，并在所有虚拟计算机内下载“官方”文件，让它们在实例化的过程中自行完成安装。这也有点超出常规，一些非动态环境很少会用到这样的操作。在大多数环境下的常见方案就是将重点放在硬件(和虚拟计算机)的加固上，并没有针对动态应用程序拓扑结构制定什么计划。

目前还没有确切的数字可以表明到底会有百分之几的应用程序需要进行动态拓扑结构的装载。所以并不是每个应用程序都需要升级成“云应用程序”。从另一个角度来说，通常很难预测在一个应用程序的整个使用周期内会进行哪些负载。由于将来应用程序可能会遇到越来越多不可预测的负载和古怪的负载模式，最终设计模式与编写动态应用程序相结合很有可能会成为一种常规做法——换句话说，每一种应用程序都要经过编写，这样在高度动态负载的情况下才会保持稳定。对于那些包含这些负载形式的应用程序而言，它们已经准备投入到使用中去了；而对于那些不包含这些负载形式的应用程序来说，这种性能仍然会存储备用、保持在未开启状态，并在最终需要的时刻派上用场。

对于架构师和软件工程师们来说，学会当前的设计模式是非常重要的，因为当前经过设计和编写的应用程序会在几年内派上用场，而且最终很有可能会在云环境内运行。这就意味着应用程序编写时应该照顾到“云应用程序”，即使目前并不需要在云环境内进行操作。

【编辑推荐】