SaaS 平台 以应用为中心 “平台”本来就比较泛,再加上“SaaS”的话就更飘渺了。 我们先从一个简单的场景来看: 开发者开发应用后在市场上线 用户购买应用使用 开发者通过市场反馈调整运维,为后续版本计划提供依据 新版本上线,用户升级使用 这是以应用为中心的一个闭环(市场-开发-运维-市场),实现了应用的整个生命周期 ..

云平台之 SaaS 随想

本贴最后更新于 1863 天前,其中的信息可能已经水流花落

SaaS 平台

以应用为中心

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

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

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

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

组成元素

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

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

面向应用用户

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

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

PaaS 与 SaaS

另外,SaaS 不是必然包含 PaaS。开发者在选定了 SaaS 后应该也可以选择 PaaS。但这个方式需要开发者熟悉多种平台,提高了运维的难度。

应用引擎

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

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

目前我们熟悉的几个 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;可以接入外部应用。自下而上、自上而下,包罗万象、井井有条。

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

 

  • 云计算
    40 引用 • 64 回帖
  • Docker

    Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口(类似 iPhone 的 app)。几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架或包括系统。

    225 引用 • 412 回帖 • 638 关注
  • golang

    Go 语言是 Google 推出的一种全新的编程语言,可以在不损失应用程序性能的情况下降低代码的复杂性。谷歌首席软件工程师罗布派克(Rob Pike)说:我们之所以开发 Go,是因为过去 10 多年间软件开发的难度令人沮丧。Go 是谷歌 2009 发布的第二款编程语言。

    319 引用 • 1158 回帖 • 731 关注
  • PaaS
    7 引用 • 8 回帖
1 回帖   
请输入回帖内容...
  • zx API  

    [em02][em02]