侵权投诉
订阅
纠错
加入自媒体

智能家居的软硬件架构技术详细分析

  通信协议的选择

  接下来我们还需要一个好的通信协议,现在很多通信协议是XMPP,很多社交软件都个在用,因为它开源做得比较好。MQTT是专门用来做物联网的协议。另外,PROTOBUF是谷歌的,这三个比较的话,MQTT和PROTOBUF是最适合做物联网通信协议的,因为这两个协议对数据量利用率非常高,不会带来额外的开销的。

  快速构建云服务

  再回到上图,如果我们要做这样一个系统,为了要简单快速的出这样一个产品,要利用很多开源的组件,比如说负载均衡这里,传统的里面是比较难做的,我们用的比较多硬件负载均衡是F5或者是淘宝的LVS,我认为LVS对于目前做硬件的来说肯定是够的。再下面Connect Server现在也有很现成的开源技术,如果采用XMPP协议的话可能要用F5,像很多也完完全全做好了,如果在TTP这一层优化比较好,做到八十到一百万长连接也没有问题,而且会特别简单。像很多轨道函数都写的非常好,我们都不用关心怎么管理这些线程质量、怎么管理连接,只要在上面写我们的业务代码就行了。另外,我们这里面要做集群,我们有很多服务的时候直接在上面注册,后面调用的时候不用关心今天多了一台机器、明天少了一台机器以及这个机器的ID是什么。另外,服务要远程交易,我们要考虑IPC框架,像淘宝和Facebook的一些,都是开源领域利用的非常好的。

  我们肯定还要用到很多缓存,缓存方面我们用的比较多的。如果我们对开源的框架用得比较好,简单的这个系统很快就可以完成了,不需要我们写很多东西,只需要在上面写业务代码就能够直接做好了。

  这里面就是刚刚说到的,如果你用Netty,只要在这里面写业务代码,当你接收到数据的时候这里面应该怎么做,包括这里面出了异常的时候要怎么做。如果选用Netty还要考虑到一个情况,高并发的时候需要对数据包做拆包的事情。我们经常发现这里接收到的数据并不是一个完整的数据,比如说我们发了大概2K左右的数据,它给到你的可能只有很少。如果这里面不完整,把组包放进来就可以了。具体的拆包、组包也提供了编码性和解码性,最重要的是在这个函数里面写你的业务代码。

  嵌入式开发

  我们要在设备端也实现接入,还要考虑嵌入式的开发。嵌入式也有一个问题,我们的设备都是需要成本的,不像写服务代码一样,服务器资源非常多,给到你很好的服务器可以用。在嵌入式方面,我们必须用最低的成本、最少的资源做最多的事情。每一个产品研发出来,第一代选用的芯片可能比较好一点,第二代为了这个产品能够卖得更好,可能会做更改,对我们来说可用的资源更多。通常我们用单片机,我们比较常用FreeRTOS,它没有TCPP协议的。做嵌入式开发的时候我们还会遇到更多的问题,像LWIP之类的,写这个协议站的人可能并没有用到很多产品,所以里面还是残留了很多BUG。这里面举了两个非常明显而且一定会遇到的问题,一个是TIME_WAIT,还有一个是CLOSE_WAIT,如果对方没有按照正常流程关闭,假如说我们的APP直接刷了,可能就会产生这个CLOSE_WAIT,它一直在那里等,我们可能只开放十多个端口接入,如果一直在等待,可能它就认为这个请求还是正常的,就不会把它释放出来。等我们给它分配的端口满了之后,下一个请求就再也接不进来了。一般有三次握手,如果断开了标志着有四次握手,我们发现它没有按照正常的四次握手,导致断开的时候少发了一些命令,所以就一直在等待,等待的时候数据怎么发也发不出来了。

  还有我们经常可能会遇到一些问题,比如说这里面可用的只有10几K、64K,我们要在上面写代码,如果写了多线程,又是单核的CPU,这里面用的时间长了会产生很多的内存碎片。当内存碎片产生了之后,多线程再申请内存做其他事情的时候,比如说有一个线程需要申请的资源比较大的时候会申请不到,就会一直在那里等,就会发现是怎么回事,这个地方本来十几毫秒就可以处理完的,可能等了一秒钟或者两秒钟甚至时间更长时间才能处理,这就是时间用了长了之后产生了内存碎片。我们回收内存也做不了,所以经常要做被动的事情,要软重启一下,所有的线程再重新跑起来。

<上一页  1  2  3  4  下一页>  余下全文
声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号