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