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。
