转载

使用基于日历的规则让您的 Bluemix 应用程序富有弹性

本文将演示如何使用 Bluemix Auto-Scaling 服务，通过扩展应用程序运行时指标（比如内存、响应时间等），让您的应用程序富有弹性。具体地讲，我将详细介绍 Auto-Scaling 服务中的一个新特性，该特性支持所有者分配基于日历的规则，将您的应用程序在特定时期内的扩展和缩小到指定的实例数量。此特性对需要让多个节点实例在特定时段内保持活动状态的应用程序很有用。

构建您的应用程序所需的准备工作

一个 Bluemix 帐户

第 1 步. 在 Bluemix 中创建一个应用程序。

登录到 Bluemix 。
在您的 仪表板 中，单击 CREATE APP 。
我们将创建一个用于演示目的的 Java Web 应用程序，所以在 Choose Your App Template 页面上，请单击 WEB 。
在 Choose a Starter 页面上，选择 Liberty for Java 并单击 CONTINUE 。
在 Name Your App 页面上，为应用程序输入一个名称。此名称必须在 Bluemix 中是唯一的。单击 FINISH 。

第 2 步. 将您的应用程序与一个 Auto-Scaling 服务实例绑定在一起

您的 Java 应用程序创建并运行后，单击左侧列的 Overview ，然后单击 ADD A SERVICE OR API 。
在 Services 列表中选择 DevOps 。在 DevOps 页面上，选择 Auto-Scaling 。
在 Auto-Scaling 页面上，您将在右边的 Add Service 列中看到您的应用程序细节。单击 USE 创建一个 Auto-Scaling 服务实例，并将它与您刚创建的应用程序绑定在一起。在提示 Restage Application 时，单击 RESTAGE 。

第 3 步. 创建一个 Auto-Scaling 策略

创建扩展规则。要获取分配扩展规则方面的帮助，请参阅以前的一篇 Auto-Scaling 文章 “ 让您的应用程序在 Bluemix 上富有弹性 ”。
创建一个时区。我们稍后创建的时间表将基于选定的时区而触发。
单击 ADD A RECURRING SCHEDULE
创建循环的时间表规则。对于我们的示例应用程序，使用如下信息完成 4 个字段：
- Start Time ： 13:40 。
- End Time ： 13:50 。
- Repeat On ： Everyday 。
- Minimum Instance Count ： 3 。
点击查看大图

关闭 [x]

对于 Recurring Schedules，需要注意的是：
- Start Time 必须早于 End Time 。
- Repeat On 字段中有 7 个值，从 Monday 到 Sunday 。可以选择一个或多个值。选择所有 7 个值时，该字段将显示为 Everyday 。
- Minimum Instance Count 的值必须小于您的扩展规则中设置的 Allowable maximum instance count 。
创建特定日期的时间表规则。在 Specific Date(s) 窗口中，单击 ADD A SPECIFIC DATE
创建一个特定日期的时间表。对于我们的示例应用程序，使用如下信息完成 3 个字段：
- Start Date & Time ： 6/3/2015 14:00 。
- End Date & Time ： 6/3/2015 14:15 。
- Minimum Instance Count ： 4 。
对于 Specific Date(s)，需要注意的是：
- Start Date & Time 的值必须早于 End Date & Time 。
- Minimum Instance Count 的值必须小于扩展规则中设置的 Allowable maximum instance count 。
- 如果存在重叠，特定日期的时间表优先于循环时间表。
- 完成后，单击 SAVE 保存该策略。

第 4 步. 监视基于日历的规则的运行情况

单击 Scaling History 选项卡来检查扩展活动的记录。
对于我们的示例应用程序，历史记录列表显示，基于事件 Recurring schedule Wed 1:40 PM triggered ，应用程序在 1:40:32 PM 扩展到了 3 个实例。
点击查看大图

关闭 [x]
我们在 13:50 后检查 Metric Statistics 选项卡时，可以看到内存使用率现在低于 Lower Threshold 50% 线。
点击查看大图

关闭 [x]
返回到 Scaling History 选项卡，我们看到应用程序逐步减少到了 1 个实例。
点击查看大图

关闭 [x]
稍后检查 Scaling History 选项卡，我们看到在 2:01:17 PM ，基于事件 Schedule Jun 3, 2015, 2:00 PM triggered ，应用程序已扩展到 4 个实例。
点击查看大图

关闭 [x]
在 14:15 后单击 Metric Statistics 选项卡时，我们看到内存使用率现在低于 Lower Threshold 50% 线。
点击查看大图

关闭 [x]
再次检查 Scaling History 选项卡，可以看到应用程序逐步减少到了 1 个实例。
点击查看大图

关闭 [x]

关于 Node.js 和 Ruby 中的开发的说明

我们使用 Auto-Scaling 的基于日历的规则，测试了用 Java 代码、Node.js、Python、Ruby、Go、PHP 和 ASP.NET 开发的应用程序。我们发现，Node.js 和 Ruby 的垃圾收集 (GC) 机制在分配内存后没有清除内存。这意味着在 Node.js 和 Ruby 应用程序扩展到多个实例，占用较高的内存后，无法在事件减少后由 Auto-Scaling 服务自动减少这些应用程序。

此问题的解决方法是将 Allowable maximum instance count 设置为一个较小的值，或者使用 cf 命令行接口来手动减少这些应用程序。