SaaS——软件即服务（Software as a Service）的出现改变了传统使用软件转变为使用服务。
SaaS与传统软件的最大区别是，前者按年付费租用服务，后者一次买断。这貌似只是“报价方式”的区别，实际上这是一个根本性的变化，这带来的是对服务模式、销售模式、公司价值等多维度的根本影响。
传统软件实施失败率高或上线后用地不爽，相当于沉没成本。从软件公司来看，销售在签订合同时其业绩任务就已经达成，因此销售、甚至售前支持顾问大都会以“拿下单子”为目的，遇到竞争激励时即使过度承诺、给实施部门挖些坑也在所不惜。而后续年份只有10~15%的维护费，利益不多，好收就顺手收一下，不好收也不值得费力再进行重度投入。而SaaS的按年付费彻底改变了这个局面。对软件公司来说，销售难度和销售周期都缩短，一个SaaS产品的Sales是能做到一年上百万的销售收入的。而对SaaS公司来说，第二年开始的续费成本非常低，客户成功部门拿走20~40%的费用，剩下60~80%都是毛利。
所以在云计算的三种模式IaaS/PaaS/SaaS，SaaS面对的用户最多，如同C端，应用程序的任何更新或者修复漏洞操作都是由软件提供商负责实施和处理的，由于租户是通过互联网获取软件服务，所以租户端无需下载任何的升级包或者修复补丁，是一种开箱即获取最新软件产品的服务方式。
什么是SaaS
从宏观的角度来看，SaaS是一种软件应用程序交付方式，软件提供商集中化托管一个或多个软件应用程序，并通过互联网向租户体用这些软件应用程序。从分类上看，SaaS（软件即服务）也是云计算重要的一部分。
云计算的三个分层，基础设施(infrastructure)在最下端，平台(platform)在中间，软件(software)在顶端，分别是分别是
-
Infrastructure-as-a-Service(IaaS-基础设施即服务)：IaaS公司会提供场外服务器，存储和网络硬件，你可以租用。节省了维护成本和办公场地，公司可以在任何时候利用这些硬件来运行其应用。
-
Platform-as-a-Service(PaaS-平台即服务)：PaaS公司在网上提供各种开发和分发应用的解决方案，比如虚拟服务器和操作系统。这节省了你在硬件上的费用，也让分散的工作室之间的合作变得更加容易。网页应用管理，应用设计，应用虚拟主机，存储，安全以及应用开发协作工具等。
一些大的PaaS提供者有Google App Engine,Microsoft Azure，Force.com,Heroku，Engine Yard。最近兴起的公司有AppFog,Mendix和Standing Cloud.
-
BaaS（后端即服务，Backend as a Service），公司为移动应用开发者提供整合云后端的边界服务。
后端服务被抽象出来，它统一向开发者提供文件存储、数据存储、推送服务等实现难度较高的功能，以帮助开发者快速开发移动应用。BaaS供应商比如AVOS Cloud。
-
Software-as-a-Service(SaaS-软件即服务)：大多是通过网页浏览器来接入。任何一个远程服务器上的应用都可以通过网络来运行，就是SaaS了。
一些用作商务的SaaS应用包括Citrix的Go To Meeting，Cisco的WebEx，Salesforce的CRM，ADP，Workday和SuccessFactors。
laaS已经变成了巨头之间的德州扑克；PaaS市场进入白热化，军阀割据天下；而SaaS市场正是百家争鸣的阶段，但是这个阶段不会持续太久。
SaaS的优势
-
获取软件服务的方式足够简单，SaaS也许是迄今为止使用软件最简单的方式之一，相比于传统使用软件的方式，租户省去了研发、部署、运维等一系列繁复的过程，且获得软件的时间和费用成本都大幅度降低。
-
SaaS化的产品通过互联网向租户提供软件服务，随着Web技术（如jQuery、Node.js）的进步，Web页面的交互体验度大幅度提升，交互更流畅、更人性化。与传统的桌面应用程序的人机交互效果相差无几。
-
与传统软件相比、SaaS软件的兼容性更好，它没有传统软件的多本版维护问题和操作系统兼容问题。在SaaS软件中，租户用户在使用软件的过程中，几乎上感觉不到软件发生了改变。当租户用户登录到系统上时，就已经获得了最新版本的软件。
-
-
SaaS可以体用跨地域、跨平台的软件服务。与此同时，软件服务商可以统一对软件进行版本管理，这将带来以下几点好处（包括但不限于）：
-
缩短产品上线时间：多端适配，统一版本，统一更新
-
降低维护成本：不需要同时维护多个版本的软件实例，运维压力减小
-
容易升级：由于版本得到有效控制，一次升级，即可覆盖所有租户端
-
-
使用SaaS产品无需担心数据安全问题，这好比将钱存入银行一样安全。相较于企业内部部署的软件系统而言，SaaS产品具备更高的安全保障能力，因为软件提供商具有更多软件安全防护的技术资源、人力资源和财政资源。
SaaS可以将任何的软件SaaS，下面列举一些通用的分类供大家参考：
-
Office在线办公类SaaS产品
-
电子邮件和即时消息类SaaS产品
-
社交媒体类SaaS产品
-
第三方API类SaaS产品
-
安全和访问控制类SaaS产品
-
机器学习类SaaS产品
-
人工智能类SaaS产品
-
地理位置服务类SaaS产品
-
数据流和数据检索类SaaS产品
企业级SaaS市场近几年在每个细分领域都涌现出了一批玩家。从技术角度看，不同的领域、不同的SaaS产品，必定有着同样的架构内核，其中最关键的便是对于多租户（Multi-Tenancy）的支持。对广大企业来说，引入SaaS产品本质上就是对互联网服务的租赁，因而多租户便必然是SaaS的天然属性之一，也是其与传统互联网应用架构设计的重要差异之一。
SaaS的多租户设计
经典的分布式服务架构天然解决了互联网应用的三高问题（高并发、高性能、高可用），这也是企业SaaS发展中后期即将面临的问题，
从资源共享的层面看，从share nothing到share everything，在天平的任何一个点上都可以支撑多租户。但正如我们前文所说，SaaS架构首要考虑的目标便是单实例，只有单实例才能将成本尽可能降低，产品才会有规模效应。所以所谓共享和隔离，在经典架构下又会聚焦为一点，即如何对不同租户进行资源层面的隔离。
SaaS系统在技术本质上也可以认为就是分布式存储和分布式计算的融合。
在多租户的实现中，往往更关键的是对于存储资源的处理，计算资源一般只在必要情况下才会考虑，我认为这主要是和存储的“有状态性”有关。
隔离存储资源概括来说可以用一个词来解决：命名空间。以数据库为例，我们只需要在每条租户的记录上，记下对应租户的标识即可。在不考虑分库分表的情况下，我们逻辑上会在同一个Schema中，存储所有租户的数据。
无论何种存储，思路都是相通的，而且处理起来相对简单粗暴。着重强调的是，在工程层面应当将这种约定在底层框架里做统一处理。比如可以通过AOP技术将多租户相关的逻辑切出来进行统一处理
SaaS架构包括分层：
SaaS架构的呈现层
SaaS架构的呈现层客户端可能是浏览器、或是本地客户端。如果是浏览器则包括Web界面技术、交互技术等，如：HTMl5技术、CSS3技术、Ajax技术等。如果是软件客户端则包括远程桌面技术、软件交互技术等。
不同的岗位工作环境有不同适用的应用技术：
-
对于一线现场（如生产制造、仓储物流配送），一般采取扫码POS或微信小程序，扫码后简单操作几下就把业务关键点记录了下来。
-
对于一线零售店面收银，现在大多数白牌平板App
-
对于来回跑中间分销、渠道、采购、督导的外勤，基本是手机App来处理业务
-
对于坐在后端的运营人员、人事法务财务，基本用的就是台式电脑Web应用来处理业务
SaaS架构的调度层
SaaS架构的调度层负责识别每个用户请求并对每个请求进行AAA认证，然后根据后端业务处理服务器的负载及其业务特征进行合理的调度。通过这样的架构SaaS平台可以横向扩展。此外在存储、缓存等方面为了满足平台的横向扩展需求，该层也必须具有良好的可扩展性。
因为客户端是不同岗位、不同素质能力水平、不同业务重心、不同工作环境，所以功能不一样、用户体验不一样，所以后端的服务层业务逻辑也都不一样。
这层因为涉及到客户端接入，所以需要API网关中间件，因为比较轻（因为还有一层公共业务逻辑处理层），所以采取微服务中间件（如SpringCloud），这些不同的微服务都打包在一个个的Docker中，为了快速弹性启动扩容。前面有API网关中间件可以做分流限流、路由导流，这样后面微服务容器怎么扩容，对前端都透明。
API网关中间件就属于这一层，只不过客户端来的请求都首先经过它再路由到业务逻辑微服务。
但是总有一些业务逻辑是这四种端应用都要处理的，所以还得分出一层叫做公共业务逻辑处理层。这些公共业务逻辑处理层按功能职责也分成一个个的服务，放在Docker容器中，受Swarm或Kubernetes集群管理。
SaaS架构的业务层
SaaS架构的业务层负责接收调度层转发过来的请求并执行真正的业务逻辑。一般业务逻辑再怎么复杂也足以转载在一台服务器上。因此业务层实际是由一排对等的服务器组成的，每台服务器都执行相同的业务逻辑。
SaaS架构的数据层
SaaS架构的数据层通过数据库集群处理存储关系性很强并且对事务性要求很高的业务数据，这类数据往往很难采用NoSQL解决因此目前还不得不借助传统的数据库集群技术来解决，主要是根据业务特征制定数据拆分方案。同时分布式数据库用于存放海量但关系性不强的数据。
-
有些数据需要放在内存里为了快速查询，布式Redis集群。
-
有些数据需要持久性放在关系型数据里，可以用MySQL关系数据库。
-
为了分布式存储，可以在MySQL之前再放一个MyCAT分库分表分布式中间件。
-
为了读写分离提高性能，我们可以在MyCAT之前再放一层MySQLProxy，用于主备读写分离。
-
-
有些数据是文件形式，可以用分布式文件系统和对象存储系统来存放（如图片、音频视频）。我们还可以使用CDN技术来做这些静态文件的分发加速。
-
有些数据是特殊的数据结构，为了加快这些特殊结构的数据存取，可以用时序数据库、图数据库、文档数据库等等。如时间序列数据（IM消息一般是这样特点）、如图数据（社交网络一般是这样特点）、如大文本数据（点评评论一般是这样特点），
对于报表统计、历史查询、综合查询、商业指标对比分析，咱们必须把这些工作放到大数据套件中来处理，和真正快速业务处理的系统分开。
不仅仅是要计算资源分开，还要存储资源也分开。因为对于大数据，存储容量要大（但不一定存储访问性能要高），内存要大（要进行大量数据取出进行计算），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产品的天生缺陷
软件控制权
与企业内部部署的软件不同，由于SaaS软件被击中托管在服务提供商的Web服务器中，所以租户无法控制所有的软件应用程序，SaaS化的软件比企业自行部署的软件获得的控制权更少，租户可操作的自定义控制权极度有限。
性能瓶颈
共享应用程序必然会带来服务器性能的下降、如计算速度、网络资源、I/O读写等都将面临严峻的考验。在性能方面，企业内部部署的“独享模式”的应用程序比SaaS软件的“共享模式”略胜一筹。
安全问题
当租户在选择一款SaaS产品时，产品的安全性将会被放置在第一位进行考虑。如数据的隔离、敏感数据的加密、数据访问权限控制、个人隐私等问题。在2018年5月25日，GDPR(General Data Protection Regulation)《通用数据保护条例》出现之后，越来越多的人开始重视数据安全问题。如何最大程度的打消租户的这一顾虑，需要服务提供商加强对自身信誉度的提升，以赢得租户的信赖。
最重要的是：SaaS的复杂性，一般的团队玩不转。PaaS能否做好的微观差距，主要体现在软件设计者和软件开发者的能力上。有个段子：美国把软件开发叫工程师，中国把开发人员称作码农。美国很多卓越的软件都是大叔设计开发的，而中国程序员35岁以后就要面临失业风险。中国非常缺乏高端的软件人才，缺乏的原因就是因为缺乏持续的积累。大家都在做一些低水平的重复劳动，和流水线上的工人没什么本质区别。
参考文章：
架构师必备技能指南：SaaS(软件即服务)架构设计 架构师必备技能指南：SaaS(软件即服务)架构设计 - 知乎
漫谈企业级SaaS的多租户设计 漫谈企业级SaaS的多租户设计 - 知乎
中国SaaS为什么不赚钱？ 中国SaaS为什么不赚钱？-虎嗅网
https://www.zhihu.com/question/21641778/answer/308674603
SaaS的本质和SaaS公司的大坑https://zhuanlan.zhihu.com/p/67169367文章来源：https://www.toymoban.com/news/detail-695946.html
转载本站文章《云计算的三种模式IaaS/PaaS/SaaS/BaaS对比：SaaS架构设计分析》,
请注明出处：云计算的三种模式IaaS/PaaS/SaaS/BaaS对比：SaaS架构设计分析 - 前端架构设计 - 周陆军的个人网站文章来源地址https://www.toymoban.com/news/detail-695946.html
到了这里，关于云计算的三种模式IaaS/PaaS/SaaS/BaaS对比：SaaS架构设计分析的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
