一. 大流量的互聯網項目

　　1.項目背景

　　之前負責的一個項目，業務背景是這樣的。城市的基礎設施建設是每個城市和地區都會涉及到的，如何在基建工地中實現人性化管理，是當前項目的主要訴求。該項目要實現如下目標：

　　工地工人的智慧考勤：

　　考勤機通過面容做人臉識別就能打卡，工人不需要脫手套按指紋，甚至不需要卸下口罩；

　　工地安全檢測：

　　檢測某一個區域沒有戴安全帽的工人，可以快速觸發總控臺，提醒管理員監管；

　　工地機器的工作情況：

　　統計工地機器是否正在工作及已經連續工作時長，用于檢測機器是否在安全時間內使用。

　　從上述項目背景中我們就能看出，每一個功能的實現都需要硬件設備來實現：比如人臉識別考勤機來實現智慧打卡，帶有人體識別功能的攝像頭來捕捉沒有戴安全帽的人員，傳感器設備來統計機器是否正在工作。

　　除了工地項目外，還有另一種很有意思的應用場景，就是統計商場、超市的熱門門店。大家肯定很好奇，這是怎么實現的？——對！也是通過攝像頭。攝像頭采集進入商場的人員，不用采集到臉，只需要根據人體的形態、衣服顏色、身高等特征值來標識一個主體。根據人體識別算法，統計哪些類型的人，在什么時間段，去了哪些門店。如果特征值足夠匹配，甚至還能統計出性別和老幼。這個應用場景是不是非常有意思?其實，很多城市已經在用這一套系統。甚至還有更有意思的應用場景，物聯網早已深入生活，而IOT的項目中的流量數據是非常大的。

　　索爾為什么要說這些呢？你有沒有發現，其實這些都跟硬件設備有關。如果老師所在的公司是一個硬件廠商，或者是一個小B中間商，就需要知道我買的這些設備，是否都能夠正常工作。如果能有一個類似于下面這樣的數據大屏，那是不是更加完美呢？我們就是這么干的。

　　問題來了，設備的心跳數據該多久上報一次？上報時間間隔的不同會對整個系統造成怎樣的影響？心跳數據怎么判斷設備是否正常？會有多少的心跳數據？

　　2.設備上報心跳的時間間隔

　　設備的上報心跳動作其實是一個很簡單的邏輯，就是上報將自己的設備key，和當前時間封裝成一個http請求消息，發送給平臺。

　　根據當時硬件部門的設定，不同設備的約定不同，每個設備大致會在2秒到5秒之間向平臺發送一次心跳。

　　3.如何通過心跳計算出當前時間段設備是否正常

　　根據目前的情況，平臺收到的設備的心跳信息可以通過這張表體現出來：

　　這個表就是用來記錄當前設備的最后活躍時間。那么問題來了，該怎么統計當前時間段的正常設備和異常設備？多久沒有上報心跳的設備會被判定為異常設備呢？

　　心跳、服務發現。對！你也發現了，它們好像在描述同一件事情。在這里，參考了微服務中注冊中心對于服務剔除的方案。比如Nacos的服務健康檢查機制：

　　Nacos Server會開啟一個定時任務用來檢查注冊服務實例的健康情況，對于超過15秒沒有收到客戶端心跳的實例會將它的健康屬性置為false，如果某個實例超過30秒沒有收到心跳，則直接剔除該實例。

　　開啟了一個每隔30秒定時任務，去設備心跳表中統計今日上報心跳的設備數量，具體的sql操作如下：

　　針對于這條sql，有同學會問，為什么不直接用日期函數：

　　因為性能，使用函數會導致索引失效，關于SQL優化這一塊的內容，大家可以在MySQL優化專題里進行學習。

　　我們可以將統計到的數據，維護在redis中。也就是說，redis中維護了今日正常設備的總數，這個數據每30秒更新一次。

　　4.并發量的產生

　　在上一章節中我們提到，任何一個設備，都會上報其心跳到平臺，而且每個設備會每隔2到5秒左右上報一次心跳，我們試算下：

　　一臺設備：每隔3秒上報一次；

　　三十萬臺設備：每隔3秒會上報30萬次；

　　平臺：每秒接收到10萬次訪問，每天將會收到將近百億的消息。

　　可以推算出，一個平臺基本上每秒都會收到大約10萬次訪問。這樣的并發量不算大，但也不能說少，而且這樣每秒10萬的請求是持續的，這10萬的請求每秒都會來，不間斷的來，此時考驗后端接口的時刻就到了。

　　5.業務如何處理

　　后端接口做到高性能、高可用設計，我們會在之后的專題去講，這里先聊一下接口收到數據后，該如何處理。

　　很顯然，接口收到設備上報的心跳數據后，要把數據落到數據庫里。這就是具體業務要做的事，很簡單，只要落到數據庫里就可以。

　　二. 待解決的核心業務邏輯

　　1.項目模塊

　　整個項目分成了以下幾個子項目：

　　數據大屏前端項目

　　數據大屏后端項目

　　硬件后端項目

　　硬件設備

　　Redis緩存服務器

　　MySQL關系型數據庫

　　這些項目之間有著重要的聯系，這樣的聯系可以總結為兩點：一是數據大屏的后端為數據大屏的前端提供數據，二是硬件設備的后端供硬件設備訪問實現數據交互。

　　那么問題來了，以第一點為例，后端和前端的數據交互方式是什么樣？

　　2.前后端交互方式

　　“前端”的概念可以是多種終端的瀏覽器。部署在web服務器上的Java Web應用程序(即“后端”)提供了供http協議訪問的web接口，也就是程序的調用入口。前端通過http協議訪問后端的web接口，實現數據的交互。比如前端通過http協議訪問后端獲取網絡資源的web接口，后端通過io流的方式獲得網絡資源并使用http協議返回給前端。這就是一個完整的前后端交互過程。

　　3.核心業務

　　如何編寫Java程序。關于Java入門及Java核心基礎部分的知識，老師為大家準備了這一套Java核心基礎課程視頻非常建議剛入門的同學好好學一遍。

　　硬件如何訪問到Java程序：

　　硬件也可以通過http協議來訪問到java的web接口；

　　數據存到哪：

　　打卡機等硬件生成員工的打卡數據，將數據發送給后端Java程序，Java程序將數據保存到MySQL數據庫中。但這還不夠，因為數據大屏的前端也需要獲得數據，于是需要讓數據大屏的后端去數據庫獲取數據；

　　優化點在哪里。

　　很顯然，設備的數據量非常大，勢必給數據庫造成過大的壓力。優化點就在于如何讓數據庫更輕松一些。使用在處理能力上面非常優秀的Redis緩存數據庫，解決數據庫的壓力。此時，與硬件對應的后端java程序將數據存入到redis中，數據大屏的后端程序從redis中取出數據，展示在數據大屏前端項目中。

　　三. 核心業務代碼

　　1.供硬件訪問的后端Java程序

　　1.1 Controller

　　1.2 service

　　2.數據大屏前端訪問后端接口

　　前端使用VUE的axios來發送http請求，訪問后端接口，并實時展示在DataV前端數據大屏框架的翻牌器組件中。

　　3.數據大屏后端提供數據的接口

　　3.1 Controller

　　3.2 service

　　四. 前后端聯調及測試

　　1.使用Postman測試后端硬件打卡接口

　　模擬使用id是1003，姓名是xiaoming的用戶進行打卡，并返回打卡成功。

　　2.使用Postman測試后端獲得打卡數據接口

　　訪問后端獲得打卡總數的接口，獲得的打卡總數為18。

　　3.啟動前端項目獲得打卡總數

　　在項目路徑中使用cnpm install 安裝vue項目需要的依賴；

　　在項目路徑中使用npm run serve 啟動項目；

　　獲得頁面數據。

　　以上內容就是為大家分享的億級流量互聯網項目構建思路，不知道你現在是不是得到了一些啟發呢?在我們的線下課程里，這個智慧工地的項目會有詳細的講解哦，歡迎你來學習。