原文地址：
https://mp.weixin.qq.com/s?__biz=MzAwNTQ4MTQ4NQ==&mid=2453562189&idx=1&sn=2e895692f47b0b3ac7842a044ef20df5&chksm=8cd1362fbba6bf39777aa5fe8a2bb1b4b5e162f3829805f2a717f6dc806973bbc07ad9d67291&mpshare=1&scene=23&srcid=#rd
分库分表就能无限扩容吗？
一、正常情况下的服务演化之路
单体应用
每个创业公司基本都是从类似SSM和SSH这种架构起来的，没什么好讲的，基本每个程序员都经历过。
RPC应用
当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了，如下图：
当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接DB的，只需要连接缓存即可，那么就可以做成分离的，减少DB宝贵的连接。如下图
分库分表
如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过ID hash或者range的方式都可以。如下图：
这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。
实际上，像上面的架构，并不能解决。
其实，这个问题和RPC的问题有点类似：数据库连接过多！
通常，我们的RPC应用由于是使用中间件进行访问数据库，应用实际上是不知道到底要访问哪个数据库的，访问数据库的规则由中间件决定，例如Sharding JDBC。
这就导致，这个应用必须和所有的数据库连接，就像我们上面的架构图一样，一个RPC应用需要和3个MySQL连接，如果是30个RPC应用，每个RPC的数据库连接池大小是8，每个MySQL需要维护240个连接。
我们知道，MySQL默认连接数是100，最大连接数是16384，也就是说，假设每个应用的连接池大小是8 ，超过2048个应用就无法再继续连接了，也就无法继续扩容了。
注意，由于每个物理库有很多逻辑库，再加上微服务运动如火如荼，2048并没有看起来那么大。
也许你说，我可以通过前面加一个Proxy来解决连接数的问题，实际上，代理的性能也会成为问题，为什么？代理的连接数也是不能超过16384的，如果并发超过16384，变成163840，那么Proxy也解决不了问题。
二、单元化
实际上，思路很简单：我们不让应用连接所有的数据库就可以了。
假设我们根据range分成了10个库，现在有10个应用，我们让每个应用只连一个库，当应用增多变成20个，数据库的连接不够用了，我们就将10个库分成20个库，这样，无论你应用扩容到多少个，都可以解决数据库连接数过多的问题。
注意：做这件事的前提是，你必须保证，访问你这个应用的request请求的数据库一定是在这个应用的。
换个说法，当用户从DNS那里进来的时候，就知道自己要去那个应用了，所以，规则在DNS之前就定好了，虽然这有点夸张，但肯定在进应用之前就知道要去哪个库了。
所以，这通常需要一个规则，例如通过用户ID hash，由配置中心广播hash规则。这样，所有的组件都能保持一致的规则，从而正确的访问到数据库。如下图：
分库分表并不能解决“无限扩容”的问题，只有单元化才能解决这问题。