一、業務背景
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）最重要一定，有沒有必要自己做分庫分表方案，是否直接使用雲解決方案能夠直接解決問題呢。
我任務第三個問題是需要深入考量的。企業在發展過程中要注意成本考量，如果作爲中小企業，我們要考量是否需要自研相關軟件，投入相應的人力物力能否得到相匹配的價值，這是很重要的。尤其是，現在雲技術的成熟，讓很多企業可以減小對底層基礎軟件和設備的維護依賴，減少成本。當然我這裏分享文章，只是想讓自己曾經做的事情能留下來，做個總結。如果有一天想拿來作爲參考，也歡迎分享。
下一篇我將分享整個數據庫應用體系構建的產品思考，爲整個體系的建設做一個總體把握。