chinasb.org是现在www.dongliu.net这个域名使用的反向代理，它同时也为其他数百个需要绑定ghs的站点提供免费的反向代理服务，借助它墙内的广大观众才能浏览这些站点。但是这个反向代理竟然被google封禁了，推测原因是应该从这个IP向google发起的请求数太多了。

现在访问只能得到这样一个消息页面：

这几天appspot.com的IP也有部分被墙盾掉了，但目前还有可用的IP，不知道其命运如何。

转载自：http://www.bityun.com/archives/341

yunster很遗憾，第一次发表GAE的文章就是负面的。虽然yunster前半年一直在搞GAE，但还是选择了中途放弃。原因多种多样，有 GAE在中国性能的问题，有稳定性的考虑，也有对开发通用性的前景担忧，当然还有更主要的原因是个人的坚持不够（呵呵，这个是主因）。yunster本人 是很羡慕像Livid这样的高手能够在GAE上开发出像V2EX这样的优秀项目，说到底yunster对GAE还是很期待的，毕竟是谷歌的服务，它的长久发展是毋庸置疑的。闲话少说，还是介绍这篇文章。

Carlos Bie是西班牙的一个开发人员。他的公司在几个月的延期后放弃了使用Google App Engine(GAE)。

在本周早些时候，Ble在他的博客中列了十三个原因关于他的公司为什么决定放弃Google App Engine。该博文在一天之内获得了89000个点击量和15个留言。一些是很同情他的遭遇，另一些则斥责他羞辱了Google，当这家公司已经做出很 多努力帮助他和他的团队更好利用这个平台。

一则留言来自Patrick Chanezon，Google的云计算及应用工具经理。出自对Chanezon的尊重和澄清他的观点，Ble更新他的博文但仍然觉得对他的批评中仍然有太多漏洞。

这里有Ble列出的关于他的团队遇到的五个问题：

1、GAE需要Python2.5, 这个版本太老了。使用Ubuntu的话就意味着你需要使用virtualenv或者chroot去保证可以正确使用SDK。 好吧，这不算什么。

2、你不能在你自己的域里用HTTPS, 因此一个安全的链接必须是建立在yourname.appspot.com上的，这太糟了。

3、没有请求可以超过30秒，否则就被强制断掉。天啊，这是最痛苦的事了。当我们上传数据到到数据库中（在no-sql 环境中叫datastore），上传的数据在30秒后被中断了。我们不得不分割文件和所有针对这种情况的挑战。运行后台任务(cron)不得不做得非常谨 慎，因为要遵守同样的规则。对于网站管理员来说，有太多的任务需要超过30秒了。你能想象么？

4、每个服务器发起的到其它站点的GET或POST请求如果5秒内没有完成将被中止。你可以配置到最多十秒。这就使得频繁访问Twitter或者Facebook变得不可能，所以你需要中间服务器。再一次，这加倍了你完成一个简单任务的时间。

5、你不能使用基于C语言的python库，只能是原生库。忘掉那些你用过的强大的第三方库吧。

Ble写道十月份GAE再次挂掉了。他说他们遇到了500错误代码，60%的时间系统宕掉了。用户不能访问或者注册该站点。

Ble承认他应该更小心一些但他曾信任的Google。

“对于我们来说，GAE已经象Wave或者Buzz一样失败了。我们已经在经济上付出了代价。我曾经很固执因为有这样伟大的公司做后盾。然而我学到了重要的一课。好公司一样会犯错。我应该在花掉这么多钱之前事先做一些调研和收集一些证明。我太瞎了。”

很多批评家们并不同情Ble的遭遇，他们说他应该做更多研究，肯定有设计的缺陷。

然而接下来是Eugene Ciurana的留言，一本GAE书籍的作者。

“Carlos, 我在很多年前写过关于GAE的第一本书，出版后我有很多机会去讲述python和Java的平台。我比较早地意识到关于”GAE是如何工作的”变成”如何 当心GAE”，最终建议大家不要在重要的应用上使用GAE。我欣赏你的博文，并发推推荐它，因为这是一个非常重要的警示。我工作中的大部分内容是如何扩展 和提高可用性。我曾很喜欢它是因为它提供了RESTful服务。真实的应用仍然是基于数据中心的或者放在Amazon或Rackspace上的。关于 NoSQL系统，Datastore很难成为一个成功的例子，它对GAE是够用的但你现在知道了它的缺点。记住! 永远用正确的工具做正确的事。我的建议是，你应该区分到底要基于文档还是基于列的数据存储，还要适应检索的需要，你应该看一眼mongoDB和HBase。我们正在大企业客户的生产环境中同时使用它们，没有什么问题。祝你好远，Eugene Ciurana”

Chanezon在他的留言里说Google已经了解到Ble的很多观点，他说公司正在修复这些问题。

Chanezon强调读GAE文档的重要性。他说局限性已经列出来了。这个服务设计的初衷就是了为了高扩展性的应用，即需要快速扩展到大量用户或数据。他提到Gri.pe就是一个典型的例子。

你觉得如何？Ble说的有道理吗？

原文翻译：atutest

文章来源：http://www.readwriteweb.com/could/

最近一段时间，发现gae上request的cpu占用明显的多了，cpu占用的配合比之以前增加了好几倍。看后台的日志，大量的request持续了较长的时间，占用了异常多的cpu。这些request都报出了

“com.google.appengine.repackaged.com.google.common.base.FinalizableReferenceQueue <init>: Failed to start reference finalizer thread. Reference cleanup will only occur when new references are created.”

这样的异常。Gae 开发者解释说这个异常抛出是正常的，原因是Gae是不允许起后台的线程的；GAE捕获了这个异常并输出到INFO级别，并且，理论上这个异常也不会对性能产生影响。

但是为什么异常出现的request，耗时都特别长呢？原来这个异常通常是出现在GAE重新加载你的web应用的时候。也就是说，这种request到来的时候，GAE启动了一个新的web container！这个过程是很耗时的，需要load很多相关的class。现在看来，当第一个请求进来的时候，GAE会起一个container来加载应用，这个instance会持续一定的时间，如果在这段时间有新的的请求，就由这个instance来处理了。如果一段时间内(这个时间现在貌似在2分钟左右)没有新的request到来，GAE就会关掉你的web server销毁这个instance。当这个instance销毁之后，一个新的request到来，就又会启动新的instance了。google 最近应该是对这方面的策略做了一些改动，或许是生存时间之类的参数变短了，总之现在大量的请求到来的时候需要新的instance，导致耗费了大量的CPU和较慢的响应。

java还是太重了，不适合这种速生速死的应用方式。GAE的技术人员已经声称会改善这个问题；自己写个cron job每一分钟去访问自己的服务也可以极大的减少web应用重启的次数。另外，减少jar包依赖对于减少重启时间也是有帮助的。

这又是一篇技术文，同时也是一篇牢骚文，正常人类可以跳过了。

GAE最近发布了1.30版本，提供了Blobstore功能。GAE是不允许写文件的，Datastore中提供的存储服务每条记录最多只能存储1M的记录，而Blobstore可以提供最大50M的文件存储。同时GAE也提供了用于处理文件上传/下载的handler，只要在上传文件的form表单中指定upload的url就行了，BlobstoreService会自动处理上传请求，存储文件及文件的类型和信息，并返回文件记录的key。

这个功能对于GAE残次的文件功能算是聊胜于无吧，看到更新后兴奋了一下，决定动手把原来的的文件上传迁过去了；然后，很悲剧的发现，现在这个功能只向付费用户开放！

Blobstore用不了就折腾点别的。原想做个发文自动推送到qq空间的功能，因为qqzone现在是支持email发文的，所以想通过邮件这条路来做。要动手才发现google和腾讯真是一对残次品，GAE发邮件只支持使用自己的smtp服务器，qq空间只接受qq邮箱smtp server发送的文章。直接走肯定是通不了了，难道要gae先发送到QQ邮箱，QQ邮箱再自动转发到qqzone里吗……

然后又看了下豆瓣的开发API，决定折腾这个。豆瓣是个技术狂热型的公司，这从他们使用python语言，以及提供开放API，以及API走gdata协议都可以看出来。但是他们的java API client再次让我郁闷了。这么个小的API client，竟然依赖那么多jar包，jar爆炸就是你们这种人造成的！好吧，依赖gdata这些还情有可原，依赖httpclient你是唱的哪处戏啊！httpclient这种，3.x到4.x一升级API全变……并且使用还很广泛，别的项目如果已经用了4.x的jar包，你豆瓣的API client何以自处，根本就放不进去了嘛。你看看你家老师Google的java API client，什么时候使用过httpclient。

回到老话题上，最悲剧的是GAE根本就不支持httpclient……又是一对残次品。悲剧的后果是没法用豆瓣的API client，直接上体力活去解析人家很高级的gdata数据。

结论：GAE现在根本不是云，也就算是一片小水雾。

我的blog开放了匿名评论以后，一直以来都挺平静的，没有垃圾评论，多半因为它本来看的人就不多……但是前端时间不晓得是哪里的谁忽然看上它了，spam扑面而来。国庆前两天就有苗头了，但我直接把垃圾评论删了了事，也没在意。回家待了几天回来，已经上白天spamming信息了。

所以我终于决定要解决一下GAE上的验证码问题了。本来生成验证码是件挺简单的事，JDK就有把文字打到图片中的方法；而且还富有大量第三方的Captcha库，能生成各式各样的验证码，诸如背景带斑点的，文字扭曲的，英文的，汉字的，机器看不懂人也看不懂的……一应俱全。但是悲剧的GAE啊！作为谷歌一直鼓吹的云，连一点点图片io操作都不支持，所有和图片相关的jdk接口全上了它的blacklist！

真是恨GAE不成钢啊。无奈之下决定山寨到底，自己从头动手：

1. 开个矩阵存放图片每个像素的RGB值，自己手动在RGB矩阵里划出数字和字符来……由于字符实在太多就只画了10个阿拉伯数字，而且横平竖直的像老式电子表中的数字
2. 写个纯java的图片编码工具，把RGB值矩阵编码成gif或者png格式的byte流，写到response里。

山寨是山寨了点，不过总算是整出来了，对付一般的小蟊贼够用了。

Google 应用系统引擎最初是以 Apache Tomcat 作为其 webserver/servlet 容器的，但最终将切换到 Jetty 上。这个决定让许多开发人员都诧异的想问：为什么要做这样的改变?Tomcat 有什么问题吗? 我们获得的一次访问 Webtide ——Jetty 背后的公司——里的这个团队的机会，得到了关于这个决定背后更详细的信息。

记者： 为什么Google选择Jetty作为其应用系统的引擎，而不是 Tomcat 或其他的?

Google选择Jetty的关键原因是它的体积和灵活性。 在云计算里，体积的因素是很重要，如果你运行几万个Jetty的实例(Google就是这样干的)，每个server省1兆，那就会省10几个G的内存(或能够给其他应用提供更多的内存)。

Jetty 被设计成了可插拔和可扩展的特性，这样Google就可以高度的自定义它。 他们在其中替换了他们自己的HTTP connector，Google认证，以及他们自己的session集群。也真是奇怪，这个特性对于云计算来说是非常出色的，但同时也让Jetty非常适合嵌入小的设备中，例如手机和机顶盒。

记者： 是什么促使Jetty成为Java里出色的servlet容器?

我们在开发Jetty时，并没有想着要把它开发成一个全功能的应用server(尽管它是的)。每一项功能都考虑了可插拔性，所以，如果你不需要他，你就可以不把它加载到内存里，把它从request 处理调用链中去掉。如果你不需要sessons，你可以把session处理器拿掉，这样你就不要浪费资源去来回寻找session cookie了。当你每秒钟都有出来上千个请求时，这些微小的查找动作的开销是非常的大的。

我们也并没有想当然的企图通过设计就可以得到最优化的代码，我们是如同收集沙粒般，每次得到一些人告诉我们如何才能有好的JVMs优化和垃圾回收办法。这是真的，已经很小心的代码仍然能被优化，最后的效果就是避免创建新的对象。例如，我们在Jetty里使用并行处理技术，但我们并没有使用很多标准的并行处理数据结构，因为这需要创建太多的对象。所以，只是作为个例子，我们使用了双并行锁循环 arrays，而不是采用并行链式 lists，这样我们就能够在不创建对象的情况下，获得了非阻塞并行效果。

记者： 是什么使Jetty成为开发人员的一个有用的server平台的(例如：testing)?

Jetty 已经在一些流行框架中内置了，例如GWT，scala/lift，grails，Jruby等等，还有很多。如果你使用了这些技术，你就直接可以用 Jetty了。 Jetty-maven 插件是另外一个非常优秀的开发工具，它能让web应用在不打包成war文件的情况下运行。源文件可以直接编辑，在不需要把它重新放进war文件的情况下获得测试结果。 Jetty嵌入式的特征让我们不再需要写通过写那些main方法、通过你的IDE，调试器或 profiler 来运行之类的无聊的事情。

记者： Jetty在处理 client-server 请求时有什么独特的地方吗?

Jetty 现在是一个第二代的异步处理server。过去的两年里，我们让Jetty实现了处理异步请求的功能，这成了它核心架构的一部分。就像其他的支持异步 serlets容器一样，我想，他们会发现这个东西并不是看起来的那么简单和容易。 我们的异步HTTP引擎被我们复用在了HTTP client 上，所以我们可以大量的降低request 和 responses 消耗。

同时，就像我之前提到过的，我们的请求处理器是可扩展和可插拔的，这让web application可以被单独省略掉，或者是单独使用，或者是进一步扩展的application。

记者： 有没有其他Jetty使用的案例，大的或小的?

使用Jetty的公司有像Zimbra/Yahoo，这意味着Jetty正作为web mail 服务器，为百万级的用户提供服务。 Eclipse IDE把它内置了进去，这意味着有成百万的开发者在桌面运行Jetty。 Jetty被 hadoop map/reduce cluster使用，在其上有几千个点的集群，处理着世界最大的TB级别的数据分类排序工作。 我们也有 J2ME 的接口，有本地编译器，所以我们可以在手机上，家用路由器和 Java cards 上运行。 更多的Jetty使用的例子可以参考 http://docs.codehaus.org/display/JETTY/Jetty+Powered

记者： Jetty的将来或蓝图是怎样的?

Jetty 最近的计划是发布 7.0.0 版本，这将会完全的迁移到eclipse foundation 下。 Jetty 7 将会支持很多 servlet 3.0 的特征，但是并不会使用新的API 和 不会依赖Java 1.6 。 Jetty 7后，很快我们会发布Jetty 8，这将会完全支持 servlet 3.0 和 Java 1.6，Jetty 会继续的创新 和跟踪各种web 2.0 里的其他的新成果。我们现在已经能支持 Firefox 3.5 里的跨域Ajax功能，我们可以在cometd版本里使用这个。我们很快就会增加对 WebSocket 和 BWTP 的支持。 对 Google wave 以及相关协议的支持的问题已经优先排到了我们的议事日程上了。

记者： Google/Jetty 还有其他的计划吗?

Google有他们自己下棋的棋局，我们并不清楚。 我们在JavaOne大会上曾经和App Engine开发者们有个简单的对话，我们愿意听他们任何的反馈和意见，用来改进Jetty的可嵌入性和可扩展性。

下面的跟Webtide团队的讨论中，我们询问了SpringSource 从Jetty转换到Tomcat的事情。

记者： 你们如何看待 SpringSource 把 Grails 从本来作为缺省容器的Jetty换成了Tomcat的事情?

原因是grails开发的领导感觉使用Tomcat能从内部的Tomcat开发人员哪里获得更好的”服务“。我猜测，他们把Grails的用户驱赶到某一个平台，以让SpringSource能更好的销售他们的技术支持服务。几年前我们看到了相同的事情，JBoss 雇佣了一下tomcat开发人员后把Jetty提出成了Tomcat，并最终和Mort Bay达成了商业合同。很遗憾，这些商业协议对技术选择有如此大的影响，当相同的是，一些基础结构的工程也正聚集到也application server 为中心的队伍里来。

Grails将会继续同时支持对Jetty和Tomcat的集成，但会改成Tomcat为缺省服务。

这看起来是 SpringSource使用/攀附 Tomcat 的一个特别合适的论断。
新闻来自:读译网

Google app engine限制实在太多，用来写blog还行，想要商用简直是痴人说梦。能想像一个连生成验证码这样的功能都不可能支持的host么，能想像一个不能上传文件，request/response都有莫名奇妙的时间限制，数据库查询只能有有一个不等条的host么？就现在的功能来说说，GAE也只能做个玩具，指望这个跟Amazon EC2、MS Azure拼那是完全没戏的。

应该说，GAE终于支持java了。java在开源社区和厂商都有广泛的支持，有众多开源的框架、库可供使用。使用java语言的人数是使用python语言的N倍！

点击http://appengine.google.com/promo/java_runtime申请GAE for java！

这两天不知道出什么事了，app engine的多个IP地址都无法访问了，仅209.85.171.118一个还暂时可用。开代理还是可以上去的，看样子应该是被GFW了。不知道这次盾是抽风误杀还是盯上app engine了，希望过段时间能好起来，不然枉费了在app engine上花的那么多功夫。

以前在blogspot的blog就因为被盾放弃了，不过这次要坚持到底。盾是在进化的，一开始可能直接封IP，域名，等摸清楚底了就可能只用关键字过滤了。blogspot,wiki都可以放开的话，那app engine也会有放开的时候。

Google App Engine现在开放注册了。每人可以创建三个application ，每个application 可以免费拥有500M空间，以及足够支持每月500W次PV的cpu时间。对于个人来说，这已经足够使用了。

Google App Engine目前只能使用python，可以使用python的大部分标准库，在将来可能加入对其他语言的支持。

下面是我的GAE application，用了水木上一个人写得简单的blog。
http://xine.appspot.com/