在设计良好的应用程序中，应用程序功能的一种状态可以平衡快速地转移到另一个功能状态上。除了预定的维护停机时间，这个应用程序始终保持不间断工作（或者，最多是无影响中断）。
不可避免的是，开发人员正决定将应用程序迁移到一个云环境上。在这种情况下，开发人员并不是主动的。为了准备迁移，他需要对应用程序进行一些修改，如添加登录框，用户必须输入正确的身份信息才能使用应用程序；这些身份信息包含了根据他所租赁的云服务类型，这个用户具有哪些应用程序的控制权限。
如果开发人员将应用程序作为 Software as a Service
(SaaS) 进行迁移，那么用户所具有的唯一控制权限就是从桌面电脑或移动设备访问应用程序，然后处理一些业务任务，如计费和发票；在这种模式下，用户是不允许控制运行任何
SaaS 应用程序的操作系统、硬件或网络基础架构的。只有开发人员才能够编译、部署、运行和管理应用程序所有功能的升级及补丁。
如果开发人员将应用程序作为 Platform as a Service
(PaaS) 的一部分进行迁移，那么用户就能够控制整个平台业务生命周期的应用程序，管理诸如电子表格和工资单等一些组件。用户要确定需要对应用程序执行哪些修改（如添加一个选项到开发人员提供的下拉列表）。这个用户仍然不允许控制操作系统、硬件或网络基础架构。
在开发人员完成迁移过程之后，他就会遇到互操作性和性能问题。正常运行时间开始下降会降低到服务水平协议（SLA）上所规定的保证水平之下。用户会抱怨在他们请求完成重大业务决策所需要的数据时，应用程序的响应速度比正常水平慢；用户会失去新的业务机会。
疯狂追求快速的解决方案会使开发人员变得被动。
被动的恶果
疯狂追求快速的解决方案会使开发人员变得被动。 他首先会假装由于要执行预定维护而停止云中的生产环境。他会在用户浏览器上显示提示信息：“服务暂停。请稍候。”然后开始在内部处理这个应用程序。
很快，这位开发人员就会发现想找到代码进行扩展而加入一个业务任务下拉列表（如开发票）是很难的。他这时才发现这个原本在内部运行良好应用程序是由前任开发人员编写的，并且有比想象更多的代码单元，例如，有
500 多个模块。
更疯狂的是，他给应用程序增加了一个模块化下拉列表补丁，然后在云中对它进行测试，以确定资源实例是如何公平地分配给应用程序的。他这时才发现负载平衡失效了；有一个达到最大容量的资源实现失效了。其他达到了各自
75% 最大容量的资源实例无法接管这个失效资源实例的事务。
在迁移之前，这位开发人员并未保证每个资源实例使用少于 50% 的容量，这样如果有一个资源实例失效，正常运行的资源实例就会接管事务。
同时，当用户怀疑开发人员在应用程序上遇到问题时，他们就会抱怨维护时间过长。用户会要求获得积分、退款和免费期来补偿
SLA 中规定的服务缺失。如果服务继续达不到要求，他们会要求允许中止服务。
这时，开发人员就会后悔他在迁移应用程序之前没有做这两件事情：
- 他之前没有将应用程序拆分成模块化部分。
- 他之前没有在应用程序中实现一个资源限制窗来跟踪资源实例是如何使用的。
开发人员会由于未在开始阶段采用主动行为变化而为服务、用户和声誉的损失而担负责任。如果他采取了主动措施，结果会很不一样。
主动行为变化
如果开发人员考虑了主动行为变化，那么他就能够保持现有的用户体验，不会破坏他的声誉，并且能够获得新的用户。
首先，他需要一个团队来帮助他将应用程序划分成模块，每一个模块只关注于一个行为变化。他的团队会在内部测试这些模块，并与用户一起检查，保证这些模块的行为符合他们的预期。当这一步完成之后，它才能够将应用程序迁移到某种云服务上。
下面是这个团队可以在应用程序中使用的两个模块示例：
下拉列表控制模块
这个下拉列表模块控制使用户能够选择列表中一系列互斥值。当鼠标单击时，用户能够且只能够选择一个选项。而在按住
CTRL 组合键时，用户可以选择列表中的多个选项。通过标准的下拉列表，用户只能够选择列表中的选项，但是如果使用组合框，那么用户就能够输入一个列表之外的值。
其中一个例子是需要激活一个业务任务下拉列表：
如果您选择了工资单处理选项，那么应用程序会在后台连接另一个应用程序来启动工资单处理。如果您选择电子表格选项，就会出现一个电子表格清单。然后您可以选择和编辑查看一个电子表格，或者添加一个新表格。
如果您选择开发货选项，就会出现一个发票清单。然后您可以选择查看和打印一个发票。您可以填写一个空白发票，然后通过电子邮件将它发送给接收者。如果您选择结算选项，那么您可以选择查看一个帐号，以及向它支付款项。
如果列表上没有某个选择，而用户知道应用程序已经增加了一个新的业务任务，那么他可以在组合框中输入这个新选项，如开发票2。
下面是另一个下拉列表，它包含 4 个临界值选项：
如果您通过鼠标单击只选择一个选项，那么临界值缩略窗口模块（下一节介绍）会显示一个窗口，上面显示应用程序执行该选项的状态。
例如，如果您只选择资源选项，关于资源使用率的缩略窗口就会出现在屏幕上。如果您只选择用户选项，那么您会看到一个显示用户状态的缩略窗口。如果您通过
CTRL 和鼠标同时选择前两个选项，那么您会看到一个显示两个相邻选项的缩略窗口。选择仪表板选项可以在一个窗口中显示前三个选项，每一个都显示不同的临界值水平。
临界值缩略窗口模块
这个模块会弹出一个缩略窗口，它是由您在临界值下拉列表的选择所激活的。这个窗口显示了应用程序的实时运行状态，它是与提供商在
SLA 中规定的临界值策略所设定的临界值相关。
如果这个模块检测到应用程序的运行状态等于或低于可接受临界值水平，那么这个应用程序就是正常运行的，运营持续性就能够保证。如果它位于临界值之上，最大值之下，那么这就意味着这个应用程序的运营可能会由于某些原因而中断，如完成某个任务的资源不足，用户在使用服务后未退出，或者队列中有过多的数据请求等。
如果中断只持续几毫秒时间，那么这通常不会被肉眼所识别，这样运营持续性也仍然能够保证。
如果您认为设置的临界值过高，那么您可能需要与提供商沟通，将它降低到一个更能接受的水平。
下一个问题是 “我如何保持主动？”
您应该如何保证主动呢？
在成功完成对应用程序修改将它绑定到一个云环境上之后，您仍然要保证主动性。需要考虑以下问题：
- 临界值策略。
- 浏览器内在限制。
- 应用程序有状态性。
- 故障恢复机制类型。
- 安全性问题。
临界值策略
临界值策略类型主要有 3 种 — 资源、用户和数据请求。对于每一种策略类型，应用程序测试都可能有与生产环境不同的临界值。要提前进行容量规划使您的系统做好实现临界值策略的准备。
资源临界值策略保证云中应用程序的资源消耗是动态平衡的。这个临界值必须小于可使用的最大额外资源实例数。如果在工作负载高峰期间资源消耗超过这个临界值时，额外的资源实例就会分配。当负载需求回到临界值，或者降低到临界值之下时，所创建的资源实例会被释放给其他负载使用。
用户临界值策略保证用户能够并发地访问应用程序，并发量最高上限为提供商的用户授权规定的限制数。例如，授权限制用户数上限为
3,000，但是只允许 2,500 个用户并发访问，而临界值设置为 2,000 个并发用户。如果并发用户数等于或小于程序，那么在资源消耗和数据请求低于预期临界值时，应用程序可以持续保持可用性。
数据请求临界值策略保证应用程序的数据请求能够得到即时处理。这个临界值应该小于最大数据请求数和用户能够同时发送的最大数据请求大小。如果数据请求数超过临界值，那么就会弹出一条消息显示目前有多少数据请求在等待处理。
浏览器的内在限制
如果您使用 Mozilla Firefox 和 Internet Explorer，那么您是否知道
Firefox 加载页面的速度比 Internet Explorer 快且使用内存更少？Firefox
的主要限制是它可能由于以下情况而关闭或产生响应延迟：
- 在资源消耗达到资源实例最大容量值后仍然请求额外的资源。
- 当资源消耗超过临界值时弹出临界值缩略窗口向您发出警告。
要解决这个问题，一定要保证资源消耗等于或小于临界值，并且采用了实例资源冗余故障恢复措施。
如果出现了缩略窗口显示资源消耗超过了临界值，那么它应该：
- 弹出一个消耗过度的警告消息。
- 要求您关闭浏览器或者使系统平台自动删除 firefox.exe
过程并重新启动浏览器。
应用程序功能的有状态性
您知道应用程序功能的有状态性是如何良好地执行吗？有状态性指的是当转到云环境中其他功能的后续状态时，应用程序功能的状态是如何正常表现的？
在这个非常简单的例子中，在云中验证用于购买零售商品的信用卡信息的功能状态应该快速地转到发送信息到银行帐号的功能状态上时，同时快速地转到通知客户零售商品已经发送到目的地址的功能状态。
如果从一个状态转到其他状态会导致应用程序在云中的性能低于内部环境性能，那么可能是由以下问题造成的：
- 应用程序中处理业务事务的逻辑缺陷。
- 资源、用户和/或数据请求所设置的临界值过高。
- 低效的资源实例可能导致不恰当的有状态性。
- 用户或数据请求争夺相同的资源实例。
故障恢复机制
故障恢复机制是为了在各种意外事件出现时仍能保证运营持续性，如即将发生的硬件错误、资源压力或较长延迟时间等。而异常情况包括不可抗拒自然力、提供者的预定停机维护或光纤线路的意外中断。
以下是应该考虑的一些故障恢复机制例子：
- 负载共享冗余：负载不超过总负载
50% 的两个或两个以上的系统。当有一台设备失效时，其他设备会在临界值内以少量或无中断或变化接管负载。
- 实例资源冗余：负载不超过总负载
50% 的两个或两个以上的资源实例。当有一个资源实例失效时，其他资源实例会在临界值内以少量或无中断或变化接管负载。
- 数据请求队列冗余：负载不超过总负载
50% 的两个或两个以上的数据请求队列。当有一个队列失效时，其他队列会在临界值内以少量或无中断或变化接管负载。
- 备用连接重试：如果网络中断持续时间超过
2 分钟，那么要通过备用网络连接重新连接到另一台物理服务器或虚拟机。
安全性问题
如果您的公司每年计划收益大于 10 亿美元，那么私有云可能比公共云更具成本效益。私有内部云具有与公共云相同的业务特征，但是在安全性、可用性和恢复机制等方面的管理上比那些收益小于
10 亿美元的小型公司水平会更高。
内部私有云允许您在一些已知的特定管辖地区（如美国或加拿大）存储和从中获取数据。它适合于存储您的敏感、法规、保密和测试数据。
相反，公共云中的数据可能存储在未知的位置，并且可能不容易获取。未知的位置是不适合存储法规、保密、敏感和测试数据。
其中一个安全性问题是提供商管理人员是否能够在未经您的允许访问您存储在已知位置的敏感、法规、保密和测试数据。另一个问题是存储的数据可能位于一些保密和法规规范与您所熟悉国家不同的地理区域。由于数据出口的限制，每个国家的法律可能会各不相同。
在获得授权之前，管理员的责任应该在合同中明确，规定他在访问您的数据时能够做什么、不能够做什么，他必须遵守什么数据出口法律，以及他必须实现什么策略来降低黑客在云中创建命令与控制中心（Command
and Control centers, CnC）的风险。
黑客会使用工具来检测从您的电脑与未知位置之间传输的数据。PaaS 平台一直被作为
CnC 中心来疏导分布式拒绝服务攻击（DDoS）所使用的僵尸网络操作和在云中植入恶意软件。黑客可能设计和部署恶意应用程序来实现以下目的：
- 分配恶意资源实例。
- 重置临界值以实现不可行的最高值。
- 将应用程序功能的状态修改为恶意功能的后续状态。
结束语
将应用程序的行为从内部修改为云环境需要预先进行规划，以解决在应用程序迁移后仍然保持行为修改主动性的问题。开发人员、用户和业务分析人员需要组成团队一起设定临界值策略、克服浏览器内部限制、定制故障恢复机制和考虑云中的安全性问题。这个团队将会发现解决问题的方法，使任务保持主动性，同时使行为修改更加简单。
|
