开始是从云时代架构的最新一期开始看的，也就是3月1号，作者今天的问题是分库分表就能实现无限扩容吗？
服务的扩容，其实刚阅读时我并不太懂，于是我就自行百度了一下，大概的意思就是现有性能不能满足将来的更多需求，所以要进行服务器的调整来满足更多的请求。
作者从不同应用开始介绍，单体应用是最早的应用形态，不需要太关注整体性能，项目规模中小型时，开发和部署都挺方便。它的优点是方便调试，代码都在一起，所有服务都在本地容器部署，没有分布式花销，不需要太多资源。而RPC应用， RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。 它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
扩容应用，作者首先介绍通过分库分表的方式来解决业务的访问量增大，服务关系错综复杂、高并发，多用户等新需求，但是通过举例说明了扩容应用的同事，每个数据库连接数就要增加，但是仅仅通过增加数据，也不能解决连接数的问题。以此引出单元化一词，简单来说解释在数据连接数过多时，尽量不让应用连接所有的数据库。通过一个规则（通过用户ID Hash，有配置中心广播hash规则），然后用户从DNS那里进去的时候，就可以知道自己那个应用，这样，所有的组件都能保持一致的规则，从而正确的访问到数据库。
分库分表并不能解决“无限扩容”的问题，只能单元化才能解决这问题。单元化带来更多的思路。有了单元化，解决了无限扩容的问题，但我们又会面临新问题-。
一致性Hash 算法分析 （内置多种路由策略供使用者根据自己的场景选择，同时提供简单的 API 供用户自定义自己的路由策略。）
特点：
1.构造一个 0~2^32-1 大小的环。
2.服务节点经过 hash 之后将自身存放到环中的下标中。
3.客户端根据自身的某些数据 hash 之后也定位到这个环中。
4.通过顺时针找到离他最近的一个节点，也就是这次路由的服务节点。
5.考虑到服务节点的个数以及 hash 算法的问题导致环中的数据分布不均匀时引入了虚拟节点。
为了解决这个问题，一致哈希算法引入了虚拟节点。将每一个节点都进行hash，生成多个节点放置在环上（虚拟节点）。自定义一个有序数组来模拟这个环，流程如下：
①初始化一个长度为 N 的数组。
②将服务节点通过 hash 算法得到的正整数，同时将节点自身的数据（hashcode、ip、端口等）存放在这里。
③完成节点存放后将整个数组进行排序（排序算法有多种）。客户端获取路由节点时，将自身进行 hash 也得到一个正整数；
④遍历这个数组直到找到一个数据大于等于当前客户端的 hash 值，就将当前节点作为该客户端所路由的节点。
⑤如果没有发现比客户端大的数据就返回第一个节点（满足环的特性）。