1樓：
通用的幾個方案。
從多到少依次是：
技術不夠架構來湊。
gateway方案。
網遊比較依賴tcp長連，所以他們比較重視這個方案，有一大堆的框架、文章可以參考。
網路不穩重試來湊。
Websocket我一般用於推送領域，網頁im之模擬較多。客戶端（瀏覽器）做好斷線重連機制即可。
網遊除外。
網遊基本都是gateway方案。
能力不夠人力來湊。
Reuseport是乙個方案，dns是另乙個方案。
兩個方案基本原理一致，下掉一部分服務，等流量切換完畢，再更新上線。
實在不夠公告保底。
停機維護。
2樓：AWP996
原生的websocket還是比較難做的，而且在實際使用中各種企業閘道器也比較難穿透，如果是基於http協議的長輪詢或者stream，配合客戶端的重連機制，手段就很多了。
3樓：
現在在用的架構是前端新增負載均衡裝置，流量在負載均衡裝置上切換至新伺服器處理。舊伺服器可以在新服務承載大部分流量之後強制切換或者等待所有流量切換至新服務後暫停。之前新老架構公升級時使用這種基本可以實現比較方便的小流量測試與上線工作。
DNS方案也是一種，不過不是很推薦，我們測試發現DNS生效時間的影響可控性不高，之前切換就出現過幾小時之後使用者DNS仍未生效的情況，原因也比較複雜。
當然這裡不要有乙個誤區，就是使用長連線之後連線一定不能斷。實際上在業務長連線過程中連線斷開也是比較正常的情況，一般程式/網頁在業務斷開時都需要嘗試重新連線至伺服器。除非你的服務是有狀態的遊戲場景，否則一般情況下連線斷開對正常功能的影響也是微乎其微的。
何況正常情況下遊戲也可以通過重連正常恢復。比如玩著玩著王者榮耀你網路抖動了一下遊戲就不能玩了那使用者早就罵娘了。
當然如果像省掉負載均衡裝置也不是不行，借助SO_REUSEPORT單機實現多程序監聽。老程序不再接受新連線即可。
4樓：jswh
一般性的思路是老的服務不關，新的鏈結進來都路由到新服務上。老服務不在接受新鏈結，通知客戶端重連或者等客戶端自己斷開鏈結，全部斷開之後自己退出結束。
具體怎麼做看情況，小打小鬧就換換埠告訴客戶端連到哪，大一點就可能要寫中介軟體。
5樓：fleuria
長連線後端服務的熱更新、負載均衡之類都挺麻煩。
手頭乙個長連線負載均衡做的比較土，約定客戶端每分鐘重新連一次，走 dns 輪詢，相當於每分鐘隨機長連乙個後端節點，這樣下線、上線節點一分鐘後能生效，均衡性比較差，但是不需要暴力斷客戶端連線。
Go 語言這麼強大，為什麼沒變成開發桌面軟體主力語言呢？
老虎說 桌面軟體需要實現ui部分，實現ui的方式，目前來看html和xml的方式是最合適的。另外乙個原因就是現有技術已經成熟了，新技術除非有乙個級別的提公升，否則很難搶占市場份額。假如你遇到了乙個問題，一直找不到解決方案，你還會繼續選擇嗎，孤軍奮戰只會讓你失去先機。即便是後端服務的市場份額，也用了很...
LabVIEW是用什麼語言開發的？
普通少年pro max 作為課題組中的 軟工 LabVIEW和C C 可以說是我工作的全部。LabVIEW底層核心部分是由C C 編寫，例如核心執行時，計算庫等等。直觀的介面是基於Qt開發的，然後這幾年在主推的LabVIEW NXG 好久沒用了，是不是這個明我忘了 好像是是C 然後用的WPF，然後中...
go有哪些快速開發的web框架？
推薦一款新的web框架 gofiber fiber 不論API還是效能都是槓槓的，非常適合小專案 請求上下文ctx提供了豐富的常用API 有很多開箱即用且功能強大的中介軟體，第三方的中介軟體也有很多具有較強的路由功能 提供全域性錯誤處理，可以集中控制請求可能發生的錯誤提供豐富的模版引擎 內建http...