GAE调价对Web架构的将来揭示了什么？
原文：What Google App Engine Price Changes Say About the Future of Web Architecture
翻译：安冲、许力波、林业、曾怀东、朱翊然、马少兵、李凯、王鑫、靳彬
当我还是一个孩子的时候，我像孩子一样说话，像孩子一样理解，像孩子一样思考：但是当我成为一个成年人的时候，我收起了那些幼稚的东西。--Corinthians
随着GAE新的定价模式调整，开发将会由成本驱动。为了使我的应用更好更快，我喜欢去优化它们，但是仅仅为了成本的便宜而去优化无疑是一种时间的浪费。-- Sylvain on Google Groups
当 GAE 摆脱幼稚，成长为一个真正的产品的时候，"pay for what you use"的美梦破了。价格改变，体系随之改变，用户随之改变，理想随之改变，但 GAE 将继续存活。
Google正在关闭很多它的项目。GAE没有被关闭。我们应该感谢由于它定价的调整而让它在更残酷环境下依然可以存活吗？如果没有迅速地向盈利转向，GAE毫无疑问仅仅将会成为诸多想法长卷中一个历史性的脚注。其涉及的迫切性由GAE提供定价百分之五十的优惠以及在多线程版本的Python铺开之前转向新的定价模式所清晰的反映出来。
梦想是美丽的：为你所使用的服务进行支付并且使得它绝对地容易使用。现在这一点很容易理解。这是公平且令人信服的。GAE曾经用了三年时间进行试运行来让梦想实现，结果是这显然是个噩梦。这是它的耻辱。Google是大胆的，他们创造新的事物。他们工作努力。GAE革新了可伸缩的应用程序的发展以及以原始和有趣的方式扩展了PaaS。他们做了惊人的工作。并且结果是被很多人喜欢甚至是热爱的。但是经济原因使他们失败了，他们不得不进行转折。这是困难的。转变的结果会是什么呢？
Pay for what you use has changed。GAE从一种将定价绑定在实际CPU使用上的抽象资源驱动模型转向为Amazon模式的将定价绑定在实际物理资产全部花费上的事例驱动模型(请参考 FAQ )。估计GAE新的定价模式将使对其使用的成本增加到2倍到10多倍。
Dead easy has changed。定价只是故事的一部分。GAE仍然承诺它的整体平台零成本维护的保障，但是更多的压力施加给了程序员来浏览新的定价模式并且重新进行复杂的编码来减少成本。GAE已经不再容易使用了，工作重心已经转移到更良好的编程上。
为什么改变？要走向商业化Wesley Chun,来自于Google\'s developer relations。做了一个试图解释变化背后原因的具体工作(摘要)：
一切都非常合理。作为优质的企业级产品，定价不必遵循成本，价格可以上升，以应付竞争，甚至更高，如果你认为你的产品具有特殊的价值。
诚然GAE开始不是这样子的。GAE开始采用一个低廉的价格，易于每个程序员使用的基于CPU使用率计费的平台。现在一切都不是这样了。以前的方法行不通，也许是因为太早了，so it\'s hard to shake that there\'s a bait-and-switch feel to this
转向 premium branding 尤其令人惊讶，因为它从来没有被 Google 定义为一个 premium service。从商业角度来看是有道理的，但这是为什么对所有的一切有这样轰动的部分原因
GAE现在要做的是一个企业级的服务。其他产品上赚到的钱将支付给它。它不再定位给那些希望托管于较低成本的GAE架构的开发者，而是定位在开发应用程序来赚钱的开发者。现存应用程序的大小，类型和业务模型，将不适合GAE了。
这是一个非常尖锐的转变。但是，让你做些什么才能生存。必须作出选择真的很难。当我们经历了所有悲痛的阶段，我们必须克服它，重新评估，并继续前进。
mdasen 很好的描述了这些早期日子里令人陶醉的感觉：
Hey hackers! 你必须在我们Google的系统上完全重写你的应用程序，因为我们的系统要比其他系统高效很多。有一些烦人的限制你必须去习惯，对一些事情也非常头疼。尽管如此，我们的服务在负载的使用上很便宜，甚至之后你只要对no-hassle-scaling上花费少量的编程时间，比你用过任何的托管都少！
With equal poignancy Stephen, in this Google Groups thread, captures the feeling of today:
现在的状况是"App Engine"成为了"App Engine for Business"，以前那个"App Engine"不复存在了。Google 已经明确了这一点。App Engine现在是一个企业级产品，价格与成本并没有关系。
梦的延续
现在我们可以回顾一下，这只不过是一个实验期…一个实验因为一个关键的方面而失败：基于付费模型的资源似乎不起作用了。
我们震惊的一部分是价格全面上涨。我们通常认为的计算资源随着时间的推移变得便宜。摩尔定律和规模经济相结合一直是我们的好朋友。可伸缩性是朝着相反的方向流动，Google要求用户预算可伸缩性，而开发者则不必。
但是，这个问题不只是盈利和亏损，本实验的结果对于未来应用体系结构有一些有趣的影响。现在，我们要讨论这个话题
我过去完全想错了，我曾以为 GAE 将发展成为一个任务队列
说一下我这个错误的预测吧，GAE 的发展和我猜测的方向截然相反：我以为 GAE 会完全抛弃 instance image 概念，转向在一个巨大的任务队列容器上编写应用程序。
这个猜想/远景的基础是一个GAE最具创新性和深远的特点的发展和演变：任务队列。它的一个大的特征是允许将应用程序分解成异步流。任务进行排队，并在一段时间后执行。取代最初用于GAE上的 monolithic 和同步模型，应用程序可以完全异步，并且可以在任何机器上运行。现在我们清楚 monolithic 的前端实例已经成为任务队列结果的冗余。
问题是任务队列仍然基于镜像。URL可指定一个操作，来终止任务队列里的一个运行时实例，其代码模板是从镜像中读取。一个镜像包含了一个可执行的应用程序的所有代码。这就是 monolithic。
但当客户端调用 URL 的时候，就开始执行一个 monolithic 镜像内的代码。正是因为这些大的镜像必须通过GAE来管理，所以Google需要向你收取更多费用。他们管理需要资源，耗费初始化时间和运行时内存，尽管你的应用没有做任何其他事情。
一个不同的想法就是为什么我们不是简单的请求中止任务队列中？不再使用 monolithic 镜像，而是异步模型。是的，GAE将不得不继续以某种特殊的方式管理并发布这些代码库，任务并不简单。但是这将解决资源粒度如何被更好的分配和衡量的问题，而不是像现在这样把 image 作为代码分发的单元，把实例作为执行的单元。下面我们将会更多的讨论粒度问题。
所以，伴随着这个非常酷的任务队列框架和编程模型的发布，我感觉他们肯定已经做好了准备，宣布 monolithic image 将要消失，实例将要消失，将有更精细的支付以替代您所使用的计费模式。我又一次错了。
这是一个量子力学问题
驱动这个剧变的是，程序运行在一个与资源量化方法与物理机完全不同的抽象机上。一个服务器只有这么多的内存和CPU。即使程序是空转的，运行它也是要使用内存的。Google必须为实例所使用的资源付费，只承担程序运行所使用的资源的费用，而不是承载一个程序所使用的所有的资源，这就在两个模型之间造成了一个不可持续且无利可图的定价摩擦。
另一种说法，程序部署的量很大，但是运行的量却很小。一个较小的工作粒度将允许作业被安排在空闲的时间，这就是为什么我觉得任务队列模型很优秀。
在实践中我们看到了这个效果。一个使用.02cpu时间的应用程序现在或许会用掉2.8实例时间。过去，如果你正确的编码你的应用程序，GAE看起来就像一个巨大的CPU，尽可能少的CPU资源被使用到了。现在，GAE已经激增为一个组件集(前端，后端，调度器等)
现在，最小化 CPU 的运行时间已经没啥意义了。如果应用程序因为 IO 被阻塞(编译者注：被OS挂起因此也没有CPU时间的消耗)仍然会被要求付费。一个实例执行多长时间，你就得花多少钱。实例消耗时间去启动，所以不管这个启动时间对你是否有意义，你都要支付15分钟的花费。而且如果一个请求在调度器看来将会消耗很长的时间，更多的实例将会被spun up。我觉得这一点你真的不能争执。关键是改变了资源是如何共享的。转变到实例模型是某种意义上的放弃。
如果 Google 认为内存是一种稀缺资源的话，很多人都要求把 CPU 计费和内存计费分离。这会要求应用更有效率的使用内存。(编译者注：这句话的意思是，很多人认为 GAE 的调价的成本压力是来自内存)问题是，对于一个实例，内存和CPU并不是可独立的。这也是为什么Google不能制做一个完美的高效的调度程序，作业单位并不匹配计算资源的单位。
成本上升
因为在新的计费模式下，实例时间增加了，所以花费增加了。Python多线程编程能帮助解决这个问题，但是在数据存储行为上的开销也在增加。
The Amazing Story Of AppEngine And The Two Orders Of Magnitude
Emlyn O\'Regan写了一篇非常棒的文章详细解释了他在新的定价模式中调整自己应用的经验。他后来接着发表了 AppEngine Tuning #1
最开始，像大多数人一样，他忽略了原来的公告，他认为变化不大，但实际刚好相反。他的账单从$0.51/day 上涨到了$49.92/day。原来一年$200 的花费变成了一年$20K。这是一个巨大的上涨。
Emlyn随后做的事情很cool，他带着我们浏览了一遍他的app，找出钱花在哪里，以及他对自己的app做了怎样的改变来减少使用Google工具和文档的花费。在新的模式下我们找到了以前不是问题但是现在是的一些行为。
这些行为包括：
一些问题是由于"just make it work"这样的设计模式而导致的. 这在项目中很典型。GAE的新定价机制使这种不严格的代码变得花费巨大，所以需要对它们进行修改。好事情是，架构不得不从现在开始考虑这些问题。最小化实例数以及最小化数据库操作。一定要检查这些。
对于GAE来说，这会减少整体资源的使用，这也是他们所期望的。发出合适的定价信号是实现这一结果的最有效的方法。
其他问题还包括由于无意的GAE API调用造成的意外结果。在API中的后果应该更明显。由于它非常微妙而且具体app有着区别，我们需要时间来解决这些问题。
Scheduler 有利益冲突问题
scheduler 的工作是在计算机集群中安排工作。在这种情况下，工作的形式包括web请求， cron jobs以及任务。所以引入了工作队列。这项工作需要以合理的方式分配资源。那么什么在处理工作呢？是实例。实例的运行占用内存，CPU，硬盘以及带宽，这意味着运行实例需要付费。切换(spin up)实例需要固定的时间，不管工作的性能如何 切换实例也需要付费。并且由于它们花费固定的代价运行，让它们在有较多负载的情况下运行更为合理。GAE并不知道你将会造成怎样的负载。GAE的负载是由一个随机过程造成的。
想彻底解决这个问题非常困难。在实时调度中，不可能确定的安排一个变化的工作负载。即便通过系统运行同样的工作负载，在不同时刻也有不同的结果。这是由cpu定价转变为实例定价造成的奇怪后果。
很多人抱怨GAE scheduler是一个内在利益冲突的矛盾体。 scheduler决定了实例运行的数量，实例运行数量反过来决定了盈利。这是一个好主意么？这种激励方式是错误的。如果开发者和GAE都有类似的激励机制会比较好，现在他们本质上是相反的。
并且，注意到google在广告方面有相同的 edge。google建立这些数据的索引，创造市场，取走广告，设定价格，并且决定广告在何时显示。这所有的一切像GAE scheduler一样对公众是不透明的。我回忆起弗洛伦萨的美第奇家族，他们通过简单的控制那些可以参与选举的人来控制公众选举的结果。
一个存在潜在冲突的令人关注的地方是认购超额。如果你分给每个应用许多RAM而google不能在同台机器上运行太多的实例，因此RAM在前端被限制在了128M以内，在后端限制在了1G以内。像其他的托管服务一样，超额订购这些资源可以使单台机器挣得更多的钱。那样可能导致交换、系统颠簸等问题，这些问题可能导致更高的延时从而需要申请更多的实例。两个方面都需要钱。而且低内存的限制使得更难去写更大的多线程应用程序，这些程序是降低延迟以及减少实例数量的策略之一。
为了解决所有的问题，许多的压力正在放到scheduler上。我们会使调度变得更好，这里面包含了你的费用。就个人而言，由于我们之前讨论的粒度错配问题，我不太清楚那样会真正的起作用。
问题在于程序员要负责平衡所有的这些目标。Gubbi表达了这种进退两难的感觉：
我抱怨的是，新价格让延迟成为了关注的焦点，然而开发者只能在应用程序代码的层面去优化它。应用程序和基础设施都应该为延迟负责。
以前是基于如何实现业务目标的策略驱动的架构，而如今程序员将在他们的程序中硬编码一个设计模型。当所有的假设发生变化时，代码会很难改动。这所有的需求将提升到抽象的水平上。例如，当一个任务是低优先级的，scheduler会说我们不需要为它而加速实例，让我们利用空闲时间再去调度它吧。
Steve已经在scheduler配置文件和请求设置文件中做了一系列的好的scheduler变化的建议，主要的思想是基于请求头和其他我们能够在那个级别上获得的信息的基础上在预定义的调度配置文件中过滤请求的能力。
The Architecture Shift
From Barry Hunter：
“旧”的方式，非常提倡低cpu的使用，即使那样可能带来高延迟的代价。缓慢请求时，将会花费大量的实例 - google的成本。
“新”的方法推崇降低你的延迟。快速的请求带来每秒钟(每个实例)更多的查询。这意味着更少的实例。
通过收取实际使用实例的费用，他们能够有助于压低实例的数量。
因此开发人员应该以压低实例的数量为目标--为了省钱。
那些需要，想要，(或者懒得去优化)，慢的请求将要支付 - 接近于google实际的开销的钱。
Google不希望你spinning up 实例并且很快的把他们撤下来。Its that spinning up, that \'costs\'.
故障排除指南
johnP 觉得编写一个 trouble shooting guide 来应付价格变化是一个好主意。他的第一个草案是：
检查google的文档
google有一些值得看的好文档：
Optimize for One Instance
我正在优化单一实例的情况，其实我只是实现了一个简单的缓存。第一次命中kiosk时生成页面并且返回它，而且在内存中保存该页面。第二次命中时从内存中获得缓存的页面。这要比我原来的方案好很多，因为在kiosk进行页面重载时我保护了任何异常发生的情况。
Task Scheduler Bunching
尽管大家着眼于任务队列与调度器交互这种方式，但是出现了另外一种情况，任务队列趋向于聚集任务，将任务并行地导入到调度器去加速产生一个新的实例。我觉的，必须首先考虑等待任务的数量，然后考虑加速实例的产生来处理队列。如果仅仅有两个实例，必须使他们等待很短的时间。(当然，如果能够给用户控制权限更好，凭借设置任务的优先级)
Dump Writes to Queue
第一种类型的请求，将被写入到任务队列，立即得到返回结果。队列将被后台的实例处理。虽然目前这种类型的花费有所上升，但是主要的优势是我基本上得到了对那种写队列被处理的大量控制。AppEngine不会为我加速处理新的前端实例。这样我就可以随意控制想多快，多少钱，来写。将会出现一个延迟，在将数据写入到数据库之前。但是我认为这点可以承受。
Use Cursors
再看看游标，如果你想对一个数据集操作，也没有多大的性能问题的限制或抵消。
Use Pull Queues, Backends, and Cron
我将考虑使用一个pull队列来处理你的任务负载，代替正常的push队列。这种情况下，我们可以用使用计划任务工具来限制任务加速的数量，以及在一个连续模式下使用离线处理方式。想的越多，我觉得这个过程适合后端和计划任务工具，而不是前端和任务队列。
Two Stage Gets Preferred
Google App Engine Post-Preview Pricing FAQ:
这种新的计费模式，仍然是很经济的，对处理获取1000个 keys-only 的查询，和得到500的数据，相比正常的查询(non keys-only)来得到全部1000数据。第一种是更加的经济。获取1000keys+500entities=$0.0001+0.00035=$0.00045;而第二种花费0.0007美元。
Stop the Bots
In Googlebot Spawning New Instances, Jeff Deskins notices something very interesting
当我们着眼于降低在AppEngine的费用时，googlebot抓取页面的速率为12页/s。这将导致另外6个实例被创建。
另一个低优先级 spiky 表现的例子同样导致花费增加，由于每个爬虫都在消耗费用，整个抓取网页的的思路都需要改变――Spiky App Penalty
处罚“spiky应用”的费用的方式太多。三年前，当我们首次启动一个GAE应用时，看准了下面的三点：伸缩性、以模式付费，简单。
我们的应用是非常“spiky”-单个用户一次产生50次请求，需要服务器快速响应。我们的应用已经在该平台上运行了三年时间，并根据GAE的规则修改了代码，使得代码能够运行在伸缩性和其他的约束条件下，并且运行良好。我们没有其他的选择，如果我们使用EC2或者其他的系统。
这种新的计费模式导致我们有两个麻烦：为空闲的实例付费、目前的模式失去简单性和可预见性
有些人建议，这种新的调度模式需要一个灵活性，来处理小和束缚的应用。你的这种计费模式却没有考虑考到大量用户---首次想用你工具，以及那些利用你的早期限制和约束来开发的人。
无法确定的成本
这种调度程序对编程人员来说是个黑盒，隐藏了核心的空间算法，使得很难理解。不能被控制，不能评理。控制实例和带宽，比控制CPU的应用将更困难。这导致了很多不确定的困惑。难道这就是世界新秩序的一部分吗？
Instance Idea Includes both CPU and RAM
FAQ的作者Greg D关于为什么GAE不为RAM建立一个单独的收费机制
例如我们已经通过charging增加了一个RAM charge。通过拥有一个实例分配的内存量，实质上我们已经在使用那个RAM了。所以收费是收取的使用CPU和RAM的费用。我们在考虑把这两种费用分离出来，这样我们就可以继续charge CPU-hours，然后也可以charge instance-hours(这个不能叫做RAM-hours)。这些都看起来越来越使人迷惑并且这么做也不会更便宜，因此看起来并不太值得去这么做。然而我知道已经有很多关于用这种收费的讨论。无论你把它称之为RAM-hours 或者instance-hours，也不论你是否在顶层为CPU-hours 收费，最后的结果都是一样。对应用程序会根据对其分配的内存量和分配的时间而收取费用。这意味着那些想省钱的应用程序有必要在RAM-hours方面做优化，这在本质上意味着用更少的时间来完成任务。
多任务的回归，宝贝
基于价格的实例，其目标是能尽可能多地利用实例。这需要多线程，因此在容器中可以尽可能多的去执行仿真进程。之前的GAE都是单线程。启动更多的实例是为了处理更多的请求。这显然并不高效，所以我们重新写线程代码，这是实际上是一种很好的方式。启动一个巨大的JVM就是我们为什么要把应用服务器放在首位而远离CGI模型的原因。GAE模型并不盈利是其一点小小的遗憾。
多线程方法的收益很高，以至于GAE指望它们来平衡提高的成本。Brandon Wirtz说：
我刚刚完成了对我的应用程序早期版本的重新编写(从Python到Java)。这不是我最新的app版本，但是这类似于一个已经部署了数月的版本。所有的版本都在做相同的事情，能够兼容各种方式。我还没有运行那个版本太久，但是我已经从20个实例减到1个实例了。当有足够的数据来确认的话，我会在8小时之内给出一个完整的报告。
我完全相信，这个app的规模，将会是整个应用程序规模的一个重要指标。(这次重新编写花费了三个小时的时间，几乎是一句句进行对照编写的)。
内存消耗会随着并发和多线程的应用而提升，因此看到它们如何协同工作讲会是一件很有意思的事情。
相比较 Amazon，GAE 还具备优势吗？
对于仅在RAM的基础上运行的服务进行比较。RAM是指示利用服务来完成任务的诸多因素之一。APP Engine 还包括许多免费的API，不需要管理APP，也不需要运行维护OS等。APP Engine是一个平台，当我们决定使用不同的资源(电子和人力资源)时，那么收费也将有所不同。
当比较价格时，千万不要忘记人力资源的数据存储，可扩展前端，memcache，以及管理这些东西的开销。我曾经管理过分布式的数据库，如果你还没有这么做，那么它比你想象的更有考虑的价值(假设你关心你的数据)。不要忘记管理成本的开销，即使一切运行正常的话，一年也得有几千美元的开销。
对于什么是有价值的，我并不认为拿一个GAE实例比较一个像VPS的实例是公平的。
它们是非常不同的’beasts’.理论上GAE提供更多的东西。Google处理所有的安装、配置以及负载均衡等。
如果仅仅使用相当于十分之一的VPS，那么这就显得有点昂贵。但是一旦你开始需要管理多个VPS，提供负载均衡器，重新提供故障情况等进行备份。所有出现的这种情况均与GAE有关。
所以不要忘记获取一个免费的实例配额。
后端服务是昂贵的
后端的instances看起来貌似是荒唐的且价格过高的(对于一个256MB/1.2GHZ的Instance来说，每月需要花费115美元)。它们这种过高的价格使得它们对于许多那种可能因为此功能而举债的那些用户而言，是毫无吸引力的，这就造成许多用户去寻找其它的产品。
在某种程度上，貌似我们到了进退不得，左右为难的地步。后端其实是应对那种需要长时间运行且频繁占用CPU的活动的好办法，它可以使我们从那些任务链的当前业务中解放出来，其中每个任务都是在一个固定的时间内完成，或者使用map-reduce操作。然而，后端是如此的昂贵，以至于大部分人都不会去使用它。不幸的是，当前使用前段的instances和task/map-reduce的业务也是如此地昂贵，这是因为我们不得不为超出我们使用的部分额外支付1/4 instance小时税。
性能 = 可伸缩性
FAQ for out of preview pricing changes:
因此，在延时和每个instance每秒可处理的请求数量之间存在这一种直接的关系，举例来说：10ms latency = 100 request/second/instance，100ms latency = 10 request/second/Instance，等等。多线程的instances可以处理许多并发的请求。因此，在CPU消耗和每秒请求数之间也存在一个直接的关系。举例来说，对于一个B4(大约2.4GHZ)instance：消耗10 Mcycles/request = 240 request/second/Instance，100 Mcycles/request = 24 request/second/Instance，等等。这些数字是理想的情况下的，但是它们应该同你能够在一个instance上完成的量十分接近。多线程的instances当前只支持Java，我们计划今年晚些时候支持Python。
由于Google所做的特定的设计决策，高延时请求并不会扩充*on appengine* 。高延时请求在其它平台上扩展的很好――运行Node.js/Tornado/EventMachine等等的分支在应对上万个l延时请求方面毫无问题。甚至传统的java appservers在可接受的限制下处理延时――取决于你正在做什么，使得你可以在每个JBoss instance上应对成百上千个并发请求。
GAE 无法再支持以广告为收入来源的应用
比如说我现在有一个依靠广告收入的应用。并且假设每个请求耗时1秒，任务调度器没有任何问题。因此，我每小时也就是3600秒为一个instance支付$0.05 。因此让我们把那个数字平均到3600个request，并且假设有1800个page views(假设用Ajax做的)。因此1000个page views的开销是：$0.05/1800*1000=0.027$。假如一切没有问题，而且不把后端任务计算在内，尽管我的十分大，我至少需要 0.027$ ecpm。举例来说，土耳其的流量有时ecpms可能会低于0.1$，而且我确定肯定还有其它国家的ecpms有着更低的ecpms，我们的流量费是最佳的。总结一下，看起来如果我使用GAE，貌似我一直会担有开销比收入高的风险……
我若在一个专用服务器上部署应用，通常一个服务器是几乎空闲的，负载基本上是0.5(8个核)，有时候是2-3，并且我确定我没有使用它们优化到%20，但是我的成本仍然是收入%10！如果我可以使用一个服务器到最大级，可能达到成本只占%2。在最好的情况下，假设没有任何问题的情况，看起来在GAE上这个比率是%25。
这可能预示着对于移动服务来说，如果想采用GAE作为移动客户端的便宜后端的话看起来并不可行。
混合架构?
或者说是通过云端集成―我希望更多的人通过GAE的用户帐户/认证，把他们的文件存放在一个或更多个CDN上，使用第三方pub-sub服务更新客户机，可能的话将不同服务间的数据(热数据vs引用数据)集成起来，为那些不会遭受流量激增的后台进程保持固定的专用实例等。我希望能够实现抽象服务―能够用于编写完成一种服务的API,并且独立于任何具体平台的库。
Python or Java?
Java 具有即时编译技术JIT,因此假设实例保持足够长的时间使即时编译生效，并假设具有更高的延迟处罚，那么在GAE上，java会比python更受欢迎吗
整个实例的代价计算太复杂
Daniel Florey关于这一切的复杂度的有很好的见解:
有没有一种方法，可以在不必了解程序调度引擎内部的前提下，建立一种简单的代价模型？我认为为消耗的资源付出合理的代价是可以的，但是对于实例/小时的方法，并不认同。这让我感觉像是impl在为我负责。我希望有一种简单的方式(从用户的角度)，可以由我负责cpu资源与内存使用的代价，可以对“可扩展性/处理能力”进行预算处理，使程序引擎负责它需要负责的一切，并可以根据设置加速/减缓我的程序。
结论
相关资料
建议继续学习：
扫一扫订阅我的微信号：IT技术博客大学习
- 作者：qyb 来源： BT的花 blogs
- 标签： GAE
- 发布时间：2011-09-15 23:46:26
-
[51] Oracle MTS模式下 进程地址与会话信 -
[49] 图书馆的世界纪录
-
[49] IOS安全–浅谈关于IOS加固的几种方法
-
[48] 如何拿下简短的域名
-
[45] 【社会化设计】自我（self）部分――欢迎区
-
[45] android 开发入门
-
[42] 读书笔记-壹百度:百度十年千倍的29条法则
-
[41] Go Reflect 性能
-
[41] 界面设计速成
-
[40] 视觉调整－设计师 vs. 逻辑
