谷歌

谷歌在中国的办公室。 路透社 今年四月正式撤离中国大陆市场的美国搜索引擎谷歌周二流露出将调整在华战略意图。该集团表示，谷歌近日将完全停止将造访谷歌中国的网友自动转向在香港的网页的做法，谷歌将在一个新网页接受中国网民访问。谷歌在中国的互联网内容提供商（ICP）牌照将在6月30日到期。倘若谷歌继续将中国网民转向香港谷歌页面，这项牌照将不会获得更新延期。 该集团副总裁在集团官方博客页面上表示，未来几天，谷歌将完全停止将造访谷歌中国的网友自动转向在香港的网页的做法，谷歌将在一个新网页接受中国网民访问。他解释说，谷歌在中国大陆运行许可证之一，互联网内容提供商（ICP）牌照将在6月30日到期。倘若谷歌继续将中国网民转向香港谷歌页面，这项牌照将不会获得更新延期，谷歌也将无法在像“google.cn”这样的商业页面上运行，谷歌在中国将会页面全黑。 这位副总裁没有明确说明谷歌是否将重新屈从于中国的审查制度。 谷歌法律事务负责人大卫•特鲁蒙在他的博客上表示他在与中国政府部门负责人的谈话中意识到中方看来不能接受谷歌将网民自动转向香港网页的做法。如果谷歌继续一如既往的话，那么中国政府可能不会更新谷歌的网络信息供应营业许可。 路透社介绍说，在中国运行的所有网站每年都必须由中国工信部更新其信息供应许可证。业内人士评论说，这一更新一般只是走过场，很少出现拒绝更新的现象。 谷歌今年一月公开挑战中国的网络审查制度，威胁退出中国市场，曾经引发海内外舆论巨大反响。谷歌于今年四月将其网络搜索网站从北京前往香港，并且将中国国内网民自动“跳转”至谷歌在香港的搜索网页。谷歌公司的一名元老今年三月在接受华尔街日报采访时透露说，谷歌将网民转向香港网页的决定实际上是中国政府间接提出的建议。 路透社评论说，在中国设有两个开发中心，雇用数百名职工的谷歌公司可能已经为今年年初的公开反抗付出了沉重的代价，谷歌在中国的许多优秀的员工纷纷跳槽。另外，谷歌在中国的另外三个营业牌照也将于月底到期。   tags: 网络 – 言论自由

苹果应该“立刻公布”他们所收集信息的内容、时间、和目的。 “iPhone和其它GPS设备用户必须清楚自己的哪些数据被收集了。” 苹果最近修改了隐私政策，称公司需要收集数据用来提供位置服务，德国这场担忧正是由此引发的。 苹果称为了在苹果产品上提供位置服务，苹果及其合作伙伴和授权许可方可能会收集、利用分享精确的位置信息，其中包括苹果电脑和设备的即时地理位置。比如比如，当用户选择使用苹果的位置服务的时候，苹果有可能会和应用提供者分享用户地理信息。 鉴于德国对Google的要求，苹果还是谨慎为好。

康涅狄格州总检察长宣布他将领导涉及多州的调查，以断定谷歌是否在从全球无线网络中提取个人数据时违反法律。此公司已宣称数据采集并非故意。 Attorney General Richard Blumenthal said more than 30 states had participated in a recent conference call on the issue

本篇是本系列的最终章，将总结一下App Engine在使用方面的注意点，最佳实践和适用场景，最后会谈一下我对App Engine的一些期望。 注意点 执行速度偏慢：由于其分布式的设计，所以在速度方面不是最优的，比如普通的Memcache能在几毫秒完成操作，而App Engine的Memcache则大概需要50秒才能完成操作。 私有API：其API有很多都是私有，特别是在其服务方面，虽然Google提供了很不错的文档，但是在学习和移植等方面，成本都很高。 执行会出现失败的情况：根据很多人的实际经验，App Engine会不定时出现执行失败的情况，特别是Datastore和URLFetch这两部分，虽然Google已经将Datastore方面出现错误的几率从原先的0.4降至现在的0.1，但是失败的情况是很难避免的。 有时会停机：虽然总体而言，停机并不频繁，但是在今年初出现长达136分钟故障导致部分用户的应用无法正常运行，其发生原因来自于其备份数据中心出现了问题。 无法选择合适的数据中心：比如，你应用所面对的用户主要在欧洲，但是你应用所属App Engine服务器却很有可能是被部署在一个美国的数据中心内，虽然你的应用很有可能在将来移动至欧洲某个数据中心，但是你却无法控制整个过程。 有时会处理请求超时：虽然能平均在100至200ms之间完成海量的请求，但是有时会出现处理请求超时的情况。 不支持裸域名：只支持类似CNAME的子域名。 最佳实践 适应App Engine的数据模型：因为其数据模型，并不是传统的关系模式，而且在性能方面表现也和关系型数据库差别很大，所以如果想要用好非常关键的Datastore，那么理解和适应其数据模型是不可或缺的。 对应用进行切分：由于App Engine对每个应用都有一定资源限制，而且为了让应用更SOA化和更模块化，可以对一个应用切分多个子应用，比如，可以分成一个用于前端的Web应用和多个用于REST服务的后台应用。 极可能多地利用Memcache，这样不仅能减少昂贵的Datastore操作，而且能减轻Datastore的压力。 在上面提到过，由于App Engine在执行某些操作时会出现失败的情况，比如Datastore方面，所以要在设计和实现这两方面做好相应的异常处理工作。 由于Datastore不是关系型数据库，导致在执行常见的求总数操作时显的有点”捉襟见肘”，所以最好使用Google推荐的Sharded Counters技术来计算总数。 由于Blobstore还只是刚走出试验期而已，而且其他模块对静态文件（比如图片等）支持不佳，比如Datastore只支持1MB以内的对象，同时每个应用只能最多上传一千个文件，而且速度不是最优，所以推荐使用其他专业的云存储，比如Amazon的S3或者Google马上就要推出的Google Storage等。 尽量使用批处理方式，不论是在使用Datastore还是发送邮件等。 不要手动创建Index：因为App Engine会自动根据你在代码中查询来创建相关的Index。 适用场景 现在而言，App Engne主要适用于下面这三个场景： Web Hosting：这是最常见的场景，在App Engine上已经部署了数以十万计的小型网站（其中有很多主要为了学习目的），而且还部署了一些突发流量很大的网站，其中最著名的例子就是美国白宫的”Open For Questions”这个站点，主要用于让美国人民给奥巴马总统提问的，这个站点在短短的几个小时内处理接近百万级别的流量。 REST服务：这也是在App Engine平台上很常见的场景，最出名的例子就是BuddyPoke，BuddyPoke的客户端就是一个Flash应用，在用户的浏览器上运行，而它的服务器端则是以REST服务的形式放置在App Engine上，每当Flash客户端需要读取和存储数据的时候，它都会发请求给后端的REST服务，来让其执行相关的Datastore操作。 依赖Google服务的应用：比如应用能够通过App Engine的Email服务来发送大规模的电子邮件。 未来的期望 更稳定的表现，更少的超时异常和更快的反应速度，特别是在Datastore和Memcached这两方面。 支持对数据中心的选择，虽然现在App Engine会根据应用的用户群的所在地来调整应用所在的数据中心，但由于整个过程对开发者而言是不可控的，所以希望能在创建应用的时候，能让用户自己选择合适的数据中心。 SLA，如果App Engine能像S3那样设定一些SLA条款，这样将使用户更放心地在App Engine上部署应用。 新的语言：比如PHP，但是如果在现有的App Engine架构上添加一门新的语言，整个工作量会非常大的，因为App Engine有接近一半的模块是语言特定的，比如应用服务器和开发环境等，所以短期内我认为不太可能支持新的语言。 总体而言，Google App Engine是Google大战略中一个不可分割的一部分，因为Google希望能通过App Engine来降低Web应用开发的难度，只要难度降低了，那么Web应用替代客户端应用的整体速度将会加快，如果出现这样的情况的话，那么将会对Google今后的发展非常有利。 本系列文章结束。 参考资料： Google’s Dr.