云平台之 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）
• 支持多种编程语言
• 活跃开发者社区