一、业务背景
1、为什么需要中间件？
谈起为什么需要数据库中间件，我们首先谈谈一个典型的网站架构演进。系统架构随着业务的变化演进，从而推动各种技术的发展，而数据库中间件技术就是在架构演进中出现的。
（1）初始架构方案
初始架构如上图所示。我们初始在单机上同时部署tomcat和DB。客户端访问的时候，首先通过DNS解析获得我们服务端的机器ip，然后通过网络连接，连接到Tomcat，然后后端应用再与DB交互，进行状态的读取和更新。但是随着业务的发展，单机部署多个应用会出现应用之间的资源争抢问题，影响一些功能的响应，降低服务质量。所以，自然而然我们要对架构进行变更，最基本的能想到的就是将不同引用分别部署，就形成了如下的架构。
（2）第一次架构变更
如上图所示，我们在这里将Tomcat和DB分别部署，这样就不存在资源争抢问题。客户端请求来到以后，不同业务服务器只提供其特有的功能，DB服务器只提供DB的读取和变更。然而，随着业务持续变更，客户请求并发增加，单机Tomcat并不能再满足高并发的请求，同时，很多的请求并不需要一直跟DB交互，所以我们可以在架构中加入缓存，提高并发量，同时减小非必要的DB请求，这样就有了架构的第二次演进。
（3）第二次架构演进
当然，我们这里可以使用redis集群，进一步提升缓存效率，如上面右图所示。随着业务持续增加，单机tomca的并发压力变得非常大，因此我们进入第三次演进，通过引入反向代理和负载均衡，进一步提升系统并发。
（4）第三次演进
到这里，反向代理将用户的请求均匀分发到每个Tomcat上。但是，随着并发请求的继续增加，更多的请求会击穿缓存，单机数据库将会成为瓶颈，那么就有了接下来的演进，将数据库读写分离。
（5）第四次演进
当业务量持续增长的时候，各种业务交织在一起，不同业务之间会存在数据库竞争，互相影响性能。那么，我们能做的就是让DB按照业务进行分库。
（6）第五次演进
这次变更我们让不同的业务方连上不同的DB，这样就可以避免不同业务对DB资源（链接，查询等）的竞争。但是，随着业务量的持续上升，单机写库将会逐渐达到瓶颈，因此我们就想到将数据的大表拆成小表，大库拆成小库。架构演进到这里遇到了我们将要讲的问题。
2、分库分表
这里总结一下，从上面的架构演进过程我们可以看到，当业务量持续上升，DB的读写分离，业务DB分离等措施采取以后，单机的DB性能瓶颈将会成为整理DB系统的瓶颈。我们当然可以通过购买高性能DB来满足需求，但是，这样做是很不划算的。作为企业，在运行和发展过程中需要注意资源的合理利用，需要考量成本。通用的做法是通过购买商用机器去构建集群，在不能无限提高单机DB性能的情况下我们自然而然的想到就是对DB进行分库分表，当然，前提是单机性能不能再满足业务需求。我们在考量是否需要做分库分表的时候，通常需要做一下思考：
（1）数据库表中数据数量级是否达到一定量级，大数据量表对索引和查询是否带来了较大压力；
（2）数据库的吞吐量是否达到瓶颈，是否需要多个数据库实例来分解大量请求带来的压力；
（3）最重要一定，有没有必要自己做分库分表方案，是否直接使用云解决方案能够直接解决问题呢。
我任务第三个问题是需要深入考量的。企业在发展过程中要注意成本考量，如果作为中小企业，我们要考量是否需要自研相关软件，投入相应的人力物力能否得到相匹配的价值，这是很重要的。尤其是，现在云技术的成熟，让很多企业可以减小对底层基础软件和设备的维护依赖，减少成本。当然我这里分享文章，只是想让自己曾经做的事情能留下来，做个总结。如果有一天想拿来作为参考，也欢迎分享。
下一篇我将分享整个数据库应用体系构建的产品思考，为整个体系的建设做一个总体把握。