在業務高速發展的時候，后端的壓力慢慢變大，服務器擴容在所難免，今天就聊聊擴容相關的問題，
首先我們看資料庫的擴容，到底是加實體還是直接升配？
在創業初期，基本上都是單庫的形式，比如最開始是4C8G的配置，到了某天資料庫扛不住了，但是資料量其實沒那么大，只是請求量上來了而已，或者由于研發寫了很多復雜的Sql導致資料庫性能下降了，
資料庫加實體
這個時候最快的解決方式就是擴容了，首先我們來看加實體的方式，比如我們可以加N個從節點來提高查詢的性能，可以對庫進行垂直拆分或者水平拆分，
以上這些都是提高性能的方式，但是都有一個問題就是得改代碼，還得測驗，時間成本較高，
資料庫升配
資料庫升配指的是直接升級硬體層面的配置，比如4C8G升級到8C32G，性能直接大幅度提升，好處是應用代碼都不用做任何改變，資料庫層面直接升級即可，
當然也有需要注意的地方，如果你們是自建資料庫的話，得進行資料遷移之類的操作，如果代碼中的IP鏈接資料庫的話得看IP會不會變，如果會變還是得改配置，重啟應用程式，
如果用的云服務，一般都是用域名進行連接資料庫，升配后連接斷開也能重連，資料也不用我們操心，只需要在控制臺點點按鈕即可完成升配，就是有點費錢而已，
云服務升配特別需要注意的是一定要選擇凌晨進行升配，在白天升配會有一定的影響，我們之前在白天升配過一次，升配失敗，導致資料庫無法回應，
服務器加實體
服務器加實體相對于資料庫來講會更簡單，我們的后端服務都是無狀態的，擴容也只需要有新的服務器，裝個環境就可以直接部署了，如果用了Docker之類的容器就更方便了，
資料庫加實體程式還得調整，后端服務加實體，不用改動代碼，如果是服務層本身就用注冊發現的機制，如果是web層，也只需要修改Nginx的配置即可，
所以建議大家在服務器需要擴容的時候盡量直接加機器，不用了也可以撤掉，
服務器升配
如果剛開始你的機器配置很低，比如2C4G這種，我建議你先升配，至少也得搞個4C8G的配置，不然性能太差了，
機器升配跟資料庫一樣，如果是自建的還好，直接將應用部署到新機器即可，如果是云服務，那么還是得選擇凌晨進行升配，不能影響業務，
總結
創業初期，資料庫盡量先升配，節約開發時間，資料量大了后在拆分多節點，
服務器配置低先升配，保證所有相同業務的部署機器一樣的配置，如果配置不是很低，那么選擇擴容節點，對業務沒有任何影響，前提是服務需要無狀態，
關于作者：尹吉歡，簡單的技術愛好者，《Spring Cloud微服務-全堆疊技術與案例決議》, 《Spring Cloud微服務 入門 實戰與進階》作者, 公眾號猿天地發起人，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/271515.html
標籤：AI
上一篇：第一章 無名小生 （凡人篇）