saas研发常见问题和解决方案

saas应用技术难点

01，什么是saas

SaaS软件是什么。从宏观的角度来看，SaaS是一种软件应用程序交付方式，软件提供商集中化托管一个或多个软件应用程序，并通过互联网向租户体用这些软件应用程序。从分类上看，SaaS（软件即服务）也是云计算重要的一部分。目前国内主流的云服务提供商如阿里云、百度云、腾讯云等，为广大用户提供了不同业务需求的云服务，它们大致可以分为以下几类：
1、基础设施即服务：如CPU、Network、Disk和Memory等
2、平台即服务：如阿里云服务器和云数据库等
3、软件即服务：阿里短信、阿里邮箱等
4、数据即服务：如阿里云对象存储，七牛云存储等
5、其他软件服务：机器学习、人工智能等
SaaS应用程序的任何更新或者修复漏洞操作都是由软件提供商负责实施和处理的，由于租户是通过互联网获取软件服务，所以租户端无需下载任何的升级包或者修复补丁，是一种开箱即获取最新软件产品的服务方式。

02，系统分级

SaaS 系统架构成熟度模型的 5 个级别——从“混乱”到“乌托邦“
基础要求：应用程序必须支持多租户。
第 0 级（混乱）：每次新增一个客户，都会新增软件的一个实例。
第 1 级（受控的混乱）：所有客户都运行在软件的同一个版本上，而且任何的定制化都通过修改配置来实现。
第 2 级（多租户 [multi-tenant]、高层建筑 [Highrise]）：所有的客户都已经可以在软件的同一个版本上运行了，而且他们都在同一个“实例”上运行。
第 3 级（多租户， 扩建 [Build-Out]）：此时你已经拥有了多租户、单一版本的软件模型。不过你还是可以通过硬件扩展（scale-out）的方式来进行扩充。
第 4 级（乌托邦）：如同第 3 级，除非你可以找出有效的方式，以在不同的“实例”上运行不同版本的软件。

其中，第2级，可以看做基本多租户要求。第2级基础上，采用分布式架构，可以较容易的实现水平扩展，就能达到第3级。

02，三高问题

经典的分布式服务架构天然解决了互联网应用的三高问题（高并发、高性能、高可用），这也是企业SaaS发展中后期即将面临的问题。目前分布式服务架构基本以微服务整套技术框架为基础了。也即是springcloud等一整套解决方案。

03，隔离级别

谈到资源，我们可能会想到CPU、内存、磁盘、网络带宽等，但如此多类型的资源，从其特征上又可以归为两类，即存储资源和计算资源。换句话说，SaaS系统在技术本质上也可以认为就是分布式存储和分布式计算的融合。
在多租户的实现中，往往更关键的是对于存储资源的处理，计算资源一般只在必要情况下才会考虑。

存储资源_关系型DB

隔离存储资源概括来说可以用一个词来解决：命名空间。以数据库为例，我们只需要在每条租户的记录上，记下对应租户的标识即可。
一般来说，不考虑分库分表的情况下，我们逻辑上会在同一个Schema中，存储所有租户的数据。这就要求每张表都会有一个tenant_id字段，也即每条记录都携带了它的“命名空间”——租户标识。

比如在租户上下文中的所有SQL语句，应当都要携带where tenant_id=?这个条件，才能保证逻辑正确，我们很难想象在代码从零到十万、百万行的过程中，所有人都自始至终都牢记这个规则。
那么类似场景下，我们就可以通过AOP技术将多租户相关的逻辑切出来进行统一处理，比如在Java中，我们可以定义@TenantContextAware注解，以声明而非编码的方式在需要的地方做对应的租户信息获取及传递处理。
那么又如何保证开发者也牢记这个规则呢，由于多租户是SaaS的天然属性，我们可以反其道而行之，默认支持多租户逻辑，同时定义@TenantContextUnaware注解，在不需要多租户的地方进行例外声明，这就大大降低了开发团队的负担。

单租户单库(繁琐,少用)

优点：
租户数据在数据库维护物理上隔离了，
由于是每个租户一个库可以在库表设计上做单独扩展，但这也引起了应用程序的兼容问题
缺点：
数据库维护成本和高，（举例：在相同数据结构的情况下，增加表中的列或索引，需要操作多个库）开发成本也高。

多租户同库(简单,中小公司好用)

可进一步细分为2种情况
01，按租户分表
02，所有租户同表(用tenantId区分)
缺点：多租户数据库必然会牺牲租户隔离。多个租户的数据一起存储在一个数据库中。在开发过程中，确保查询不会暴露来自多个租户的数据。
优点：成本较低。

多租户同库+分片表(不是很复杂)

分片多租户即：多租户的单应用+支持多租户的单数据库（分片）

看起来是不是跟第一个图中：同一个应用程序，每个租户一个库模式差不多，只不过每个库多了几个租户数据？
其实是大不相同的。
首先，第一种模式中不同租户的库是可以分别扩展的，也就是结构可以不一样，但分片多租户的是同一种数据结构。
其次，分片模式的扩展性很强，它可以是一个分片一个租户，也可以是一个分片多个租户，具体要看具体的分片策略。

各模式下相关指标对比：

存储资源_key-value型DB

再以常用的NoSQL方案Redis为例，一般来说也是在同一个分布式集群中存储所有租户数据，那么很明显在key上携带租户标识即可。
所以无论何种存储，思路都是相通的，而且处理起来相对简单粗暴。但这里我想着重强调的是，在工程层面我们应当将这种约定在底层框架里做统一处理。
Redis Key的维护，也建议定义统一的KeyGeneratePolicy来维护。

计算资源

隔离计算资源的方法也可以用一个词来概括，那就是亲和性，简单来说就是租户与集群计算资源的亲和性设计。

计算与存储除了“状态”方面的差异外，还有一个非常重要的区别，计算的财务成本往往远高于存储，比如我们一台虚拟主机上可能只允许数百个线程同时处理请求。
正因为如此，宝贵的计算资源在非必要的情况下一般不会再进行细粒度的隔离，例如我们一般不会在运行时只允许某租户的请求只提交给指定工作线程处理。
另外一方面，计算资源发生倾斜的后果，往往比存储要严重的多，如同木桶效应般，直接且显著地影响整个集群的服务能力。
但特定场景下较粗粒度的隔离，有时候还是非常必要的。比如为了减少系统故障时租户的影响范围，我们可能会将租户的请求哈希后提交给不同的线程池处理，因为这种情况下，反压将会产生全局的影响。
另外我们也可能在特定场景下进行进程、集群层面的隔离。总的来说，对计算资源进行隔离，没有既定的模式与套路，而且往往需要高超的资源操作水平，一般不到万不得已不建议实施。
同样地，如果一定要实施，那么也应当以组件化的方式进行，保证业务逻辑的纯粹性。
通过上述对存储和计算资源的隔离处理，我们的SaaS架构整体看起来将会是下图这个结构。

在这里用一个表格就一些要点对两种手段做个简单的对比，便于大家更直观地理解↓

单实例架构的扩展

面向企业的SaaS服务往往还有一些特点可能会引出一些高阶需求，而独立的单实例架构有时候并不能完全满足这些高阶需求。此时就需要对原有架构进行扩展，以实例级别的整体隔离，配合租户级的请求分流手段，为SaaS带来资源、软件版本等多方面的隔离。
比如我们往往会根据企业客户的规模和特点对其保障等级进行分级，那如何进一步合理地隔离资源，保障不同级别客户的使用体验，也是一个无法逃避的问题。可以考虑将这类客户的某些资源实施特殊的保护性隔离，或者干脆将单实例架构扩展成为多实例架构，将客户分流到不同保障级别的资源池。
如果有个别客户体量远超其他客户，那么在成本允许的情况下，我们甚至可以考虑为其建设专属资源池，对其进行重点保障，这种级别的保护并不意味着牺牲了小体量客户的体验，相反，往往大体量客户才更容易发生一些影响稳定性的突发事件，所以可以认为是一种多赢的操作。
另外，SaaS往往能给客户带来更快的特性交付，但这种快速交付很可能带来不佳的使用体验，比如严重BUG的存在。
那么这个时候，如果我们的系统是多实例架构，那么就可以很轻易地实现灰度发布，从而使得特性交付的过程更加稳健，也是对品牌形象的一种保护。

04，租户识别

简单来说，如何识别这个用户属于那个租户。比如用户所属公司不同，登录系统后的logo等肯定不同，功能菜单可能也细节差异，甚至部分可定制的业务逻辑可能也存在差异。

登录名

比如手机号，一般saas的注册都是通过特定租户管理员增加用户来实现的，而非常规的手机号验证注册（当然也有，比如企业微信，一个用户可以历隶属多个企业）。登录名来判断。这种方式可能涉及到租户切换（有点类似权限体系的角色切换，管理员可以切换到其他角色视角（看到不同的菜单样式））问题。比较粗暴的方式就是一个id（比如手机号）只能隶属一个租户。

独立域名

可以使企业独立域名，或者saas系统的二级域名。一般大客户会有这种要求（从技术角度，没啥用，依然解析到saas提供商的ip，不过二级域名可以和购买方客户号保持一直，上层的大领导会比较开心）。这样也可以通过域名识别租户。

05，升级维护

对于SaaS系统，系统的升级维护工作不能暂停当前客户正在执行的业务，避免业务数据丢失，因此需要一种全新的软件发布机制，通过可视化，自动化的操作，实现持续，无缝，零重启的软件交付过程。在升级维护时，SaaS软件主要面临以下几个挑战：

版本可回退

如果新上线的功能模块遇到重大问题，可以回退到之前的版本而不影响用户的正常业务。

系统向下兼容

新版本的系统需要尽可能的向下兼容旧系统的数据。在最坏的情况下，当升级过程发生时，用户正在使用旧版本提交数据，如果适配旧版本提交的数据，需要慎重考虑。

灰度发布

灰度发布包含两个方面：前后端灰度发布和移动端的灰度发布。

热部署(零重启,7*24服务）

以往的软件在升级或者修复Bug是，都需要将运行的程序脱机一段时间，等待升级或修复工作完成后，再重新启动应用程序。而SaaS产品则需要全天候保障服务的可用性。这就需要你考虑如何实现在不重启原有应用程序的情况下，完成应用程序的升级修复工作。

06，可配置

尽管SaaS产品在设计之初就考虑了大多数通用的功能，让租户开箱即用，但任然有为数不少的租户需要定制服务自身业务需求的配置项，如UI布局、主题、标识（Logo）等信息。正因为无法抽象出一个完全通用的应用程序，所以在SaaS产品中，你需要提供一个可用于自定义配置的组件。

07，安全

在SaaS产品中，系统安全永远是第一位需要考虑的事情，如何保障租户数据的安全，是你首要的事情。这如同银行首选需要保障储户资金安全一样。安全组件就是统一的对SaaS产品进行安全防护，保障系统数据安全。

08，多语言,多时区

09，其他

多租户saas应用如何维护多版本(？稳定版，尝鲜版)

这实现起来难度很大，最新版和稳定版之间的差异不仅仅只有界面和功能这么简单，往往你功能迭代过程中，即使是同一套业务，也可能会出现数据表字段的增减、数据表的增减，甚至是数据表的拆分。你的业务是通的，你的数据肯定也是同一份的，当你背后的数据库结构发生变化后，你的数据库必然是跟着你的最新版业务逻辑走的，你的稳定版后端逻辑就需要对新的数据库结构做兼容，稳定版和最新版差距越大，你的兼容工作量就越大，这时候你的稳定版可能就不稳定了。

基于租户id升级的SaaS方案

通过租户id实现的SaaS方案：https://juejin.cn/post/6844903993085263886#heading-12
作者将原始表升级为分区表，并且配合着存过做数据表检查。新增租户时，也会自动在各个表中新增分区。
同时，通过构造基于Mybatis-plus的拦截器，自动为查询语句增加租户过滤条件。
提供的源码地址：https://github.com/longxiaonan/java-sea/tree/master/javasea-orm/javasea-orm-mybatis-Interceptor

微服务面临的问题和解决方案

面临非常多问题，比如：
为了避免逐个管理配置文件，需要引入配置中心，对配置进行集中化管理。
由于日志分散的，且某一个操作都跨越多个application，所以需要引入“日志链路追踪”对请求进行串接。
对研发而言，保证操作类接口的幂等性（可能会自动重试）
整个微服务是个比较庞大的体系，这里不在详细叙述了，网上资料也比较充分，可自行研究。

可参考：
微服务架构所面临的技术问题
【微服务扫盲篇】之微服务框架常见问题和解决思路

每个租户独立数据源的demo

Spring Boot 构建多租户SaaS平台核心技术指南:https://juejin.cn/post/6844903854144749581

可观测性(监控)

SaaS 应用的可观测性设计:juejin.cn/post/6844904194478981133

参考

企业级SaaS的多租户设计：https://blog.csdn.net/u012921921/article/details/106115974
SAAS 租户识别的方案：https://juejin.cn/post/6924172118187999239
SAAS平台的基础，构建多租户系统的思考：https://juejin.cn/post/6955442519702241293
SaaS(软件即服务)架构设计：https://juejin.cn/post/6844903858628476936
多租户系统设计：https://juejin.cn/post/7022925733039177759
实现SaaS（软件及服务）架构所面临的三大技术挑战：www.uml.org.cn/zjjs/202003051.asp
多租户 saas 企业web应用如何维护两套版本，一套的稳定版本给大多数用户，一套是最新版本给喜欢尝新用户:https://segmentfault.com/q/1010000040308329
多租户SaaS的数据库设计模式：https://linpxing.cn/cxy_saas_tenant_db_11/
通过租户id实现的SaaS方案：https://juejin.cn/post/6844903993085263886#heading-12
微服务引入模块：参考这里的图：https://www.xugj520.cn/amp/SaaS_Architecture.html
saas设计技术难点:https://juejin.cn/s/saas设计技术难点