构建云应用程序 避免建成“空中楼阁”

因为有着成千上万台服务器在运行，失败是在所难免得，所以google的架构的解决方案时直面失败，在失败的时候以更强劲的资源应对。同样的，应当把个人应用程序运行在云环境中，因为个人的电脑资源更容易出现问题。所以应用程序必须能够实现在两个以上EC2实例中运行。

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

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

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

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

另一个问题就是需要决定如何处理一个应用程序中多版本复制所共享的文档和物体。它们可以放置在网页文件系统中，但是性能仍然是个大问题。对于在功能上支持SAN或是NAS的云环境而言，文件可以定位在中心区域，尽管这可能会强制增加一些潜在的危险。

文档的复制版可以放在每个服务器内，尽管这可能会在分配和版本控制方面遇到一些挑战。最佳的方案就是将所有的文档全部放置在中心区域内(比如说，放在以Amazon为载体的应用程序S3中)，并在所有虚拟计算机内下载“官方”文件，让它们在实例化的过程中自行完成安装。这也有点超出常规，一些非动态环境很少会用到这样的操作。在大多数环境下的常见方案就是将重点放在硬件(和虚拟计算机)的加固上，并没有针对动态应用程序拓扑结构制定什么计划。

目前还没有确切的数字可以表明到底会有百分之几的应用程序需要进行动态拓扑结构的装载。所以并不是每个应用程序都需要升级成“云应用程序”。从另一个角度来说，通常很难预测在一个应用程序的整个使用周期内会进行哪些负载。

由于将来应用程序可能会遇到越来越多不可预测的负载和古怪的负载模式，最终设计模式与编写动态应用程序相结合很有可能会成为一种常规做法——换句话说，每一种应用程序都要经过编写，这样在高度动态负载的情况下才会保持稳定。对于那些包含这些负载形式的应用程序而言，它们已经准备投入到使用中去了;而对于那些不包含这些负载形式的应用程序来说，这种性能仍然会存储备用、保持在未开启状态，并在最终需要的时刻派上用场。

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

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友