前章
第二章强拆
2.1 为什么要强拆？
本章读者群是，技术总监，系统架构师，数据库架构师，系统设计师，高级程序员。只有这样的角色才能起到强拆作用！没有领导的号召，城管才不去搞拆迁活动啊！
因为我们的数据库大部分基本上，几乎是，90%都是混合型数据库。所有的系统，该系统所有的业务都在一个数据库里面实现。也就是说所有的表都同在一个用户下，集群多也是100%克隆式的扩展而已！为什么要混合在一起呢？那是因为数据库设计课程当中没有讲过，讲的是3N方式和冗余措施，讲的是逻辑关系ER图。而应用开发人员还有ROSE的时间图，状态图。
一般来说一个系统上线要2-3年的时间才出现数据库性能的问题。而此时留守来的只有高级开发人员和技术总监，以及招来少量的低级开发人员做维护性开发。慢起来就是突发的事件，要承担巨大的精神压力，轻则业务缓慢运行，重则业务中断。比如12306每到节假日不可开机！做为留守或者是半路而来接手的技术总监幸福指数直接下降！顶多都是临时优化，头疼吃感冒药，脚疼打麻醉药，应付过去了事。实在没办法立即采购硬件来顶。和尚敲钟，能顶一天算一天。假如你要在这家公司长期干下去，不想蹦来蹦去的，或许你接手这个系统已经优化很多次了，已经买了多次硬件来顶，到你手上已经没有了优化空间和余地了。
那么怎么办？老板会怎么看你？老板会会相信前几任把优化空间用完了吗？他只会认为前几任有本事，而且你是废物！
2.2 第一次拆按业务来拆
一个系统，可以细分多个子系统，或者说子业务，不同的业务。比如说我所在的第三方支付公司，公司业务主要流程如下，商户开户-，商户发来交易，过风控，发给银行，走银行通道，结算，划款，退款，拒付。那么大致来说有如下几个业务：
1 管理业务主要是商户管理，商户自身管理。
2 风空业务 这个业务涉及到很多规则。
3 交易业务 处理交易，接受银行交易返回信息，核对交易。
4 银行通道管理，银行通道有很多限制，比如说交易量，拒付指数
5 财务业务 涉及到结算，划款，退款。
那么就说可以分成5种业务
这里主要是根据业务来划分，也可以叫系统。接下来如果需要可以深度拆分，系统-》子系统-》模块
或者是业务-》子业务--》模块。这就根据用户数量级别，公司经济实力，以及开发实力来定。
做为技术总监，高级开发人员应该说是熟透业务，按业务来拆分是轻而一举的事情！
第一按业务来拆分的话，当其中一个业务发生了性能问题，不会影响到其它业务的正常运行。然后混合型数据库，当每月月底或者月初的时候，都要给商户做结算，有的是30天，有的60天，有的是90天，还有的是180天。另外还要给销售人员算提成，提成都是根据商户的交易量来算的。这将是个巨大的IO运算量，每到这个时候数据库就要卡好几次对吗？而且会影响到其他业务正常运行，比如通道不行了，很慢啊！商户打来电话抱怨很慢了。这要承受巨大的压力！
有了业务拆分，它好！你也好，何乐而不为呢？采用JAVA思想高内聚，低耦合，通过接口来完成业务之间的数据共享。那么设计接口呢？有以下几种方式
1 后端数据库DBLINK模式，没个业务都用一个用户名归纳子在一起，包含，表啊，存储过程啊，视图和函数啦！这里介绍下恒波手机卖场，用.NET开发的WEB进销存系统就是采用该方式完成业务拆分。
2 采用多数据源方式，NET和JAVA都支持多数据方式。比如财务当中的结算业务就要调用商户管理业务的数据库。那么财务业务要再多配个数据源就是商户的数据源。我们公司就采用这种方式
3 采用MQ消息机制，JAVA通过内部服务对象发消息给另外个对象要求某些数据。
4 采用数据库中间件 MYCAT ，通过数据库中间件，mycat,myproxy,oneproxy等分析接手到的SQL语句来，分析用到的表名来路由具体的数据库。
这四种方式最好的是第三种，在JAVA层完成数据接口。主要是清晰可控，并发能力也能提高，自然这涉及到了开发实力。不过一开始设计的时候考虑进去了的话，确实是一件不难的事情。其次是第二种采用多数据源方式，这方式NET会用得多。也比较容易实现。
再者是第一种方式，这方式适合把业务放在数据库端来实现的，而应用端只实现用户友好方式。
最后一种就是第四种，这是一种偷懒的方式，基本上应用层代码不用改，数据库层表可以不用分离。就靠数据库中间件来路由。
为什么这样排序呢？因为有利于开发人员进行SQL的分离，目前的SQL很多是多表的联合查询，这些表很多是跨业务系统的。开发人员依旧把过去混合模型中的习惯延续下去，自然对后续的机器扩展带来性能问题。
物理部署方案
1 单数据库模式
2 单集群模式
3 多集群模式
2.3 第二次拆读写分离 OLSPOLTP OLAP
。。。。。。。。。
苹果用户请打赏
