金氧

云平台之 SaaS 随想

SaaS 平台

以应用为中心

“平台”本来就比较泛,再加上“SaaS”的话就更飘渺了。

我们先从一个简单的场景来看:

  1. 开发者开发应用后在市场上线
  2. 用户购买应用使用
  3. 开发者通过市场反馈调整运维,为后续版本计划提供依据
  4. 新版本上线,用户升级使用

这是以应用为中心的一个闭环(市场-开发-运维-市场),实现了应用的整个生命周期,我们可以把平台看成是这个场景的支撑,场景中的所有活动都是在平台上完成的,整个场景就是一个 SaaS 生态系统。

组成元素

在这个 SaaS 生态系统中,我们可以简单总结出以下几个必须的组成元素:

  • 开发者:个人/组织,要做的事情是开发应用、运维应用
  • 运行环境:应用程序实际运行的环境,要解决的是如何接入/部署应用
  • 运维控制:应用运行情况监控,要解决的是动态监控
  • 用户:使用应用的个人/组织,要做的事情是(购买)使用应用
  • 社区:开发者社区、用户社区,供开发者/用户进行分享、反馈
  • 应用市场:应用上架展示,供开发者应用上线,用户(购买)使用

按参与者角色(开发者、平台、用户)把这几个组成元素分类后,SaaS 平台部分包括了:运行环境、运维控制、社区、应用市场。这里的“平台”是个广义概念,是多个具体平台的综合。例如“Android 平台”,包括了开发平台、应用市场、硬件平台、开发者社区等。

面向应用用户

如果把 SaaS 应用比作是一个游戏,那么,

  • SaaS 平台制订了基本的游戏规则,并提供了游戏道具
  • 开发者制订了游戏的细节规则,形成游戏玩法
  • 用户选择游戏,玩游戏

最终,用户的体验是该游戏是否好玩,这是由平台和开发者共同决定的。也就是说,SaaS 平台和开发者是利益共同体,并且平台的基本规则决定了游戏的质量的起点。

PaaS 与 SaaS

从用户角度看:PaaS 面向的是开发者用户,SaaS 面向的是应用用户
从应用角度看:PaaS 侧重应用的 Runtime,SaaS 侧重应用的接入与集成
PaaS 不关注应用业务领域,SaaS 则是某业务领域
PaaS 成功与否看的是开发者的反馈,SaaS 成功与否是应用用户的反馈
另外,SaaS 不是必然包含 PaaS。开发者在选定了 SaaS 后应该也可以选择 PaaS。但这个方式需要开发者熟悉多种平台,提高了运维的难度。

应用引擎

应用引擎(App Engine)是目前业界实现 PaaS 的主流方式。它至少需要为开发者提供以下几个功能:

  • 部署:上传部署包部署
  • 实例管理:启停实例
  • 日志:查看日志,分实例

内部至少需要实现以下几个功能:

  • 请求路由:请求分发到应用进程实例
  • 状态采集:基础设施、实例状态采集
  • 应用隔离:应用之间不能相互影响
  • 实例管理:按需启停
  • 资源控制:应用对资源的使用是受控的
  • 耗用统计:API 调用次数、IO/存储大小
  • 配额模型:量化应用对资源的使用

目前我们熟悉的几个 XAE 都是这样做的,并且从传统的沙箱模型(API 受控)迁移到基于 LXC 的容器(Docker)已经是趋势,因为这样对应用开发的限制更小,开发者更容易接受。

服务

目前业界主流的 PaaS 中都提供了基础服务,这些服务都是属于技术服务:

  • 缓存
  • 消息队列
  • 消息推送
  • 文件存储
  • 定时任务
  • ...

这一块相对比较固定,调用方式一般都是基于 SDK API,有的也有 RESTful 接口。

部署包

以 Java 为例,部署包一般都是 war 包,但除了满足标准 war 结构外,还需要加入一些平台特定的配置规则。比如通过配置文件描述 appid(或是通过 war 包名),用于部署时对应到平台上的应用配置。也就是说所有的应用配置都是可以做成非包内配置文件的,好比应用上某些地方需要抉择使用数据库或配置文件,这是平台设计时需要仔细考虑的。

应用集成

应用集成主要是针对 SaaS 而言,用户选择多个应用后可以在一个视图中使用它们,这些应用之间也可能存在调用交互。

视图

最简单的视图集成方式就是通过导航(图标),用户安装了某应用后,该应用图标就出现在这个用户的“首页”视图中。由平台给出集成规则,应用开发时遵循这些规则就可以集成进来。

对于平台来说,这一块很有难度,或者说很难把握:

  • 如果集成规则太复杂,那会对开发者造成很多困扰和不便,但对用户来说就更透明、无缝,用户体验会更好
  • 如果集成规则太简单,那对开发者约束较低,但集成度也更低,用户体验可能很难提升

目前业界的大多数 SaaS 在做这一块时都选择了简单的集成方式:接入图标,用户使用时点击图标并跳转到对应的应用。深度的集成(样式、交互模式统一)的方式很少见(互联网 SaaS 基本不可行,除非已经是业界标准)。

RPC

服务端的调用也存在集成,应用之间互调也是 SaaS 需要考虑的场景。这部分可选的做法是 SaaS 提供 RPC 协议实现,这样应用间可以通过统一的调用协议进行互调。当然,也可以通过 HTTP 来实现,这样限制更少一些,但平台对应用的管控也会更弱。

多租户

多租户支持主要目的是简化应用开发,让应用可以全心全意关注业务逻辑而不是关注租户相关逻辑,具体细节请参考这里

开放平台

前面我们提到过 SaaS 应该是可以接入其他 PaaS 应用的,这类应用我们可以认为是“外部应用”。既然是外部应用,那肯定是需要特定的接入规则,可以考虑参考行业标准规范。

OAuth

通过该协议,SaaS 可以将服务(甚至是一些应用)暴露为 RESTful 接口给外部应用使用,这样可以充分利用平台的资源,吸引更多的应用进入到 SaaS 这个生态系统中。

分润

最终买单的是用户,SaaS 平台和开发者是利益共同体,所以平台在指定规则时需要考虑好与开发者的分润。对于部署在 SaaS 内的应用和外部应用,分润规则应该是不一样的。下面是两种简单的方式:

  • 内部应用:通过平台提供的支付接口进行分润,应用好卖,平台跟着受益
  • 外部应用:应用支付给平台配额耗用费用,应用固定支付给平台其资源使用费用

总结

SaaS 需要从至少两方面进行设计:基于特定的 PaaS;可以接入外部应用。自下而上、自上而下,包罗万象、井井有条。

平台最终比拼的是应用资源而不是平台本身,尽可能吸引开发者是很重要的成功前提。要做到这一点,我们需要:

  • 垂直领域(例如协同办公)
  • 降低开发门槛(减少配置,轻量化 SDK)
  • 概念具象化(例如多租户)
  • 实现采用业界主流技术(Golang/Docker)
  • 支持多种编程语言
  • 活跃开发者社区

« 跨域 Cookie 实现单点登录 Swift中下划线和"#"的妙用 »