一、前言
什麼是模式？簡單說就是一種總結，一種模版，一種標準流程。慣用法-設計模式-架構風格，就是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向用戶大屏，推送對應的報警消息。
- 控制聚合模塊，消費報警消息，觸發對應的報警控制傳感器，如紅燈、蜂鳴等
- 。。。
三、總結
其實看完之後，會發現每個模式都似曾相識，都與以前接觸的架構、模式、方法論千絲萬縷。就像多播應用模式，設計模式中的觀察者模式、架構風格中的事件驅動架構，其實都是一樣的。
所以，希望大家在看了這些應用模式後，將它內化爲自己的東西，最好能看到各個應用模式背後的架構思想。