互联网时代的软件革命—SaaS架构设计（第三章）

 

 

 

第 3章

构建Multi-Tenant应用

 

 

3.1  第一阶段：做项目... 49

3.1.1  发现商机... 49

3.1.2 “4+1”视图... 50

3.1.3  项目托管... 58

3.2  第二阶段：做产品... 59

3.2.1  共享设备... 59

3.2.2  创业之旅... 61

3.2.3  可配置化... 62

3.3  第三阶段：多租户... 63

3.3.1  成长的烦恼... 63

3.3.2  如何转化成SaaS多租户模式... 65

3.3.3  SaaS多租户设计... 70

3.3.4  SaaS多租户模式的威力... 72

3.4  小结... 73

 

 

 

郭靖和杨康是同窗挚友，现在读大学四年级，明年就要毕业了，想到即将走出校门，两人心中充满了期待和忐忑。

郭靖出生在北方城市，从小接触计算机，经常写个小程序什么的，无论搭建交友社区，还是帮别人建网站都不在话下，很早表现出在编程方面的过人天赋。进入大学后他更是延续了对IT技术的狂热追逐，在知名网站的IT频道有自己的技术博客，同时还是好几个论坛的版主。

杨康来自南方大都市，父母和亲戚不少都在做生意，规模并不大，但生意很红火。杨康从来都是个活跃分子，喜欢与人打交道，有他在的时候他永远是大家交谈的中心。他炒股、泡妞，在别人眼里好像有些不务正业，但他有独到的眼光，他也有他的梦想，那就是依托互联网成就自己的一番事业。

3.1  第一阶段：做项目



3.1.1  发现商机
这不，暑假到了，杨康又琢磨着干点啥。通过学弟欧阳克引见，杨康来到欧阳锋的公司，想通过自己的观察和感受多了解企业的现状和需求。欧阳锋的公司是做电子贸易的，客户来自全国各地，不一会工夫，欧阳锋和他的业务员就见了5个客户，中间还被好几个外地客户的电话打断。
杨康：欧阳叔叔，您精力充沛，以一当十啊！
欧阳锋：哪里啊，其实是没办法，现在客户多得都快管不过来了，光靠脑子是记不下来的，只能再请几个帮手了……
杨康发现了这其中的商机，为什么不用软件管理起来呢？
杨康：其实用不着，假设我们开发一套系统，管理所有的客户资料、商务行程和客户订单，那肯定可以大大提升效率。
欧阳锋：也许是个办法，你小子不是搞软件的吗，我就交给你好了，让克儿也一块帮忙。
杨康：没问题，我这两周就跟着您，先搞清楚公司的业务流程。
……
要做CRM（Customer Relation Management）系统，一两个人是搞不定的，当然要拉上他的死党郭靖。三人分工，杨康负责商业需求，郭靖和欧阳克负责设计开发。
3.1.2 “4+1”视图
拿到需求后郭靖很是兴奋，以前的设计都是自己搞着玩的，这回终于可以面向真正的客户、大展拳脚了。事不宜迟，郭靖开始忙起来，想到要让欧阳克理解架构、尽快上手，他打算参考RUP（Rational Unified Process）中的“4+1”视图模型（逻辑视图/过程视图/开发视图/物理视图+场景视图）来分析设计（见图3-1）。

图3-1 “4+1”视图
“4+1”视图最早由Philippe Kruchten提出，他在1995年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳，现在已成为架构设计的结构标准。五类视图需要考虑的问题不一样：
场景视图
也叫用例视图，描述用户的业务场景，从用户的角度识别出业务需求，它是架构设计的起点和终点。
逻辑视图
如果设计采用面向对象的方法，逻辑视图就是对象模型。逻辑视图重点在于功能，功能包括可见的业务功能，也包括不可见的系统功能（如日志、权限、事务等）。同时更重要的是确立逻辑分层、模块划分和模块之间的依赖关系。
开发视图
描述软件在开发环境下的静态组织。开发视图关注程序包，应用的统一框架，引用的类库、SDK和中间件，以及工程和包的划分规则等，规范、约束开发环境的结构。
过程视图
描述系统的并发和同步设计。过程视图聚焦在进程、线程等运行时概念，以及相关的并发、同步、通信等问题。如果系统不需要考虑这些方面，本视图可以省略。
物理视图
也叫部署视图，描述软件如何映射到硬件，反映系统在分布/部署上的设计。物理视图需要解决最终如何安装和部署到服务器，以及网络分布的问题。
3.1.2.1  场景视图
杨康在欧阳锋的公司调查了两周，整理了一份调查报告，公司主要有两类角色：老板和员工，客户关系管理的业务场景大致是这样——如图3-2所示。

图3-2  业务场景
作为老板，我希望了解客户的增长和流失数量以及趋势；
作为员工，我希望保留我的客户资料随时查阅，并且通过邮件、IM、IP电话快速与客户交谈；
作为员工，我希望以日历的方式提醒我当天和未来的商务行程。
……
场景是基于角色来识别的，但不少小公司角色定义比较模糊，角色兼顾的情形比较常见，比如老板有时候也要充当员工，所以郭靖先抛开角色的差异，抽象核心的业务逻辑。当然最终提供给用户的UI界面必须可以还原不同的用户场景，而实现的方式类似“我的工作台”。
CRM的主要用例图如图3-3所示。
CRM的主要用例包括：
（1）管理客户：管理客户资料、联系人等，包括增、删、改、查；
（2）管理行程：管理如拜访客户、合同谈判、签订合同等商业行程的安排；
（3）管理订单：管理与客户签订的订单。

图3-3  用例图
3.1.2.2  逻辑视图
1．模块划分与依赖关系
为了更好地分析和表达系统的逻辑结构，区分业务边界，郭靖又根据业务场景将CRM系统拆分成【客户】模块、【行程】模块、【订单】模块和【报表】模块4大模块（见图3-4）。

图3-4  模块结构图
模块说明：
模    块 缩    写 功能描述
客户 Customer 管理包括：客户资料、联系人资料
行程 Schedule 管理商务行程
订单 Order 管理用户订单
报表 Report 反映客户增长和流失数据趋势、订单金额和数量增长趋势等

2．业务实体
分析过需求后不难发现，客户分组、客户、联系人是【客户】模块主要的业务对象，它们的属性和相互关系也很明确，郭靖立刻用UML Class图画了下来，如图3-5所示。

图3-5  类图
CustomerGroup：客户分组
Customer：客户
Contactor：联系人
同时郭靖还分析了【行程】、【订单】、【报表】等模块，此处不再一一列举。
3.1.2.3  开发视图
前面说到开发视图是用于描述开发环境下的静态组织的，郭靖打算从开发环境、技术架构、分层策略和目录结构4个方面加以阐述。
1．开发环境
对开发环境的说明，需要明确开发的语言、数据库类型、应用服务器类型，以及其他软、硬件要求。
开发语言：Java、JavaScript、Html
数据库：MySQL 5.0
应用服务器：Apache + JBOSS
其他软件：Ant、JUnit等
2．技术框架
开源框架是现在技术应用的热点，经过数年的“框架大战”，对应表现、业务、持久三层的各种框架各自找到了自己应有的位置。“Struts+Spring+Hibernate”已成为Java开发的主流体系。在这个体系中，它的地位在短期内是难以撼动的。郭靖当然不会不知道，其实他对于开源框架早已驾轻就熟，这次他仍旧搬出了“Struts+Spring+Hibernate”的三驾马车式框架结构（见图3-6）。

图3-6  Struts+Spring+Hibernate框架结构
之前这3种框架各自在发展，但如何整合起来发挥最大的能量，形成一个轻量级的框架集呢？郭靖觉得很有必要在开发视图中说明清楚（见图3-7）。

图3-7  调用关系
3．分层策略
分层是架构的基础，不管是经典的J2EE架构，还是轻量级的J2EE架构，一般大致分为5层（见图3-8）。

图3-8  分层
数据持久层：也叫领域对象层（Domain Object），由POJO（Plain Old Java Object）组成。
DAO组件层：由DAO（Data Access Object）组件组成，一般封装了对数据库的CRUD原子操作。
业务逻辑组件层：一般由Service对象组成，实现系统所需要的业务逻辑处理。
控制器层：控制器用于拦截用户请求，调用业务逻辑组件，根据处理结果转发到不同的表现层组件。
表现层：一般由JSP组成，负责接收用户请求，反馈处理结果。
4．目录结构
目录结构与分层策略和打包部署直接相关，根据以上5层，郭靖制定了目录结构规则（见图3-9）。

图3-9  目录结构
一级目录包括：
 api：存放service的接口定义源文件；
 action：存放action的源文件和配置文件；
 biz：存放各模块的业务逻辑组件和DAO组件；
 bundle：存放JSP和HTML文件；
 deploy：存放构建后待部署的jar文件。
biz目录下根据模块再分为dao和service目录，以及它们的实现类目录impl。
3.1.2.4  过程视图
“4+1”视图本身是可以裁减的，一般而言，“场景视图”和“逻辑视图”必不可少，其他视图依场景而定是否需要，郭靖认为当前的系统暂无并发或同步等问题，所以将过程视图忽略。
3.1.2.5  物理视图
系统部署时将Web服务器、应用服务器和DB服务器分离，以保证业务繁忙时快速的响应性能（见图3-10）。

图3-10  部署图
3.1.3  项目托管
经过一个月左右的设计、开发、测试，这套CRM系统基本成型。
郭靖：这两个礼拜我们去了三趟南方，如果项目上线，系统维护肯定少不了，那我们岂不是要经常两头跑，这怎么吃得消……
杨康：我也感觉到了，有没有更好的服务方式呢？
郭靖：我们可以效仿ASP（Application Service Provider）的做法，将设备托管在我们这里。因为这是一套基于Internet的B/S系统，欧阳锋的公司只要可以上网，即可登录使用这套系统，而且以后系统的维护/升级、Bug修复就方便多了。
杨康：不错，这完全是一套双赢的方案，我们在异地维护，欧阳锋也可节省一笔开支，不用再报销我们的差旅费。交给我好了，我去跟他谈。
经过杨康一番摆事实、讲道理，欧阳锋同意了设备托管的系统部署方案，一套符合成熟度模型Level 1（定制开发）特征的SaaS系统诞生了。而且上线之后欧阳锋比较满意，因为他有时间去打高尔夫了。
3.2  第二阶段：做产品



3.2.1  共享设备
转眼三个月过去了，这天是元旦后的第一个周六，杨康和郭靖正在学生公寓玩网络游戏“魔兽争霸”，这时手机响了。
欧阳锋：杨康，前几天梅超风来我这洽谈业务，正巧看到了你们做的CRM系统，她很感兴趣！
（杨康心中窃喜，没想到这么快）
杨康：哦，是吗？
欧阳锋：她也很想装一套，但是她公司的业务与我的有所不同，她有自己的业务员，也有外地加盟的代理商，她希望业务员之间的客户资料保密，业务员只看到自己的客户，你想想办法吧……
接完电话，杨康回头冲郭靖兴奋地大叫。
杨康：兄弟，我们又有客户了，哈哈。
郭靖：说来听听……
郭靖：这是个新需求！但好办，控制客户资料的数据访问权限，我们在配置管理工具SVN中单独创建一个分支，单独开发一个版本，并单独部署一套系统。
杨康：那服务器呢？要不要再买一套？
郭靖：暂时不用，我分析了现有设备的负荷，如果梅超风公司的使用规模跟欧阳锋相类似，完全可以搭建在现有设备上！
杨康：那我们可以省下一笔不小的费用啊，哈哈。
郭靖：这就是共享设备的好处！
为了“隔离客户资料”的需求，需要在“客户”Service组件中添加一个方法：getCustomerListByCreator()（见图3-11）。

图3-11  时序图
如此这般之后，梅超风公司的CRM系统也上线了，虽然其后还有一些很个性化的需求，但原有设计和逻辑基本可以满足。当然美中不足的是从此版本的分支多了起来，杨康、郭靖需要同时响应两家客户的需求变更，版本管理日益复杂，这对于一帮学生而言，无论时间和资金都是一大挑战。
3.2.2  创业之旅
话分两头，郭靖和杨康毕业了！不走寻常路，由于大学期间积累了不少项目经验，郭靖和杨康打算成立自己的公司开始创业之旅。公司的名字很酷：神雕科技有限公司，杨康任CEO，郭靖任CTO，学弟欧阳克也在公司实习。
 VS 

成立了公司可不一样，必然要有规模和成本意识，在公司成立前后的那段日子里，杨康和郭靖时常一起畅想公司的未来与发展。
杨康：项目面向单一客户，而产品则面向大众或者行业，通用性更强，成为成熟的解决方案后成本更低。
郭靖：如果我们沉淀以往所做项目的用户需求，推出系统化、可配置的CRM产品，这样再有客户来，只要简单地安装即可。
杨康：我们已有欧阳锋和梅超风两家公司的需求，我最近又在谈托雷、丘处机和段皇爷三个项目，抽取共性需求应该并不难。
郭靖和杨康都意识到应该尽快从项目转型成产品，于是，第一代产品化的CRM系统开始酝酿……
3.2.3  可配置化
既然是产品，必然可以兼顾多方的共性和个性化需求，郭靖想到了之前在老师洪七公那里学来的一套功夫——MDA（Model Driven Architecture，模型驱动架构），MDA利用元数据建模，可以方便灵活地实现可配置化。
MDA架构（见图3-12）

图3-12  MDA架构图
MDA四层模型（见图3-13）
（有关“可配置性”的更多内容请见第5章：Multi-Tenant应用的可配置性。）
当然杨康的市场能力还真不是吹的，产品推出不久，因为强大的可配置灵活性，杨康发展了超过50家客户。通过产品可配置化改造，杨康、郭靖的CRM系统进化到了SaaS成熟度模型的Level 2（可配置）阶段。

图3-13  MDA四层模型
3.3  第三阶段：多租户



3.3.1  成长的烦恼
看着越来越多的客户好了起来，郭靖不免想起了自己幼时的恩人——江南七怪，当年多亏了他们照顾。现在的“江南贸易公司”处境并不好，何不让他们用CRM呢？
郭靖：柯伯伯，我们公司的CRM系统挺实用的，我把它送给你们，希望助你们一臂之力！
柯镇恶看了看其他六人，无奈地说：靖儿，你们公司刚开业不多久，开支又大，我听隔壁老板说他当初上了一套类似系统，花了将近半年的利润。免费白送不大好，不合适、不合适啊……
郭靖：柯伯伯言重了，您还跟我客气啥呢？
一旁的妙手书生朱聪灵机一动：要是可以按需付费，岂不更好？一来我们不会一开始投入过大，二来生意有了起色，发挥作用了，我们也可持续使用。
郭靖：按需付费？这个主意挺好的，我回头找杨康研究研究……
见过江南七怪后，郭靖的心情有些沉重，这是个问题，郭靖拉来了杨康商量。
郭靖：表面上看公司的客户已经几十家，但是不是还有大量的潜在客户我们没有挖掘，这些客户规模较小、实力较弱，可他们同样有强烈的管理需求，我们为什么不把门槛降低、规模做大呢？
杨康：中国有超过2000万的中小企业，他们才是我们未来的蓝海！
郭靖：听说现在有一种SaaS多租户模式，跟我们想象的场景很相似，但我没弄明白是怎么回事……
杨康：Right，你说对了，SaaS是Software as a Service的缩写，是一种将数据和软件托管在服务提供商那里的全新商业模式，它支持多租户（Multiple Tenant），支持购买前试用（Try-before-buy），支持功能自定义（Customization），支持灵活的定价策略，可根据自己的需要选择按月、按年甚至按次等不同的按需服务购买方式，而且客户不需要任何别的其他投入。
杨康：最近国外有家做CRM的公司【Salesforce】非常火，它就是典型的SaaS应用。
郭靖：那我们Google一下……
郭靖迫不及待地打开了电脑——
Salesforce.com是全球按需CRM解决方案的领导者，当前全球有43,600多家公司和646,000名注册用户正使用Salesforce的强大功能分享客户信息，以及开发具有更高收益的客户关系。Salesforce.com如何能提供比别人更多的成功机会？方法很简单：
强大的功能：当今业界技术最先进的产品——第20代产品具有1 000多种功能，因此具有统领全球业务的能力；
灵活的定制：这是业界灵活度最高的CRM解决方案，独有的自定义选项卡和全新设计的Customforce令自定义灵活度显著提高，用户可深度扩展，因此能满足各种规模的企业的需求；
最佳的用户体验：方便易用，简洁的界面一目了然；
多语言支持：支持14种语言；
按需应用、按需付费；
快速实施：多数公司在30天之内把Salesforce.com成功融合于企业运转之中；
快速回报：通常在实施后的几个月之内，客户即可获得可观的回报；
没有安装费：软件托管于Salesforce.com公司的强大数据中心，用户只需登录即可使用，免除软硬件购买、安装、调试过程；
高度安全：系统和数据处于层层保护之中；
免费版本更新；
免费用户支持。
郭靖：简直太妙了，这种商业模式肯定火！
杨康：为什么不呢，我马上起草报告改变公司今年的战略——进军SaaS！
3.3.2  如何转化成SaaS多租户模式
SaaS虽好，但怎么样才能转化成SaaS多租户应用？从技术的角度分析需要改造哪些地方？带着这些疑问，郭靖去找他的导师洪七公。
洪七公：SaaS现在已成为一股潮流，它将颠覆传统的软件交付方式，你们的产品打算走SaaS路线，我非常支持。
洪七公：其实从架构层面来分析，SaaS区别于传统技术的重要差别就是Multi-Tenant模式……
郭靖：Multi-Tenant？多租户？
洪七公：是的，多租户就是说多个租户共用一个实例，租户的数据既有隔离又有共享，说到底就是如何解决数据存储的问题。
郭靖：哦，隔离？共享？
洪七公：现在SaaS Multi-Tenant在数据存储上存在三种主要的方案，分别是——
3.3.2.1  独立数据库
这是第一种方案，即一个Tenant一个Database（见图3-14），这种方案的用户数据隔离级别最高，安全性最好，但成本也高。

图3-14  方案一
优点：
 为不同 的租户提供独立的数据库， 有助于简化数据模型的扩展设计， 满足不同 租户的独特需求；
 如果出现故障， 恢复 数据比较简单。
缺点：
 增大了数据库的安装数量， 随之带来维护成本和购置成本的增加。
这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。
3.3.2.2  共享数据库，隔离数据架构
这是第二种方案，即多个或所有租户共享Database，但一个Tenant一个Schema（见图3-15）。

图3-15  方案二
优点：
 为安全性要求较高的租户提供了一定程度的逻辑数据隔离， 并不 是完全隔离；
 每个数据库可以支持更多的租户数量。
缺点：
 如果出现故障， 数据恢复 比较困难， 因为恢复 数据库将牵扯到其他租户的数据；
 如果需要跨租户统计数据， 存在一定困难。
3.3.2.3  共享数据库，共享数据架构
这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据（见图3-16）。这是共享程度最高、隔离级别最低的模式。

图3-16  方案三
优点：
 三种方案比较， 第三种方案的维护和购置成本最低， 允许每个数据库支持的租户数量最多。
缺点：
 隔离级别最低， 安全性最低， 需要在设计开发时加大对安全的开发量；
 数据备 份和恢复 最困难， 需要逐表逐条备 份和还原。
如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。
3.3.2.4  三种方案比较
洪七公：从隔离和共享两个相反的方向比较，依次是方案一、方案二和方案三，如何选择取决于产品的定价策略和租户对数据安全的接受程度。
三种方案比较见图3-17。

模式 隔离级别 共享级别 安全性 成本
独立数据库 高 低 高 高
共享数据库，隔离数据架构 中 中 中 中
共享数据库，共享数据架构 低 高 低 低

图3-17  方案比较
郭靖：老师，我明白了。我们的CRM系统未来将以中低端市场为主，我们决定采用第三种方案，只要做好数据隔离就好了。
洪七公：千万不可掉以轻心，SaaS下的安全性设计很重要。一般常见的安全性设计分为两类：系统级和程序级。
系统级：
 使用HTTPS协议以SSL（Security Socket Layer）交换数据， 增强通信安全；
 通过数字签名 防止传输过程篡改；
 对用户身份识别的UserToken使用DES算法数据加密；
 业务数据定时自动备 份。
程序级：
 完整的权限配置， 包括功能权限和数据权限；
 客户端输入校验， 防止JS攻击、XSS攻击、SQL注入等；
 辅助安全设计， 比如密码控件、图片验证码、手机确认码等。
郭靖：我知道该怎么去做了，谢谢老师指点！
3.3.3  SaaS多租户设计
决定采用“共享数据库，共享数据架构”方案后，郭靖着手开始改造。改造成SaaS多租户的重点在于租户管理和数据隔离。
租户管理：包括注册、订购、计费等；
数据隔离：变更表结构，增加TENANT_ID字段。
3.3.3.1  租户管理
既然SaaS是敞开大门做生意，允许任意客户可以通过互联网随时随地开通、订购和使用产品，那么SaaS的租户管理就显得格外重要。
注册（见图3-18）

图3-18  类图_注册
Tenant：租户；
User：租户下的用户账号，一个租户下可以有多个用户账号。
Tenant的status属性用于定义租户的当前状态：待审核、已审核、启用、禁用、取消等。登录时必须判断租户的状态，只有处于“启用”状态的租户才能登录进入系统。
订购（见图3-19）

图3-19  类图_订购
 PricePolicy：价格策略， 支持按时间（月、季、年）、按次数计价， 以unit表示；
 Subsciber：订购记录， 记录租户选择了何种价格策略， 以及服 务期限或服 务次数。
计费（见图3-20）
 Journal：流水账， 记录租户使用服 务的日志， 用于生成账单和报表。

图3-20  类图_计费
3.3.3.2  数据隔离
为每个需要隔离的业务表加上TENANT_ID字段以实现租户数据之间的隔离，这是最通常的做法（见图3-21）。

图3-21  类图_客户管理
对比前后的DB设计，多出的TENANT_ID属性是SaaS多租户模式相对于传统模式最大的不同点。
3.3.4  SaaS多租户模式的威力
又三个月过去了，郭靖主导的SaaS多租户模式改造项目开发完毕，杨康忙不迭地算了一笔账：
项  目 每客户收入
（单位：元） 每客户成本
（单位：元） 每客户利润
（单位：元） 预计客户数
（单位：个） 预计利润
（单位：元） 人均支持客户数
（单位：个）
改造前 8,000 5,800 2,200 300 660,000 10
改造后 500 220 280 50,000 14,000,000 150

很明显，因为改造成SaaS多租户后单一成本极大降低，价格亦大幅降低，自然可吸纳大量的付费用户。对比前后的利润增长20余倍，技术支持人员人均可支持的客户数也增加10多倍，效果十分显著。看过这份表格后，郭靖和杨康不由轻松地畅想起了未来——
郭靖：这回我可以腾出更多的人力去提升性能和可伸缩性了，Yeah！
杨康：这回我可以多招些Sales去拓展渠道和市场了，哈哈。
经过数据隔离相关改进后，杨康、郭靖的CRM系统更进一步，已经实现了SaaS成熟度模型Level 3（多租户）阶段的主要特征。
3.4  小结
本章以CRM系统为例，以软件交付形态由做项目到做产品，再到多租户的转变，反映了SaaS成熟度模型从Level 1，到Level 2，再到Level 3的演进过程。核心内容包括：
通过“4+1”视图设计架构；
SaaS多租户模式下三种数据隔离方案；
SaaS多租户设计。
从本章内容中我们可以看出SaaS成熟度模型不同等级的不同特点：
Level 1：设备托管；
Level 2：设备共享、可配置化；
Level 3：多租户、数据隔离、高性能。
如果希望达到SaaS成熟度模型的Level 3级要求，最核心需要解决的是数据隔离的问题。后续章节将就如何达到Level 4级要求进一步展开。