D 的个人博客

但行好事莫问前程

  menu
417 文章
3446695 浏览
10 当前访客
ღゝ◡╹)ノ❤️

BAE、SAE 与 GAE 对比

从数据库、应用配置、计费、域名绑定、平台服务对比了 BAE、SAE 以及 GAE 的优劣,最后给出云平台选型的建议。

数据库

SAE 不支持 InnoDB(可申请支持),BAE 默认支持。

BAE 不支持数据库连接池(c3p0、BoneCP 已测不支持),数据库连接不能长时间保持。

GAE 使用 Datasotre 存取数据,最近也提供了云 SQL(MySQL),但申请比较困难,配额/性能笔者未测试过。

另外,SAE 显式给出了主从库的访问方式,应用可以比较灵活地设计存取策略,例如读写分离。并且 SAE 是每个应用都拥有自己的数据库,而 BAE 是所有应用共用一个库。

应用配置

BAE 的 duapp-web.xml 基本是抄袭 GAE 的 appengine-web.xml,元素基本一致。

比较奇葩的是 BAE 静态资源配置默认所有后缀为静态文件类型(例如 .html)的请求路径都默认假设为静态资源,需要在 duapp-web.xml 中指定排除。

计费与配额

SAE 按应用天计费“豆豆”,服务也按流量计费、CPU 时间、调用次数计费。注册或活动送配额,否则需要购买。

BAE 目前还没有详细的计费,只限定了应用数。公测结束后应该会细化计费模型。

GAE 目前的计费模型主要是按 API 调用计数,流量分为 In/Out 配额。每天会定时刷新免费配额。

综上,GAE 的计费一目了然,主要就是 API 调用次数;SAE 的计费比较复杂,不同服务有不同的计费策略;BAE 还没有明确的计费模型。

域名绑定

GAE 开通企业套件后随便绑,企业套件有免费版。

SAE 需要确认通过域名备案才能绑定,并且绑定后的流量计费翻倍。

SAE 目前可以随便绑,但没备案的话绑定域名的请求走海外中转,流量计费翻倍(原二级域名请求计费不变)。

BAE 目前可以随便绑,但没备案的后果自负。

平台服务

SAE 提供了 SDK 包,包含了开发需要的本地服务实现。

BAE 则分别提供了服务 Jar,调用方式按不同服务而异。

GAE 提供了完整的 SDK 包,包含了开发需要的本地运行环境和配置客户端。

综上,GAE 提供了完整的平台化服务,覆盖了从开发到上线运维的一系列工具;SAE 则提供了部分工具,平台化不完整,增加了开发、运维难度;BAE 则是分别提供不同服务给开发,没有统一的 SDK 与调用方式。

另外,值得一提的是 BAE 虽然服务没有整合到一个 SDK 中,但其分散的服务也比较适合应用自己选择。 其中云消息(消息服务)以及云触发(数据变更通知)是 GAE/SAE 没有提供的服务,某些业务场景应该会非常适用。

结论

SAE 与 BAE 主要还是面向应用部署托管,普通应用修改后易迁移部署到 BAE 或 SAE。

新应用开发可以选择和平台绑死(依赖平台服务)或按照普通应用开发。

使用配置工具来上传、更新应用配置其实是非常好的方式,但目前 SAE/J、BAE/J 都没有提供客户端配置工具,这增加了使用者的维护工作量。

GAE 提供了比较完整的服务平台,覆盖了应用的生命周期,最近也提供了云 MySQL 服务以吸引更多开发者。

需要根据应用类型来考虑平台选型,例如 GAE 基本以 API 计数的配额就不适合做社交应用,‘墙’的问题也需要考虑解决方案。