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