SaaS 架构基础理论
Posted 桂林米粉必加鸭脚
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了SaaS 架构基础理论相关的知识,希望对你有一定的参考价值。
SaaS架构基础理论
《互联网时代的软件革命 SaaS架构设计》学习笔记
1、背景
云计算提供的强大软硬件环境和基础服务,将逐渐成为支撑SaaS应用的基础设施。各个云计算平台所包含的大量具有自身特色的公共服务,将为SaaS应用的开发提供了丰富的资源。而统一整合各个云计算平台的公共服务,也成为了SaaS服务集成平台SIP的发展目标。未来的SaaS应用将架构在又SIP整合的多个云计算平台上。
2、SaaS商业模式
2.1、什么是SaaS
ASP是Application Service Provider“应用服务提供商”,这种模式将用于需要的软件统一部署在应用提供商的软硬件环境中,软件运行所需的人力、物力资源都有提供商维持,而用户只需要在自己办公室使用这些软件即可。------重点在于提供有软硬件环境这样的服务,且网络带宽和软件技术上有限制,ASP用户体验不好,用户无法接受自己软件和数据交由第三方托管。
SaaS是Software as Service“软件即服务”,用户对软件的需求实际上是对应用服务的需求,而用户使用软件实际是在消费应用服务。软件的用户是服务的需求者和消费者,而软件的提供商是服务的提供者和生产者。----对于软件来说,离开软件提供商的支持和维护,很难真正用起来。
ASP | SaaS | ||
---|---|---|---|
不同点 | 看问题角度 | 站在软件开发商角度看问题,希望以一种新的新式向用户提供软件 | 站在用户角度看问题,考虑用户需要什么,搞清楚提供软件的本质是未来提供服务 |
不同点 | 关注目标 | 开发商只是为了解决用户硬件环境的持续维护问题,应用服务的统一托管 | 关注软件本身,是否能为用户提供有效的服务 |
相同点 | SaaS和ASP之间形似而神不似 |
2.2、SaaS软件的优势:
2.3、SaaS劣势:
- 对互联网的依赖,已经不是问题
- 数据安全性:传统软件用户数据存放在自己的电脑商或企业自己的服务器中,用户自己维护数据的安全性;-SaaS软件的数据库一般配备有双机热备分系统,实时备份用户数据。
- 数据保密性:传统软件数据由用户自己保管;SaaS软件商自身信用建设。
3.SaaS应用架构
3.1、SaaS成熟度模型
SaaS相对传统软件,将原本由软件使用者所承担的软硬件、网络、系统维护的费用,转成支付给SaaS服务提供商的租用费用;
对SaaS服务提供商,依然需要承担相应的软硬件、网络、系统维护等费用。除了降低软件使用者的第一次一次性投入成本呢,将一次性的投入转变为时间、需求的逐步投入。
比较项 | 传统软件200个客户的综合成本 | SaaS软件200个客户的综合成本 |
---|---|---|
软件开发成本 | 取决与客户需求的异同,以及软件可配置性的强弱 | 1个软件开发成本 |
服务器成本 | 200台服务器 | 10台服务器 |
网络设备成本 | 200套 | 5-10套 |
IT维护人员成本 | 200人 | 2-3人 |
3.2、SaaS成熟模型分级
SaaS软件要降低企业综合使用成本最主要的手段是发挥SaaS的规模效应。
规模效应是商业模式和应用架构,一般采用多个租户共享一个运行实例的架构(Multi-Tenant,多租户架构),高性能,可配置,伸缩性。
可配置 | 高性能 | 可伸缩 | |
---|---|---|---|
Level1 | × | × | × |
Level2 | √ | × | × |
Level3 | √ | √ | × |
Level4 | √ | √ | √ |
Level1:设备托管
Level2:设备共享、可配置化
Level3:多租户、数据隔离、高性能
Level4:多租户、可配置、可伸缩
3.2.1、Level1 定制开发
软件服务提供商为每一个客户定制一套软件,并为其部署。独立数据库实例和应用服务器实例,数据库中的数据结构和应用的代码可跟进客户需求做定制化修改。
3.2.2、Level2 可配置
开发通用型产品,为满足不同客户的不同需求,通用性产品具有配置性,客户通过简单的配置满足自己的个性化需求。为每个客户独立部署一个运行实例,每个运行实例运行同一份代码,通过配置的不同需求满足客户的个性化需求。
3.2.3、Level3 高性能的多租户架构
多租户实例的应用架构可以有效降低SaaS应用的硬件即运行维护成本,最大化的发挥SaaS规模效应。
实现Multi-Tenant架构的关键是通过一定的策略保证不同租户间的数据隔离,确保不同租户既能共享一个应用的运行实例,又能为用户提供独立的应用体验和数据空间。
独立数据库、共享数据库独立数据结构、共享数据结构。
实现方式:
- 在传统企业应用的数据模型基础商,增加一个Tenant表,用于描述租户信息。
- 在大部分与租户有关的业务数据表中添加TENANT_ID 字段。
- 数据模型改造完成后,还需要改造登录逻辑,在会话记录用户属性的TENANT_ID。
- 在业务数据查询过滤时,都加上TENANT_ID =?过滤条件。
3.2.4、Level4 可伸缩的多租户架构
随着租户数量的逐渐增加,集中式的数据库性能就将成为整个SaaS应用的性能瓶颈,如果不进一步考虑数据库的分区设计,就只能依赖更强大的硬件设备来向上扩展。单一设备极限,导致SaaS架构无法满足低成本运营需求。
水平扩展在用户数大量增加的情况下,无需修改应用架构,仅简单增加硬件设备的数量,就可以支撑应用规模增长。
从Multi-Tenant SingleInstance系统扩展为Multi-Tenant MultiInstance。用户首先通过接入Tenant Load Balance层,再被分配到不同的Instance上,通过多个Instance来分担用户访问,实现水平扩展。
数据库实现方式:
Tenant Load Balance层会存放用户、租户、对应的Instance的映射关系,用户登录后即可通过映射关系,将用户重定向到相应的Instance。
3.3、如何选择合适的SaaS架构
考虑因素包括:
- 你的产品所面向的客户群的特征与需求;
客户是否原因接受共享应用的模型、个性化需求是否强烈 - 你的产品的租户数量级别;
成熟度高的SaaS产品开发成本(开发维护成本)更高,租户数量决定选择的成熟程度。
租户小于10个,多租户架构带来的收益并不大;大于50之后,多租户架构是SaaS的必然选择。
租户数量在10000以下时,可伸缩性无需考虑;租户在50000~100000甚至更高时需要重点考虑伸缩性 - 你的团队的开发能力与你们愿意付出的开发/改造成本
下一篇就多租户-高性能多租户-可配置多租户-可伸缩多租户具体实现解释
侵权请联系删除
基于多租户SaaS架构设计:SaaS多租户平台基础功能介绍
多租户技术(英语:multi-tenancy technology)或称多重租赁技术,是一种软件架构技术,它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件,并且仍可确保各用户间数据的隔离性。 多租户简单来说是指一个单独的实例可以为多个组织服务。
技术离不开生活,技术源于生活
房东有一套两室一厅的房子,房东和两个租户分别签有合同,合同内容包含租户拥有哪个房间、期限与其房东的授权证明。
A租户是一对小夫妻,B租户是一个刚毕业的单身大学生,A租户在自己的房间有自己的角色(妻子与丈夫),B租户同样在自己的房间拥有自己的角色(单身狗),两个租户都与房东有关系,但俩个租户之间却没有任何关系。
多租户技术特点
1.多个租户共享平台。
2.租户之间数据隔离。
3.租户之间发布更新互不影响。
4.签订合约租户无线扩展
FaaS介绍
微服务(MicroService)是以专注于单一服务/功能的小型单元块为基础,利用模块化的方式组合成复杂的大型应用服务。
FaaS是Function as a Service的缩写,可以简单理解为功能服务化。FaaS提供了一种比微服务更加服务碎片化的软件架构范式。FaaS可以让研发只需要关注业务代码逻辑,不再关注技术架构。
例如:FaaS提供“选择工作流模板”、“启动工作流”、“完成流程”、“查看工作流状态“功能,当触发“启动工作流”事件后,再研发所需的业务代码。业务与架构分离,让专业更加专业。
FaaS特点
无状态,目的:业务隔离
1、组件业务配置抽离,脚手架工程使用则配置。
2、项目适合即使用
脚手架工程pom.xml引入便使用
脚手架 目的:自定义模版,快速集成
版本化 目的:多元化的需求变更互不影响
通过FaaS将架构分层
前端:
组件研发完成上传npm仓库,并提供组件使用说明。注意:同一类业务封装成一个插件,高内聚低耦合原则。
脚手架研发引用组件,并根据组件使用说明向组件传递参数。
并不是所有功能页面全部使用远程组件开发,只有可重复利用的页面使用该模式。
后端:
FaaS组件
提供功能即服务的组件,实现插入即可使用。
MS服务
微服务层,通过脚手架使用FaaS组件,对外提供单一服务。
WS组件
消费者层,用于消费MS服务,对外提供具体的业务实现。注意:该WS不直接对外提供服务,需打成jar包发布到maven私服上。
WS服务
脚手架工程,直接装配WS组件。同时也可以实现特性业务研发。
基础功能介绍
应用注册
就像是将每个房间安装完锁后,把钥匙交给房东。
申请应用
租户选择房间,并向房东申请签订合同。
授权应用
租户和房东签订合同,确定那个房间(钥匙),什么期限。
数据授权
只有签订合同租户才享有房间内物品使用权。
应用隔离
每个房间互不干涉
权限管理
用户有用户的权限、房东有房东权限、房间有房间的权限,三者不不干涉。
房间(平台)
一个房间对应一个平台(医生端、患者端、SaaS端),同样也可以是一个应用(预约挂号、随访问卷),房间只需要关联一个应用而已。同一个房间却可以被多个客厅关联,通过关联关系区分房间属性(所属)。且房间拥有独立入口。
应用(菜单首页)
所有应用菜单统一挂载在应用商城,应用商城是个房间。创建房间时可选择应用,不选则默认应用。有了应用后,通过权限功能给组织角色授权。
客厅(项目)
一个客厅代表一个项目,客厅是一个项目的门户,通过客厅可以展示与客厅关联的每一个房间。客厅默认关联应用商城(房间),其他房间、应用可等创建客厅后登录客厅在应用商城里下载。创建客厅将自动创建管理员帐号密码及初始化角色。
拓展内容:客厅不作为根节点,客厅之上也许还有房东,一个房东可以关联多个客厅。
钥匙(鉴权与重定向)
每个房间都会是一个独立的个体,插拔即可用。不会限制团队、语言,只需要提供鉴权机制与鉴权后的重定向路径即可。用户想进入房间,首先需要鉴权,通过后通过钥匙打开房门地址。
合同(用户APP记录)
用户从应用商城下载应用的记录。
文章来源:CTO老王;
编辑:云朵匠 | 数商云(微信ID:shushangyun_com)
以上是关于SaaS 架构基础理论的主要内容,如果未能解决你的问题,请参考以下文章
云架构&云原生 IaaS,PaaS,SaaS,Serverless