<meta name="source" content="lake">
簡介： 雲上專屬 自主可控 最省成本
作者：****陳招尚（勝通）
一、自建數據庫需要考慮的問題
自建數據庫需要考慮的問題：
第一，搞定數據庫高可用問題。
第二，提升數據庫資源利用效率問題。
第三，資源瓶頸。提升利用效率的同時，解決資源瓶頸問題。
第四，運維幸福感。運維數據庫需要解決運維幸福感問題。
第五，爲公司節省成本。隨着公司業務發展越來越強，對節省成本要求更多。
總結：DBA把數據庫管理好，是基本崗位要求。“妝成有卻無”，我們把妝畫好了，但是別人卻看不出來。我們數據庫產品沒有什麼問題，並且每年爲公司節約成本，對公司管理層來說，是DBA管理工作者的基本功。
但是數據庫能否正常運行，受很多因素影響，有問題時DBA可能會背鍋。因爲應用瓶頸，大多用擴機器解決，但有的時候擴機器無法解決數據庫問題。還有DBA人數和研發人數比例失調，一位DBA對應的服務有100位~200位研發人員。對支持業務與解決運維問題之間需要平衡，支持業務多一些，運維投入就少一些，DBA常常疲於支持業務與運維間平衡，兩者相互制約。
自建數據庫需要考慮的問題很多，在過去很長一段時間裏面，經常面臨各種選擇問題。比方爲了提升業務幸福感，如果晚上掛了啓用延遲處理機制等。
二、阿里巴巴內部數據庫的部署歷史
阿里巴巴內部數據庫的部署歷史，10年前MySQL版本還比較低，沒有大規模應用於大型系統中。
1）第一種部署很簡單，如圖所示：所有主部署全部在一臺機器，所有備部署全部在一臺機器。
在這種情況下，隨着公司的業務高速發展，後端運維崗位投入、IT資本投入都比較大。從DBA團隊角度來說，穩定性壓倒一切，所以選擇這種部署方式。比如部署三個實例，這三個實例同時提供服務，只要這臺機器的利用率資源夠用就可以滿足。
那個年代在平時是沒有問題的，但是在雙11業務壓力突然上漲的環境下，會有連接數問題：連接數很多，如果壓力不夠，對數據庫響應時間會很長。
比如一臺數據庫實例，前面服務200臺應用服務器，平時連到數據庫只有5個連接數，正常情況下實例只有1000個，可提供1000個連接服務。如果在雙11高壓場景情況下，應用服務器從200臺擴衝1000臺，爲了抗住壓力，連接數會設到20~40，數據庫系統裏面的連接很可能會達到10000或者超過10000。
我們當時面臨的情況是，應用數據庫各個方面都沒有異常，但是應用響應時間特別長。MySQL在當時5.1版本，業務壓力增大的情況下，連接數是很大的問題。
第二個問題是：主機宕機問題。如果有一臺主機掛了，主機內的三個實例全部需要切到新的一臺機器上去。切換硬件相對的影響很大，三個實例可能包含公司1/3的業務，那麼1/3的業務都會受到影響。爲了減小這種影響，要求備庫能夠百分百支撐起這臺主機掛掉的情況，所以主庫和備庫的配置需要保持一致，那麼對備庫的投入成本與對主庫的投入成本也一樣多。
2）第二種部署
因爲業務發展太快，硬件達到指數級往上投入，公司要求DBA進行成本優化，如下圖所示，實現主備交叉部署，主實例相對用到更多的資源，備實例用於複製備份場景，使用的資源會少一些。
這種部署下，我們面臨的第一個問題是：部分超賣，堵運氣。舉例說明，比如主機部署了64核，感覺是部署了96核。DBA實行了部分超賣，這個時候就是堵運氣。左邊主機如果掛掉，兩個主部署會全部切到右邊的主機上面，左邊實際達不到64核物理上CPU總數，這是第一個面臨的問題。
第二個問題是讀寫分離。如果主備交叉部署時，還想要提升資源利用效率，自然會想到會將備部署利用起來，做讀寫分離，會把一些讀請求放到部署上面，這種情況下，左側的主機有流量，右側的主機也有流量，利用率更高。當然這樣做也有堵運氣成分在，在大型促銷場景下，需要把主備部署自動切換關掉，相信尖峯時刻機器不會掛掉，另外業務上把很多機器切開，影響面會比較小，所以當時以這種方式應對。
3）第三種部署
開始構建集羣型的方式，兼顧成本與穩定性，如下圖所示：
第一個提升是將不同的機器充分進行打散，引入現在還在用的內部系統叫移山系統，進行資源調度，根據監控每臺機器的資源利用效率，及時觸發條件，將整個集羣裏面的實例進行資源調度。相當於整體實例利用率水平保持在比較均衡的狀態。
第二個提升是備庫預熱，如果突然主備切換，備庫如果沒有承擔讀會是冷啓動，備庫需要有一個預熱的過程，否則如果流量很大，那麼可能會出現備庫被燙死的情況，對此我們做了備庫預熱。
第三個提升是讀寫分離的問題，我們也考慮到讀流量。
4）第四種部署
重要系統和非重要系統交叉部署，如下圖所示：
在前面三種模式下，核心系統和非核心繫統分成兩個集羣處理，核心系統更會往穩定性部署，而非核心繫統會更向成本優化角度部署。這時出現一個情況，就是我知道哪個系統是核心系統，哪個系統是非核心繫統，但是如果出現非核心繫統突然變成核心繫統的情況，在認爲的非核心繫統裏面諮詢，非核心繫統用到的資源會增強。爲應對這種問題，我們增加了重要系統，鎖定資源，不被爭搶的功能，鎖定資源不會增強。
非重要系統：大量混合部署，資源隨時彈性，移山及時再平衡。比如做大型活動，流量上漲，可以根據資源CPU跟IOPS利用效率把機器上其他資源移走，實現資源利用效率整體平衡。
三、經驗分享
經驗1：主備交叉部署，一種僞超配的降成本方案
如下圖所示，實際上一臺機器用到了96核，但是主機上是64核，因爲主資源備交叉部署，利用的效率並沒有達到滿負載。
收益：
CPU資源利用效率整體上達到70%。
連接資源被有效利用。
更低成本。
注意點：
HA機制要靈活，什麼時候自動切，什麼時候手動切。如尖峯時刻手動斷開主備庫的連接，以應對高流量諮詢問題。
主機問題監控，核心資源打散。比如雙11的時候，後端資源保障上都會資源打散，大家千萬不要讓主機滿載運行，如果主機滿載運行的話，一旦掛掉就會出現雪崩的情況，因爲切到備庫，備庫也會掛掉，這是我們的一個經驗。
經驗2：應用分級，保障粒度差異化
應用分級，以不同的分級保障不同粒度差異化，比如分爲一般性業務或重要性業務。一般性業務，可以利用交叉部署獲得更多資源利用。重要性業務，更偏向穩定性方案，一定要有對外SLA保障。因爲很多一般性業務依賴於中小型的業務，做應用分級，可以提升整體利用效率，提高可用性。如下圖所示：
兩種不同等級業務的數據庫資源模式
兩種不同等級業務的數據庫資源模式，需要通過三個階段的隔離實現:
MySQL實際上是喫內存性的，比如內存有64g基本上會把64g內存用完，超賣在內存這塊是做不到的，所以開始從內存隔離，隔離過後，在一臺機器上使用內存大家不會搶單。
如果在非重要的集羣裏面，業務流量突然上漲，非重要變成了重要，就把CPU綁定，實現 CPU的隔離，使其不會被爭搶。
如果重要性上升到公司的核心業務，這時可能會把它獨立出來，進行物理機隔離，進入第三個階段。
經驗3：兩種抽象的資源部署方案
無論是數據庫，還是應用部署，資源調度對最底層的分配方式只有兩種：均衡分配與緊湊分配。
均衡性分配，如下圖所示，離散型數據庫實例分佈，優先在更空的主機上繼續分配實例，資源主機的利用率相對比較均衡，整體性能表現也會相對比較穩定。
緊湊性分配，如下圖所示：堆疊型數據庫實例分佈，優先在更滿的主機上繼續分配實例，資源主機的利用率會更高，各主機性能表現不一，成本更優。
緊湊型和均衡型交叉應用場景
典型應用場景，比如一開始是緊湊性分配，更關注成本。大促的時候，增加了機器，變成均衡分配，實現資源均衡綜合調度。大促做完之後，再回歸到緊湊性分配，把機器空出來用到需要的地方。這種資源挪騰可以是自動化的，也可以人工手動方式進行挪騰。平時緊湊分配使資源利用率更高，成本更低，大促時使用均衡分配，穩定性更高。如下圖所示：
經驗4：資源彈性，消除業務流量評估焦慮
業務流量評估焦慮：
評估過程：業務指標–業務QPS/TPS–全鏈路壓測–數據庫準備。
標準上線流程：提前資源報備，詳細部署監控，SQL審覈，深夜值班觀察表現。
三種結果：沒抗住是因爲沒評估好，抗住了是應該的，資源利用率不高是因爲沒評估好。
如上圖所示，業務方心目中的每一個數據庫都非常重要，業務是他的全部。但是DBA實際操作時會區分出哪些是核心業務，如右圖紅色部分；哪些業務是非核心業務，那些業務運行一段時間就下線了等。
所以從DBA角度看，數據庫地位實際上是有差異性的，爲應對這種差異性，我們在內部專門做了混合性集羣，這種模式下，DBA開始時不需要評估流量大小，可以直接放入集羣中。如果業務突然漲上來，可以迅速地彈上去，然後立刻鎖定CPU，使其不會再增強，保證一段時間內的重要性地位。如果業務持續增長，再把其轉移到專門爲其設置的集羣裏面，這個過程保證了數據庫的穩定性和可用性。同時減少了因DBA評估錯誤出現的問題。
四、雲數據庫專屬集羣產品介紹
雲數據庫專屬集羣 部署架構圖
針對阿里的實踐，在雲上推出了雲數據庫專屬集羣，這種專屬集羣與PaaS平臺區別是什麼？
PaaS平臺買的都是實例，專屬集羣買的是主機，客戶可以自己構建一整套專屬集羣模式，構建專屬的一套技術管理業務，好處還包括能夠超配、客戶自己管理、可以實現主備交叉部署提升資源利用率、可以實現在不同機器之間資源調度、資源再均衡、資源迅速攀升和收縮等各個方面的能力。
以上是專屬集羣的產品簡介，總結：第一它是雲上專屬的數據中心；第二是自主可控；第三是因爲DBA對業務更瞭解，可以實現成本最優化。
雲數據庫專屬集羣 能力建設進展
PAAS服務有的功能，雲專屬數據庫都有。混合部署在研發中，其他我們都已經實現支持了。原數據庫 PasS能力都有，包括高可用、高可靠性能等方面。
另外我們還新增了資源調度功能，包括緊湊型、均衡型、通過移山進行資源均衡、資源的彈性擴縮等等。雲數據庫專屬集羣是以主機的形式在管理數據資源，不再像PaaS平臺是以實例的形式管理。
