11月6日消息，在由七牛云主办的架构师实践日（深圳站）物联网与智能硬件架构技术沙龙上，来自AbleCloud的技术合伙人孙志东进行了题为《构建高可用、可扩展的IoT云服务》的分享。以下是他的演讲内容整理。
　　IoT的难题 -- 机遇与挑战
　　IoT时代已来，这是大家都清楚的，里面有挑战也有机遇。机遇是用户对产品认知度越来越高，另外是产业、产品都要升级，包括互联网思维引入，
　　怎么运营我的产品和我的客户，怎么指导后续产品的发展方向和营销方向等等。互联网+的东风到了，但是我们面对这样的东风，面对这样一个完全未知的东西内心多少会有一些恐惧，恐惧在哪儿？就是里面充满了很多挑战。这些挑战从传统角度来讲，第一它们的时间周期没有那么长，因为现在正是一个最追求速度的时代，你的产品迭代速度跟不上，可能市场上就没有先机，而且这是快速变革的时代，没有办法。第二是我们的厂商缺少互联网开发的相关团队，对架构这一块理解可能没有那么多有经验，理解上没有那么深。另外，设备智能化了之后干什么？从用户角度来讲给他提供了更丰富的体验，其次更多的是对厂商而言的，通过设备跟用户有了更多关联。这种关联除了是直接用户行为数据能够获取到，设备本身的运行情况也能拿到，根据这些数据怎么运营、怎么发挥更多的价值，这是后续智能硬件要有长远发展必须考虑的问题，这是对于厂商的挑战。
　　对于一个创业团队来讲也有挑战。创业团队有互联网思维和产品迭代的常规的方法论，开发团队可能也有，但是对整个硬件的供应链以及传统这一块可能也不是很了解，所以就需要一种结合，这种结合就是硬件团队发挥自己的专长，能够选一个更加合适自己的云平台或者有一个理想的云端的总体架构，这样可以避免走一些弯路。互联网发展到现在，你会看到无论是淘宝还是其他BAT公司都会一步一步迭代下来，曾经走过的弯路基本上是雷同或者类似的。我们物联网时代是不是也重蹈那样的覆辙呢？是不是一定按部就班的把他们走过的坑再走一遍呢？这个答案大家是心知肚明的。
　　AWS的IoT基础架构
　　正式开始之前，我们先看一下AWS的IoT的基础架构，中间的黄色框是IoT的基础服务，最外面的是设备上提供的SDK，然后帮助这个设备去联网。最右侧那边可以是外部的应用，也可以是APP的应用，其次是有自定义的服务。中间看起来就是一个设备的安全的认证和设备链接的管理，提供一个通路、一个链接，帮助你把设备进行链接，其他没有了，这是对IoT的基本构想。

七牛架构师实践日

　　IoT的技术挑战
　　根据从我们的客户或者合作伙伴那边进行一年多的探索，包括我们自己对整个行业的认识，认为IoT里面的技术挑战其实不仅仅只是一个链接的问题，链接只是其中一小块，这里面安全问题是大家最关注的。如果你现在不关注，有一天你必然会关注，所以我觉得不如提前关注。怎么防止设备被伪造，怎么防止设备被别人窃取了之后，被我没有授权的人控制，怎么防止这些设备不会发起一个对云端的冲击导致设备无法运转，这是系统必须考虑的问题，不只是做一个设备认证就可以了，而是贯穿到整个技术体系中。设备的长链接管理要考虑这个设备是不是做认证，是不是合法可信的设备进入到服务中来，还要考虑用户对设备有没有控制权限，用户数据、用户密码和账号体系是不是完善的，这些是贯穿在整个体系中的。比如说账号体系、OTA怎么做管理，包括绑定关系，什么人具有什么角色、什么权限都需要严格的定义清楚。还有一部分是数据怎么做存储，IoT的数据跟互联网完全不一样，待会儿我们会展开来讲。
　　除了标准化、通用化的东西之外，我们还要提供一个完全不一样的产品，它的核心不是在账号体系是怎样的，不是在于绑定关系是怎样的，而在于它提供的内容，也就是非标准化的部分怎么体现，智能硬件云端智慧的地方在哪里，这是我们所有做产品的应该更深入思考的问题。关于APP账号和推送等，比如说我去淘宝、腾讯肯定不是因为账号有什么区别，而是看内容和自定义有什么区别。我们真正去运维、管理这些自定义组建服务的时候涉及到专业的问题，这些服务怎么架构和设计，每个模块直接的边界应该怎么划分，它们之间的关联关系应该管理。如果物联网发展成互联网那么大规模的时候运营怎么做，互联网里面最大的问题就是运营、版本依赖，这里面有没有什么思路可以帮助我们提前做一些规划，让大家遇到这些问题的时候可以借鉴这些先进技术解决这些问题，至少提供一些思考和帮助。
　　最后一部分就是数据的分析。我们看一个完整的架构，基本上是这样的，最底下是IaaS层，上面是PaaS层，比如说账号等这些东西都不需要做过多的产品上的深入的研究，更多的还是在SaaS这一层，怎么开发、怎么快速迭代产品，迭代云端的智能的逻辑部分。除此之外就是最上层，上层这一部分就是我的接入层，包括两部分，设备的接入和APP的接入，还有外部的控制台等。其次，考虑到未来互联网的架构肯定是云之间是互通的，我们要构造的是开放的。基于Google为对云的设想，认为所有设备都是为人服务，它不是一个设备，而是一个服务。基于这种设想，首先云是开放的，我的设备才是开放的。现在我们做很多硬件，比如京东、国美、苏宁都做这样的事情，我的渠道需要跟他的云对接，否则他们可能不允许在他们渠道铺货。
　　做一个简单的总结，架构分层主要是这样。首先是访问的接入层，这部分要考虑设备的安全性认证，第二部分设备接入要考虑负载性，考虑服务负载是怎样的，延时怎样、吞吐怎样，第三方面是流式处理。设备就是两个通道，控制流讲究的是实时、双向，数据流主要是流式的，一个是对资源消耗比较大，另外是对延时要求并没有那么强，可能要求100毫秒以内给我应答，但是用户没有要求那么强，1、2秒延时还是可以接受的。
　　除了云端还有一个是APP的，就是通用服务层，帮助账号绑定和消息推送等等的管理。其次是真正核心的部分，就是整个云端的架构最核心的部分，云端的逻辑、云端的智能怎么开发、怎么运行、怎么运维。
　　主要问题应对
　　接下来我会更细致的针对刚才提到的那些挑战和问题做一些总结，每个问题再稍微的展开一下，提一些我们常用的方法，大家可以去借鉴和参考。
　　1.多重安全保证
　　安全方面的保证，我的设备接入云端，云端要验证设备，首先设备也要验证云端，因为DNS劫持不是没有发生过，如果被劫持了，你的内容会流到别人的设备上。基于这一块的想法就是做RSA非对称加密。数据加密也有很多种，因为网络也不是可靠的，我们需要做一些认证。网络不可靠包含几个层次，一个是网络可能被别人攻击，别人的请求可能发过来，虽然不知道我的协议，但是数据可能会发过来，所以我们各个层次要做防攻击的准备，校验我们的数据是不是合法的。还有一个是设备的绑定，比如说最简单的方式，用户知道一个ID就可以做绑定，这种方式肯定是不安全的。比如说我随便把你的设备ID变一下，所以就要考虑绑定码的机制。一个是设备上，被云端激活之后，云端给他一得动态的绑定码，APP绑定的时候通过局域网做通信拿到绑定码，如果这个人没有对设备完全控制拿不到这个绑定码，这个绑定是时效的。还有给设备办法一个P码，你要知道这个设备跟P码是怎样的一一对应管理，防止被误绑。一般设备不是某一个人的，而是家庭里所有成员能共享的，所以必须要有分享机制，分享的时候绑定码要有时效的考虑。
　　认证访问请求方面，首先是认证所有访问请求，在访问层确保所有用户都是可信的，要验证用户是不是有访问控制权限。其次要保证这些数据，这些数据包括账号，账号和密码不能被泄露，如果是明文存储的，一个是损失了用户其他的系统安全性，另外是伪造成这个用户对你所有的设备进行影响。
　　2.分布式长连接管理
　　长连接管理方面，这个话题不是所有智能硬件都需要的一个问题，只有这个设备需要被反向控制的时候才需要长连接的管理，如果没有用户控制或者没有动态的控制的过程可能不需要，只需要这个设备能够联网，在需要上传数据的时候跟云端建立连接不需要长连击，大部分情况下，无论是智能家居还是其他都需要长连接管理。目前互联网情况下你的设备IP不固定，因为有多层路由，还经过防火墙，所以一种方法是通过设备跟云端维护长连接，既可以做数据的上传，也可以从云端找到这个设备，给这个设备下发一些控制。这里面要考虑的问题是可扩展性，当我有十万台的时候可能随便写一个程序，长连接维护不是那么困难的事情。但是我是常年维护，很多设备不是使用一年、两年就坏掉了，所以我要考虑长远发展，可能百万、千万级的设备都是可能的，所以最早写这个协议的时候一定要考虑扩展。现在的通用扩展有两种，水平扩展和垂直扩展。水平扩展是购买更多的机器来承载更多的负载，通过负载均衡的方式保证这个系统随着设备规模增加不用改任何程序，设备不用做任何升级。还有一种方法是不断的买更高性能的机器，这种是比较有短见的方式，而且是成本比较高昂的方式。互联网都经过了这样的发展路径，最早是单机，过不了半年发现单机不行，然后做主备，然后主备不行做分布式，最后做一个最终的扩展性。
　　我们做可扩展性、分布性的目的还是更高的可用性。当规模和集群越变越大的时候，所有时效可能性就越变越大，当集群里面某一些台设备发生故障的时候不能影响用户或者降低对用户的影响，所以要考虑怎么做时效的转移，设备和云端怎么处理，这些都要考虑。
　　另外是防攻击，在云端出现极端异常的时候怎么做降级，就是保证功能是基本正常的，保证用户的体验保证一部分的满足，总比完全瘫痪好很多。其次是高效能，肯定要考虑节约成本，如果一台机器只能承载十万台设备，我到一百万、五百万的时候，机器的成本也是非常高昂的，所以我们希望单机支撑百万级的PC机，我们验证过，我们做到两百万。讲这个数字是说，大家构建云平台的时候这也是可以作为一个基数。
　　3.设备TCP长连接管理
　　简单讲一下长连接怎么做负载均衡和时效转移。首先，这是设备端，直接的做法是通过TCP连接，我们叫Gateway，就是一个网关，跟它进行长连接，防止设备异常断电和云端断电，所以要维护协调。怎么做扩展呢？就是通过一个Scheduler，相当于负载均衡的模块，这也不是单点的，如果是单点系统性、可靠性也没有那么高，所以这也是多点部署的，比如说我们通过DNS连接，通过它拿到一个真正的接入点，Gateway的连接信息，后面是在这上面做维护。Scheduler相当于Gateway的管理者，需要动态的拿到活着的位置。通过这样的架构就保证设备不断的增加模块就可以了，让设备通过负载均衡的方式按照连接数最小或者延时的分布去做负载均衡。这里面不展开了，里面有很多可以参考的东西。
　　4.云端存储
　　接下来就是存储的问题，大家知道一个应用里存储是瓶颈，或者说迟早是瓶颈。所有的计算、带宽都可以通过扩展方式解决，即不断增加服务器，但是存储是一个单点，所有的产品都会落到存储上。IoT和互联网最大的区别在哪儿？互联网是读多写少型，IoT则是反过来的，用户看这个设备的数据没有那么频繁，或者用户都不会看原始的数据，只需要看汇总的数据、云计算的结果，而不是原始的数据。用户看到的数据量或者他看的频率实际上没有那么高，设备是7×24小时不间断，而人总有4万秒休息的时间，所以跟互联网是完全不一样的。这种情况下我们怎么选择存储？用传统的那种引擎肯定是不合理的。这里推荐一种LevelDB的解决方案，它是基于IoT的模型做优化，是写入密集型的存储。最早提出这个模型解决的问题是什么呢？既然要解决写入密集型的预算，对写入的延时要求是非常低的，这样单次的延时变小了，我的吞吐才能承载这么多设备同时并发的写入，所以优化写。传统的磁盘对顺序写是友好的，对随机写是不友好的，一块盘承载的每秒钟的写入量是160次，假设有一百万设备，设备每一分钟传一次，你想象一下这个每秒种写出来至少有上万，接近两万。两万是什么概念？Twitter两三年前最高峰也就是三四万，所以这个很难想象。两万是一个什么概念？我们放在一天就是几亿的PV，在百度一天也就是几亿的PV。如果我们的设备量真正到达这样的规模必须要考虑这样的问题，而且我们有很多厂商经过半年的发展就已经遇到了这样的问题，有很多数据存储方面遇到很多问题。如果你是考虑做这样一个产品，有数据存储的需求，需要考虑这样一个选型的问题。
　　继续回到这个模型，所有的写入都没有随机写，都是顺序写，因为对顺序写是友好的。顺序写主要考虑吞吐的问题，没有旋转、延时这些问题，所以可以做一个合并，合并以后再顺序写到磁盘上。内存的数据首先冻结，这些数据顺序写到磁盘里，它是一个新的文件，不存在随机写入。底下做了很多分层来优化它的写，如果不做分层，所有内存文件不断的打开，相当于一个一个的模块，每一次把内存里面相同行的写入合并到一行，这样就造成读一个数据的时候需要回访历史上所有的块才能找到真正的数据，所以要做优化，要把小块的文件合并成大文件。本来需要读五个文件，现在合并到一个文件里面，这样只需要一次就可以了，所以性能也是足够的。它的缺点是读会慢一些，因为毕竟还是要写到磁盘上，还是要牺牲一点读的延时性，来保证它的写入是高效的。
　　刚才讲到的其实还是一个单机的问题，就是怎么提高单机的存储，你做一个存储引擎的选型来保证单机的写入性能是最高的。但是我们发现单机肯定也是不够长远的，淘宝也好、百度也好都经过了这样一个过程，所有的数据库经过一段时间之后都得做分片，搞成一个分布式的写入。而且这里面有很多的坑，基本上做一次数据的调整、做一次分片，整个研发部基本上半年甚至一年时间都没有任何进展，因为这里面有数据的迁移和校验等非常复杂的事情，看起来是简单的架构调整就完成了，实际上工作非常多。我自己切身的体会，在百度我们做广告库的分片，做了至少半年。在阿里做分片的时候基本上做了一年多，因为阿里是纯粹的业务型公司，对数据库依赖非常高，业务逻辑非常复杂，所以做梳理是非常耗时间的，而且坦白讲这个事情对公司是没有任何价值的。所以，我觉得大家在第一次选型的时候就应该考虑这样一种架构，我们对数据自动做分片。分片解决两个问题，一个是读可以做扩展，一个是写做扩展。所有的写入都可以在每一个分片上做，这样的话我的写入吞吐可以成倍的增加，而且延时肯定比单机还要好。单机还有一个问题，很多数据库都有一些限制的，比如说有的单秒存储有限制，当超过两三千万的时候性能会出现急剧的下降。
　　另外，基本的模型是这样的，首先最外层是查询的接入层，所有的客户端无论是通过SDK还是通过客户端上自己做一些路由，然后到QueryRouter，这上面所有的分片都可以看到，这个就是做数据的路由，它的状态可以任意扩展，只要客户端能访问到这个结点就可以了。还有一个是QueryRouter是所有请求都经过它，它可以做更多数据，这一层可以做更多缓存，比如说只服务一二三结点，这上面的缓存只有一二三的，如果做所有的，这上面的缓存会降低很多。NoSQL大概是三年前兴起的，这种模型有好处，它的模型非常简单，它是没有任何模式的，不需要像数据库那样优先定义所有的字段和类型。另外是可扩展性强、性能高，它的性能高的原因是什么呢？它把本来服务器做的事情交给客户端，比如说不做索引和预算，纯粹提供就是单纯的数据存储，专注于存储方面的东西，你需要在上层做更多的预算。当然这也是一个趋势，因为也会发现我们的应用性降低了，因为这个很容易写，很容易被大家利用起来，所以慢慢往这方面转型，开始往上层做SQL这种类型。对于大部分业务型的数据，比如说账号这些用SQL型的也够了，就没有必要用NoSQL，毕竟它是一个新的东西，而且有很多程度没有那么高，尤其是出问题的时候很难把这个东西完全驾驭，所以要适当的做一些选型，根据不同业务的复杂度做一个选型。
　　5.微服务架构设计
　　数据存储讲完了，剩下的就是核心的关于智能硬件本身业务逻辑的部分应该怎么做架构。除了通用的服务，剩下的就是自定义的服务，这些服务也会越来越多，一个庞大的系统，一个智能硬件需要的后端是需要大量的非通用的服务做承载的。这些服务之间怎么去定义边界，怎么去做服务的一些定义？这些是我们在做架构的时候必须考虑的，包括模块之间的依赖关系是什么样子的，当服务越来越多的时候怎么做运维，服务之间的依赖怎么梳理，我怎么判断哪一个模块出了问题或者结点在哪儿、怎么快速响应，这是越来越头疼的问题。还有一个最头疼的问题，我管的服务越来越多，每次要做服务器的更换或者服务器的迁移，每次还要重新做一些测试，因为用的机器可能完全不一样，有没有一种机制让我测试一次，然后把它分发到任何一个结点上都可以和我期望的运作模式是一样的，有没有这样的技术来帮助我们。
　　这里是我们提供的一个微服务和基于Docker容器化的方式解决刚才提到的几个问题的。Docker本身是一个容器，它的好处是可以在机器上虚拟出一些，不论物理依赖的环境是什么样的，我可以虚拟出一个一样的环境，在这个基础之上做操作版本，这样可以把服务和环境打包，通过容器把这些服务一次性的加载起来，保证在任何一台机器上所有的运行环境一致，这就解决了运维人员非常头疼的问题。
　　其次微服务跟我们的架构没有太大关系，之所以在这里讲就是因为微服务在互联网公司里面都是非常提倡的，但是“微服务”这个名词互联网架构里面不会提，因为大家都觉得这是理所应当的，没有什么新鲜的事情。为什么这个名词近两年又火起来了呢？因为它要进入非互联网公司企业，这种理念一定要给到大家。做编程的时候要知道模块怎么划分类，怎么去写这个类的职责，包括基本的原则怎么在代码里体现，这样来保证我的服务是稳定的、可测试的、能够容易可读的，这样的思想上升到另外一个层次就是服务，把所有模块拆成服务，每一个服务都依赖于以前在编码层次的经验，来保证每一个服务是简单的、功能独立的，同时这个服务是任意升级的。我在做小的服务升级的时候以前可能需要做大量回归验证，可能不知道影响到底有哪些，做起来可能影响很大，但是通过这种微服务把所有服务做很好的拆分，每个服务交给不同的团队，只需要这个团队专注自己的业务，有一些相对的明确接口也可以绑定。
　　怎么做容器化的管理呢？从这幅图来讲，前面是集群化的管理，这里是最简单的Docker的框架。首先它是基于Linux，在这上面用户可以自己在上面做一些开发，把这一整套可以做一个运作。Docker可以提供一个统一的运行环境，还有一个好处是资源的地方率很高。在BAT里面最前端的承载大家的所有网页浏览等常规操作的时候是第一层，这一层是无状态的，所有的业务逻辑都需要路由到后面一层，所以前面的CPU利用率都不高，非常低。无论是腾讯还是阿里，都是靠容器化的方案。当然最早的时候Docker还没有出来，都是各家公司做一些开发提供类似的方案。Docker现在已经开始被大家所接受了，而且从前年开始已经逐渐慢慢的成熟，有好多大的公司已经把这个技术引进来。
　　七牛架构师实践日Docker解决了单机的问题，但是我考虑到一个系统肯定是一个集群，这个集群怎么做管理，当机器挂掉之后怎么做管理，怎么把负载均衡和时效转移到其他机器上，这就涉及到集群管理的问题。基本上就是这样一个思路，首先有一个服务发现，这个agent是在一台物理机上有一个容器，然后把这些容器统一汇集到Schedule这一层，然后重新分布到另外的ETCD模式，然后收到中控结点的命令，然后收到命令之后会重新加载agent。这里面有一个储备的选取，保证Schedule这方面是高可靠的服务，因为任何一个点都可能down掉，所以需要有这样一个机制。
　　最后，在服务管理、运营管理上还要考虑怎么做调度、怎么做扩容。当服务是无状态的时候，可以通过Docker容器把服务加载起来做水平的扩展，应对更大的流量、更大的负载。其次，我的版本如何管理？是不是所有的工程师写的程序都要自己去操作，SSH到一台机器上做部署，写那么多配置，其实我们完全可以有一个方案做可操作的界面，用户直接上传，由这个系统来选择在哪台机器上做部署、做监控，都由这个系统来做。
　　6.大数据分析
　　最后一部分是数据分析，由于时间关系不做太多展开。IOT的数据肯定是越来越大，因为它是机器产生的数据，不是人产生的数据。当然用户的数据也有，所以这个分析模型比互联网的模型还要复杂，不仅是用户的数据，还有机器的数据。数据分析包含几层，一个是怎么做数据的收集和采样，另外一个是数据的存储，这个存储跟刚才讲到的业务分布式存储不太一样，分布系统处理的数据规模比在线的应用多很多，所以在存储选型上一般选择列存，一般可以把数据做很好的压缩，把相同列的数据存储到一起。相同列的数据一般来讲具有很好的特新，所以压缩比非常高，占用的磁盘空间就小，当读取数据的时候在磁盘上的空间也比较小。
　　大数据分析引擎架构有几部分，首先是有一个可视化的api，然后还有一个分析模型，包括漏斗模型等等，在这个存储之上还可以做一个缓存。存储层写入是比较密集的，列存写入效率不是特别高，就通过做消息队列的模型，这样跟我们刚才讲的模型一样，可以把写入效率提高。其次，可以把数据通过内部处理写入到最终的列存里面。最终就产生了这样一个可视化的效果，可以做地域分析、用户行为分析，也可以做设备活动状态的分析、故障率的分析，这样来指导我的产品、指导我的硬件后面怎么做迭代层、怎么做升级，包括知道用户喜欢用什么功能、用户在什么时间段喜欢用这个功能，知道后面营销策略针对哪些地域作为重点。
　　七牛架构师实践日谢谢大家！