操作命令

在智能化、自动化的趋势下，智能家居行业迎来了飞速发展的时期，而众多企业的入局也使得本就火爆的智能家居市场持续升温，同时，随着消费者消费水平的不断提高和消费观念的快速转变，智能家居朝着个性化、时尚化发展的趋势越来越明显。全球市场研究与咨询机构StrategyAnalytics最新发布的研究报告《2018年全球智能家居市场预测》指出，2017年全球智能家居市场规模达到840亿美元，较2016年的720亿美元增长16%。2018年全球智能家居设备，系统和服务的消费者支出总额将接近960亿美元，并在预测期(2018年至2023年)的复合年增长率达到10%，达到1550亿美元，其中亚太地区将达260亿美元。同时，据IDC统计的数据显示，2017年，全球智能家居设备出货量达4.331亿台，比上一年增长27.6%。同时，IDC还预计到2022年，全球智能家居设备市场出货量达到9.397亿台。这表明全球智能家居需求量增大，发展前景广阔。大数据时代不容忽视的信息安全风险

尽管智能家居需求量在不断增大，但其在应用中暗藏的信息安全问题却不容忽视。家庭是一个可信任的隐私区域，酒店是一个半信任的半开放区域，而互联网则是一个不可信的开放区域，当数据从互联网的开放区域进入到家庭或酒店等区域时，如果没有安全的防御策略与手段，风险也会随之入侵。目前智能家居中存在的安全风险主要有以下4类：

数据传输未加密或简单加密，导致用户信息泄漏。(比如：传输到云端的数据被截取、复制)客户端APP未安全检测，相关代码存在漏洞缺陷。(比如：通过漏洞取走用户的账户、密码等)硬件设备存在调试接口，使用有安全漏洞的操作系统或第三方库。(比如：入侵设备，劫持设备应用)远程控制命令缺乏加固授权，存在非法入侵、劫持应用的风险。(比如，摄像头被非法入侵使用)为了方便人们对智能家居的使用，让人们随时监控操作智能化产品，大多智能家居产品都是通过云端远程发送控制命令来实现人们对智能家居产品的控制，而恰恰是这种方便的手段，由于缺乏安全防御手段，可能就会给智能家居的带来了巨大的风险。如何实现智能家居产品安全防御

提高智能家居产品的安全性需要时间的检验。一方面需要提高智能家居产品企业管理者与设计者的安全意识，尤其是企业管理者的安全意识，让智能产品在开发的过程中，不仅仅关注产品功能和用户体验，而更应该加入安全防御手段，为用户的安全风险考虑。另一方面，从用户本身来讲，智能家居产品使用的安全意识也有待提高，很多用户只关注产品的功能和使用的便利性，但不愿意为企业提高产品安全性而增加的费用买单。这样的恶性循环，导致厂家与消费者在产品的安全防御上都没有动力，一旦出现安全风险事故，就悔之莫及。值得注意的是，我国相关的信息安全法律法规及智能家居行业管理机构要加强对智能家居产品安全的保驾护航力度，我国去年颁布的《网络安全法》充分体现了政府和人民群众对网络安全的要求。智能家居行业管理机构也应该加强对智能家居企业的沟通与监管，为智能家居使用者的信息安全保障护航。对于智能家居企业而言，若想在智能家居蓝海中占得一席之地，首先就要解决产品的安全防御问题，以此才能让消费者在享受智能家居带来的便利的同时，不用考虑信息安全问题，获得消费者的忠诚度，增强企业的品牌影响力。

随着互联网的发展，越来越多的业务不仅仅由单一节点（或是单一语言）就可承载，而是趋向多语言分布式协同开发（如接入层由Node.js完成，逻辑（数据）层由C++/GO/Python实现）并由此组成大型异构系统。

我们（现SuperTeam）基于 Tars 体系研发出 Tars.js 以便用户在不改变异构系统整体架构的情况下快速搭建（迁移）Node.js服务，并可非常方便的将原来的单一服务拆分为多个（逻辑）子服务。

Tars.js在腾讯内部经过5年多的沉淀与迭代（Node.js@0.10版本即提供支持），广泛运用于腾讯QQ浏览器、腾讯桌面浏览器、腾讯地图、应用宝、腾讯手机管家、互联网+、腾讯医疗、腾讯觅影、保险、彩票等几十个重要业务中，日承担了上百亿流量。

Tars.js包含下述特性：

l 100%由JavaScript编写，不包含任何C/C++代码。

l 多进程负载均衡与管理。

l 代码异常监控与重启。

l 服务日志搜集与处理。

l HTTP(s)服务监控与用量自动上报，并支持用户自定义维度上报（PP监控）。

l 符合 Tars(IDL)规范的编解码模块。

l 支持 TarsRPC调用与染色（模调自动上报）。

l 支持在线发送管理命令、拉取服务配置。

l 独创 LongStackTrace™异常跟踪机制。

l …… 更多特性可访问 @tars/node-agent 了解

设计理念：

»A．高自由度：

l 兼容所有（≥0.10）官方Node.js版本。

l 对 Node.js源码无侵入无修改。

l 底层对上层完全透明，支持各种上层框架，无需变更。

也就是说：

您可以使用任何您熟悉的框架（如 Express.js/Koa.js等，包括但不仅限于Web框架），也无需对框架进行任何修改（无需引入任何中间件）。即可通过Tars.js运行，享受平台提供的各种监控与管理特性。

与此同时，Tars.js所提供的模块，也可以根据您的需求引入（如未使用到则可不引入）。

»B．高性能：

Tars.js为高性能与大并发量而设计，使用了大量的前端（V8）优化技巧（如FlattenString/FastProperties等）尽量降低所提供的能力对于业务性能的影响。

经过我们测试（WebServer），默认的旁路上报与监控对服务性能的影响≤5%，常用模块（RPC、日志等）性能位于业界前列。

»C．差异化：

Tars.js根据不同的业务类型提供差异化运营方案：

l 高流量业务：尽力降低框架对业务性能的影响。

l 低流量业务：充分利用硬件资源提升开发体验。

HelloWorld

我们来看Node.js官网的 例子 (如下)，无需任何变更，直接通过Tars.js进行部署，它会拥有哪些特性？

✓ 进程管理

默认基于 cluster 模块进行负载均衡，进程数可以配置为1~max（CPU核心数）、还可配置为auto（物理核心数相同）以减小内存压力提升“性价比”。

与此同时，进程僵死检测也会同时启动，实时监控业务进程。

»案例说明

某服务在论坛UBB代码转HTML时，使用未优化的正则表达式进行XSS攻击过滤，但由于用户发帖时图片采用BASE64编码，导致正则表达式计算时间过长，CPU使用率飙涨到100%：

开启僵死检测后，Tars.js监控到业务进程僵死时，自动重启业务进程，从而缩短了业务无响应时间：

Tars.js虽然无法解决业务代码的问题（BUG），但会尽最大努力保证业务的可用性。

✓ 服务监控

以服务名、接口名（URL-PATH节）为纬度，统计总流量、平均耗时、超时率、异常率：

其中返回码大于400（可配置）作为异常进行上报。

»监控说明

Web服务一般由静态与动态资源（接口）组成，由于静态资源（本地文件）的请求耗时远低于动态资源（业务逻辑），请求量往往又很高，拉低了服务整体耗时。

基于此，Tars.js将请求URL中的PATH节作为接口，每个接口均可查看其总流量、平均耗时、异常率，便于用户全面了解服务性能。

✓ 特性监控

无论您服务的类型是什么，总是会上报下述特性，便于回溯问题与评估性能：

l memUsage：内存用量，将会上报rss、heapUsed、heapTotal这三个用量（单位为字节）

l cpuUsage：CPU用量，将会上报CPU使用率，数据汇总为逻辑单核（单位为百分比）

l eventloopLag：（任务）队列延迟，每隔2秒采样（单位为毫秒）

l libuv：I/O用量，将会上报activeHandles、activeRequests这两个用量

各策略以平均值（Avg）、最大值（Max）、最小值（Min）分节点进行统计：

✓ 日志输出

所有通过Console模块（如console.log）输出的日志，都会输出到服务本地文件内。并附加相关信息（如下），方便定位问题。

日志格式：日期时间|进程PID|日志级别|输出文件名与行号|日志内容

2018-07-0112:00:00|332|DEBUG|app.js:13|Serverrunningathttp://127.0.0.1:3000/

✓ LongStackTrace™

由于Node.js采用异步机制，在发生异常时堆栈不完整，导致定位问题复杂。

鉴于此，我们提供了长链路跟踪技术在产生异常时自动附加前序调用堆栈，同时还支持在异常堆栈中过滤出用户代码部分。

由于开启此特性时会造成性能损耗，故默认关闭，管理平台等性能不敏感业务可直接通过配置开启。

»案例说明

执行上述代码会抛出下述异常：

ReferenceError:ThisMayThrowErrorisnotdefined

atTimeout.setTimeoutas_onTimeout

at_disibledevent="http://superzheng.com/">@SuperZheng 创立于2017年。团队成员均为全栈架构师（Super寓意Superman——无所不能），熟知Web(3D)、终端、后端与大数据计算，并由传统前端向互联网从业者方向发展。欢迎前端牛人加入，共创前端美好未来。