分类： 未分类

随风

近几年物联网飞速发展，市面上也出现了很多物联网操作系统。比较有名的有rt-thread，tencentos-tiny以及鸿蒙等。这些物联网系统各有差异，这符合物联网碎片化的生态现状。下面我将以tencentos-tiny为例子分析一下目前物联网操作系统的一些特点。

打开tencentos-tiny的官网，映入眼帘的是比较熟悉的代码结构。分别是内核，驱动，网络以及一些辅助的工具，这和大多数的嵌入式操作系统是类似的。

我们再来看看下面这张图。

这张图是tos系统官网给出的架构，可以看出它的模块化设计是非常优秀的。内核只包含了最为重要的特性，即任务调度，时间以及内存管理，以及ipc通讯的组件。而物联网的工具箱则被放置于内核之外。我们用vscode阅读一下它的内核源码。

可以看到它的确非常的精简，每个功能的实现代码有些甚至只有几百行。这样精简的实现，使得它可以轻松移植到stm32f1这样的芯片。

但是如果进行全量移植的话，f1这样的芯片内存空间仍然不是很足，但是tos系统可以轻松的裁剪，移植的体验也非常不错，如果你不需要其它的功能的话，你只需要把kernel和arch目录以及tos_config复制到你的工程就行了，当然你还得进行一些微调，比如系统时钟脉冲设置，但我花了一些时间也就顺利移植成功了。

可能到现在你有个疑问，stm32真的有必要使用操作系统吗？的确，裸机编程能满足大多数场景了，但是如果你想实现实时性很强，任务又非常多的话，使用操作系统的确非常便捷。tos系统采用了抢占式的任务调度。高优先级任务就绪的时候会立即打断低优先级的任务。相同优先级的就是使用时间片调度。这样能保证高优先的任务能优先被处理。tos系统还提供了任务之间通讯的机制，互斥锁，消息队列以及事件机制。这使得基于任务编程成为轻松的事情。否则的话你就只能一个循环加中断或者dma等。这样的cpu利用率以及响应速度都并不能让人非常满意。

tos系统如果仅仅有上述任务调度功能，它就不能称为物联网操作系统，而顶多叫做实时操作系统。tos系统提供了非常强大的网络工具，可以兼容esp8266等众多芯片，提供了一个统一的at指令框架以及各种协议栈的支持。都说抽象是软件的灵魂。tos系统实现了at指令的抽象框架到sal层的抽象框架，从而虚拟出socket接口。有人觉得这不是多此一举吗？这当然不是，实际上这个设计和“一切皆文件”是有异曲同工之妙的。不过由于tos系统是腾讯开发的，它当然要给很便捷的api给自家的iot平台，但这些工具的确方便了物联网的开发。下面引用一下腾讯知乎的一张图，它清晰地阐述了sal接口的好处。

不过说了这么多，sal接口对我的吸引力并没有那么大，实际上我们使用的通讯芯片一般都是确定的一种，并不太可能替换另外一种，但是移植这抽象层占用的flash空间又是真实存在的，因此我倒不如直接at指令来的方便。

物联网操作系统的产生屏蔽了纷繁复杂的物联网硬件，提供了一些较为统一的接口，据说鸿蒙还提供了分布式软总线，但我还没有看过。但是我感觉只靠这样的一个操作系统就能一统江湖，估计还是任重道远。不过我发现了一个有趣的现象，人们正打算在物联网操作系统中提供js引擎。我觉得这个技术未来确实有比较好的前途。我们下次再讨论一下js引擎对于物联网的影响。

最后来个传送门，祝大家元旦快乐。

随风

java曾经的确是风光无限，现在也依然热度不减。但眼下的java的确已经面临了严峻的挑战。java语言曾经的面向对象特性和虚拟机特性使得它非常适合大规模的上层应用，更重要的是它是跨平台的，一次编译，到处运行使得java空前成功。

java不是跨平台的第一人，但绝对是那个时代做到最优秀的。在开发简易程度和性能上做到了良好的平衡。但是令人想不到的是，随着科技的发展，那些曾经的独门武功竟然成了巨大的绊脚石。

jvm成就了java。jvm是一种hotspot虚拟机。如果你对jvm有所了解，你一定会惊叹它的博大精深和设计巧妙。jvm的存在，产生了一大批jvm语言，这是因为jvm其实是语言无关的。jvm语言著名的有kotlin,groovy和scala。你只需要实现字节码规范，你就可以驾驭jvm。这为jvm生态打下了坚实基础，同时jvm的jit编译器极大的改善了性能，使得java语言效率远高于python。jvm的线程模型也非常不错，这比python解析器可要高级得多。jvm还有出色的垃圾回收器，你可以用指令选择不同场景下的垃圾回收器。包括串行的，并行的。以及最新的g1垃圾回收器和zgc回收器。这些垃圾回收器已经满足绝大部分场景。基于最新的JDK15来看，“停顿时间不超过10ms”和“支持16TB的堆”这两个目标已经实现，并且官方明确指出JDK15中的ZGC不再是实验性质的垃圾收集器，而且建议投入生产了。

但是风水轮流转，云原生时代的到来，使得java瑟瑟发抖。那些引以为豪的优秀特性变得不再重要，首先是一次编译，到处运行。现在但凡新一点的语言，跨平台已经成为标配，而且不需要拖着一个沉重的jvm。加上docker的流行，环境已经不是什么问题了。在无服务器应用则更惨了，无服务器应用弹性伸缩，依赖于函数模块的快速启动，而jvm启动需要预热，因为jit需要一定的预热时间，加上类加载的设计。这一下好了，启动速度直接龟速。 如果写过springboot你一定对它的启动速度印象深刻。隔壁go语言的启动简直是快如闪电啊。第三就是面向对象机制，使其适合大规模的编程，可惜随着微服务的流行，人们已经不再追求巨石应用，而是切分成一个个小应用。java冗长的语法，怎么比得过函数式的程序语言呢。最后是高并发场景，这是java当年的强项。java凭借着优秀的高并发支持而流行。但是如今它一对一的线程模型加上各种复杂的锁机制，导致新手根本无法上手。而隔壁nodejs根本就是单线程加事件循环，实现了巨大的吞吐量，不需要锁机制，加上js天生容易掌握，java再次完败。

但是java是否就此停止挣扎了呢，当然不可能。java世界看到了威胁，正开始准备一个超级大招-graalvm。有了它我们就不需要jvm这个累赘了。https://www.graalvm.org/

graalvm的官网映入眼帘的就是高性能，云原生，多种语言。下面排着各种语言的logo。这不免让人疑惑，难道它所有语言都支持。不错，它几乎全支持我们常见的语言，这使得我们多种语言互操作变得十分简单。它最重要的功能当然就是解决java的弊端。它实现的java编译为本地二进制代码。双击就能够运行。从而实现了高速启动，使得Java不至于在云原生时代无所适从。配合springnative，你就能实现java云原生场景的快速启动。

graalvm 的设计是令人惊叹的，java不是一种满足封闭原则的语言，它带有很强的动态性。如类加载机制。这些难以通过静态编译实现，但是 graalvm 有自己的独门武功，可以通过多次运行辅助分析出程序里的动态部分。限于篇幅，这里就不再赘述了。

这篇文章涉及到了较多的新名词，但只要阅读了cwl公众号的那篇云计算时代的文章应该还是对这些新名词有一定了解的。这里立一个flag，下篇文章带大家实操 graalvm ，体验一下云原生java的魅力。

最后来个传送门

随风

物联网发展到了今天，可以说是有了长足的发展。各大科技公司的公有物联网平台纷纷上线，也提供了许多不俗的功能。不过人们也开始发现，物联网时代似乎仍然离我们很远，那究竟是什么阻碍了物联网的发展？

很多人第一印象觉得是算力，通讯技术和电池技术的约束。这样认为也不是没有道理。算力，通讯技术和电池技术确实是物联网技术之中很重要的一环。通讯技术决定了物联网产品是否能够稳定地进行信息传输，算力决定了智能设备的信息处理能力。电池技术则决定了设备的续航时间。但是约束物联网发展的也许并不是这些，而是我们究竟能用物联网做些什么，以及使用物联网究竟能带来哪些根本性的好处。

目前大多数的公有云平台事实上是to c模式的。保罗万象，偏向于监控生产过程。然而实际上我们需要的恰恰是垂直应用场景，也许是智能家居的或者是工业互联网的。智能家居事实上已经比较成熟，但在工业应用物联网上仍然存在不少硬伤，稳定性以及业务多变性。就像蓬勃的互联网一样，不存在一种互联网产品能满足所有需求。互联网只是一个概念，物联网也如此。因此需要有出色的物联网应用，方能发挥物联网的最大价值。而目前物联网应用开发的生态还很薄弱，缺乏相应的框架系统，大部分仅仅只是mqtt实现库，缺乏业务级别的支撑。因此开发者不得不自行设计业务框架。这无疑耗时耗力。

物联网的中间件以及相应的开发模式仍很贫瘠，大部分物联网项目的终点是监控，这无疑难以发挥它本身应有的互联价值。设备之间的联动仍然是难以像设想中的那样完美。资本是逐利的，连接量的提升并不能直接像互联网场景那样获得巨大的商业价值。因此物联网的商业模式并不能直接复制互联网的模式，物联网时代是属于创新者的，创新者将会赢得最后的胜利。

java语言的null大概就像c语言的空指针一样非常讨厌。特别是业务复杂的时候，多层判断简直让人抓狂，kotlin语言就针对这个问题进行了优化。那么作为java语言的编程者是不是就坐以待毙了呢？当然不是。我们可以使用Optional进行优化。

先强调Optional并不能消除null，这是不现实的，也不必要。在不复杂的场合，我们直接判断就可以了。Optional本质上也不是什么黑魔法，它就是一个容器，跟arraylist是一个性质的。因而可以得知，使用它必然产生一定开销，如果是算法比赛这类场景那还是建议不要用了，毕竟输入输出我们都希望多快好省。

Optional作为返回值是非常理想的选择。聪明的你撸了一个非常好的类，但在Optional还没出现之前，你不得不使用null作为某些情况的返回值，最终使得使用者相当抓狂。Optional作为返回值，可以摆脱这一噩梦。业务上需要空值时，不要直接返回null，可以选择使用 Optional.empty()。使用者使用Optional#ifPresent就可以比较好的减少null带来的困扰。

随风

随着摩尔定律日渐失效，多核心编程已经是不得不面对的现实。而java从一开始就设计成了一种支持多线程的语言。那么我们如何使用java来进行多线程程序的编写呢？很简单，一般来说，在java开启一个多线程，我们有三种方法，这几种方法使用场合不一样，并没有孰优孰劣。

1.继承Thread类，这种方法很简单，但是java是单继承的，这阻碍了你业务的继承扩展，因此并不适用于需要继承扩展的场合。

2.实现Runnable接口，这种方法比较灵活而且简单。后面文章也主要使用这种方法。这种方法只需要实现run方法就可以轻松创建一个线程。

3.实现Callable接口，这种方法功能最为强大，可以在任务结束后返回值。call方法还能够抛出异常。而run方法并不能返回值。

下面是创建线程的简单例子。

package com.company;



class MyThread2 implements Runnable{
    private static int count = 0;// 计数器

    @Override
    public void run() {
       synchronized (this) {
           ++count;

           try {
               Thread.sleep(1000);
           } catch (InterruptedException e) {
               e.printStackTrace();
           }
           System.out.println(count);
       }
    }
}
public class test {
    public static void main(String args[]){
         MyThread2 myThread2=new MyThread2();
         Thread t1=new Thread(myThread2,"t1");
         Thread t2=new Thread(myThread2,"t2");
         Thread t3=new Thread(myThread2,"t3");
         t1.start();
         t2.start();
         t3.start();
    }
}

可以看出创建一个线程还是相当的简单的，但令人头疼的其实是线程同步问题。上述代码中++count并不是一个atomic操作。实际上包含了查询，+1和赋值操作，这样的结果就是在并发中会产生所谓的线程同步问题，读者可以试着把同步字段删除。这将会导致结果为333，这与设计的初衷就发生了违背。为什么会这样呢？原因很简单，sleep的时候线程将会被挂起，这样其它线程就会相继进行++count操作然后也被挂起。最后输出的当然是最终的数值3。因此如果我们需要使其线程同步的话，我们需要加上互斥锁，通过锁的竞争确保其同步。但这样的代价是多线程实际上退化了。这样就导致了性能实际上没有提高，反而由于上下文切换等下降了。

可能读者会觉得这样一段小代码没有什么实际用途，其实这种想法是错误的，java springboot controller实际上是单例多线程的，因此如果我们在@controller下使用全局变量将会导致跟上面一样的错误。如果我们做的是购物系统，那么很遗憾，你这个系统将会产生超卖问题。当有人可能会说，我们呢平时crud也没感觉要加锁，其实数据库的事务本来就是atomic的，所以并不需要加锁。因此我们技术人要感谢前人的努力，才使得现在做一个web应用如此简单，但是简单的背后却是tomcat和spring全家桶这样的大黑箱。如果我们不努力研究黑箱的本身，那么最终我们就只能是一个crud程序猿。

最后卖个广告，创万联新一代物联网平台正在火热建设中，其中包含了大量的优秀特性。更安全，接口更加规范，极大提高了“柔性”程度。平台跟项目绑定的时代也许将要彻底告别，我们欢迎各位开源人士的加入，你们的加入是我们组织的福气。让我们共同迎接aiot和数字孪生的美好未来。

随风

go语言有21世纪c语言的美誉，实际也表现出了极好的性质。go语言具有轻量级的协程goroutine，能轻而易举地实现数万并发。并且可以真正多核并行，充分利用cpu。语法明快，使用起来没有臃肿和历史包袱。标准库文档齐全而且极易阅读。

在爬虫领域，人们使用最多的当属python，python有数不清的爬虫库。以至于人们几乎把python等价成了爬虫专用。似乎人工智能和数据科学领域也如此。实际上，无论是人工智能还是爬虫，它们都是一种算法或者说是一种技术手段，使用什么语言其实影响并不大。

什么是爬虫？爬虫违法吗？爬虫用一句话来概括就是the website is the api。爬虫程序利用网络请求或者selium一样的模拟点击自动化测试工具来获取互联网上的海量信息。百度等搜索引擎其实也是这样做的，所以爬虫技术本身其实并不违法。但是造成了网站服务器崩溃以及其它恶劣影响事件则有可能会违法甚至犯罪。

go语言有强大的net库，本身带有cookiejar等组件，来保持会话，还有健壮的并发机制。对于海量信息的获取，go语言能够使用简单的算法就能获取极高的爬虫效率。而不需要像python scrapy 那样使用twisted以及队列模型，这极大的增加了编程的复杂性。至于chanel（管道），go语言更是原生支持。所以go语言在爬虫领域有着十分光明的前景。

go语言缺乏很好的大而全的爬虫框架，但是也有诸多工具，如goquery，colly，chromedv，运用这些工具我们已经足以完成一般的爬虫软件开发。当然纵观go语言领域，大而全的框架其实很少，更多的是轻量级框架如gin。也许是吸取了spring全家桶笨重的教训，即使是springboot，大大简化了配置，但是由于历史包袱原因，至今底层仍需要netty或者tomcat的支持，排错比较麻烦，对新手不那么友好。

爬虫学得好。。。，下面我就不说了，各位还是在尊重法律的基础上畅享爬虫带来的乐趣。

随风

go语言的关键字极其少，充分体现了少就是多的哲学。go一共有多少关键字呢？我在论坛搜索了一波，发现只有25个关键字。

go的25个关键字：
break default func interface select
case defer go map struct
chan else goto package switch
const fallthrough if range type
continue for import return var

可以看出这些关键字里面居然连常见的int等类型定义都没有，却添加了内置支持类型map和chan。map的作用不用多说，键值对处理的必备，而chan则是go语言处理协程通讯的基本工具。但是int等类型真的不是关键字吗？我的回答是，那当然，看看下面这段奇怪的代码你就明白了。

代码“居然”正常编译运行了，不过这样的写法估计你离离职也不远了吧。

不得不说go的关键字设计确实有点大胆，只能说佩服佩服。

欢迎关注创万联公众号。

随风

由于ipv6落实的缓慢，不少地方仍然无法使用ipv6。而ipv4的地址早已枯竭，那怎么办呢？人们想到了一种nat技术。但这样一来就造成了人们大部分生活在一张大内网。在大内网里，人们仍然可以正常上网，但对于我们这种有服务器运营需求的人可就麻烦了。没有公网ip意味着无法从外界自由访问，只能供给内网使用，那我们辛辛苦苦写的物联网平台岂不是毫无作用？别急，正所谓山重水复疑无路，柳暗花明又一村，内网穿透技术解决了这个看似无法解决的困局。

内网穿透的工具众多，如花生壳等，但是普遍价格不菲。有些厂家并不良心，高价买回的穿透隧道却只是映射单一协议和单一端口映射的穿透隧道。一但有大量web程序要部署其中的成本堪称天价。我所工作的某实验室也曾经使用过某穿透产品，价格贵而协议单一，端口也单一，稳定性很差，经常掉线。为此我们web人员深有体会，感觉到内网穿透行业巨大的天坑，并决定抛弃这款产品。

我的一个好朋友曾经给我介绍过frp这款软件，这款软件是一个用go语言写的开源软件，能映射众多协议和端口。只需要一台公网服务器和少量配置即可完成服务端搭建。我并不打算在这里介绍搭建方法，因为网上相关资料极多。客户端可以采用openwrt的软路由，这样整个内网的设备都可以方便地穿透出去。在我的极力建议下，实验室的frp和docker配合搭建的云平台终于开始走入正轨，并逐渐显露出frp穿透的巨大优势。

技术是需要冒险的，如果不是这样。试问浩瀚苍穹，人类何能遨游其中？这就是我对实验室frp搭建的总结。最后说个题外话，我们祝贺创万联获得新软著和wonder获得物联网工程师证书，这些小小成果总将汇成大流。

随风

物联网和人工智能无疑已经成为了工科创新比赛中热点中的热点。挑战杯以及互联网+关于这两者的创新作品多到眼花缭乱，物联网甚至开始有些跟不上创新比赛的要求了，因为有关于物联网的毕设作品都已经到了烂大街的地步。

不过我今天不讨论创新比赛，因为创万联现在已经不是创新比赛团队。我们的目标只有一个，实现市场化。因而市场价值对于我们来说才是最重要的东西。当然市场价值也有长期和短期的，今天我们主要讨论短期的。

进入21世纪以来，科技日新月异，各种科技产品蜂蛹而出。但在我看来智能手机，网购，即使通讯和移动支付都属于互联网革命。本质是互联网技术的深化应用。互联网的宗旨是连接人与人，因而我们当前的时代是信息时代。但大概在2015年左右，物联网由于智能家居的发展，开始由概念走向现实的时候，我们已经可以断定，一个新时代就要到来，物联网革命即将拉开序幕。基于物联网的各种市场应用，在不久的将来一定会大放光彩。但人工智能的短期前景其实并不算太明朗，主要的约束是算力，GPU的价格居高不下，大规模走进日常生活，或者短期内想单纯依靠人工智能构建一个商业帝国我想可能性非常地小。但长期来讲两种技术一定会走向融合，形成aiot技术，届时我们的生活将会翻天覆地，马云口中的数据时代也就会真正到来。

连接万物的物联网主要的硬件基础设施在于通讯技术和嵌入式处理器。软件设施就是物联网平台以及对应的消息中间件。其实目前的工业上的现场总线，以及相当接近物联网的概念，但仍然不是真正的物联网，真正的物联网是打破地域和区域界限的。举个例子，我们可以在美国收到来自江门设备的报警。物联网现在最难克服的问题不是技术，恰恰就是生态以及对应的效益，简单采集数据的物联网毫无意义。

人工智能技术发展最为迅速的就是自然语言处理和视觉，目前主要的实现手段就是深度学习。深度学习中著名的卷积神经网络已经得到了极为广泛的应用，分类识别效果也非常地优秀。但有一点需要注意的是，这里的人工智能都严重地依赖数据集，制作数据集非常耗费时间和精力，数据集是深度学习的灵魂，如果没有优秀的数据集分类和识别效果也就无从谈起，因而想要人工智能大规模投入生活的各个方面，我们首先必须解决数据采集的问题，物联网也正是解决的最好途径。

如此看来，短期内我觉得还是物联网更具大规模市场应用前景。

随风

随着docker等容器技术的流行以及云计算的成熟。微服务作为一种全新的设计思维悄然问世。微服务是soa架构的变种。微服务是一种云原生的架构，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。微服务的本质是分布式的，不同于传统的大型集中形式架构，微服务每一部分都可独立部署，耦合程度非常低。微服务的诞生标志着程序开发进入了真正的云时代。

讲了一大通概念我自己都很烦，我确实不热衷于炒概念，不过概念有时候也是必须的。它可以清晰地描述事物的本质。微服务，顾名思义在于微和服务。微相对于宏，就是小型的集合体。服务就不用多说了。微服务确实带来了很多好处，例如管理上的以及维护等。但也使得程序整体变得更加复杂了，所以只有大型的或者是分布式的应用又或者是云原生应用才会感受到微服务带来的好处。如果为了微服务而微服务，就我个人感觉而言，还不如直接不用微服务，因为分布式固有的复杂性并不低，需要处理诸如消息注册发现以及服务调用问题，还有部署大量的微服务本身就是一个复杂的学问。

我认识微服务时间不长，但微服务的思维在创万联由来已久。但苦于没有找到合适的工具，直到我认识了Spring Cloud，这一切才发生了改变。Spring Cloud确实给我带来了极大的冲击，一瞬间我感到只有一句话—–太爽了。感谢spring全家桶，你的存在让我这种蹩脚程序员不至于碌碌无为，也可以开发出好玩的应用。

Spring Cloud并不是彻底地重构出一个全新的架构，其实这也是spring家族历来坚守的信条：不重复制造轮子。在spring诞生的十几年，spring确实做到了。它不但打败了强劲的对手ejb，而且开发出了spring boot使得java开发的复杂性断崖式下降。spring boot核心思维约定大于配置，确实革命性地减轻了配置的烦恼。Spring Cloud正是基于这种思维，用约定大于配置的思想整合了大量地分布式开发组件，给开发者带来了很多的方便。

Spring Cloud 为开发者提供了快速构建分布式系统中一些常用模式的工具（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线）。分布式系统的协调导致了样板模式，使用 Spring Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。它们将适用于任何分布式环境，包括开发人员自己的笔记本电脑、裸机数据中心和托管平台（如 Cloud Foundry）。

Spring Cloud包含了一系列的工具，Netflix Eureka 就是其中最重要的组件之一，它的功能类似于国内的dubbo。提供服务注册发现以及集群部署等一系列微服务最核心功能。服务发现是基于微服务的架构的关键原则之一。尝试手动配置每个客户端或某种形式的约定可能很难做到，而且很脆弱。Eureka 是 Netflix 服务发现服务器和客户端。服务器可以配置和部署为高可用性，每个服务器将有关注册服务的状态复制到其他服务器。此外还有hystirx熔断器，用于管理崩溃的微服务，防止千里之堤，溃于蚁穴。zuul网关提供了对外服务的路由管理，还有openfeign者提供了服务调用的功能。有了这些组件的加持，开发起来岂能不如虎添翼。

路漫漫其修远兮，吾将上下而求索。知识是无止境的，创万联日后也会秉承开源技术精神，将自己所思所想，技术经验都分享给各位朋友。也许有人会说，你们这样做究竟为了什么，是灌输思想吗？非也。须知创万联开源社区要想发展壮大就有赖于更多的技术爱好分子的加入，我们此举也是渡人渡己，况且我们的认识很多都是不完整和错误的，如果有人指出错误，我们更是受益匪浅。最近鸿蒙的发布，也采取了开源的策略，可以意识到，技术滴水不漏，自家传的时代已经一去不复返。

欢迎关注创万联公众号，这里提供更多通俗技术分享。

本文参考资料：spring官网：https://spring.io/（大陆访问可能速度较为缓慢。）