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