在从版本控制库中拉代码： https://gitee.com/zhang.w/boot-backend
1 此项目源码采用前后端分离方式，spring boot开发后端，使用shiro进行权限控制,layui、bootstrap、jquery、html为前端,基于json进行交互,接口完全采用Restful的风格，实现按钮级权限控制，可以作为开发项目的脚手架，做为基础项目。 3 环境要求 jdk8、mysql、maven 5 初始化工作 6 运行数据库脚本，在/文档和sql/db/boot_backend.sql 7 配置信息在application.yml里，数据库的用户名、密码、ip、端口等，根据情况修改一下 8 使用说明 9 安装运行文档在/文档和sql/01 安装运行.docx 10 右键运行启动类com.zw.admin.server.ServerApplication 11 访问http://localhost:8080，用户名和密码都是admin 12 参与贡献 13 小威老师 xiaoweijiagou@163.com
1.安装配置jdk环境，maven环境，本地git软件，idea
2.注册码云的账号
3.通过开发⼯工具导出项⽬目
4.进⾏行行项⽬目的构建，是⼀一个标准的SPringBoot项⽬目 dao-service-controller-html-js-css 前端用的layui
5.pom文件介绍
SpringBoot项目的特点是约定大于配置，没有太多的配置文件，还是有一些的，而且SpringBoot会维护一个配置bean，之前spring开发基本都是xml配置
6.application.yml 配置文件
springboot项目的配置文件不再采用xml的方式，而是使用yml格式，当前springboot的配置也有另外一种格式，applicaiton.properties，但是后一种格式可读性太差，不建议使用
7.功能模块
7.1 Shiro 权限配置 ehcache生效
7.2 Redis 内存缓存服务
7.3 数据库设计 数据库管理软件-Navicat使用
4.数据库设计 表设计，有些表及它中间包含的数据都是系统运行所必须的，每个系统都差不多，在脚手架工程中一般都会包含。这些表的结构大致不会变化，而且跟你使用的开发语言无关。 表的命名是有规范的，通常来说，根据前缀区别不同的模块，表名一般是下划线。 介绍这样的一些基础表： sys_file_info:id是文件的md5，这样可以保证同一个文件只会被上传一次，程序在上传的时候如果没有上传成功，并且是因为数据库的主键冲突，这时就要根据该文件的md5值去数据库查询，把已经存在的文件的path或url取出来返回给上传方。path和url的区别，主要是因为系统设计了两套上传逻辑，分别是本地上传和云存储。 sys_logs:日志，日志表会记录一些比较重要的操作。使用日志表的方式比较特殊，用到了spring的aop面向切面的思想，不需要你手动去new，只需要通过切面加自定义的注解，你的某个方法如果想要被记录日志，可以直接在方法上面加一个日志注解，这样，当这个方法被调用的时候，就会顺便往日志表中插一条记录。我们线上的项目的日志打印功能通常都是关闭的，因为磁盘空间永远不够，如果你以debug的方式在线上启动项目，就我们这个业务量不是很大的系统，每天产生的日志文件大概有7GB，我们买的阿里云服务器，磁盘通常都不会太大，当你有一天发现你的系统突然无法访问，也没用被别人攻击，一定去检查一下，是否你的磁盘满了。而且日志表的作用很多，也可以记录一些跟业务相关的比较中亚的信息，例如，我们项目中的物联网采集设备，在开机的时候会发送一条启动成功的信息，每个半分钟会发送一条心跳信息，但这些信息我们在项目里面没有必要去处理，但是有的时候系统会不稳定，需要查看这些日志，来判断是因为什么原因导致系统出问题。开始的时候，是通过开发人员后台查询打印出来的的日志判断是否正常，这样非常不方便，后面开发了一个功能，把这些启动信息，心跳信息都存在日志表中，客户可以在界面直接查看设备是否正常。 权限相关表：不管用什么权限框架，表结构基本一样《用户user、角色role、权限permission》，以及他们之间的多对多映射关系表。在系统中使用非常灵活，对系统的扩展帮助非常大。通过对权限的灵活控制，可以实现很多你想要的业务逻辑，而不需要写一行代码。 stb_area：全国区域规划表 sys_ys7_account：系统要使用其他第三方的系统的一些功能，这时候第三方的系统也需要账号密码登录，为了让我们的系统能顺利地交付给客户使用，这样的第三方系统的账号信息我也可以通过界面维护 t_dict：数据字典表，性别、状态、民族、国籍、组织机构 t_mail ，t_mail_to：系统用来发送邮件的 weixin_*：是跟公众号开发相关的 定时任务表：QRTZ_*:这是使用定时框架quartz所需要的表，通常来说，在网上找的资料，使用quartz框架实现定时任务，不需要数据库表。quartz的表结构的非常重要的作用就在于可以实现分布式的定时任务。 例如：有十个相同的项目被部署，每个项目中都有一段相同的定时任务逻辑，那如果在到达这个执行时间时，这些任务都应该被执行吗？没有必要所有的任务都执行，只需要有一个任务执行成功就可以了，所以我们把任务执行的状态信息保存起来，刚你要去执行某一个任务的时候，先去查看这个状态，如果是 可以执行的状态，那就执行，并且把状态修改为不可执行。其他任务来的时候一看状态不可执行，就继续进行下一次等待。其实，这就是分布式锁，只不过是通过数据库的方式实现的。 https://blog.csdn.net/jiangyu1013/article/details/79882868 t_job：也是quartz框架中需要的一张表，这张表可以记录当前系统所有的定时任务执行情况，并且有可视化的界面进行维护。你可以去动态的指定某个方法什么时候被执行，以及他执行的次数。 Ps：定时任务框架还有SpringTask，我们在项目中也用到了，但没有相关表被使用。 4.8.物联网业务相关表 基地：农场 通知： 设备相关 设计思路：分了两个大的阶段，第一阶段，我们做的是沙盘演示功能，沙盘上面的传感器可以记录温度，湿度，风速，风向等信息，可以进行远程控制，可以显示每个设备的近一段时间的数据折线图。因为这些信息的度量单位，数值上的差异是很大的，统计信息需要根据不同的设备分别进行，而且任务要求时间比较急，客户的意思是先做一个简单的出来（此处客户给我挖了坑），所以我把这些信息都单独建了表，把采集过来的信息根据设备类型直接入库，然后再去做后续的显示，参加了展览会，取得了很大的成功（客户获得了数十个订单）；第二阶段，需求变化比较大，因为通过分析发现，采集来的数据除了数值和单位不同，其他信息都是相同的，所以我就进行了数据表的合并，放到了设备采集表中进行统一记录，但是并没有把原来的分表删除，因为考虑到数据量很大的情况下，对应每种设备还是可以单独记录的。 设计中需要注意的问题：对于需求的变更，因为不知道客户需要的到底是什么，会出现某个功能可能已经开发的差不多了，又需要多加字段，造成开发量的增加。还有因为设计的时候不可能考虑的很周到，必然会出现一些字段的变化，也会造成工作量的增加。大家在进行工作量预估的时候，一定要把这些因素都考虑进去。
7.4 文件上传功能-本地存储
7.5 EasyPOI的入门
7.6 海康威视监控摄像头
7.7 邮件告警-JavaMail邮件收发
7.8 ElasticSearch数据快速搜索
7.9 数据采集LogStash&数据可视化-Kibana的友好展示
7.10 Solr跟ES比较以及不采用Solr的原因大揭秘
7.11 使用Quartz实现邮件的定时收取
7.12 短信、电话平台介绍 阿里大于-》可以发国际短信，6毛一条，开通要求很严格，有段时间必须是企业
7.13 Docker
7.14 MongoDB
7.15 爬虫程序制作
7.16
7.17
7.18
7.19
7.20
模块
8.业务模块
8.1 数据的采集需要物联网设备与web后台进行交互，交互的方式需要一个中介，中介的作用是一个消息队列，可以接收物联网设备的传递过来的信息，并且转发给web设备。
中介的实现方式很多种，可以自己搭建对应的平台，也可以采用第三方的平台，从技术实现的难易程度和成本控制上来说，花钱采用第三方的是最经济实惠的。而从技
术选型上来说，我们跟设备端的工程师确定共同的一个平台。一期采用的是开发快平台，负责数据采集后的传递，他的功能很强大，在数据传递中不需要考虑粘包，拆包
问题。二期准备把平台换成阿里云的，因为阿里云的更稳定，更可靠的。平台本身不会对数据库做任何的处理，只负责消息的收发，硬件程序员将采集的数据发送到平台，
而web端对对应的端口进行监听，监听到数据就进行处理，否则一直等待。
任意的第三方平台的接入，考虑的最多的就是对于多语言的支持能力，对于问题的解决速度，以及api的更新要保持节奏。
10.数据库设计
11.后期管控
11.1 Druid 连接池可视化监控
11.2 ToolKit 一键云 持续集成
11.3 阿里云监控配置
11.4 多环境配置文件
11.5 Mysql 备份 回复 Crontab 全备 增量
11.6 代码管理 git svn
11.7 域名申请 备案
11.8 负载均衡
11.9
12. 消息队列
13. 项目组搭配