应用程序迁移到云平台的最佳实践

越来越多的开发者和公司选择将应用程序迁移到云平台上，对于真正的企业级产品来说，这个过程不是简单的点几个按钮就大功告成。我们需要从云平台的环境特点出发，对自身的产品做一定的适应调整。IBM 云平台专家 Sheetal 和 Ashish总结了应用程序迁移到云平台的最佳实践，包括支持静默安装、控制磁盘空间使用、设置应该由 API 或 CLI 来完成、跟踪和日志信息必须通过 API/CLI 收集等。

Sheetal 和 Ashish 将迁移分为 3 种场景，分别为：

• 将您的应用程序集成到另一个云产品中——目前需求是增强现有云应用程序以及您的应用程序功能。目标是实现无缝集成。通常，在需要将新功能引入到现有的产品时，就会涉及从头开始设计和开发新功能；另一个可选方案是利用一个现有产品（这种情况下，不需要启用云），将其功能集成到云产品。在这种情况下，您必须确定您的应用程序可以与现有云产品正确 “连接”。
• 将您的应用程序添加到另一个在云中托管的设备——一个云设备由预安装和预配置软件和应用程序构成；有时也可用作一个自包含服务器。当您计划添加一个附加应用程序到现有云设备包以增强其功能时，确保您的应用程序可与软件包中的其他应用程序和配置文件以及设备资源依赖项正确交互。
• 将您的应用程序作为一个独立的云设备进行托管——将您的应用程序用于云环境的一个方法是在其自身的云设备中使用，特别是如果不需要将它与另一个云应用程序集成时。

对于如何实现顺利迁移，他们提出了应用程序自身调整的若干实践，包括支持静默安装：

在安装过程中不显示消息或窗口的安装称为静默安装。当将一个应用程序集成到另一个应用程序或一个设备时，它就成为单一产品的一部分，单个安装程序是首选创建的。如果您的产品不能以静默方式安装，对您的产品来说，在单个安装过程中信息来自用户请求，而此时设备团队可能不想显示 / 询问其用户。这对用户来说是一种麻烦，对于他们来说并不需要了解这些基础产品的详细信息。如果静默安装不可用，您将失去已经取得的高效性，因为对于用户来说，就像是安装两个不同的产品。

控制磁盘空间使用也很重要：您的系统资源应该能够自动地缩减所占的磁盘空间以帮助控制磁盘使用。如果将您产品的功能和流程会产生日志并跟踪数据到一个输出文件，设备服务器中应该有一个流程以限制该数据流来防止内存不足问题的出现。创建一个属性文件，定义即将生成的输出文件的大小和数量。这些值应该能由系统管理员编辑。创建一个进程以监控这些文件。

应该由 API 或 CLI 来完成设置和收集跟踪、日志信息：

您必须能够通过 API 或命令行界面访问和操作所有配置设置。由于 REST Web 服务提供的松耦合性、轻量级以及可互操作性，它们是非常流行的，可能是您最常遇见的一个。如果其他流程需要手工更改一些属性文件或其他文件，可采用它以便于 CLI 或 API 完成那些更改。如果在设备或者设备部分整体功能的安装过程中需要完成一个特定设置或配置，使用这些 ACL 或 API 来完成。设计应该是这样的，设备不需要了解应用程序的内部设计就能够对设置进行任意更改，你应该可以使用 CLI 来完成。另外，无论在何处更改这类配置或设置无论在何处更改，在理想情况下，应及时生效，而不需要要重启应用程序；这样就不会扰乱整个设备的运行。

当产品中出现问题时，要完全诊断清楚，从产品中收集日志是非常重要的。采用命令行机制（或其他）来执行选择性或隔离诊断操作；操作将不会影响整个设备。这包括收集可直接被管理员所用的日志 / 跟踪信息的功能。

高可用性支持是一个很好的优势：大多数 IBM 设备尝试支持高可用性；客户也有此需求。如果您的产品不支持高可用性，那么该设备的整个高可用性功效就会大打折扣。让您的产品在开发初期就完成高可用性设计或者留有一定空间将来开发，都是一个不错的主意。

除此之外，还包括：

• 提供生命周期功能——任何作为您应用程序的一部分运行的进程、线程或守护进程必须有其自己的生命周期功能。它应该提供开启、暂停和停止的常见状态，而且应该有一个方式可让产品自己使用 CLI 或 API 控制这些状态。
• 所有配置均应是可重配置的——预安装阶段假设的任何配置必须在设备创建时能够进行重置（Reset），也可选项根据用户需求重新配置。
• 能够在设备中激活和禁用应用程序——这对您的应用程序来说是一个很强大的优势，可通过使用一个命令行、API 或 GUI 激活或禁用应用程序，这样产品相关文件仍然驻留在磁盘中，但是不能消耗其托管系统的 CPU 和内存资源。这样，您就可以将您的产品嵌入到另一个产品中，在需要时通过开启或关闭来使用它。在云中，一个设备可以通过解除相关特性来关闭它所提供的某些服务，即使是在该应用程序正托管初始产品的时候。
• 命令应可在任何 shell 中运行——尽量确保所有命令不受限于任何特定 shell。与您应用程序相关的 CLI 命令（至少是最重要的那个）不应限制为只能在某个 shell 上运行。集成到您产品的设备可能在不同的 shell 上运行，不一定是您选择的那个；在这种情况下，您将不能运行 CLI 命令，仅仅因为 shell 不同。

启用版本标记、使数据备份和恢复可用、应用程序应是独立的自给自足的、API 应该能够将数据导入或导出应用程序、提供一个编程式方法来管理用户、最大限度地减少对外部的依赖关系、有一个可以彻底终止程序的 API 等也在最佳实践之列。