1、優先使用無狀態服務
有狀態服務和無狀態服務，原本是各有優勢，並沒有明顯的優劣之分，但是在大集群、服務化的場景下，無狀態服務則更有優勢。
因為有狀態服務在服務架構較為簡單時雖然有易開發，高併發等優勢，但隨著業務規模的擴大，也會造成異常恢復困難、難以並行擴展等問題。而在這種場景下，無狀態服務在服務管理、並行擴展方面有著先天的優勢。
一般來講，使用負載均衡，大多是服務規模較大，業務負載的場景，因此更推薦使用無狀態化的服務。
2、忽視健康檢查配置！
健康檢查是負載均衡服務的重要功能之一，也是服務判斷後端節點是否存活的重要標準（很多場景下甚至是唯一標準）。不僅僅會影響到顯示的狀態，還會影響到用戶的服務質量，甚至造成整個服務異常。下面舉兩個例子：
誤區1：健康檢查判斷異常參數過於敏感，在系統壓力較大時錯誤判斷而移除正常的節點，導致剩下節點壓力增大，從而繼續發出移除操作，直到全部節點移除，系統雪崩。
應對之策：在線上壓力較大，偶現超時的場景下，建議採用快速拉起，緩慢宕機的策略。通過適當拉長節點異常宕機時週期，減少錯誤判斷的概率，而在服務正常時快速接入服務，緩解負載。
誤區2：健康檢查宕機參數設置時間過長，結果在節點宕機時無法快速拉起，在異常時影響到了用戶訪問。
應對之策：在線上壓力較小、健康檢查接口響應正常的情況下，可以考慮縮短宕機時間，這樣在異常時可以快速移除異常節點，減少對用戶的影響。
因此，健康檢查參數並沒有一個固定的原則，關鍵還是要看業務本身的特點，以及對業務來說，最重要的是什麼：是業務穩定，還是用戶體驗？
3、接入負載均衡無法保障高可用
有一個常見誤區就是認為服務接入負載均衡就算高可用了。而事實上實際服務的高可用性是需要通盤考慮的事情，比如全鏈路移除單點，服務本身對於異常的處理等。
因此說，接入負載均衡僅僅是保證了接入點的高可用（如果掛單點那接入都不是高可用的），真正要實現高可用還需要全局保證，負載均衡只是構築服務高可用的一個工具，而不是全部。
4、接入負載均衡後並不會實現業務加速
負載均衡是一個高性能的轉發服務，但是對於單次請求來說，無法做到性能加速。
如果你本來的請求要 100ms返回，使用負載均衡之後也不會把你的請求縮短到 10ms。
而且從理論上說，無論任何形式的負載均衡，都只會增長調用鏈而不是縮短（一些軟負載均衡，如 DNS，Service的 Iptables不會增加調用鏈本身，但是也會加入額外操作）。因此，對於單個請求，結果往往是變慢而不是加速（一般負載均衡服務增加的成本是微乎其微的 ms以內，應用完全感知不到）。
負載均衡對性能的提升，是通過分擔負載帶來的並行擴展能力從而提升服務的穩定性。而由於業務並行擴展，造成單臺壓力變小，從而提升服務的整體性能。
另外，由於負載均衡服務往往有更可靠的接入端（BGP網絡），更高效的轉發設施（專用轉發設備和鏈路），更好的優化，一般性能還是遠遠優於自己搭建的轉發服務。因此很多場景是會有更好的性能表現。
阿里雲江蘇授權服務中心，全面負責阿里雲江蘇地區相關業務，為江蘇地區的企政大客戶提供專業的阿里雲產品和整體項目解決方案，為阿里雲客戶授權區域內的會員提供專業的本地化服務。 5*8小時售前支持；7*24小時售後支持，用戶有問題可隨時與服務中心聯繫，無需提交工單，免去等待，即可獲得即問即答服務。快速上雲，輕鬆運維。
閱讀更多 博融雲服務 的文章
