用这8个概念说一说软件服务SAAS
这几年，数字化的概念很火爆。
本文从黄奇帆先生《结构性改革》一书中关于数字化的解读开始
所谓数字化，是指大数据，人工智能，移动互联网，区块链等一系列数字化技术组成的「数字综合体」
数字化的三大功能
第一个是 IAAS，基础设施作为使用的服务。
第二个 PAAS，大数据平台作为使用的服务。
第三个是 SAAS，算法应用软件作为一种服务。
这三个词，代表数字化的三兄弟，三种不同功能的软件。
重点来了，写这篇文章的目的是想从软件技术实现的角度，拆解 SAAS 软件实现的一部分原理。
为什么是一部分，因为 SAAS 的概念很宽泛，有点类似之前的微服务。有不同维度的理解。很难在一篇文章，几千字内讲明白。
01 SAAS
SAAS 这种软件形态的产生是为了降低软件复杂性，方便大型软件售卖和服务。
SAAS 全称是软件即服务，作为一种软件售卖方式，用软件的方式解决客户问题的一种价值交换方式。
说到这里我们先了解互联网行业下的「服务商模式」
前几天著名的软件服务商 有赞 被爆大规模裁员，而裁员对象主要以技术研发人员为主。
有赞的产品就是依托于大平台流量，为中小企业做软件服务。
通用版本或者定制化付费服务开发。
我们经常会评论一个公司是以技术起家，还是以销售或者产品起家。
在互联网行业，虽然目前很多技术门槛很低，甚至技术很廉价。
一个事实是，并不是所有的公司都有能力拥有自己的技术团队，有必要长期维护一支技术团队。
很多互联网大厂基于它们的技术，人才，资本等各种优势构建出的技术平台能力，背后总会有下游的「服务商企业」
这些服务商做的事就是基于大平台的技术能力，为他们的客户提供技术服务。
如下图所示，我们看看
02 服务商
微信开放平台关于服务商的定义
服务商
微信支付服务商需要具有一定的技术开发能力，基于平台开放的多种产品，为特约商家完成开户申请、支付接入、技术开发、机具调试、活动策划、经营管理等全生态链服务。为微信支付商家提供服务支持的服务商可申请奖励。
来提取关键字
01 依托于平台开放
02 生态链服务
一句话解释
在开放平台的基础能力范围内，为用户提供软件服务
基于开放平台做业务
技术上需要保证数据隔离和应用隔离。
Saas 形成是追求共性的过程，Saas 生态化是求同存异的过程，所以当我们能够满足大部分客户需求时，我们得考虑大客户的个性化需求场景
03 开放平台
我们通常可以接触到的开放平台，微信开放平台，公众号开放平台，抖音开放平台
没错，就是这些大厂提供的业界行业标准，或者说某一个领域的通用行业解决方案提供者
开放平台会有多个参与者，平台基础能力提供者，开发者，客户商户等。具体可以参照我之前写的文章
读到这里，我们陆续上一些生涩的技术概念，别忘了这是一篇软件设计思路文章，以 SAAS 软件的设计要素为关键词
04 开发者
SAAS 服务软件的第一个特性是应用隔离
开放平台和服务商通过开发者开发应用的形式把自己的技术能力对外开放。
通过各种应用提供软件服务。
应用隔离
对于客户来说，客户的业务系统在服务器上是独立的，这种独立包括数据存储，算力执行，对外展示，账户系统等等。
对于平台及服务商来说，客户的应用是分散的，可控的，集中管理的。
05 应用标识
开放平台使用 app_key 标识应用。
与 app_key 对应的是 app_secret。
应用开发者在开放平台申请应用时，开放平台会为开发者颁发 app_key 和 app_secret。
app_key 和 app_secret 的理论基础是 OAuth 协议中的客户端 ID（client ID）和客户端密钥（client secret）。
核心作用是向服务器申明自己的身份，是授权的一个参考基础。
06 协议标准
开放平台相关的协议标准，离不开 OAuth
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
OAuth 的核心作用是颁发授权码
授权是为了应用安全，授权又会涉及功能实现的各个周期以及不同类型的码。
比如 微信开放平台中关于 access_token 有这么一句话
为了安全考虑，开发者请勿将 access_token 返回给前端，需要开发者保存在后台，所有访问企业微信 api 的请求由后台发起
07 应用角色
The Third-Party Application: "Client" The client is the application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.
The API: "Resource Server" The resource server is the API server used to access the user's information.
The Authorization Server This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.
The User: "Resource Owner" The resource owner is the person who is giving access to some portion of their account.
OAuth 定义的四种角色中，app_key 是在 Client 这个角色中做文章。
授权方式
在 OAutth 协议体系中，客户端获取授权码有四种方式。
- 授权码（authorization-code）
- 隐藏式（implicit）
- 密码式（password）：
- 客户端凭证（client credentials）
哪一种授权方式，第三方应用申请令牌之前，都必须先到授权服务器备案，说明自己的身份，然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）
总结一下以上涉及到的相关概念
开放平台参与角色，授权方式，身份认证方式。
如需深入了解，建议阅读主流开放平台的技术文档，OAuth 协议规范
回到本章开始的问题，如何实现应用隔离？
总结
理论基础是 OAuth 协议下的 client ID，实践参考是 app_key 的场景应用。
08 一切皆应用
用 app_key 做标记
在前后端分离的大背景下，应用开发会有两个大的阵营，服务器和客户端。
客户端环境可以理解为一个一个的应用组成的集合，我们可以用 app_key 做标记。
我们出一个简单的设计模型
app_key 的周期开始于云端服务中心，由云服务中心进行分配和管理。
数据表中按需增加字段 app_key。
应用场景包括
- 不同的端创建不同的应用
- 不同的端共享云服务的接口能力
- 使用 app_key 做必要的数据隔离和应用隔离
在特定场景的技术发展阶段，一定会出现各种各样的应用
以上也可以扩展为多租户应用设计的一部分
如果你是程序员，从业者，那这篇文章设计的概念应该是标配。
如果是产品或者运营等其它行业从业者，能了解这些就足够了。
今天发现一张产业生态的图分享
欢迎一起交流，输出更多 SAAS 相关的分享
参考网址
https://aaronparecki.com/oauth-2-simplified/
https://oauth.net/2/
《结构性改革》