原型产品0.0.1完成，小开心一下：）

原型产品0.0.1开发完成了，总结如下：

1，找通讯网关厂家，给提供了一批通讯网关，各种型号的，有4GRTU、DTU、串口服务器、Lora自组网等设备，都玩了一遍，对设备的工作方式、数据传递等有了具体的体验。结合原来就有的几个电表以及基于modbus的温湿度传感器，硬件ok了。

2，基于mysql创建了几个表：通讯网关、网关通道、电表信息、645协议数据项元数据表、电表单数据项实时数据表、电表实时数据表，录入了几条示例数据。

3，整合netty、springboot、springcloud框架：建了一个eureka-server，管理微服务；建了一个eureka-client，整合netty监听了两个端口，一个是modbus协议，一个是电表645协议，完成了645协议的解析入库，目前已经能够正常工作，实现电表数据的采集入库。

看着自己亲手写的程序在稳定运行着，还是很开心的。中间其实遇到很多问题，有的问题可能卡半天一天。我试着回忆整理部分经验和教训：

1，工程项目里面建一个mybatis-generrator模块，可以辅助生成entity、mapper、mybatis xml等代码，能节省大量重复性代码编写。

2，spring cloud的各组件依赖包，很多重复依赖，所以各种冲突问题，一般提示的ClassNotFoundException，都是版本冲突。所以在可能的情况下，一定要手动编写依赖的组件版本号，尽量不写版本号。还有就是在project的root模块里面配置jdk、springboot、springcloud基础依赖，其他模块都定义为作为root的子模块。root模块可以什么代码都不写。不必要的依赖一定要删掉，否则用处没有，引起的包冲突会浪费大量时间。

3，springboot整合netty有很多坑：一是netty给终端发指令，16进制报文一定要大写，否则有的直接可能会变成ff，而打印的时候根本看不出来；二是在handle里面操作entity入库时，需要在ChannelInitializer里面加载spring管理的handle，否则handle里面无法注入service，这个问题后来和原来兄弟聊天，认为netty是比spring 服务更底层的通讯框架，不应该在handle里面依赖注入，这个问题我还没想到解决方案，也许需要用到mq、redis等，等后面有时间了再研究应用。

4，springboot调用定时任务Schecule很方便。

5，Controller里面模拟用户对设备发送终端指令，而用户需要等待终端回应的报文结果，如何在controller里面捕获等待？我目前的做法是通过线程同步锁，感觉效率不高、可读性也不太好，不知道有没有更好的方法。

6，idea工具真的很好用，绝对比eclipse好用。虽然我eclipse也几乎没有用过，就是用来搜索过代码，但是光搜索代码这一个功能，idea都秒杀eclipse。idea的各种提示、代码Refactor等功能，真的用的很爽。

7，码云（www.gittee.com）团队真的很棒，还不知道他们和git或者github什么关系，但是提供的这些代码平台服务真的很贴心，很是感谢他们。我想我将来要做的也是码云类似的服务模式，就是给底层电工、小工程商或者小的企业用户提供一个免费的好用的基础物联网平台，提高他们的工作效率和客户体验，通过更加高级的数据分析、面向大客户提供定制服务或者是通过给他们推荐平台兼容的设备来赚取利润维持我的成本。也算是为社会做贡献了。