企业应用与互联网应用的区别，多租户方案

我们的产品最近在规划做一个比较大的变化，从单应用支持单个项目，向单应用支持多项目转变（多租户）

产品是所谓的企业应用，虽然用的技术差不多，但是我感觉和互联网应用有很大区别，暂时想到以下几点：

1、并发数

企业应用的并发数和互联网应用（近似理解为网站）相比，差别极大。因为网站面对的是数以万计的互联网用户，而企业应用面对的是内部用户，所以并发量完全不在一个层面上。不用跟大的电商、社交网站比，即使是很小的网站，并发数也远远超过我们的应用

所以，一般来说，企业应用在架构上不需要特别考虑http并发的问题，只需要稍微注意下实现无状态server，支持水平伸缩即可

2、数据量

数据量这个指标，主要还是取决于应用的规模，跟是企业引用还是互联网应用，关系不是特别大。就目前的经验来看，我们应用的性能瓶颈，主要也是出现在数据库IO上。后续在集中部署的场景下，更有可能面对数据库伸缩的问题

3、可配置性

互联网应用不强调可配置性，一般的商城、论坛等，每个用户能做的事情都是一样的。虽然像QQ空间那种，允许用户做一些自定义，但是只是页面组件和模板化的技术，跟企业应用的可配置性还不一样

企业应用会面对很多定制需求。比如说我们的产品，要提供给不同的项目，而每个项目的需求都会有一些细微的差异。同样的工单，不同项目需要不同字段；工单端到端的业务流程，不同的项目有不同的环节；另外不同的项目，可能会与不同的外部系统对接……

如果是单应用支撑单项目的情况，可以通过定制开发的方式实现，只是工作量的问题。但是一旦转变成多租户的部署形式，就会相当麻烦，主要是升级的时候不能互相影响，还有怎么处理数据库表结构的差异

所以，这是比互联网应用复杂的地方

4、多租户

互联网应用天生就必须是多租户的，但是企业应用就不同，我们的产品之前一直是单项目单产品的方式，也搞了好几年了。现在为了降低成本，优化集中部署管理，才开始转向多租户方式

多租户的设计思路，目前想到2种：

第一种是应用只有一套数据库表，基本上沿用现有的表结构，只增加一列项目ID来区分。这种方案短期来看比较简单，但是以前只存放一个项目的数据，现在却要存放几十个项目的数据，很快就会遇到数据库瓶颈（业务数据每天都在增加），最终还是要拆表

第二种是一开始就根据项目把表拆开，每个项目一套表。在项目少数据少的时候，可以只用schema区分，部署在同一个db server里；随着项目和数据增多，再增加db server，做数据迁移。由于本来就根据schema拆了表，迁移起来比较容易

长期来看，我认为第2种方案是比较好的。首先每个项目有自己的表，数据分散，IO性能较优；一个项目的表中的数据损坏，也不会对其他项目造成影响；最后，有天然的数据隔离

但是这要求应用能够访问适当的表和数据库，当一个请求到来的时候，应用需要知道要到哪个表中去查询所需的数据，这也叫数据路由。数据路由交给APP来实现是不合适的，因为APP的代码会非常繁琐，并且新接入一个项目，增加了数据库表之后，还需要修改APP的代码，这是不可接受的。需要把数据路由做成透明的，由专门的抽象层解决这个问题

淘宝在这方面有成熟的解决方案，大致的思路是在orm之下，jdbc之上，提供了一层TDDL层，由这层来实现数据路由的功能。应用对数据库的请求是透明的，TDDL将请求分发到合适的数据库中。TDDL对上层（orm）应该是封装成jdbc的接口，可以看作是一个jdbc驱动，直接注入到orm中。当新项目接入，增加新的表之后，只需要在TDDL层进行配置即可，APP的代码也不需要修改

另外要解决数据迁移的问题。需要开发配套工具，支持数据快速迁移，减少业务中断的时间

总结：

2种方案都需要对产品的实现做修改，可以作为规划，落入后续版本中，短期内难以做到

结合云部署的方案，当前可以把应用预装入虚拟机，然后导出得到镜像，在不修改应用的前提下，实现快速部署。另外，多个项目的数据库，可以共享db server，节省硬件费用，以及oracle license费用，这需要修改产品的安装脚本

上述方案应该看做是过渡方案，长期来看，还是需要对应用进行改造，才能实现真正的多租户。目前可以识别出的技术难点，主要有3点：

1、数据库路由模块的设计和实现
2、数据迁移工具的设计和实现
3、针对多租户场景，可配置性设计的调整（当前的可配置性设计，针对的是单个项目）

3是个大问题。需要把多个租户的需求全部切割成最小的单元，并且这些单元可以按照一定规则组合。

4的话我想应该看后台服务器是谁维护，如果是像互联网公司那样，就搞成一个数据库的形式，以后可以分库，分表，集群

不就是SAAS么、、、  保证好数据分离、响应速度就ok了   不过遇到SB企业要求各种定制你就傻了   以前做过SAAS OA