1. SaaS 介绍
概念
SaaS 是 Software-as-a-service(软件即服务)的简称，是随着互联网技术的发展和应用软件
的成熟，而在 21 世纪开始兴起的一种完全创新的软件应用模式。它是一种通过 Internet 提
供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，
通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，
并通过互联网获得厂商提供的服务。
用户不用再购买软件，而改用向提供商租用基于 Web 的软件，来管理企业经营活动，
且无需对软件进行维护，服务提供商会全权管理和维护软件，软件厂商在向客户提供互联网
应用的同时，也提供软件的离线操作和本地数据存储，让用户随时随地都可以使用其定购的
软件和服务。对于许多小型企业来说，SaaS 是采用先进技术的最好途径，它消除了企业购
买、构建和维护基础设施和应用程序的需要。
在这种模式下，客户不再像传统模式那样花费大量投资用于硬件、软件、人员，而只需
要支出一定的租赁服务费用，通过互联网便可以享受到相应的硬件、软件和维护服务，享有
软件使用权和不断升级，这是网络应用最具效益的营运模式。
SaaS 专用名词
1.多重租赁(Multi-tenancy)
SaaS 的"多重租赁"概念就是，多个公司将其数据和业务流程托管存放在 SaaS 服务商的
同一服务器组上，相当于服务商将一套在线软件同时出租给多个公司，每个公司只能看到自
己的数据，由服务商来维护这些数据和软件。也就是说，多个公司登录到同一网站，但登录
后看到的界面和数据，不同的公司大不相同。
2.单点登录(Single sign-on)
这个概念应用在 SaaS 上，就是指把多个不同的在线应用软件服务搭建成为一种新型的
整合服务。用户通常只需要登录一次就可以使用集成好的应用软件组合。
3.基础架构平台(Platform infrastructure)
有时候 SaaS 的拥护者希望出现一种基础架构的平台来推动 SaaS 更好地发展。
这是因为首先得有一个平台来支撑 SaaS 软件应用程序的运行，如今最著名的是国外
Salesforce 公司的 APP Exchange 平台，国内 800CRM 的 800APP Native 的平台与 Salesforce
兼容。
4. SaaS(软件作为服务)
厉害的 SaaS 销售代表直接用 SaaS 就能解决你所有管理软件问题。比起其它软件，SaaS
软件更便宜，灵活性更强，能省掉更多的麻烦。
5 SaaS 成熟度模型（SaaS Maturity Model）
(1)Level1：定制开发
这是最初级的成熟度模型，其定义为 Ad Hoc/Custom，即特定的/定制的，对于最初级
的成熟度模型，技术架构上跟传统的项目型软件开发或者软件外包没什么区别，按照客户的
需求来定制一个版本，每个客户的软件都有一份独立的代码。不同的客户软件之间只可以共
享和重用的少量的可重用组件，库以及开发人员的经验。最初级的 SaaS 应用成熟度模型与
传统模式的最大差别在于商业模式，即软硬件以及相应的维护职责由 SaaS 服务商负责，而
软件使用者只需按照时间，用户数，空间等逐步支付软件租赁使用费用即可。
(2)Level2：可配置
第二级成熟度模型相对于最初级的成熟度模型，增加了可配置性，可以通过不同的配置
来满足不同客户的需求，而不需要为每个客户进行特定定制，以降低定制开发的成本。但在
第二级成熟度模型中，软件的部署架构没有发生太大的变化，依然是为每个客户独立部署一
个运行实例。只是每个运行实例运行的是同一个代码，通过配置的不同来满足不同客户的个
性化需求。
(3)Level3：高性能的多租户架构
在应用架构上，第一级和第二级的成熟度模型与传统软件没有多大差别，只是在商业模
式上符合 SaaS 的定义。多租户单实例的应用架构才是通常真正意义上的 SaaS 应用架构，
即 Multi-Tenant 架构。多租户单实例的应用架构可以有效地降低 SaaS 应用的硬件及运行维
护成本，最大化地发挥 SaaS 应用的规模效应。要实现 Multi-Tenant 架构的关键是通过一定
的策略来保证不同租户间的数据隔离，确保不同租户既能共享同一个应用的运行实例，又能
为用户提供独立的应用体验和数据空间。
(4)Level4：可伸缩性的多租户架构
在实现了多租户但单实例的应用架构之后，随着租户数量的逐渐增加，集中式的数据库
性能就将成为整个 SaaS 应用的性能瓶颈。因此，在用户数大量增加的情况下，无须更改应
用架构，而仅需简单的增加硬件设备的数量，就可以支持应用规模的增长。不管用户多少，
都能像单用户一样方便地实施应用修改。这就是第四级也是最高级别的 SaaS 成熟度模型所
要致力解决的问题。
5.独立软件开发者（ISV）
开发软件的个人或者公司，ISV 通过平台来出售自己的软件
6.软件入口
ISV 出售软件时，提供给用户使用的接口，即 ISV 开发的软件的进入网址。
7.创建子版本
ISV 根据软件的功能，版软件分成几个不同的子版本，用户可以根据所需运用购买不同
的版本，其工作有 isv 完成
8.租户
购买了软件的个人或者公司。
9.注册序列号
isv 注册软件时获得的序列号，是 isv 软件唯一不可变更的序列号，可不计入数据库，
单必须保存在 isv 软件的配置文件中。
10.免登陆
由平台跳到 isv 软件时，不需进行再登陆，isv 软件根据传过来的用户信息，直接初始
化用户信息。
身份验证令牌，在 saas 平台跳到 isv 软件时使用，用于验证跳转用户的合法性。Token
动态生成，为了安全，其生命长度只有 10-20 秒。
12 免登入接口
由平台提供的一组验证程序，修改其中的注册序列号后绑定到 isv 软件，以实现用户的
免登入。
13．参与的软件
不是自己购买开发的软件，而是由别人购买并添加，其所有软件显示为参与的软件。
14．AssP
软件互联平台，在这既 SaaS 平台
2． SaaS 平台功能
软件注册
业务流程图
图 1 软件注册流程图
注册用户
点击注册软件
填写软件信息和软件入口
在用户软件上绑定软件序列号
在用户开发的软件列表添
加此软件，获得序列号
提交
调试软件
软件上架，进入商场
平台管理员审核软件
成功
失败
失败
成功
成功
失败
结束
进入开发的软件
编辑软件信息
业务详细说明
用户先注册一个平台的帐号，登录后，点击我的软件（即开发的软件）进入，
后点击注册软件，填写相关信息，提交成功后，会产生一个软件注册序列号，此序
列号为核对客户软件的凭证。最后还需通过平台管理员审核，该软件才会出现在软
件商城中，才可供平台用户购买。
功能描述
注册软件主要是用于给想在该平台上出售软件的第三方客户（软件提供商）提
供软件入口，同时填写软件相关详细信息，图片，类别等。
注意：注册软件时需要客户填写软件入口，即客户所提供软件的发布网址，当
平台上的客户购买了软件后，点击进入使用时，将通过该软件入口进入软件。
用例图
图 2 软件审核用例图
图 3 注册软件用例图
平台管理员
软件审核
查看软件信息
审核软件
删除软件
<<uses>>
<<uses>>
<<uses>>
注册用户
注册软件
注册信息
绑定序列号
获得序列号
<<uses>>
<<extends>>
<<extends>>
软件编辑
业务流程图
图 4 软件编辑流程图
业务详细说明
软件注册成功并通过审核后，即可在我的软件（开发的软件）中查看，编辑或
删除该软件信息，同时还可为软件进行版本分类，可创建，查看，删除子版本。
功能描述
在我的软件中可查看，编辑，删除该软件信息，同时还可为软件进行版本分类，
可创建，查看，删除子版本。
用例图
图 5 软件编辑用例图
编辑子版本
获得子版本序列号
绑定序列号
软件上架
结束
开始
软件开发者
查看子版本
编辑软件
创建子版本
编辑软件信息
删除软件
<<uses>>
<<uses>>
<<uses>>
<<uses>>
软件购买
业务流程图
图 6 软件购买流程图
注册用户
进入软件商城
点击购买某软件，
进入购买页面
选择购买版本
填写购买授权个数
和年限
确定购买
购买成功
是否已经购买
结束
点击取消
没有
有
进入购买的软件
进入添加用户
用户是否存在
添加用户，把用户
添加到相应软件中
注册用户
已添加的用户个数<授权个数?
进入续费页面，添
加授权个数
是
否
否
授权期限未
到？
进入使用
进入续费页面，添
加授权期限
是
否
业务详细说明
用户在软件商城可查看所有平台已通过审核的软件，若用户已登录并未购买过
该软件，则可点击购买进行购买软件；点击查看详细信息，可查看软件的详细信息，
点击购买可进行购买（前提是用户已登录并未购买过该软件），若此用户已购买过该
软件则会提示已购买并跳到购买的软件页面，用户可点击进入使用，若此用户未登
录，则提示请先注册并登录。
添加用户：
若租户购买的授权个数大于 1，则可添加其他用户使用软件，添加用户有两种方
式：
1. 若用户已存在，即添加已在平台上注册的用户，则可通过注册时填写的电子邮
件地址进行查找，并添加，添加成功后，对方即可在参与的软件中使用该软
件。
2. 若用户不存在，即添加还未在平台上注册的用户，则可通过创建新用户来进行
添加，并把创建的信息告知对方，对方即可在参与的软件中使用该软件。
若不在想让某用户使用该软件，可通过删除操作来删除。
续费：
租户可根据仅追加使用授权个数，仅追加购买授权期限或同时追加个数和权限来
进行续费
功能描述
软件商城显示所有注册了并通过审核的软件，平台上已注册并登录的用户充值
后可选择相应的软件根据授权个数和授权时间进行购买。购买成功后即可在购买的
软件中查看并使用，同时还可进行续费，添加用户等操作。
添加用户用于租户添加自己所购买软件的使用人员，也可根据需要进行删除。
注意：授权个数即可使用该软件的人数，客户购买了软件后即成为租户，租户
可通过添加用户操作添加用户。
授权时间即该软件可使用的时间，若租户想增加授权个数或增加授权人
数，即可通过续费来完成。
用例图
图 7 软件购买用例图
参与软件
业务流程图
无业务流程图。
业务详细说明
通过软件购买中的添加用户可添加用户，成功后，用户点击参加的软件中相应软件的进
入使用，可使用包括自己购买的和通过其他租户添加进去使用的软件
功能描述
参加的软件中显示用户可使用的软件列表，包括自己购买的和通过其他租户添加进去使
用的软件
用例图
注册用户
购买软件
查看软件信息
购买软件
添加用户
续费
<<uses>>
<<uses>>
<<uses>>
<<uses>>
软件参与者
参与的软件
使用软件
<<uses>>
图 8 参与软件用例图
账户与个人信息
业务流程图
无业务流程图。
业务详细说明
用户可根据需要查看余额，进行充值，查看个人信息，修改密码等
功能描述
帐户与个人信息可查看用户的余额，可进行充值，查看个人信息，修改密码等操作
用例图
图 9 帐户与个人信息用例图
系统
注册用户
修改密码
个人充值
查看个人信息
<<uses>>
<<uses>>
<<uses>>
SaaS 平台免登陆接口
业务流程图
图 1-6-1 免登陆接口的处理流程
SaaS软件对请求访问调用接口
判断请求接口的名称
返回调用未声明接口的错误信息
获取请求的参数
返回需要请求参数为空的参数信息
判断请求参数信息的合法性
返回不存在或非法的参数错误信息
判断请求信息是否超时重传
返回超时重传的错误信息
处理接口调用请求,返回结果数组
[未找到相应的接口名]
[存在此接口名称]
[调用接口的参数全部获取]
[请求的参数不完全或为空]
[调用接口的Token已经超时]
[Token未超时]
[计算的sipsign符合要求]
[根据参数计算的sipsign不符合要求]
用户请求登陆SaaS软件，平台对SaaS软件传参数
业务详细说明
用户请求访问购买的 SaaS 软件：
用 户 请 求 使 用 用 户 购 买 的 SaaS 软 件 时 ， 平 台 会 将 用 户 ID(User_ID), 软 件
ID(Application_ID), 购买此软件的租户 ID(Renter_ID), 防止重传的 Token 这 4 个参数传值提
供软件提供商提供的网址。同时将此时生成的 Token 序列和时间与访问的用户 id，软件 id
一起保存在数据库里,Token 的有效时间理应当设为 10 秒到 20 秒左右。
SaaS 软件访问 调用免登陆接口：
SaaS 软件在注册时候会获得一个独有的软件序列号，软件提供商在软件开始运行
的代码中加入请求，访问平台判断此用户和本软件是否是合法的软件和用户，SaaS 软件应
该将软件序列号，时间戳（系统当前时间），请求的接口名，与传送过来的四个值用 md5 加
密生成一个新的 sipsign 的值，再把 sipsign，时间戳，请求的接口名和传送过来的四个值传
给平台的 页面请求调用免登陆接口。（如图 1-6-2 和 图 1-6-3）
图 1-6-2 sipsign 验证的生成
图 1-6-3 请求接口的 URL
判断请求接口的名称：
请求接口理应当分为很多类型，所以在处理页面上应当做分类处理，当然目前只实
现的免登陆接口，但为了以后的扩展这种业务流程上的判断不能少（接口名称的命名规则建
议为：公司名.模块名.功能名，这样可以用 split 做分类操作）。如果不存在此名称的接口，
则返回一个错误信息。
获取请求的数据：
根据接口类型的不同，获取不同名称的数据参数。如果获取的某一个数据参数为空，
则返回一个错误信息。
判断是否重传：
根据传送过来的 Token 序列号和用户 id，从数据库读出相应的 Token 记录，并比
较 Token 中的时间与平台上的当前时间是否超出了 Token 防重传的时间限制。如果超出了
防重传的时间限制，则返回一个错误信息。如果根据 Token 从数据库读不出任何数据，也
返回一个错误信息。
Token 存取的流程如图 1-6-4:
图 1-6-4 Token 存取流程
判断参数的合法性：
根据传送过来的参数，和平台从数据库读出相应的软件序列号重新做一次 sipsign
的运算，再将运算结果和 SaaS 软件传送过来的值做比较，如果相同则合法，如果不相同则
返回一个错误信息。
处理接口调用请求，返回结果数值：
通过一系列的合法判断，最后执行接口的处理请求，不同的接口处理方式不同，需
要返回结果由’&’特殊字符拼接成一个字符串返回给 SaaS 软件(也可以返回一个 xml)，如果
不需要返回结果的，可以返回一个成功信息。(这部分还需要对安全性进行考虑)
功能描述
接口的实现主要是针对 SaaS 软件与 SaaS 平台之间的关联矛盾。因为用户数据与买卖交
易数据都存放在 SaaS 平台之中。当 SaaS 软件需要获得买卖此软件的某些合法的用户数据的
时候就需要和平台进行一定的交互，此时候就要通过接口来实现此种交互。
目前 SaaS 平台上只实现了免登陆的接口，免登陆接口实现用户从平台到第三方软件的
链接不需要二次登陆，只需要在平台上购买了此软件，则可以从平台上直接登陆第三方软件
使用。
接口的种类可以有很多种，如果要扩展的话还可能要有获取购买此软件用户授权的接口，
查询购买此软件的用户信息的接口，以及其他等等。
用例图
接口模块不存在用例图。
SaaS 软件用户初始化
业务流程图
图 1-7-1 SaaS 软件初始化流程
业务详细说明
用户在平台登陆：
基于 SaaS 平台的 SaaS 软件的用户都是在平台上实现注册登陆的，这样平台上管理
多个 SaaS 软件的时候就可以一次登陆免去多个二次登陆的麻烦。用户在平台通过单点登陆
(SSO)链接到 SaaS 软件上。
选择购买的软件进入：
用户可以拥有多个软件，不同的软件有不同的软件入口地址。
用户在平台登陆
选择购买的软件进入
初始化租户信息及相关信息
SaaS软件调用免登陆接口
初始化用户信息
载入登陆用户的权限，信息
提示错误信息，返回平台
使用属于此用户的软件
[用户非法]
[用户合法]
[本地数据不存在此租户]
[本地数据存在此租户]
[本地数据不存在此用户]
[本地数据存在此用户]
判断用户所属租户是否存在
判断用户是否存在
SaaS 软件调用免登陆接口：
所有的软件一开始都应当判断进入用户的合法性。
判断用户所属租户是否存在初始化租户信息：
先查看本地数据库中是否存在与此租户是否存在，如果不存在则需要初始化租户及
相关的数据，所谓的初始化租户及相关的数据不止是将租户的信息加入到本地数据库，而且
要初始化 SaaS 软件的默认配置。譬如说 SaaS 软件本身具有默认的几个角色，但由于 SaaS
软件的特性是由多个不同的租户使用，不同的租户定义的角色有所不同，但又具有相同的系
统默认的角色，在这种情况下就需要在初始化租户的时候初始化 SaaS 软件的默认配置，将
系统本身默认的角色与此租户关联起来。还有一点要注意的是，SaaS 软件本地数据库里的
租户 id 就是用户在平台上的用户 id,通过这样才能判断平台上的用户是否已经在软件本地
里初始化过。
判断用户是否存在初始化用户信息:
如果本地数据库没有此用户信息，且此用户又是合法的，则将此用户的信息存放在
数据库里。如果 SaaS 软件系统功能上是分角色权限的，则需要把给此用户赋予一个最低的
权限，再由系统管理员（即是租户）提升此用户的权限。
载入登陆用户的权限，信息：
当一切判断结束后，如果用户合法且系统初始化信息完毕则用户获得一个具有他在
此系统的权限和信息的 Session。
功能描述
SaaS 软件初始化的过程也即是为了解决平台与 SaaS 软件之间的关联矛盾问题。但不同
的是此部分必须要由软件提供者完成，也就是软件提供者需要在用户登陆的时候就需要判断
初始化数据(尽管从流程上看很繁琐，但必不可少)。这个初始化的过程可以解决不同租户在
软件中配置不同且又都保留系统默认配置的问题。
在初始化的设计我们采用的是一对一的设计方式：
图 1-7-2 初始化方式
这种初始化方式即是每个用户就需要经历初始化判断的过程，且只有判断后才能把用户
数据添加到本地数据库里。即是一个租户买了软件后添加了用户，租户可以不先登陆，用户
可以先登陆（因为所有的用户都会触发初始化过程），然而只有登陆过的用户才能出现在
SaaS 软件的本地数据库中。这种初始化过程是采用分别初始化，一一对应的方式。（至于基
于组织结构方式进行初始化方式，我们在改进的功能点与方案中再进行描述讨论）
用例图
此模块无用例图。
租户1
租户1下的用户1
租户1下的用户2
判断初始化租户 判断初始化用户
在数据库添加用
户数据
3．SaaS 平台需改进的功能点与方案
基于组织机构的软件用户管理方式
原功能描述
SaaS 平台的设计是基于用户的软件使用方式，也就是说每个用户在平台上都是平级的，
当用户购买了软件之后他就成了这个软件的一个特定的租户，当用户想要其他的用户使用自
己购买的软件的时候，可以把这个软件的使用授权赋予其他平台用户，至于具体的权责划分
就在软件中划分，当然租户可以收回赋予的软件使用授权。这样的方式是以个体用户为中心，
采用平级的处理来实现软件用户管理。（这方面还需要对恶意注册进行考虑改进）
改进后的功能描述
根据新的需求，SaaS 平台追加一种基于组织机构的软件用户管理方式。也就是说一个
组织机构购买了一个软件后可以把软件授权赋予在所属组织机构的用户上。这样的实现方式
可以让软件用户的管理更简单，组织机构当然也可以回收某个用户的使用权限，并赋予某个
用户多个软件的使用权限。同时，SaaS 软件初始化的过程中可以让组织中的人员角色与 SaaS
软件中人员角色相对应（此功能很难实现）。
实现方案
如果要添加基于组织机构的软件用户管理方式，则必须先要添加组织机构的注册。也就
是说注册的类型分为个人用户注册和组织机构注册。至于组织机构的里所属的用户在理念上
是可以由用户自由添加和管理的（这种设计可以认为 SaaS 平台也具有 SaaS 软件的部分特
点），同时组织机构里的用户也可以设置职位（职位在 SaaS 平台中并没有太大的作用，但此
类信息在组织机构的初始化过程中可能要用到，详细信息在基于组织机构的软件用户初始化
方式中讨论说明）。那么一个基于组织机构的软件用户管理方式可以看成是一个简单的管理
系统，如图 3-1-1:
图 3-1-1 组织机构的软件用户管理方式
既然组织机构里有属于此组织机构独有的用户，那么出于安全与系统设计上的考虑我们
需要让组织机构中的用户与普通的个体用户分别独立开来，所以我们要加一张组织机构用户
表来专门存储组织机构用户数据，同时必须要有一个数据字段来记录组织的 id，如图 3-1-2：
图 3-1-2 组织机构用户数据结构
用户数据信息里可以存放用户的账号，密码，职位等其他用户信息。而组织机构用户是
可以由组织机构随意添加的，但组织机构用户只能有其所属的组织机构管理（此部分存在一
个恶意注册的问题，可以考虑每个组织机构有个添加用户的上限）。当然，组织机构用户与
普通的个体用户在平台上的功能也应该有所不同，且他们涉及到的关系业务逻辑也应当有所
不同，具体的设计想法如下：
1, 个体用户与组织机构间没有任何关系，即是和组织机构用户没有任何
关系，个体用户购买的软件授权是不可以赋予组织机构的用户的。
2, 个体用户是一个平级的概念，组织机构用户有上下级关系。
3, 个体用户可以通过购买软件成为一个租户，组织机构用户永远都是隶
属于组织机构这个租户下的用户，同时也不具有购买软件的功能。
4, 个体用户和组织机构用户登陆后所看到的页面应当是不同的。
5, 个体用户只能由平台的系统管理员管理，而组织机构用户可以由组织
机构管理。
软件使用授权的使用分配，其具体的实现方式因为个体用户与组织机构的分类而进行分
基于组织结构软件用户管理
添
加
组
织
机
构
用
户
删
除
组
织
机
构
用
户
设
置
组
织
机
构
用
户
信
息
和
职
位
赋
予
组
织
机
构
用
户
软
件
授
权
管
理
组
织
机
构
用
户
软
件
授
权
类处理的，普通个体用户的软件授权是赋予其他的普通个体用户，这个个体用户可以由用户
自己添加也可以查找现有的个体用户的账号，这种授权方式简单但操作起来麻烦又不便管理。
至于组织机构的授权方式，就是组织机构购买的软件授权赋予组织机构下的组织机构用户，
这种选取方式更灵活，如图 3-1-3 ：
图 3-1-3 组织机构软件授权方式
为了更好的管理组织下的用户，组织机构也需要设定一个层级关系，如图：3-1-4
图 3-1-4 组织机构人员层级关系
又由于组织机构用户是与组织机构与个体用户的数据表是分开的，所以组织机构管理员
对组织机构用户的添加，删除，修改都是可以的，且不会影响平台用户的操作和数据。
要实现这部分功能，要添加组织机构表，组织机构用户表，方便层次管理的部门表。如
果要自定义角色的话还要添加个组织机构角色表。
组织机构管理者
组织机构人员列表
用户1
用户2
用户三
[赋予软件A的授权]
[赋予软件B的授权]
[赋予软件A的授权]
[赋予软件B的授权]
基于组织机构的软件用户初始化方式
原功能描述
原来平台上的用户都是个体用户，且都是平级的，初始化的方式是采用分别初始化，一
一对应的方式。也就是说每个可以使用此软件的用户只有第一次登陆到 SaaS 软件中去才能
在 SaaS 软件中初始化用户数据。这种初始化方式每次初始化的流量小，且每个用户的登陆
都能触发租户信息的初始化，但不方便的是需要每个用户登陆到软件中。
改进后的功能描述
由于出现了基于组织结构的软件用户管理方式，相应的也应当增加基于组织机构的初始
化方式。基于组织机构的初始化方式不同于普通的个体用户初始化方式，其应当采用的是组
织机构管理员登陆一次性初始化这种方式。也就是说，当组织机构购买了此软件的时候需要
组织机构管理员登陆 SaaS 软件以便于初始化。而且这种触发方式只应当由组织机构管理员
来触发实现，当组织机构管理员未触发此初始化事件的时候，其他组织机构用户是无法访
问 SaaS 软件的。（这种初始化方式一次性要传送大量的数据，如果发生网络冲突或中断的话，
要利用一些方法进行修正，当然也可以沿用原来的初始化方式，不过这样就大大降低了组织
机构的灵活性）
实现方案
方式一
从最直接的实现方式入手就是当组织机构管理员登陆软件的时候传送大量的数据，从而
使得整个组织结构的系统初始化。此方式如图 3-2-1：
图 3-2-1 组织机构初始化方式 1
由于存在一个网络冲突的原因，有可能在第一次初始化的过程中失败。所以基于这部分
的考虑，在设计上我们在组织管理员初始化之后需要每个组织机构用户在登陆 SaaS 软件的
时候都需要通过少量的数据交互与平台核对一下用户是否完成全部初始化完成，也就是说平
台上的组织机构用户的数量与软件上的组织机构用户数量进行核对比较，如果不符合的话就
应当调用平台上的提供的接口重新初始化。方式如图 3-2-2：
组织管理员
初始化 登陆系统
[携带所有的组织机构信息] [成功初始化]
图 3-2-2 组织机构防初始化失败方式
这种方式的实现需要在平台添加一个重新初始化接口，同时 SaaS 软件的初始化代码也
要有所更改。还有一点非常重要，就是在 SaaS 软件中默认配置的初始化一定要放在用户初
始化的前面（因为判断的时候只是判断用户数量是否初始化完成）。
方式二（强烈不推荐）
这种方式是继续沿用原来的初始化方式,也就是分别初始化，一一对应的方式，此实现
方式要考虑个体用户和组织机构所构成的租户 id 重叠问题(因为 SaaS 软件本地的数据库的
租户 id 是和平台上的用户 id 相关联的，现在又多了组织结构表和组织机构用户表，即是组
织机构管理员也可以成为租户，这样 id 就可能相同)。我们可以让个体用户的租户 id 用数字
表示，而组织机构的租户 id 用数字字母形成的序列号表示。当然，如果采用这种方式的话，
SaaS 软件的 id 模式就可能不统一了。也可以在初始化过程中指明初始化类型是组织结构方
式的，从而用一种算法替换 id 数值，这种方式也可以解决个体用户与组织机构用户的 id 冲
突问题。
总的来说，这种实现方式不利于管理，使得组织结构方式的软件用户管理灵活性大大下
降，但实现起来比方式 1 更简单（更改的代码量少）。
组织机构用户
核对用户数量 登陆系统
[携带组织机构用户数量]
[成功登陆]
[请求调用重新初始化接口]
