一、前言
什么是模式？簡單說就是一種總結，一種模版，一種標準流程，慣用法-設計模式-架構風格，就是IT這邊常見的三層模式，至于應用模式，我的理解是特定應用領域下的模式，
由于物聯網的特性，其有很多應用模式，這些應用模式并不是專屬于物聯網應用領域，而是在物聯網應用領域，放大了這些應用模式的效果與價值，
簡單說一下，文章中提及的工業物聯網專案下的風機監測，
工業物聯網專案下的風機監測系統，是通過一系列傳感器檢測風場諸多風機的狀態，比如是否存在傾斜倒塌風險，
二、應用模式
1.Interpolation（插入）
a.定義
通過某網路的周邊節點資料，確定中間節點資料
b.問題
一個在時空上連續分布的資料，由于網路波動等原因，缺少部分分布點的資料，
c.解決
由于時空分布的連續性，某個點的資料不可能出現突然猛然增降（如果真的有，大概率也被視為例外資料，進而被清洗了），所以可以通過該點周邊的資料平滑地推斷出該點的資料，
d.缺點
缺點無非兩點：資料可信性、方案落地的要求
前者，由于有部分資料并不直接來自于實際采集，必然導致最終結果的一定程度失真，
后者，這個方案的落地，必須確保這些時空分布點的關聯性足夠強，尤其是時空點的分布并不是足夠密集時，
e.示例
以工業物聯網專案下的風機監測系統為例，
時間：就單個風機，如果傾斜傳感器采集頻率為10/s，那么連續1分鐘內的資料只有590，那么也是可以接受的，甚至這些資料只有300個，只要資料丟失呈現均勻分布，而不是斷崖式的，那么也是可以接受的，只是后續，需要讓技術確定為什么采集資料少了這么多，囧
空間：同樣就單個風機而言，即使在一個小時內某個傾斜傳感器沒有采集資料，但其他部位的傾斜傳感器作業正常，那么可以通過其他傳感器，推斷出這個故障傳感器的資料，進而保證上層程式正常運轉，
2.Sensor Facade（傳感器裝飾）
a.定義
通過中間服務，將傳感器原始資料，轉換為可讀性更高的資料，接耦，帶來硬體升級的成本降低
b.問題
傳感器型號眾多，從通行協議，到互動方式，差異性較大，尤其一些型號的傳感器，可能突然就不生產了，
c.解決
類似于設計模式的Facade模式，通過一個Facade層，屏蔽具體硬體型號帶來的差別，為上層提供統一的資料模型，
d.缺點
每種傳感器都需要建立對應的facade，并且統一的資料模型的抽象決定了這層Facade的上限，
至于每層facade的新增開發量，就取決于facade的抽象設計水平了，
e.示例
以工業物聯網專案下的風機監測系統為例，
該系統的傾斜傳感器有五種，后續還要支持更多傳感器型別，這些傳感器來自不同的廠家，有的使用mqtt協議，有的使用自定義二進制協議，采集的資料也存在差異（是否有溫度采集），
為了避免影響到上層應用，所以在終端服務器（網關層）進行了Facade處理，通過抽象的二進制協議決議&互動模塊和Mqtt互動模塊，將不同傳感器的資料進行處理，最侄訓得一個統一的傾斜資料模型，供上層應用使用，
3.Cache（快取）
a.定義
當傳感器資料被異步獲取/發送時，可以將快取的資料回傳，進而提高性能，避免重新采集/生產資料，
b.問題
傳感器資料的被訪問頻率，與傳感器采集頻率不同步，或者傳感器資料被多個消費者異步消費，
c.解決
傳感器資料采集/處理完畢后，將結果資料置入一塊快取，在資料尚未快取失效期間，外部（其他傳感器/服務節點）請求資料時，直接回傳快取中的資料，
d.缺點
僅適用于異步資料互動，異步處理復雜度相對高一些，
e.示例
以工業物聯網專案下的風機監測系統為例，
該檢測系統有一個震動傳感器的資料采集，由于震動資料的特殊性，所以必須是連續的高頻采集，比如一天采集十分鐘長度，頻率為1000HZ的資料，這份資料采集后，會有三個資料流出向：
- 交由演算法程式處理，計算結果儲存到資料庫中
- 將轉化后的資料進行存盤，便于后續演算法優化
- 上層應用可能會掃描到該資料，用于上層使用（如展示等）
當時的解決方案，就是本地通過檔案系統快取原始資料，消費者（演算法、轉換程式、上層應用）通過異步掃描的方式獲取該資料，每天創建對應快取檔案后，會清理一天前的快取檔案，
4.Gateway（網關）
a.定義
整個系統出入流量的“總閘”，實作安全傳輸，以及相關協議轉換（利用Interpolation、Sensor Facade等）
b.問題
用戶請求格式、協議存在很大差異，每個微服務都需要進行請求格式轉換、協議轉換，并對回傳進行處理，
與此同時，每個微服務都需要實作完整鑒權，確認請求權限，并且由于每個微服務都暴露在外網，系統安全性大大降低，
而這一切，帶來了性能降低、成本提高、安全性降低等一系列問題，
c.解決
系統進出流量，統一經過網關，由網關作為edge service，進行系統內外的互動，
一方面由于網關隔絕了系統內外，大大提高系統內其他服務的安全性，
另一方面由于所有流量都經過網關，所以請求&回應的統一處理可以交由網關處理，如協議轉換，格式轉換、安全傳輸等，
d.缺點
系統增加了一個可能的新性能瓶頸-網關，這包含了網關所帶來的性能瓶頸，以及網關的單點故障考量等，
作為系統的基礎組成，網關的設計影響了系統的安全，性能等，不合理的網關設計，反而會帶來耦合，進而提高系統的復雜性，
e.示例
以工業物聯網專案下的云平臺為例，
云平臺，采用了網關，進行協議轉換，以及鑒權等，
協議轉換：由于存在傳感器將原始資料直接上傳云平臺，所以云平臺需要協議轉換模塊，進行內容的轉化，
鑒權：通過網關統一對傳感器、用戶的權限校驗，內部服務進行“裸奔”，而部分敏感操作，有對應服務進行二次權限校驗，
f.擴展
網關是一個邏輯概念，并不是類似路由器這樣的物理存在，而在應用中，可能被拆分為多個組件，
這里要說一下，之前小伙伴問我XXX集團的網關是什么組件，是不是Spring的gateway，說實話，就是沒有理清這里的概念，網關雖然是功能上一個整體概念，但落在應用中，可能是由多個組件組成，而SpringCloud的gateway等，只是一個較為成熟的落地方案，可以理解為一個用于快速應用的腳手架，比如在XXX集團里的統一接入層，包含了網關的功能，包含CDN、LVS、XXX（類似Nginx）、鑒權平臺、無線接入平臺等等，
5.Sensor Aggregator（傳感器聚合器）
a.定義
往往上層服務所需資訊，不只是在一個傳感器中體現，而是在多個傳感器的聚合資訊中，
b.問題
物聯網某個“物物件“的狀態/某個指標，是由多個傳感器資料聚合而來，如果平臺接受所有傳感器資料，這個資料量就超出了當前系統的承受量，
c.解決
物聯網某個“物物件“的狀態/某個指標，可通過對相關的多個傳感器采集資料聚合而來，再將聚合后的結果，上傳至平臺，
d.缺點
- 需要對多個傳感器資料進行聚合，可能需要對應聚合演算法
- 末端的單個傳感器，往往缺乏多個傳感器的資料聚合能力，所以可能需要額外的硬體，進行資料聚合，
- 由于聚合方式&演算法的緣故，可能聚合結果存在一定程度的失真，
e.示例
以工業物聯網專案下的風機監測系統為例，
風機的傾斜指標，是由塔頂傾斜與塔底傾斜組成，不同部位的傾斜是由三個傾斜傳感器的資料，通過演算法聚合而來
空間三個維度分別對應一個傳感器，進而獲得較為精確的結果，感興趣的小伙伴，可以自己計算哈，
f.擴展
資料聚合并不僅僅針對于“物物件”的單個指標，也可以直接針對“物物件”，具體粒度取決于業務需求，以及技術限制等，
6.Control Aggregator（控制聚合器）
a.定義
通過對傳感器&傳感器集合資料分析，進行決策，進而對控制集進行操作
b.問題
一方面一個事件的處理，往往會涉及多個控制傳感器的處理（亮燈、起落架抬起等），另一方面，每次相關事件處理，都需要呼叫多個控制傳感器，
c.解決
通過定義控制聚合器，由控制聚合器，呼叫對應的多個控制傳感器，
d.缺點
控制聚合器往往是單獨的硬體（部分情況下為邏輯模塊），需要額外處理，另一方面控制聚合器不太容易進行變更，如變更所屬控制行為，
e.示例
以工業物聯網專案下的中控系統為例，
工業物聯網的中控系統，存在報警控制聚合器邏輯模塊，一旦系統觸發對應報警，則由報警控制聚合器觸發對應的蜂鳴器、紅燈等，
f.擴展
多個控制行為的聚合，如觸發報警，會涉及紅燈、蜂鳴、彈窗等
我認為原檔案這部分描述不夠好，原文是：
The Control Aggregator pattern uses analysis performed on the collected information of multiple sensors to create actions that may occur on multiple control points to achieve a desired outcome.
Data from a large number of sensors needs to be collected and analyzed, possibly leading to control actions taken across multiple devices.
但控制聚合，其實與是否多個傳感器資料沒關系，
可以理解，傳感器聚合器和控制聚合器都是個“頭”，系統通過“頭”，進而把握”頭“下面的存在，
簡單來說，系統是個Boss，xx聚合器就是TL，xx就是對應TL下的員工，Boss直接從傳感器聚合器獲取資訊，直接將命令下發給控制聚合器，至于這兩個聚合器怎么獲取資料，怎么進行控制，Boss不管，
7.Multicast（多播）
a.定義
單個事件，發送給多個消費者進行消費（可以是實體內（喚醒判斷、資料ETL），也可是實體間（中控、平臺））
b.問題
一個事件的發生，往往會處罰多個action，
并且這些action時常變化，如果編碼到事件源，則會導致系統耦合度過高，
c.解決
其實就類似架構設計中的事件驅動架構，設計模式中的觀察者模式等，
由事件源發出一個訊息，感興趣的消費者可以進行訂閱，并執行對應的action，
d.缺點
事件源，到消費并不是可靠的，可能存在丟失，可能需要建立可靠性消費，但這樣系統的復雜度和成本就會大幅提升，
另一方面，由于是異步（不考慮同步）消費，消費結果是無法直接反饋給事件源，但可以通過中間狀態&事件源采用事件驅動處理進行改善，
e.示例
以工業物聯網專案下的中控系統為例，
當報警觸發，會發送出對應的報警訊息，系統內部會有多處消費，如：
- 通信服務，消費報警資訊，進而對目標群體，進行短信推送等，
- 指標展示服務，通過websocket向用戶大屏，推送對應的報警訊息，
- 控制聚合模塊，消費報警訊息，觸發對應的報警控制傳感器，如紅燈、蜂鳴等
- ，，，
三、總結
其實看完之后，會發現每個模式都似曾相識，都與以前接觸的架構、模式、方法論千絲萬縷，就像多播應用模式，設計模式中的觀察者模式、架構風格中的事件驅動架構，其實都是一樣的，
所以，希望大家在看了這些應用模式后，將它內化為自己的東西，最好能看到各個應用模式背后的架構思想，
四、附錄
參考
- MSA-IOT
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/296418.html
標籤：架構設計