在從版本控制庫中拉程式碼：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.5EasyPOI的入門

　　7.6海康威視監控攝像頭

　　7.7郵件告警-JavaMail郵件收發

　　7.8ElasticSearch資料快速搜尋

　　7.9資料採集LogStash&資料視覺化-Kibana的友好展示

　　7.10Solr跟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的更新要保持節奏。

　　　　開發平臺：http://www.aliyun.com/　　找到到開發者指南：http://aliyun.com/　　找到開發者工具：微信，SDK 　　　　X-SDK開發嚮導:開發手冊 　　8.2 感測器與平臺互動 （ 本方案中採用Netty 接收 TCP UDP Mqtt Https ） 　　　　8.2.1 閘道器 傳輸，可以將資料打包後傳送，制定協議 　　　　8.2.2 感測器直接接入平臺，但是單體感測器成本增高，每個都需要聯網模組　　　 　　　　硬體跟程式之間通訊就是傳遞的byte陣列，所以需要定義規則進行解析，這裡的規則指的就是協議。 協議是由硬體工程師跟軟體開發一起制定的 　　　　 同一個資料庫中，不同的感測器設計出來的表結構除了單位不同，其他都是類似的，同學們可以會考慮把這些資料都放在一張表中，但請不要這樣做，因為隨著資料量的增加， 　　　　遲早都要進行資料庫的分庫分表，為了業務的擴充套件性，不要放到一起。資料採集15秒就會上報一次。資料庫的記錄會增長的很快 　　　　　　 　　　　　　對硬體傳遞過來的資料進行解碼 9.LayUI 沙盤演示頁面前端接收到資料並且用echarts渲染出來 　　

10.資料庫設計

sys_file_info:id是檔案的md5　　 t_device_gather裝置採集表 sys_logs:日誌

　　　　　　

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. 專案組搭配

　　

介紹下目前整個軟體開發團隊的配套成員
|技能|人數| |-------|----| |android|1| |ios|1| |前端|1| |美工|1| |java|2|