SaaS——软件即服务(Software as a Service)的出现改变了传统使用软件转变为使用服务。
SaaS与传统软件的最大区别是,前者按年付费租用服务,后者一次买断。这貌似只是“报价方式”的区别,实际上这是一个根本性的变化,这带来的是对服务模式、销售模式、公司价值等多维度的根本影响。
传统软件实施失败率高或上线后用地不爽,相当于沉没成本。从软件公司来看,销售在签订合同时其业绩任务就已经达成,因此销售、甚至售前支持顾问大都会以“拿下单子”为目的,遇到竞争激励时即使过度承诺、给实施部门挖些坑也在所不惜。而后续年份只有10~15%的维护费,利益不多,好收就顺手收一下,不好收也不值得费力再进行重度投入。而SaaS的按年付费彻底改变了这个局面。对软件公司来说,销售难度和销售周期都缩短,一个SaaS产品的Sales是能做到一年上百万的销售收入的。而对SaaS公司来说,第二年开始的续费成本非常低,客户成功部门拿走20~40%的费用,剩下60~80%都是毛利。
所以在云计算的三种模式IaaS/PaaS/SaaS,SaaS面对的用户最多,如同C端,应用程序的任何更新或者修复漏洞操作都是由软件提供商负责实施和处理的,由于租户是通过互联网获取软件服务,所以租户端无需下载任何的升级包或者修复补丁,是一种开箱即获取最新软件产品的服务方式。
从宏观的角度来看,SaaS是一种软件应用程序交付方式,软件提供商集中化托管一个或多个软件应用程序,并通过互联网向租户体用这些软件应用程序。从分类上看,SaaS(软件即服务)也是云计算重要的一部分。
云计算的三个分层,基础设施(infrastructure)在最下端,平台(platform)在中间,软件(software)在顶端,分别是分别是
laaS已经变成了巨头之间的德州扑克;PaaS市场进入白热化,军阀割据天下;而SaaS市场正是百家争鸣的阶段,但是这个阶段不会持续太久。
SaaS可以将任何的软件SaaS,下面列举一些通用的分类供大家参考:
企业级SaaS市场近几年在每个细分领域都涌现出了一批玩家。从技术角度看,不同的领域、不同的SaaS产品,必定有着同样的架构内核,其中最关键的便是对于多租户(Multi-Tenancy)的支持。对广大企业来说,引入SaaS产品本质上就是对互联网服务的租赁,因而多租户便必然是SaaS的天然属性之一,也是其与传统互联网应用架构设计的重要差异之一。
经典的分布式服务架构天然解决了互联网应用的三高问题(高并发、高性能、高可用),这也是企业SaaS发展中后期即将面临的问题,
从资源共享的层面看,从share nothing到share everything,在天平的任何一个点上都可以支撑多租户。但正如我们前文所说,SaaS架构首要考虑的目标便是单实例,只有单实例才能将成本尽可能降低,产品才会有规模效应。所以所谓共享和隔离,在经典架构下又会聚焦为一点,即如何对不同租户进行资源层面的隔离。
SaaS系统在技术本质上也可以认为就是分布式存储和分布式计算的融合。
在多租户的实现中,往往更关键的是对于存储资源的处理,计算资源一般只在必要情况下才会考虑,我认为这主要是和存储的“有状态性”有关。
隔离存储资源概括来说可以用一个词来解决:命名空间。以数据库为例,我们只需要在每条租户的记录上,记下对应租户的标识即可。在不考虑分库分表的情况下,我们逻辑上会在同一个Schema中,存储所有租户的数据。
无论何种存储,思路都是相通的,而且处理起来相对简单粗暴。着重强调的是,在工程层面应当将这种约定在底层框架里做统一处理。比如可以通过AOP技术将多租户相关的逻辑切出来进行统一处理
SaaS架构的呈现层客户端可能是浏览器、或是本地客户端。如果是浏览器则包括Web界面技术、交互技术等,如:HTMl5技术、CSS3技术、Ajax技术等。如果是软件客户端则包括远程桌面技术、软件交互技术等。 不同的岗位工作环境有不同适用的应用技术:
SaaS架构的调度层负责识别每个用户请求并对每个请求进行AAA认证,然后根据后端业务处理服务器的负载及其业务特征进行合理的调度。通过这样的架构SaaS平台可以横向扩展。此外在存储、缓存等方面为了满足平台的横向扩展需求,该层也必须具有良好的可扩展性。
因为客户端是不同岗位、不同素质能力水平、不同业务重心、不同工作环境,所以功能不一样、用户体验不一样,所以后端的服务层业务逻辑也都不一样。
这层因为涉及到客户端接入,所以需要API网关中间件,因为比较轻(因为还有一层公共业务逻辑处理层),所以采取微服务中间件(如SpringCloud),这些不同的微服务都打包在一个个的Docker中,为了快速弹性启动扩容。前面有API网关中间件可以做分流限流、路由导流,这样后面微服务容器怎么扩容,对前端都透明。
API网关中间件就属于这一层,只不过客户端来的请求都首先经过它再路由到业务逻辑微服务。
但是总有一些业务逻辑是这四种端应用都要处理的,所以还得分出一层叫做公共业务逻辑处理层。这些公共业务逻辑处理层按功能职责也分成一个个的服务,放在Docker容器中,受Swarm或Kubernetes集群管理。
SaaS架构的业务层负责接收调度层转发过来的请求并执行真正的业务逻辑。一般业务逻辑再怎么复杂也足以转载在一台服务器上。因此业务层实际是由一排对等的服务器组成的,每台服务器都执行相同的业务逻辑。
SaaS架构的数据层通过数据库集群处理存储关系性很强并且对事务性要求很高的业务数据,这类数据往往很难采用NoSQL解决因此目前还不得不借助传统的数据库集群技术来解决,主要是根据业务特征制定数据拆分方案。同时分布式数据库用于存放海量但关系性不强的数据。
对于报表统计、历史查询、综合查询、商业指标对比分析,咱们必须把这些工作放到大数据套件中来处理,和真正快速业务处理的系统分开。
不仅仅是要计算资源分开,还要存储资源也分开。因为对于大数据,存储容量要大(但不一定存储访问性能要高),内存要大(要进行大量数据取出进行计算),CPU性能要高(要密集计算)。所以对于统计、查询、分析这些功能,服务器云主机和云存储都要和应用业务处理分离。
分离后,就需要从应用业务处理系统中抽取数据。
所以,对于数据抽取层:我们有一系列的ETL工具,还有数据爬虫引擎用于爬内外静态数据,还有用Flume、Logstash、Splunk收集IT资源日志和应用系统运行日志。
抽取来的数据可以放在大数据仓库中,我们可以采用Hadoop HDFS、Hbase、Hive等等开源中间件。
要计算处理时,我们可以在YARN或MapRedurce计算调度框架下使用Spark、Storm来进行内存计算和流式计算。
处理后的数据,我们可以用presto查询,我们也可以用ElasticSearch来搜索。
最后,我们使用一些可视化工具把结果用图表形式输出出去。
按照这样的技术架构搭建好后,每一个客户要在公有云上专属独立部署,那么给它用DevOps工具新启几个服务层Docker,如果公共业务逻辑模式也要变化,那就新启几个公共业务逻辑Docker。毕竟我们有分布式用户登录验证网关和API网关,所以不管是公有云专属部署还是私有云部署,都没问题。
对于主数据管理模块,因为也有UI层、逻辑层、数据层,所以主数据这些各层的代码和数据和中间件,可以打包成一个部署单元,用一套专门的DevOps工具及脚本进行自动化部署、配置变更、升级。
对于数据层,我们有KV分布式数据库、分布式关系数据库、主备读写分离中间件、分库分表中间件、CDN分发、时序数据库/文档数据库/图数据库、我们确实需要在API网关路由层面用DevOps工具及脚本、集中配置中间件Puppet来做到自动化部署扩展、配置变更、升级。这样不同的企业指向了不同的分布式数据库引擎地址和分布式数据库存储卷。这样就方便了既能做公有云专属部署又能做私有云部署。
软件控制权
与企业内部部署的软件不同,由于SaaS软件被击中托管在服务提供商的Web服务器中,所以租户无法控制所有的软件应用程序,SaaS化的软件比企业自行部署的软件获得的控制权更少,租户可操作的自定义控制权极度有限。
性能瓶颈
共享应用程序必然会带来服务器性能的下降、如计算速度、网络资源、I/O读写等都将面临严峻的考验。在性能方面,企业内部部署的“独享模式”的应用程序比SaaS软件的“共享模式”略胜一筹。
安全问题
当租户在选择一款SaaS产品时,产品的安全性将会被放置在第一位进行考虑。如数据的隔离、敏感数据的加密、数据访问权限控制、个人隐私等问题。在2018年5月25日,GDPR(General Data Protection Regulation)《通用数据保护条例》出现之后,越来越多的人开始重视数据安全问题。如何最大程度的打消租户的这一顾虑,需要服务提供商加强对自身信誉度的提升,以赢得租户的信赖。
最重要的是:SaaS的复杂性,一般的团队玩不转。PaaS能否做好的微观差距,主要体现在软件设计者和软件开发者的能力上。有个段子:美国把软件开发叫工程师,中国把开发人员称作码农。美国很多卓越的软件都是大叔设计开发的,而中国程序员35岁以后就要面临失业风险。中国非常缺乏高端的软件人才,缺乏的原因就是因为缺乏持续的积累。大家都在做一些低水平的重复劳动,和流水线上的工人没什么本质区别。
参考文章:
架构师必备技能指南:SaaS(软件即服务)架构设计 https://zhuanlan.zhihu.com/p/67848677
漫谈企业级SaaS的多租户设计 https://zhuanlan.zhihu.com/p/133311041
中国SaaS为什么不赚钱? https://www.huxiu.com/article/354905.html
https://www.zhihu.com/question/21641778/answer/308674603
SaaS的本质和SaaS公司的大坑https://zhuanlan.zhihu.com/p/67169367
转载本站文章《云计算的三种模式IaaS/PaaS/SaaS/BaaS对比:SaaS架构设计分析》, 请注明出处:https://www.zhoulujun.cn/html/webfront/engineer/Architecture/8466.html
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。