今天，收到一封「搜狐云景」送邀请码的邮件，价值 200 rmb，立马前往官网简单了解一下，这个玩意儿是搜狐公司云战略的一个产品，一个 PaaS 平台，简单了解了一下特性：

1、自由定制运行环境，这表示支持多语言环境，官网说支持 Python、Java、PHP、Lua、Ruby、Node.js 等语言，这对于我这 Python 码农来说是利好啊，200 rmb可以在这平台跑跑博客了。

2、灵活自定义调度，这表示用户可以根据自身应用规模设置调度规则，这种高大上的技术目前只在 AWS 的 E2C 上看到，且设置方面非常简单，「搜狐云景」作为国内的 PaaS 平台能够提供这个功能，实在点赞，但是不知道做的怎么样了。

开始体验之自动调度——最小实例调度

按前文所述，比较对「自动调度」好奇，因为这关系到一个应用出现高峰时或出现单点故障时候，保障应用的高可用和高性能（水平扩容），因此开始了体验之路，看看有哪些神奇的地方，关于怎么创建应用，这篇文章介绍的非常详细了，一切就绪后，「自动调度」中一个子功能的关键见下图：

看来，「搜狐云景」的「自动调度」参考了前辈 AWS 啊，上图红框标注的，根据我的理解，应该是应用的服务实例范围，比如现在设置成，最小 1 个对外服务实例，最大 3 个服务实例，那么果断猜测「搜狐云景」对用户的应用高可用性保障（单点故障）的实现原理就是依靠最小实例数了，那么怎么自动完成的了？马上体验一把，这时 候我拖动滑动条，把最小实例数设置成 2，此时，我的对外实例数只有 1 个，如下图：

过了大概 1分钟以内，神奇事情发生了，我的对外实例数变成了 2 个，如下图：

于是，我删除一个实例（假装这个出现故障了），同样也是在 1 分钟以内帮我水平扩容到 2 个实例，看来「搜狐云景」的单点故障功能正如上文描述，依靠最小实例数实现，保证用户对外提供的服务不间断。

为了验证这个功能，等待了 1 分钟以内，很让我吃惊的是，「搜狐云景」提供了缩容服务，多余的实例被自动卸载，因为我这个测试应用肯定没什么访问量，一个足以（虽然违背单点故障模式），那么运行大于 1 个实例数肯定是不经济的行为，云计算的内涵不就是按需服务么。

到此，「搜狐云景」的「自动调度——最小实例数调度」还是给我非常好的印象，这个功能对于用户来说还是比较友爱的，即满足了用户应用的「单点故障功能」，又为用户应用提供最经济实惠的计算资源「没访问量缩容之最小实例数，降低成本」。

开始体验之自动调度——性能调度

作为开发者，应该都对自己的应用的性能非常关心，因为涉及到用户体验，是产品的成功与否因素之一，那么我们的应用放到别人的 PaaS 平台「搜狐云景」托管，出现了性能问题，是否能够第一时间帮我们自动处理这些事情？这又勾起了我的好奇心，「自动调度」的子功能如下图：

立马创建一条规则，假如这个应用前 5 分钟请求数达到 5 次就出现了性能问题（这个程序员是无证上岗的吧？）：

然后，开始连续访问多次应用，产生数据（满足自己创建的规则），看看这时候是否如官网描述的那么神奇「用户自定义规则」，当用户的应用的性能达到瓶颈后， 自动帮我们处理水平扩容这事儿。博主强 F5 刷新中，一共 10 次，看看效果怎么样，此时，博主已经做好准备去发微博，号召粉丝吐槽「搜狐云景」吹牛，这个功能不好用，但是，但是神奇的事儿又发生了，「自动扩容」生效 了，且还发现一个亮点，「实时计算用户应用的资源」，这功能太强大了，客官不用急，见下图：

后记

到此，博主把国内 PaaS 平台新秀「搜狐云景」的「自动调度」功能都体验了一番，不得不为这个平台的这个功能点赞，货比三家（你懂的），在国内 PaaS 平台中算是一匹黑马。最后，微博上想吐槽这个功能也可耻的失败了。希望这个 PaaS 平台像官网文案那样「更开放、更智能.....」走的更远，当然可以「更优惠」，我们屌死用户最爱的。