数据库资源的改进设计
这是学习笔记的第 1954 篇文章
今天在和同事聊系统配置的时候，突然联想到一个问题，问题的背景是对于磁盘的使用情况，是希望在独占模式下做到定制化配置还是作为一种统一的配置方式管理，简单来说，就是对于数据库服务器的磁盘配置，是根据磁盘来映射特定的服务器还是把服务器磁盘统一规划起来，用一个统一的分区或者卷来提供服务。
其实显而易见，第一种方式看起来蛮好，但是对于运维来说，是不够规范的，而且从管理的角度来说，定制化程度太高，从系统角度来说，是可以简化的。从我的角度来说，我是更倾向于第2种方案。
方案很快就敲定了，但是我细细意向，我们其实在数据库方向的一些工作是和这件事类似的。
比如我们现在的数据库管理模式是不透明的，我们通常会收到业务提交的资源申请和变更申请，我们大多数情况下是去执行，在这个之外是去衡量成本和配置，但是问题的本质却没有发生变化，多年的经验告诉我，大多数的业务资源使用率是很低的，其实从资源成本的角度来说，这么多的资源空置其实是可以避免的，另外一个角度假设我们现在有100台数据库服务器，但是资源之间彼此是隔离，完全没有调动起来。
我下午在设想一个问题，如果我们有1000台数据库服务器，那么我们是否可以精简到100台，充分提高资源使用情况，这个问题看起来有些刻板，但是确实是运维价值的一种体现，而如果精细规划，其实想想这个目标其实也是很可能达成的。
我设计了如下的图，可以作为一种思路和参考。
我们可以开放统一的接入管理，而在数据库层面可以对每个数据库创建相应的统一账户，比如读写，只读账户等。这样从接入层面映射下来我们就可以不用专门维护防火墙层面的权限了。
假设我们按照Zone为粒度进行资源划分，那么可以把一些资源和使用要求较低的业务放在一个默认的资源池里，对于资源使用较高的分别为zone2,zone3,如果zone1里面的实例因为扩展需要快速影响，也可以通过这种机制来快速实现。
对于每个Zone的节点来说，我们至少要保证哪个节点可用，同时需要按照故障的机制来进行高可用设计，本质上是希望整个服务是具备冗余机制。
如下图所示，比如数据db1有读库和写库，我们可以在中间件层实现一些基础映射功能，而对于再上一层的接入也是类似的方式。
