web应用程序慢解决方法_云解决方案与传统Web应用程序

在最近的博客文章中，Garter的Thomas J. Bittman声称，在140位接受调查的客户中，只有5％的客户对其私有云解决方案完全满意。 有趣的是，在95％的“不满意”受访者中，只有6％将此归咎于技术。 其余的问题则源于他们对云的理解以及云如何使他们的业务受益。 换句话说，他们在将其架构（业务，应用程序，信息，基础架构）和IT（运营，支持，管理，治理）适应云模型及其含义时遇到了麻烦。

关于本系列

这个由三部分组成的系列文章重点介绍如何通过在应用程序设计，开发和IT管理领域采用云最佳实践来最大程度地利用云为IT解决方案带来的好处。

• 本部分探讨了为什么云解决方案不同于标准Web应用程序，以及它们的设计有何不同。
• 第2部分讨论了可支持真正的敏捷开发以及将功能连续交付给生产的云就绪软件的特征。
• 第3部分将根据IBM开发项目中的经验教训，说明如何调整开发过程以充分利用云的全部潜力。

什么是云就绪软件？

在云环境中使用了许多术语来标识应用程序或通常在云中运行的软件。 尽管没有针对启用云的软件的标准定义，但我们可以将其定义为最初为部署在传统数据中心中而开发的软件，然后只需进行很少修改或不做任何修改即可迁移到云中。 在本文中，我们使用术语“ 云就绪” （也称为云本机或以云为中心 ）来标识可以利用云基础架构基础技术的应用程序和软件，从而成为云基础架构本身的良好公民。

从这个意义上讲，支持云的软件是最初在设计时就采用云原则开发的软件，或者经过了广泛重组以获取这些原理的软件。 让我们仔细看看这些原则。

原则1：假设虚拟化

虚拟环境原则上等于真实环境。 但实际上，虚拟化会影响已部署组件的粒度。 应用程序部署单元必须遵循虚拟化工作单元（虚拟机或容器）的粒度，因为这些是用于扩展，恢复，配置等的工作单元。

必须将可扩展，恢复或以不同方式配置的应用程序组件分配给单独的VM或容器； 否则，他们将无法充分利用虚拟化的附加价值。 例如，当前端工作负载增加时，将前端和后端组件都包含在同一部署单元中可能会导致创建不必要的后端服务器。

原则2：云是应用程序框架

VM和容器不是服务提供商提供的唯一服务。 防火墙，负载平衡器，VPN，内存缓存，共享存储和存储复制是通常提供的其他类型的服务。 这些服务通常构成云解决方案提供商的云基础架构的骨干，并围绕它们进行了优化。

面向云的应用程序应尝试利用这种优化的基础架构，而不是提供备用的，次优的机制。 例如，所有云提供商都提供某种形式的负载平衡，以提供可伸缩性和可用性。 插入具有自己的内部平衡机制并由解决方案（应用程序）开发和运营团队进行管理的中间件集群会大大增加解决方案的总体成本和复杂性。 另一方面，为了完全使用CSP的负载平衡解决方案，部署的应用程序组件必须完全无状态，并且会话数据仅保存在外部共享存储或缓存上。

原则3：无处不在的容错能力

无法保证VM在云中的生存。 在应用程序级别必须容忍失败和重新启动。 还必须容忍不一致的数据或不一致的状态。 能够协调2PC事务的复杂体系结构组件（例如事务管理器）不能很好地应对无法保证其生存期的VM（如果重新启动其VM的情况如何？）以及解决方案的随机分布（如果正在运行）在另一个地理位置分散的数据中心？）。

因此，每个事务都必须在应用程序级别进行反事务处理，该机制可以随意扩展。 此问题也适用于数据库。 最终具有内置弹性的一致数据库比ACID SQL DB更可取，后者会在体系结构中造成单点故障。 结果是数据货币无法在中间件级别得到保证，并再次成为应用程序逻辑的一部分。

微服务架构

彼得·罗杰斯（Peter Rodgers）博士在2005年云计算博览会上的演讲中首次引入了“微Web服务”一词。微服务具有以下特征：

• 服务很小。 它们具有执行单个功能的细粒度（类似于UNIX哲学“做一件事情，做好一件事情”）。
• 组织的文化应包含自动部署和测试，以减轻管理和运营的负担。
• 文化和设计原则应包含失败和错误，类似于抗脆弱系统。
• 服务具有弹性，弹性，可组合性，最少性和完整性。

为了了解微服务及其在云环境中的重要性，让我们研究一下传统的Web（整体）应用程序。

企业Web应用程序通常由三个主要部分构建：用户界面（在用户计算机上的浏览器中运行的某种形式HTML和JavaScript），数据库（通常由关系数据库中的表组成）和服务器端应用程序。

该服务器端应用程序处理来自浏览器的HTTP请求，执行逻辑，从数据库中检索和更新数据，以及选择并填充要发送到浏览器HTML视图。 此服务器端应用程序通常是一个整体：在单个系统映像上运行的单个逻辑可执行文件。 对系统的任何更改都涉及构建和部署新版本的服务器端应用程序。 进行任何更改都需要重建和部署整个整体。 例如，通过增加活动副本的数量进行扩展，就需要扩展整个整体，而不仅仅是需要更多资源的部分。

这种方法导致底层基础结构的低效使用，如果您的解决方案有专用的基础结构，这可能是可以接受的。 但是，如果您必须针对多个并发工作负载优化物理系统，则它会很快变得难以管理，就像在完全虚拟化的环境中一样。

此缩放比例立方体说明了可用的不同缩放比例选项：

比例尺

X轴缩放可将工作负载分散在一个应用程序的多个副本之间，通常是在负载平衡器之后或在集群管理器下。

Y轴缩放将应用程序拆分为多个不同的服务。 每个服务负责一个或多个紧密相关的功能。

Z轴缩放基于每个记录的属性在一组服务器上拆分数据（也称为分片 ）。 此选项通常用于扩展数据库。

微服务架构利用了扩展的所有三个方面。

简而言之，微服务架构样式是一种将单个应用程序开发为一组独立服务的方法，每个服务都在自己的进程中运行，并通过轻量级机制（通常是HTTP资源API）与其他服务进行通信。 这些服务围绕业务功能构建，并且可以独立部署。

微服务允许每个服务管理自己的数据库，这些数据库可以是同一数据库技术的不同实例，也可以是完全不同的数据库系统。 这种方法称为多语言持久性 ，您可以在整体中使用它，但在微服务中它的出现频率更高。

多语言持久性

包括Netflix，Amazon和eBay在内的大多数大型基于云的系统都从单片架构演变为微服务架构。

不变的服务器

标准化是云计算的主要组成部分。 如果严格执行用于构建系统的标准映像目录不支持云环境，那么它将很快变得难以管理。 例如，从目录映像重新启动发生故障的虚拟机时，必须绝对确定要使用与发生故障的代码和配置相同的代码和配置来重新启动系统。

在传统环境中，这种情况更有可能是一个问题，在传统环境中，服务器和应用程序是由单独的组并通过不同的进程维护的。 因为每个部分都需要优化，所以通常情况是每个系统都是唯一的（换句话说，应该完全相同的系统实际上不是完美的克隆），或者是因为环境支持不同的应用程序集，或者是因为变更过程仍在进行中。 应用程序配置或内容中的计划外更改称为“ 漂移” 。

由于软件或硬件的不断变化，配置漂移是数据中心环境中发生的操作的自然结果。 配置漂移可能会使应用程序管理极为困难。

正确的部署和配置对于生产至关重要，您需要在生产前投入足够的精力，以确保使用经过验证的特定特定版本的软件正确配置和部署托管资源。 无法检测和了解托管资源的配置或内容的计划外更改可能会增加操作失败的风险并阻碍故障排除工作。

实际上，不可能完全管理服务器的配置，因此有很大的机会进行配置漂移和对正在运行的服务器进行意外更改。 在敏捷开发中，这个问题更加明显，因为这种方法强调了持续部署的重要性。

一种替代方法是基于凤凰从灰烬中反复升起的概念。 phoenix概念由不可变服务器方法体现，在该方法中，服务器是从头开始定期重新创建的。 一旦部署了服务器，就永远不会对其进行修改，而只会用新的，更新的实例来替换。 可以对基础映像进行任何所需的更改，进行测试，然后进行翻转。 无需更改的服务器将被拆除并更换。

这种不可变的服务器方法的主要好处是，一旦设置了服务器，便可以绝对确定其状态，而不管其历史记录如何。 例如，考虑删除软件包的过程：如果您不再需要以前安装的软件包，则可能必须跳过很多步骤才能删除它。 如果只是从头开始，您可以确定将仅安装所需的组件。

不变的基础设施并不是一个新概念，最近有关容器（尤其是Docker）的炒作使这一概念更加普及。 不可变的服务器方法确实具有某些含义（通常，没有什么是免费的，并且一个大小不能容纳所有大小）。 例如，您应该最小化每个实例配置项目的数量和范围，并在可行时通过自动测试对这些项目进行更改。 同样，数据库系统也面临着特殊的挑战，应特别注意确保数据的持久性。

结论

如您所见，支持云的应用程序具有一些特定的特征：

• 他们的设计具有虚拟化意识，可以利用环境提供的运行时功能。
• 他们将云基础架构用作应用程序框架，利用服务提供商提供的架构模式，而不是尝试使用不同的架构覆盖它们。
• 构建它们时要考虑到生存能力，因此可以控制特权技术，而不是完全依赖外部中间件。
• 他们遵循微服务架构，因为它最有效地利用了基础技术资源。
• 它们被部署为不可变的服务器，以为整个解决方案提供稳定性和可预测性。

继续阅读第2部分和第3部分 ，我们将向您展示这些选择如何影响实际项目的开发，并分享最佳实践以简化流程并降低成本。

---

翻译自: https://www.ibm.com/developerworks/cloud/library/cl-get-the-most-out-of-cloud-1-trs/index.html