SaaS是Software-as-a-Service（软件即服务）的简称，“软件即服务”？是不是有点拗口？其实你就理解成为“按需租用别人提供的软件服务”就可以了，它是一种软件交付模式。
SaaS这个说法是区别于以往软件购买和交付方式而提出来的。在以前，你公司要使用一款软件来管理财务记账的时候，那你要向软件提供公司说明需求、支付购买软件的钱并提供安装软件的硬件环境，然后软件公司就会上门安装调试软件，调试完后就可以正式投入使用了。这里有一个很显著的特点是，软件都安装在你指定的地方，你拥有100%的管控权，相应的你后续还需要继续投入人员和资源维护系统的正常运行。
SaaS（软件即服务）的模式就不一样了，在客户还没有来之前，软件提供公司就自己提服务器、数据库等硬件，把软件安装发布好，作为一个软件使用方就变得轻松许多，一上来就可以直接体验了，体验之后，你觉得哪些功能合适你的，就挑出来，按月支付支付比较便宜的费用就可以正式使用了。后续的升级、维护也由软件公司来负责，把所有的软件相关工作都归类准备好了，你直接过来挑自己需要的用就好了，其他的用户过来也是一样。“按需付费”是SaaS的一个非常重要的特性。在这种模式下，软件是别人的，发布在别人的服务器上，数据也需要保存在别人的服务器上，安全和信任一直是个令人担忧的问题。
业内有一个很恰当的比喻，一开始的时候，各家都自己挖井抽水蓄水，挖井抽水蓄水的技术是有专业的公司提供，但总的来说喝水这个事情是自家管自家的，这是传统的软件的供水模式。SaaS模式下，挖井抽水蓄水净水修水管这些工作对使用方来说都是透明的，你有需要的时候就打开水龙头取水就OK了，然后每月自来水公司会过来跟你结算。同样的，优缺点很明显，优点是按需用水省事了，成本变低了，缺点是水由水务公司完成控制供水稳定性、供水质量取决于水务公司实力。
Saas系统分层：展现层>调度层（租户识别）>业务层>数据层
呈现层
saas平台架构的呈现层可以使用的客户端可能都浏览器或本地客户端。如果是浏览器则需要Web界面技术、交互技术等技术（如：HTMl5技术、CSS3技术、Ajax技术等）的支持，如果是软件客户端则需要远程桌面技术、软件交互技术等技术支持。
调度层（租户识别）
saas平台架构的调度层体现分布式系统的特性之一。
调度层可包含一个配置中心，其中存放租户租赁服务的相关服务配置信息以及版本号，调度层首先认证并识别租户，根据租户在配置中心的配置信息，向业务层发送用户请求（租户识别可以用spring拦截器实现，然后使用ThreadLocal传递给业务层），根据业务处理器的负载、业务特征进行合理的调度。通过应用这样的架构SaaS平台可以横向扩展。此外在存储、缓存等方面为了满足平台的横向扩展需求，调度层也必须具有良好的可扩展性
业务层
saas平台架构的业务层负责接收调度层转发过来的请求，而且还要通过对接受到的请求执行真正的业务逻辑。一般来说业务逻辑的执行使用一台服务器就够了。因此业务层实际是由一排对等的服务器组成的，每台服务器都执行相同的业务逻辑。
数据库和缓存层对业务层应该是透明的。程序员在写代码的时候，只关心业务逻辑，不应该担心多租户的问题。
数据层
saas平台架构的数据库集群用于处理存储关系性很强并且对事务性要求很高的业务数据，这类数据目前还要用传统的数据库集群技术来解决，saas平台架构的数据库集群主要是根据业务特征制定数据拆分方案。同时分布式数据库用于存放海量但关系性不强的数据（如：用户的操作日志等）。
1、安全组件
在SaaS产品中，系统安全永远是第一位需要考虑的事情，如何保障租户数据的安全，是你首要的事情。这如同银行首选需要保障储户资金安全一样。安全组件就是统一的对SaaS产品进行安全防护，保障系统数据安全。
2、数据隔离组件
安全组件解决了用户数据安全可靠的问题，但数据往往还需要解决隐私问题，各企业之间的数据必须相互不可见，即相互隔离。在SaaS产品中，如何识别、区分、隔离多个租户的数据是你在实施SaaS软件架构设计时需要考虑的第二个问题。
3、可配置组件
尽管SaaS产品在设计之初就考虑了大多数通用的功能，让租户开箱即用，但任然有为数不少的租户需要定制服务自身业务需求的配置项，如UI布局、主题、标识（Logo）等信息。正因为无法抽象出一个完全通用的应用程序，所以在SaaS产品中，你需要提供一个可用于自定义配置的组件。
4、可扩展组件
随着SaaS产品业务和租户数量的增长，原有的服务器配置将无法继续满足新的需求，系统性能将会与业务量和用户量成反比。此时，SaaS产品应该具备水平扩展的能力。如通过网络负载均衡其和容器技术，在多个服务器上部署多个软件运行示例并提供相同的软件服务，以此实现水平扩展SaaS产品的整体服务性能。为了实现可扩展能力，就需要SaaS展示层的代码与业务逻辑部分的代码进行分离，两者独立部署。
例如使用VUE+微服务构建前后端分离且可水平进行扩展的分布式SaaS应用产品。对于可扩展，还有另外一种方式，即垂直扩展，其做法比较简单，也比较粗暴：通过增加单台服务器的配置，如购买性能更好的CPU、存储更大的内存条、增大带宽等措施，让服务器能够处理更多的用户请求。但此做法对于提升产品性能没有质的改变，且成本很高。
5、0停机时间升级产品
以往的软件在升级或者修复Bug是，都需要将运行的程序脱机一段时间，等待升级或修复工作完成后，再重新启动应用程序。而SaaS产品则需要全天候保障服务的可用性。这就需要你考虑如何实现在不重启原有应用程序的情况下，完成应用程序的升级修复工作。
6、多租户组件
要将原有产品SaaS化，就必须提供多租户组件，多租户组件是衡量一个应用程序是否具备SaaS服务能力的重要指标之一。SaaS产品需要同时容纳多个租户的数据，同时还需要保证各租户之间的数据不会相互干扰，保证租户中的用户能够按期望索引到正确的数据，多租户组件是你必须要解决的一个问题。其余的组件都将围绕此组件展开各自的业务。
Level1：定制开发，每次新增一个客户，都会新增软件的一个实例。
Level2：可配置，所有客户都运行在软件的同一个版本上，而且任何的定制化都通过修改配置来实现。
Level3：高性能的多租户架构（多租户[multi-tenant]、高层建筑[Highrise]），所有的客户都已经可以在软件的同一个版本上运行了，而且他们都在同一个“实例”上运行。
Level4：可伸缩的多租户架构（多租户，扩建[Build-Out]），此时你已经拥有了多租户、单一版本的软件模型。不过你还是可以通过硬件扩展（scale-out）的方式来进行扩充。
a.隔离数据库；
b.共享数据库，隔离数据结构；
c.共享数据结构，tenantid字段隔离(推荐)；
注意的问题：数据隔离要透明
saas系统说起来很简单，任何系统似乎加个tenant_id(租户id)就变成saas系统了。
比如原来的用户登录是：
select username,password from users where email='abc@qq.com'
改成
select username,password from users where email='abc@qq.com'and tenant_id=1；
对于复杂业务的saas系统，这样做法非常危险，而且开发效率很低。你想想如果那个程序员写sql时候忘了加“and tenant_id=1”.结果不堪设想。
比较好做法是在数据库访问层对SQL进行改写。
TenantContext.exec("select username,password from users where email='abc@qq.com'")；
在连接池根据TenatnContext改写Sql，这样做好处是，1.系统信息串了互相独立，不易泄露。2.若将来做分表分库也很方便，上层应用不用修改。
数据库层性能优化（建立合适索引，消除大数据表连接，避免复杂SQL）；
应用层性能优化（Cache，统计报表，异步操作，基于租户的索引搜索）；
展现层性能优化；
数据可配置（定制字段，预分配字段，键值对）；
功能可配置（原子功能划分，功能包设计，功能使用校验）；
界面可配置（系统菜单，页面元素）；
流程可配置；
可伸缩性；
负载均衡；
数据库读写分离；
数据库垂直切分/水平切分；
应用安全（身份认证，权限管理，日志记录，应用监控）；
数据安全（数据隔离，数据库连接安全，敏感数据加密，数据量监控）；
网络安全（安全传输，网络攻击防范，网络监控）；
租户识别方案
比较好做法是通过url识别租户。系统是给租户生成一个随机的三级域名，比如abc.crm.baidu.com.如果客户想使用自己的域名，可以在cname到我们生成的三级域名，并在管理系统里面做绑定。
这样一个租户可以有两个域名，访问saas,一个随机生成的三级域名，另外一个租户自己的域名.代码里面可以根据过来的域名，判断是那个租户然后初始化TenantContext。
如果不想通过域名来做，也可以通过登录名来判断。这种方式要涉及到租户切换问题。
SAAS的优势在于一套系统多人使用，似乎和定制化开发有冲突。比如A客户想要A功能，B客户不想要。但定制化开发是无法避免的，比如CRM系统这样复杂的系统，不可能一套系统满足所有公司的要求。定制化开发尽可能分系统，分模块去做。然后通过控制台中配置不同租户订购不同模块，那些模块可以在前端页面上显示。不同的子系统需要分开部署。前端可通过nginx根据url分发，比如abc.crm.baidu.com/bi/xxx/xx这个地址，就分发到BI子系统。不要尝试OSGI去搞模块化，这个是个大坑。
开发和产品，现有需求一定要分析清楚，不要一上线发现后患无穷。新功能尽量做的独立可以配置。
SAAS付费企业客户对系统问题都特别敏感。为了减少升级可能出现问题的影响范围，一般都采用灰度升级策略。如果使用了url来区分不同租户，灰度升级配置就会很方便。可以配置nginx来根据域名做分发，比如租户A（aaa.com）到实例1（版本1.0），租户B(bbb.com)到实例2(版本).当需要域名配置非常多的时候，nginx配置文档会乱。这块时候可以考虑使用nignx_lua来写一些扩展模块。
多租户Saas系统架构还应该满足以下需求：
编号需求描述
1、软件授权云平台付费授权机制，可按时间、功能、数量等进行付费授权；
2、组织入驻允许组织主动申请加入平台；
3、实名认证个人实名认证、组织实名认证；
4、资质审核个人和组织的资质审核，如对获得的证书或荣誉进行审核；
5、组织绑定个人账户绑定组织，与组织建立关联关系；
6、组织解绑个人账户与组织进行解绑；
7、账户注销个人账户注销，并销毁所有个人资料和档案；
8、统一登录即SSO；
9、统一注册提供统一的用户注册页面；
文章来源：CSDN，作者：hp15；
编辑：云朵匠 | 数商云(微信ID：shushangyun_com)
【数商云www.shushangyun.com】致力于提供企业级的商城开发服务，长期为大中型企业打造数据化、商业化、智能化的saas多租户商城系统解决方案，同时我们还提供B2B电子商务平台、B2B2C多用户商城系统、B2C电子商务系统、跨境进口电商平台、供应商系统、新零售电商平台、直播电商系统等一系列供应链平台定制开发服务。
点赞 | 0
