IOT網關，接收sensor數據的總入口，主要是日誌，安全防護，流控，協議轉換等功能，
圖1 IOT網關
之前有提到IOT網關是基於python的twisted框架實現的，初期的時候該IOT網關主要實現的功能是 數據接收和轉換功能 和 安全防護 。
數據接收和轉換功能 ，這裏很簡單，擬定好數據交互格式後，IOT網關按照約定好的格式進行解析，然後轉發給後端服務進行進壹步的處理
安全防護 ，設備的區分主要是依靠燒錄到硬件的SN號來實現，SN號包含的信息比較多，如生產批次，設備型號等，受制於廠商我安全防護不能做的非常完善，同時sensor與IOT網關的交互不能非常復雜。安全防護這壹塊理論上是設備接入要壹型壹密或者壹機壹密，協議上還應該啟用tls/ssl安全通信協議。
圖2 鑒權
安全防護要做ssl這類的安全通信協議的話，要考慮設備廠商實現通信模塊能力，設備功耗，設備性能（低端設備cpu性能可能比較差，可考慮對稱加密形式），IOT網關也需要引入相應模塊。
另外認證從性能方面考慮，後期在設備比較多的情況下，可以加入redis等內存型key-value數據庫，緩存設備信息，提高鑒權模塊性能。
實踐中，我們的sensor基本都是依靠電池供電，因此我們的IOT網關基本是面向短鏈接（後期我們有監測設備，依靠外部電源直接供電，為長連接），因此在每次發起連接我們都要進行壹次鑒權，鑒權通過後，設備方可上傳傳感器監測數據和設備自身狀態。
圖3 數據交互流程
這壹塊的調試工作長達半年左右，才基本穩定下來，主要集中在設備商處除了硬件穩定性，還有在調試中發現傳輸的字符串亂碼（c語言處理問題），沾包（廠商開發人員tcp協議不熟），優化傳輸效率，關閉cork或者 Nagle 算法（傳輸包很小）。
因為IOT網關不能主動斷連接，理論操作中，IOT網關應該和sensor有心跳協議，保證連接的有效性。設備商在數據流程交互完成後，竟然沒有close 連接，直接休眠，導致網關所在服務器的連接的文件描述符壹直沒有正常釋放，後面為了預防這種現象，我開啟了操作系統層面的keepalve定時器，回收失效連接（系統默認時間是2小時左右，我縮短了失效時間），理論上來說應該是應用層面去實現心跳協議。
整個IOT網關的設計，是無狀態，可伸縮的，單網關在普通型ecs上可輕松達到數百tps。