前言

物聯網如今是一個大的趨勢，但是概念還比較新穎。大家對這一塊的技術積累也比較匱乏，藉此前段時間摩拜單車出現了大規模癱瘓的現象。我們今天來討論一下物聯網專案的開發方式。

關於tcp/ip 相關的知識點

socket通訊的單機瓶頸

物聯網的專案socket使用方式有兩種：

1. 短連線的socket請求
2. 維持socket長連線的請求

對於socket短連結來說就好比是http請求，請求伺服器，伺服器返回資料以後請求管道就關閉了，伺服器與客戶端的連結就釋放了。但是對於socket長連結就不同了，當裝置與伺服器建立連線以後就要一直保持連線，或者說保持較長時間的連結，那麼就會大量消耗伺服器的資源。若存在大量的這樣的請求以後伺服器終究會受不了垮掉。通過對TcpClient/server最大連線數我們得知單機socket服務是存在最大連結數限制。儘管理論值很大，但還要考慮到實際伺服器的記憶體／cpu／頻寬等條件，我們不可能指望單機承載特別大的連結請求。

該如何負載均衡socket長連線的請求

提到負載均衡大家可能會想到很多負載均衡的框架，比如說比較出名的：nginx。但是悲催的是他是基於轉發的方式，不能應用在socket長連結請求上。在這一塊目前還沒有特別優秀的處理框架，而且從技術角度來分析也不可能存在。那我們只能自己想辦法了。

socket分發服務架構圖

1、 裝置請求分發伺服器，分發伺服器返回有效的socket伺服器ip與port，然後斷開連線。
a) 裝置與伺服器建立連線。
b) 伺服器接收到連線請求後，立即將分配好的socket伺服器ip與port資訊響應給裝置。
c) 伺服器主動斷開socket連線。
2、 裝置得到ip與port以後，裝置去連線socket伺服器，然後與其進行協議通訊。
a) 裝置連線到socket伺服器。
b) socket伺服器響應連線成功響應資訊。
c) 裝置與socket伺服器保持長連結通訊。

*. 若裝置未收到連線成功響應則再次嘗試連線，若三次請求依舊沒有成功建立連線，那麼裝置需要去請求分發伺服器然後再重新上述操作。
*. 當裝置在異常情況下連結不上socket伺服器時，依舊嘗試三次若不能成功，則直接請求分發伺服器，然後再重複上述操作。

分發伺服器處理業務

我們來看一下分發伺服器該處理的業務：

    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {

        //todo 根據自己的負載情況獲取相應的socket伺服器資訊
        String ip = "192.168.1.188:2030";

        SocketUtils.send(ctx,ip.getBytes());
        ctx.close();
    }
    
 

*. ip的獲取需要根據自己的業務來完成。

總結

我們通過這樣的方式就可以輕鬆的解決大量裝置與伺服器通訊的問題，若後面有更多的裝置請求只需新增更多的socket伺服器即可。當然可能大家擔心分發伺服器受不了，其實這是多餘的，因為分發伺服器只做轉發，而且完成處理以後就直接把連結給釋放，並且當裝置拿到socket伺服器的ip地址以後就將不在訪問分發伺服器了，它的壓力是可控的不會特別也不會頻繁。

關於distribute-netty： 該demo僅僅用於說明分發伺服器的工作原理，具體的業務實現還需要根據自己的業務來完成。

對於分發伺服器的設計還可以採用web服務方式，這樣相對容易做成負載均衡。不過這個會增加前端裝置成本，需要先採用http請求獲取業務伺服器ip、埠，再使用socket長連線方式連線業務伺服器。