1、详细设计说明书SaaS统一信息化平台文档一旦发布，请务必按文档执行并坚持遵守。如果您有改进的建议，请将您的建议发邮件或当面告知所列作者。SaaS统一信息化平台文件号: LITTCORE-0001详细设计说明书版本号: 1.30修订历史记录版本日期作者修正原因1.02013-05-23蔡源初始化文档1.12013-08-30蔡源增加【定制化、个性化】章节1.22013-09-29蔡源增加自动登录的设计1.32013-10-15蔡源增加参数字典设计增加客户管理设计1.42013-10-18蔡源增加应用场景及解决方案章节，用于描述特定业务流程或者功能流程的实现1.52013-12-04蔡源增加【团队
2、协作】相关设计，主要包括项目管理和任务管理1.62013-01-15蔡源增加用户与租户空间一对多的设计，用户可以在不同空间中切换1.72014-05-05蔡源参数字典增加filter和params属性，用来根据业务过滤和获得额外参数1.82014-05-16蔡源细化具体的子系统和具体的功能模块1.92014-05-22蔡源细化QuickView，增加动态查询条件定义和动态表格定义1.102014-06-19蔡源增加DynamicSearch，支持动态组合查询条件1.112014-06-26蔡源增加系统公告模块1.122014-06-27蔡源更新参数字典编号规则为：模块名+属性名，全局唯一1.1
3、32014-08-20蔡源增加【文档管理】模块定义增加【项目文档】模块定义1.142014-11-10蔡源增加【个人文档】模块定义1.152014-11-13蔡源快速视图和动态查询条件增加descr属性，作为tip浮动显示，因为只显示名称太短了，无法详尽描述这个视图的功能1.162014-12-03蔡源细化OA协同办公的基础功能模块1.172015-01-06蔡源增加【业务角色】设计，用于配置数据访问权限和字段访问权限1.182015-02-01蔡源将概要性内容转移至概要设计，仅保留具体设计部分1.192015-02-05蔡源增加租户配置信息设计启用AppStore设计，每个业务子系统通过Ap
4、pStore来进行管理增加“系统版本定义与升级”1.202015-02-27蔡源客户信息增加收货地址属性1.212015-03-27蔡源细化MVP所需的功能模块说明1.222015-05-11蔡源细化消息中心的事件推送和任务提醒；删除【文档管理】，统一使用网盘；增加通用数据权限设计1.232015-06-03蔡源增加图片服务的说明1.242015-06-24蔡源配置管理重构，基于obj+json-text方式存储，而不按单个属性存储1.252015-06-30蔡源调整tag表设计1.262015-07-02蔡源TODO增加公开和场景功能，提升协作效果1.272015-10-10蔡源联系人增加i
5、sFav属性1.282015-10-10蔡源基础平台功能修订，调整表结构1.292015-10-19蔡源增加“系统自动升级”1.302015-10-20蔡源增加对业务日志的实现方案设计OpLog增加opComment属性1.312015-10-21蔡源增加Portal组件的详细设计1.322015-10-25蔡源拆分“平台运营系统”为“平台管理系统”和“平台运营系统”，将运营类分开1.332015-11-12蔡源增加【业务关注与消息通知】的设计1.342015-12-04蔡源附件表新增recordUid1.352015-12-18蔡源增加公告的缩略图、统计等1.362015-12-29蔡源增加
6、运营中心基础表设计1.372016-01-18蔡源增加通用的数据权限表1.382016-03-10蔡源增加【通用自动编号组件】的设计1.392016-03-18蔡源增加【数据关联表】设计1.402016-04-11蔡源增加【用户抄送】设计1.412016-04-27蔡源增加实名认证相关字段1.422016-05-23蔡源增加workStatus字段1.432016-05-25蔡源增加用户余额的设计，支持充值提现1.442016-06-15蔡源TenantMember增加微信关注相关字段目录修订历史记录2目录41. 引言121.1 编写目的121.2 背景121.3 参考资料121.4 术语定义
7、122. SAAS设计122.1 多租户模式122.1.1数据隔离122.1.2实现多租户的三种模式122.1.3数据过滤132.1.4总结132.2 定制化、个性化132.3 门户、流程、智库、社区132.4 MetadataDB142.5 系统用户角色142.5.1租户拥有者142.5.2租户管理员142.5.3租户成员142.6 客户用户角色152.6.1系统管理员（内部）152.6.2高管（内部）152.6.3客户经理（内部）152.6.4销售主管（内部）152.6.5销售人员（内部）152.6.6合作伙伴（外部）152.6.7供应商（外部）152.6.8客户（外部）162.7 身份验
8、证与授权162.7.1授权模式162.8 可扩展性162.8.1基础设施可扩展性162.8.2应用架构可扩展性162.9 数据权限172.10 参数字典172.11 日志记录172.11.1业务日志182.12 个性化192.12.1界面个性化192.12.2数据个性化192.12.3功能个性化193. 数据模型203.1 用户信息（UserInfo）203.2 用户扩展信息（UserExt）213.3 用户状态信息（UserState）213.4 用户自动登录信息（UserAutoLogin）223.5 用户操作日志(UserOpLog)223.6 组织架构（UserGroup）233.7
9、用户组成员（UserGroupMember）233.8 租户订单信息（TenantOrder）243.9 租户信息（Tenant）253.10 租户配置信息（TenantConfig）253.11 租户成员信息（TenantMember）263.12 租户状态信息（TenantState）263.13 应用商店（AppStore）273.14 应用订单信息（AppOrder）273.15 参数字典类型（DictParamType）283.16 参数字典（DictParam）283.17 租户参数字典（TenantDictParam）293.18 菜单（Menu）293.19 角色（Role）3
10、03.20 用户角色（UserRole）313.21 用户组角色（UserGroupRole）313.22 角色功能权限（RoleFuncPermission）313.23 激活码（ActivationCode）313.24 业务角色（BizRole）323.25 业务角色成员（BizRoleMember）323.26 业务角色数据权限（BizRoleDataPermission）333.27 业务角色字段权限（BizRoleFieldPermission）334. 系统辅助数据模型334.1 快速查询视图(Quickview)334.1.1简单查询条件（QuickviewFilter）344
11、.1.2高级动态查询条件（QuickviewAdvFilter）344.1.3表格呈现（QuickviewGrid）354.1.4最终效果354.2 附件(Attachment)364.3 标签(Tag)364.4 标签关联数据表(TagAssoc)374.5 用户评论(UserComment)374.6 用户收藏 (UserFavourite)374.7 用户Portal小组件表（UserPortlet）385. 消息中心数据模型385.1 用户消息订阅（UserMessageSub）385.2 用户一般消息（UserMessage）385.3 用户推送消息（UserPushMessage）
12、395.4 短信发送日志（SmsOut）395.5 短信接收日志（SmsIn）405.6 通知公告(Affiche)405.7 通知公告统计（AfficheStat）405.8 用户反馈(Feedback)415.9 用户事件(UserEvent)416. 个人事务数据模型426.1 记事本（Note）426.2 代办事项（Todo）426.3 个人网盘（ShareFile）426.4 联系人（Contacts）436.5 联系人分组（ContactsGroup）436.6 联系人分组成员（ContactsGroupMember）437. 运营中心数据模型437.1 报表分类（ReportCa
13、talog）447.2 报表模版447.3 报表实例（Report）447.4 报表订阅（ReportSubscribe）448. FRAMEWORK设计448.1 分布式448.1.1分布式系统容错458.2 分布式Session(SNA)458.2.1Sticky Session、Non-sticky Session和Replicated Sessions458.2.2基于 ZooKeeper 集群的分布式 Session 方案468.2.3基于Cookie的分布式SessionId468.2.4问题478.3 用户、部门、组织、角色与权限478.4 动态属性与用户自定义属性478.5 电
14、子表单488.5.1技术方案488.6 DynamicQueryObject498.7 FuncInceptor498.8 内容过滤498.9 SOA498.10 电子邮件服务508.11 缓存服务508.11.1缓存分类508.12 消息服务518.12.1短信服务518.13 任务服务518.14 模板服务518.15 附件服务518.16 文档服务518.16.1功能点518.17 图像服务528.18 Quickview（组件）528.18.1首字母或拼音过滤528.19 自定义列呈现（组件）528.20 Tags（组件）538.21 Portal（组件）538.21.1Portlet
15、Meta538.21.2Portlet函数列表548.21.3Portlet事件列表548.21.4内置Portlet548.22 数据清理服务558.23 系统帮助558.23.1功能点558.24 系统自动升级559. 运维&实施569.1 系统版本定义与升级569.1.1代码中版本号变更流程5610. 应用场景及解决方案5610.1 用户会话超时5610.2 用户账号激活5710.3 租户开通5710.4 租户到期5710.5 租户续费5810.6 租户升级5810.7 租户注销5810.8 用户登录5810.8.1非租户5810.9 租户成员注销5810.10 用户信息获取5910.1
16、0.1租户管理员5910.10.2租户成员6010.11 邀请用户6010.11.1加入邀请(邮件)6010.11.2加入邀请(站内通知)6110.12 切换工作空间6110.13 数据授权6110.14 业务关注与消息通知6110.14.1数据授权与分页查询6211. 平台管理系统6311.1 参数字典（暂不实现）6311.2 系统配置6311.3 在线用户管理（暂不实现）6311.3.1强制用户下线6411.4 AppStore管理（暂不实现）6411.5 租户管理6411.6 订单管理6511.7 用户管理6511.8 数据备份/恢复6511.9 数据迁移6611.10 数据清理6612
17、. 平台运营系统6612.1 客服6612.2 大数据6612.2.1租户行为分析6612.2.2用户行为分析6713. 基础支撑系统6713.1 用户系统6713.1.1用户注册6713.1.2用户登录6813.1.3用户档案6813.1.4忘记密码6813.1.5用户登出6913.1.6自动登录6913.1.7账号迁移6913.1.8邀请用户6913.1.9受邀加入7013.1.10共享APP（暂未实现）7013.1.11第三方接入7013.2 Dashboard7013.3 消息中心系统7013.3.1消息通知7113.3.2通告中心7113.3.3新闻中心7213.3.4短信中心(暂不
18、实现)7213.4 租户系统7213.4.1空间管理7213.4.2组织架构7513.4.3成员管理7613.4.4角色权限7813.4.5参数字典管理7813.4.6数据备份/恢复7913.4.7操作日志7913.4.8模板管理7913.4.9个性化管理7913.5 AppStore系统7913.5.1租用APP7913.5.2已购APP7914. 个人事务子系统7914.1 我的消息7914.2 我的待办8014.3 站内信8014.3.1功能点8014.4 记录本8014.4.1功能点8014.5 TODO List8114.6 工作计划8114.7 日报周报8114.7.1功能点811
19、4.8 我的网盘8114.9 我的通讯录8214.9.1功能点8215. 团队协作子系统8315.1 项目管理8315.2 任务管理8315.3 主题讨论8315.4 文档管理8315.5 知识库8316. CRM子系统8317. 企业门户网站子系统(CMS)8318. OA办公自动化8318.1 审批管理(工作流)8319. 财务管理子系统8419.1 应收款管理8419.2 应付款管理8419.3 费用预算8419.4 报销管理8419.5 用款管理8420. 运营中心子系统8420.1 综合报表子系统8521. 客户自助服务平台（SELFSERVICE）8521.1 咨询投诉8521.2
20、 询价8522. 附注8622.1 参数字典表清单8622.1.1通用8622.1.2用户表8622.1.3角色表8722.1.4租户表8722.1.5站内信8722.1.6TODO8722.1.7日程计划8822.1.8客户信息8822.1.9项目8822.1.10任务8822.1.11公告891. 引言1.1 编写目的详细设计的主要任务是对概要设计方案做完善和细化。说明书编制的目的是说明一个软件系统各个层次中的每个程序（每个模块或子程序）和数据库系统的设计考虑，为程序员编码提供依据。本文档在概要设计的基础上，进一步完整详尽的描述了系统实现的技术细节，及根据业务需求制定的系统所需要实现的业务
21、功能，功能模块的详细定义。1.2 背景1.3 参考资料1.4 术语定义缩写英中2. SaaS设计2.1 多租户模式2.1.1 数据隔离l 将每个承租者的数据隔离到不同的数据库。l 共享数据库，Multi-Schema，将每个承租者的数据隔离到独立的表和模式。l 共享数据库，Share-Schema，在所有承租者之间共享一组相同的表和模式。2.1.2 实现多租户的三种模式 无共享，完全独立：每个租户独立使用一套应用程序和一个数据库，应用与数据库均不包含租户信息，通过访问入口路由到指定租户的路径上。n 优点：u 无需修改原有应用程序跟数据库。u 租户间不会相互影响，可对个别租户做自定义。n 缺点：
22、u 部署跟运维相对繁琐。u 物理设施资源开销最大。u 无法对多租户数据进行查询归并，存在数据孤岛 共享应用，多数据源：使用同一套应用程序，数据库访问时根据租户信息路由到指定数据库或Schema上。n 优点：兼顾了开发和性能。n 缺点：u 无法对多租户数据进行查询归并，存在数据孤岛 共享应用，单一数据源：使用同一套应用程序，使用同一个数据库，数据模型中定义了租户信息，通过过滤条件过滤租户数据。n 优点：性能最优，部署简便n 缺点：u 对系统架构和开发工程师要求较高，否则可能存在数据安全性问题u 运维复杂，当数据发生异常需要恢复时，无法简单依赖数据库的恢复机制，并将影响到多个租户的数据2.1.3
23、数据过滤在共享同一数据源的模式下，需要对每个数据查询增加租户信息的过滤条件；在单app环境下，一个用户只对应一个租户，通过登录用户信息即可获得租户信息，比较简单。但是在平台模式下，一个用户可以租用多个app，用户与租户是一对多的情况。解决方案：用户在登录一个app时，app通过appKey去平台获取该用户的信息，并在本地session中保存用户登录信息，平台可以根据appKey与用户ID获得唯一的tenant，即app本地session中只需保存用户对象与tenant对象一对一的关系。只有用户在登录平台系统时才有一对多tenant的情况。2.1.4 总结实际使用中可能综合运用3种模式，即如果客
24、户较为重要，愿意为安全性、性能等额外付费，可部署为独立模式。常规情况下则使用共享数据库模式，但根据性能或部署需要，可能根据用户数切分为多个domain，每个domain中的用户共享一个数据库，这样如果某个domain失效，不会影响其他用户的使用。但基本原则是所有数据表均按SaaS模式设计，以便实现不同模式下的切换。2.2 定制化、个性化定制化指的是同一SaaS服务可以为不同用户在相同基础功能的基础上提供一定程度的功能定制或强化，在不改动或尽量小改动服务的基础上实现不同用户的差异化功能性需求。如：数据模型的定制化，业务流程的定制化。个性化指的是为客户提供的，满足用户企业或个人个性需要的非功能性需
25、求，如国际化、主题、收藏夹、菜单结构调整、Logo或程序名调整、Dashboard等。2.3 门户、流程、智库、社区注：所有方面，不仅是为了解决企业内部问题，更可以推向上下游，如企业门户网站就是对外的，通过BPM可集成上下游的业务系统，实现供应链的业务流转并最终实现E2E。智库可以形成企业最佳实践和解决方案，可以在行业中共享和推广。社区更可以通过人与人之间的关系，加强企业间沟通。注2:4个类别，都是强调信息的汇聚、共享、传播，通过SaaS模式可以实现这些方面的最大化，这是传统单一企业内部信息化无法实现的。通过门户来集成分散的功能，信息，提高用户对关键信息的关注度，提高用户对信息的获取和处理效率
26、。通过流程来组装分散的业务，实现上下游业务的E2E一体化，提高业务协作能力，提高业务间信息共享，并最终提高企业整体业务的处理效率。（注：流程可能在某些环节的处理效率会比以前降低，但其目的是优化整体效率）通过智库来积累知识，沉淀企业智慧。知识的有效积累可推动企业业务流程重组和优化，加强企业文化建设，提高员工凝聚力。社区是强调企业人与人之间的沟通，有别于上面三项都是以企业运营为目的的。- 这个待定2.4 MetadataDB元数据数据库，定义了多租户相关信息，用于租户信息管理，作为基础的公共服务独立于业务系统数据库。2.5 系统用户角色2.5.1 租户拥有者租用app的用户，作为app的拥有者，其
27、拥有app的所有功能模块使用权限；同时作为拥有者，可以对app进行续费、升级、停用等操作。此外作为app的第一个默认用户，也是默认的租户管理员（租户开通时默认创建），具有租户“系统管理”模块的功能权限，可以在租用范围内创建角色，邀请其他用户加入，分配权限。2.5.2 租户管理员租户拥有者出于管理角度考虑（如租户拥有者是老板，但是管理员是IT管理员），可以将租户中的任意用户提升为系统管理员，由其作为租户管理员协助或负责租户内相应的管理工作，如用户管理，角色管理，功能权限分配，邀请用户加入等。租户管理员在权限上与租户拥有者一致，但租户拥有者作为最高级别，可随时将租户管理员降级成普通用户；而反之则不
28、行。2.5.3 租户成员租户开通后，默认只有拥有者一个成员，此时拥有者可通过邀请方式请求其他用户加入到该租户中共同使用租用的app。如：老板租用了CRM系统，邀请公司内部员工加入到该系统中，员工即可使用CRM系统的功能，并在租户范围内共享数据。用户在加入一个租户后，需要租户管理员为其开通相应功能模块的使用权限（通过设置角色），否则只能共享【个人事务】中公开部分的数据。2.6 客户用户角色2.6.1 系统管理员（内部）管理系统用户、角色与权限，保证系统正常运行。2.6.2 高管（内部）审查客户贡献数据、客户构成数据、客户服务构成数据和客户流失数据。2.6.3 客户经理（内部）维护负责的客户信息。
29、接受客户服务请求，在系统中创建客户服务。处理分派给自己的客户服务。对处理的服务进行反馈。创建销售机会。对特定销售机会制定客户开发计划。执行客户开发计划。对负责的流失客户采取“暂缓流失”或“确定流失”的措施2.6.4 销售主管（内部）对客户服务进行分配。创建销售机会。对销售机会进行指派。对特定销售机会制定客户开发计划。分析客户贡献、客户构成、客户服务构成和客户流失数据，定期提交客户管理报告。2.6.5 销售人员（内部）接受销售任务，负责与客户接触，实施销售任务，跟踪客户消费。2.6.6 合作伙伴（外部）部分数据交互，并提供合作伙伴关心的数据，可由合作伙伴自行访问（SelfService）。2.6
30、.7 供应商（外部）部分数据交互，并提供供应商关心的数据，可由供应商自行访问（SelfService）。2.6.8 客户（外部）提供客户关心的数据，可由客户自行访问查询（SelfService）2.7 身份验证与授权身份验证和授权是现实应用程序的安全性概念中主要的两个：l 身份验证允许一个应用程序在连接时验证一个人（或一个应用程序、智能卡等）是否与它声明的一样。l 授权定义一个用户在一个系统上的权利与权限。用户身份验证通过之后，授权会决定该用户在系统上有权做什么。因此，授权应该发生在身份验证之后。身份验证和授权在 SaaS 应用程序中很复杂。在一个安全性 SaaS 解决方案中，底层的身份验证和
31、授权基础设施有两种设计方法：集中式或联邦式。2.7.1 授权模式黑盒模式：即简化的权限模型，不开放授权功能给用户，角色和权限由系统内置，用户在加入App时自动绑定角色，对于一个App来说通常有：创建人，管理员和普通成员3个角色。白盒模式：即允许用户授权，App创建人可在自行创建用户组和角色，并对每个功能模块进行细分授权。该模式可实现更精细的权限控制，类似传统的企业应用。2.8 可扩展性2.8.1 基础设施可扩展性l 计算资源快速供给l 应用快速部署l 资源按需分配l 自动化管理2.8.2 应用架构可扩展性l 应用服务器水平扩展l 数据库水平扩展n MySQL Sharding（）l 异步消息队
32、列l 缓存机制l 负载均衡l 流程可定制l 功能可配置2.9 数据权限对于前台数据查询，通过定义数据级权限实现动态表格内容输出，不同角色的用户将看到不同列的表格及经过过滤的数据内容。 按角色定义哪些数据项可以呈现，并能调整列呈现的顺序； 按角色定义过滤条件，实现基础数据的过滤；2.10 参数字典参数字典分“参数类型表”和“参数字典表”。参数类型表定义不同类型的业务参数，如用户类型、公告类型等。每个类型又可分为：1 不可修改，2 可增加，3 可修改，4 可删除4种。如公告类型，可被定义为“可增加”类型的，即公告类型可以增加，但不能被修改或删除。参数类型表另外用状态字段定义：1 正常，2 屏蔽，9
33、 系统。对于某些业务需要，不需要用到的参数，可设置成屏蔽，即在业务系统中将无法使用该参数；对于状态为系统的，则不能进行此项操作。参数字典表为明细表，对参数类型定义业务参数，如公告类型可分为：1 公告，2 新闻，3 通知，4 紧急通知等，由于公告类型为可增加类型，故可在此基础上进行增加，但一旦使用过的公告，则不能进行修改或删除了。对某个业务参数细项，又有3种状态：1 正常，2 屏蔽，9 系统。由于业务需要可暂时屏蔽某些业务参数；但对于状态为系统的则不能进行此项操作2.11 日志记录日志按照类型分：操作日志、业务日志、系统日志。不同类型的日志有其相应的处理逻辑及具体实现，以下分别说明。操作日志：记
34、录操作员登录后执行的相关操作。（目前只对更新数据库的操作记日志，查询不记录）业务日志：记录业务处理信息，如转账时金额的变动数额等。系统日志：记录系统日常运行时的行为日志，目前采用通用的日志框架，以手工编码的形式记录操作日志同具体的业务应该是相互分离的，不在同一个事务中，及无论业务操作是否成功，都将记录用户操作。而业务日志记录业务的详细信息，应作为业务的一部分，与业务存在同一个事务中。因此操作日志一般在控制层编写，而业务日志一般在业务层编写。注：可通过注解+拦截器模式提供非入侵的操作日志记录；而业务日志一般只能编码实现。操作日志模型属性名称类型备注busiType业务类型int0 - 未指定1
35、- 保存2 - 更新3 - 删除4 - 查看5 - 查询6 - 审核.moduleCode模块编号String对所有功能模块，都有唯一对应的编号，如“系统配置”对应“SYS-001”opId操作员IDLongopName操作员名称String冗余数据，这样就不需要关联操作员表了opIp执行操作的IPStringopDatetime操作时间Date数据库默认content操作内容String具体操作内容描述status操作状态int0 - 失败1 - 成功2.11.1 业务日志业务日志需要记录详细的业务数据变化，无法使用Annotation在方法级进行拦截，需要硬编码实现。考虑到一定的通用性，我
36、们采用基于事件(Event)的日志模式，即在日志模块中通过订阅操作事件（OpEvent）获得业务模块发布的业务事件，再通过模板消息将业务参数格式化成操作详情。需要记录业务操作日志的，在业务执行完后通过EventBus发布继承于BaseOpEvent的事件对象，操作日志模块统一订阅该事件并统一转换存储。发布事件代码示例：说明：业务操作的名称将通过国际化转换成对应用户语言，国际化KEY命名规则：模块编号.func.功能编号；日志详情基于动态参数格式化，因此需要将必要的属性作为事件的动态参数传入，国际化KEY命名规则：模块编号.func.功能编号.log。由于某些日志详情需要生成HTML的超链，依赖
37、contextPath，因此约定contextPath将作为默认0位传参传入，业务参数在参数数组中的位置从1开始，如下面事件中commentId的位置为1。2.12 个性化2.12.1 界面个性化用户可在一定程度上对界面做定制化，如使用个性化主题，个性化布局，可自行调整菜单结构等。2.12.1.1 系统菜单可配置性菜单对不同的租户来说，可能有不完全一样的名字。例如客户管理，在医院使用时，就得改成病人管理，客户服务人员就得改成医生，客户服务记录就是就诊记录等。另外菜单的层次结构和分布，不同的租户可能也会有不同的要求。在设计上需要考虑以下几个问题： 一个租户一套菜单； 一个菜单可以关联一个子功能；
38、 组织成树型结构，构成上下级菜单结构； 同级菜单之间还存在显示顺序的问题2.12.1.2 页面元素可配置性各功能界面上的内容也是供用户和系统交互的界面元素。不同的租户可能有各种不同的需求。由于租户可以自定义扩展数据，这些数据是需要在页面上展示的，因此无论对页面元素的个数、位置、顺序，还是元素的含义，租户都会有一些个性化的需求。同时对于在设计时设定的界面元素，一般情况下是不允许删除的，但有时候还是允许租户将一些无关紧要的字段隐藏。2.12.2 数据个性化在实际应用中，不同租户之间需求的差异导致系统需要针对不同租户保存许多扩展性数据。在传统应用中，可以通过定制实例，增加客户的扩展数据，来满足其个性
39、化要求。在多租户SaaS应用中，所有租户都使用同一个数据架构，常见的解决办法就是实现扩展数据的可配置。名称值对的方式将扩展数据的保存和原数据表分离，另外用一个统一的扩展数据表来保存。扩展数据表将数据表的横向扩展列转换为纵向的数据集，将每一条原始数据记录的一个扩展字段，都保存成一条扩展数据行。将数据表中的数据记录与配置元数据表中的配置记录关联，构成扩展数据记录。可以提供无限数量的自定义扩展字段。但是其增加数据操作的复杂性，查询时也要多次访问数据库才能得到完整的业务数据。这些都会影响数据访问性能。此外可结合使用NoSQL，通过SchemaFree模式提供高扩展性和个性化。2.12.2.1 参数字典
40、不同的用户在对参数字典的使用上也会存在差异，如客户等级，有的喜欢用1、2、3表示，有的喜欢用A、B、C表示，这就需要参数字典也需要能够支持多租户，并可定制。2.12.3 功能个性化对于SaaS应用，面对为数众多的租户，大部分租户可能只会使用到应用中的部分功能。因此系统需要支持租户有选择的使用自己需要的功能，满足功能可配置要求。2.12.3.1 原子功能划分要实现功能可配置，首先需要将整个系统的功能进行分解。整个应用需要分解成最基本、相对独立、互不重叠的原子功能。所有原子功能叠加起来，就是整个应用所提供的全部功能。进行原子功能划分，首先就是功能分解，即将整个系统的功能分解成最基本的相对独立的原子
41、功能，应遵循以下几个原则： 每个功能都是有价值的；n 每个功能都是不可再细分；n 功能间互不重叠；n 功能之间不循环依赖；n 整个系统功能是完整的。将功能分解完毕后，由于不是所有的原子功能都是可以单独使用的。有些功能是需要依赖其他功能才能使用，功能之间是存在一定的依赖关系。因此功能分解完毕后，还需要对功能进行定义，描述相关依赖关系。2.12.3.2 功能包设计当系统功能被划分为许多原子功能后，直接配置原子功能给每个租户是比较复杂的。需要根据用户类型和使用的场景，对原子功能进行打包，然后为每个用户配置其合适的功能包。功能包的设计要遵循高内聚、低耦合的原则，尽量将相关的和相互依赖的原子功能设计在一
42、个功能包中。同时应该减少功能包和功能包之间的依赖，使得各个功能包尽可能独立的进行操作使用。通过功能包的设计，虽然可以将系统功能组合成几个相对比较独立的部分，但是这些功能包仍然不可以完全独立使用，也就不能够单独销售。为了让用户购买了系统以后可以充分使用其同能，需要按照不同的商业意图构造合适用户的销售包。例如，按照客户使用功能的多少，可以把系统划分为最小版、标准版、完整版。2.12.3.3 功能使用校验在经过对系统进行原子功能划分和功能包的设计后，系统的不同租户可以按照不同版本使用了，系统需对原子功能进行校验，确定租户在系统中可以使用和操作哪些原子功能。3. 数据模型3.1 用户信息（UserInfo）用户信息表中只保存比较固定的数据，便于快速查询和缓存，其他经常要变的数据放到附属表中属性名含义数据类型备注id序号，主键Integer由数据库自动生成loginId登录IDString登录名password密码String密码userType用户类型(1001)int1：内部用户2：外部用户（客户、供应商、合作伙伴等）userName用户名称String用户姓名nickName昵称Stringgender性别(0002)int0:未知1：男2：女email电子邮件Stringmobile手机号StringmobileValid手机号是否已验证B
