如今，負載均衡已經不是一個新鮮的詞，也不是什麼新技術，主要用於解決單機負載能力的侷限性，但問題是你的應用真的到了單機的負載上限了嗎，未必，很多不知道如何推斷瓶頸，如何解決問題的人就開始盲目的增加機器，似乎只要能加機器，性能就都不是問題，負載均衡技術成了這類人心中的白馬，一臺機器能搞定的事你用了10臺，這顯然是成本問題。
其實很多問題都可以很簡單的解決，看以下場景
1、一個數據庫服務器上跑兩個數據庫，並且在生產環境中，這兩個數據庫所帶來的負載是差不多的，並且通過工具監測發現是硬盤的IO遇到了瓶頸，怎麼辦？相信很多人馬上想到，加一臺服務器，配讀寫分離，或者同步複製，把兩個數據庫分別用單獨的服務器跑 等等方案。其實這個問題很簡單，既然瓶頸在IO，那麼我們就解決IO問題，加一塊硬盤，兩個數據庫的數據分別放在不同的硬盤上不就解決了嗎，在有些場景下增加內存可也以降低磁盤IO，也能很簡單的解決問題
2、對數據庫熟悉的人都清楚，索引在查詢中的重要性。然而在我遇見的很多開發者中真正能用好索引的人很少，很多時候有索引和沒索引（或者索引不當）造成的性能差別是相當大的，如果這也要通過增加機器來解決不知要多少機器夠你用的
3、文件下載服務器，這種服務器的瓶頸通常都會出現在單機的網絡吞吐能力上，而單機網絡吞吐能力取決於網卡的吞吐能力，難道說就因爲網卡的問題又要加機器嗎，其實很多人忽略了一個問題，就是一個機器是可以加多個網卡的
其實可以例舉的場景很多，不過通過以上三個場景，相信很多人已經發現問題了，只是我們太關注負載均衡，集羣這樣的技術，而忽略了其實有些問題可以很簡單且低成本的解決的
總結：不要盲目的應用各種技術，要學會思考，發現問題的本質纔是更好的解決問題的關鍵