今天在和同僚聊系統配置的時候，突然聯想到一個問題，問題的背景是對于磁盤的使用情況，是希望在獨占模式下做到定制化配置還是作為一種統一的配置方式管理，簡單來說，就是對于資料庫伺服器的磁盤配置，是根據磁盤來映射特定的伺服器還是把伺服器磁盤統一規劃起來，用一個統一的分區或者卷來提供服務。
其實顯而易見，第一種方式看起來蠻好，但是對于運維來說，是不夠規範的，而且從管理的角度來說，定制化程度太高，從系統角度來說，是可以簡化的。從我的角度來說，我是更傾向于第2種方案。
方案很快就敲定了，但是我細細意向，我們其實在資料庫方向的一些工作是和這件事類似的。
比如我們現在的資料庫管理模式是不透明的，我們通常會收到業務送出的資源申請和變更申請，我們大多數情況下是去執行，在這個之外是去衡量成本和配置，但是問題的本質卻沒有發生變化，多年的經驗告訴我，大多數的業務資源使用率是很低的，其實從資源成本的角度來說，這麼多的資源空置其實是可以避免的，另外一個角度假設我們現在有100台資料庫伺服器，但是資源之間彼此是隔離，完全沒有調動起來。
我下午在設想一個問題，如果我們有1000台資料庫伺服器，那麼我們是否可以精簡到100台，充分提高資源使用情況，這個問題看起來有些刻闆，但是确實是運維價值的一種展現，而如果精細規劃，其實想想這個目标其實也是很可能達成的。
我設計了如下的圖，可以作為一種思路和參考。
我們可以開放統一的接入管理，而在資料庫層面可以對每個資料庫建立相應的統一賬戶，比如讀寫，隻讀賬戶等。這樣從接入層面映射下來我們就可以不用專門維護防火牆層面的權限了。
假設我們按照Zone為粒度進行資源劃分，那麼可以把一些資源和使用要求較低的業務放在一個預設的資源池裡，對于資源使用較高的分别為zone2,zone3,如果zone1裡面的執行個體因為擴充需要快速影響，也可以通過這種機制來快速實作。
對于每個Zone的節點來說，我們至少要保證哪個節點可用，同時需要按照故障的機制來進行高可用設計，本質上是希望整個服務是具備備援機制。
如下圖所示，比如資料db1有讀庫和寫庫，我們可以在中間件層實作一些基礎映射功能，而對于再上一層的接入也是類似的方式。
