谈应用形态和分区分库

对于业务系统，主要分为两种主要的形态，一种是以核心数据主导的业务系统，一种是以工单流程主导的业务系统。对于前一种典型的主要是资产系统，资源系统等，其中资产和资源都是核心数据，其余的所有业务功能都围绕核心业务数据展开，改变核心数据的属性状态或关联关系。而对于OA，电子运维等系统则是工单流程驱动型系统，这种系统往往并没有一个全局的核心数据层，不同业务类型下的单据相互之间相对独立。

对于第一种情况在进行业务模块划分的时候往往有一个公用的基础数据层或全局模型层，然后才会到具体的业务层，而业务层本身又根据核心业务对象的全生命周期展开进行划分。而对于第二种情况则相对简单，全局模型很薄，往往完全可以根据业务域或业务单据类型进行纵向划分即可。

对于第一种情况的分区和分库，一般我们会按照底层数据层模块，中间各业务生命周期来划分不同的业务模块，但是在这种情况下可以看到上层的业务模块往往全部需要依赖底层的数据提供业务模块。这样在对于整个业务系统来看的时候，无法真正的做到各个业务模块相互独立。数据层模块在这种情况下已经下沉为平台层数据提供业务组件，该组件为所有上层业务模块提供服务，和上层业务模块强耦合。在这种情况下业务对象管理模块发生任何变化都可能对上层模块造成影响。或者讲业务对象管理模块已经变化为整个应用的核心的领域层，承载了关键的领域逻辑，并为上层提供领域服务。

对于第二种情况，可以看到在进行业务模块切分的时候可以完全的做到全纵向切分，没有任何需要依赖的底层业务模块。传统情况下我们在进行组件化设计和开发的时候，往往只考虑了应用逻辑层的组件划分和隔离，而没有真正去考虑数据层数据表之间的分区和隔离，不同组件仍然可以随意的访问其他业务组件的底层数据表和对象。而在真正的组件化架构下，底层数据库各种数据对象仍然需要进行分区和隔离，比如对于不同的组件数据表进行分Schema存放。

业务组件按道理不应该清楚其它业务组件底层的数据库细节，因此跨业务组件间的协同应该在业务逻辑层完成，而不是组件到数据库的交叉访问。只有真正做到这一点后，才可能很好的支持后续业务系统的垂直分库操作。当单点出现性能瓶颈的时候，可以很方便的将原有的业务系统垂直划分为多个业务子系统，并分别进行部署和管理。在传统模式下，我们却很难真正的做到这一点。

在前面两种情况说明清楚后可以看到，对于第一种情况谈到的共享底层业务对象，我们可以考虑建立读写分离集群。而对于第二种工单流程型的业务系统，由于单据数据会随着业务工单不断增长，更加适合采用数据表的水平shading来满足可扩展性的问题。当同时存在两种情况的时候，往往则是读写分离+cluster的集合。

对于大型业务系统构建，一开始就需要考虑到后续业务增长情况，进行提前组件划分，对数据库进行分Schema设置，对于跨组件的方式进行接口设计和服务识别，确保业务组件间的交互只能通过服务进行，所有这些准备都是为了保证后续更好的进行大应用拆分。

   青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密