第1章物聯網模式簡介---獨特要求和體系結構原則

物聯網用例的獨特要求

物聯網用例往往在功耗、帶寬、分析等方面具有非常獨特的要求。此外，物聯網實施的固有復雜性（一端的現場設備在計算上受到挑戰，另一端的云容量幾乎無限）迫使架構師做出艱難的架構決策和實施選擇。可用實現技術的多樣性和缺乏完善的標準是額外的挑戰，使體系結構決策變得困難。

本書試圖通過識別可以支持這些用例的架構之間的共性，來緩解與構建物聯網用例相關的一些挑戰。重要的是不要被用例的多樣性所蒙蔽，并認識到多樣性存在于表層和底層。

本書旨在通過展示如何將不同物聯網用例的實現追溯到少數架構模式，彌合當前理解中的這一差距。在介紹各種物聯網模式之前，值得一提的是，物聯網架構不同于非物聯網架構的獨特期望：感知事件和驅動命令具有廣泛的延遲預期——從實時到激發和忘記數據分析結果需要在各種消費設備上報告/可視化/消費——手機、臺式機、平板電腦等。同樣，數據消費者有不同的背景、數據需求和應用程序角色（人物角色）。

人們經常被迫與傳統以及尖端設備和/或外部系統集成——很少有瑣碎的用例具有獨立/獨立的架構。從遺留系統和非遺留系統中提取數據的方式有很大的不同——遺留系統可能會在內部整理數據，然后將其推送到外部端口（文件傳輸），而較新的系統可能會以連續的流（時間序列數據）推送數據。這種可變性是選擇特定物聯網架構模式時的關鍵考慮因素之一。不同的部署需求—邊緣、內部部署、混合、云等等。遵守嚴格的監管規定，尤其是在醫療和航空領域。有人期望立即獲得回報，投資回報率（ROI）、業務成果和新的服務業務模式。持續創新，產生新的服務或產品（尤其是云供應商），迫使物聯網架構與這些新產品或服務保持持續同步。缺乏能夠制定端到端物聯網解決方案的熟練架構師——盡管可能有特定技能的人（設備架構師、連接架構師和云架構師）；然而，很少有端到端的物聯網架構師。設備、設備連接、物聯網協議或消息傳輸層沒有通用標準，導致設備管理復雜。通常，物聯網堆棧不會孤立運行，任何非瑣碎的部署物聯網解決方案都需要與其他外部系統（ERP、AMDB、MES等）集成。即使在這里，也沒有關于如何無縫集成這些系統的標準。外部系統通常比物聯網部署早幾十年，并且在沒有考慮集成需求的情況下進行了大量定制。從一個角度來看，物聯網實施是一項流程自動化舉措。一般來說，該過程是存在的，但是手動執行的，物聯網有望部分或完全自動化該過程。

這些現有的工作流程沒有記錄在案，并且是流程從業者部落知識的一部分，這給物聯網架構師帶來了挑戰，因為他們對流程和工作流程不清楚。因此，他們面臨著一個兩難的問題，即哪些子流程應該自動化以最大限度地提高ROI——他們必須決定是否滿足于微小的改進（局部優化），并放棄通過考慮全局優化可以積累的好處。

設備生命周期管理在有氧醫療設備等領域是一個挑戰，因為它們無法承受停機時間，但仍需要及時的固件更新（尤其是與安全修復相關的補丁，不能推遲到某個時間點之后）。需要定期校準現場傳感器是一個挑戰。漂移速率因傳感器而異，也因環境而異。有一種趨勢是通過在邊緣或云中應用AI/ML模型來補償這種漂移，但這些步驟遠非理想，因為它們缺乏準確性，并且可能沒有充分考慮局部或環境條件。依賴于位置信息的用例往往具有有限的可接受性，因為所有的位置傳感器（室內或室外）具有有限的精度。大量邊緣處理的歷史數據（幾十年來積累的）遷移到云是另一個關鍵的架構挑戰，在許多機器到機器（M2M）到物聯網的轉型計劃中都看到了這一挑戰。所需的非功能性需求（NFR）（可擴展性、可用性、安全性、數據駐留/隱私等）值因用例而異，并增加了另一層復雜性。物聯網數據的消費者有不同的背景（例如，家庭自動化用戶的信息需求與想要監測工廠正常運行時間的工業用戶有很大不同，而工業用戶的信息需要又與使用物聯網進行自動化臨床試驗的輔助醫療人員的需求不同），因此他們有不同的操作和利用物聯網系統的方式。盡管這似乎對設備UI設計有更大的影響，但它也會以微妙的方式影響解決方案架構。在下一節中，我們將列出有助于您解決實施物聯網解決方案的獨特需求的架構原則或注意事項。

建議的體系結構原則和注意事項

確保體系結構一旦實現，即具有可擴展性、可修改性、魯棒性和容錯性的某些原則與物聯網體系結構尤其相關。讓我們來看看其中的一些：基于開放通信協議構建，以支持不同的設備通信需求：因為物聯網是真實（硬件）和虛擬（軟件）領域的融合，每一個領域都以自己獨立的速度發展。穩健的物聯網架構應該足夠靈活，以支持這兩個領域當前和未來可能的增強功能——例如，一方面，設備/硬件方面的連接/電源功能不斷進步，而另一方面，中央服務器方面在分析和AI/ML能力方面取得了進步。

????????因此，現實世界和虛擬世界之間存在固有的阻抗失配（涉及這些增強的速率和性質）。物聯網架構師不僅應該意識到這種不匹配，還應該納入所需的考慮因素，以在更長的時間內支持用例需求。這些要求部分是通過遵循分層架構來處理的，通過分層架構，特定層中的組件可以插入或插入，對整體架構的影響最小。

????????專為“端到端”安全設計：安全性是任何軟件系統的重要考慮因素，尤其是在數據或命令通過公共通信信道進行通信的情況下。然而，就物聯網而言，安全需要更深入的考慮，主要有兩個原因：與虛擬/軟件世界中的行動不同，在現實/物理世界中發起的行動是不能取消的：在有人檢測到異常并采取糾正行動之前，一臺灌溉泵被（惡意）指示開始在農田中抽水，它會泵出相當多的水。這與軟件世界中的場景形成了鮮明對比，在軟件世界中，一條簡單的更新指令就足以撤消/滾動回溯數據庫的更改。在醫療保健等領域，物聯網系統通常控制人類生活（例如，由物聯網系統控制的氧氣呼吸機），情況可能更具災難性。與純軟件系統相比，攻擊向量要廣泛得多：這是因為需要保護完整的數據管道（終端設備>網關>通信通道>中央服務器>應用程序），并且數據管道中的每個實體都有不同的適用安全要求——終端設備（其固有的受限計算/存儲能力）無法支持中央服務器所能支持的嚴格安全性，因此需要獨立分析每個組件的安全漏洞和相關安全防護措施。同樣，數據在傳輸過程中以及在任何時候都應受到保護。

????????通過“API-first”方法實現的企業集成：任何生產級物聯網系統通常都會與其他外部系統集成，以提供全部價值。物聯網系統整理的真實世界數據被輸入（數據推送）到外部系統，以實現更豐富的用例。類似地，來自外部系統的數據（數據拉取）用于豐富整理后的數據。這種類型的集成是不可能的，除非物聯網系統已經使用API-first作為核心架構租戶之一進行架構設計，企業應用程序可以使用物聯網數據。這些API還支持跨物聯網和非物聯網（即外部系統）的工作流。滿足不同的數據需求：物聯網系統由不同的用戶使用，每個用戶都有不同的背景和信息需求。因此，重要的是要捕捉所有（當前和未來）利益相關者的原始數據需求，并以一種易于被不同利益相關者（人物角色）同化的方式呈現數據。

????????基于角色的訪問控制（RBAC）是一種向利益相關者顯示所需信息，同時掩蓋非相關信息的機制。此外，一些利益相關者將有實時數據需求（希望緊急警報實時通知的運營商），而其他利益相關者則希望從合并數據中獲得見解（批量處理）。將數據攝取與數據處理解耦是使我們能夠滿足這一需求的一個原則。以下列出了一些其他數據整理/操作要求：來自制造執行系統（MES）和實驗室信息管理系統（LIMS）等源的各種（結構化、半結構化和非結構化）操作數據應整合在邊緣、云或兩者的通用數據存儲（數據湖）中。出于可擴展性、效率和成本優化考慮，分離流式、批處理和正確的時間數據管道。數據生產者與消費者的解耦確保了強健的體系結構以及技術和實現選擇的靈活性。提供部署靈活性的技術中立架構：物聯網系統可以部署在不同的配置中，如內部部署、公有云、私有云和/或混合多云配置，這取決于客戶對安全的敏感性以及治理和監管需求。考慮到這一點，體系結構應該足夠通用，可以滿足不同的部署需求，并可以由多個技術堆棧支持。這通常是通過創建物聯網參考體系結構（沒有特定的技術選擇），然后過渡到技術體系結構（其中通用體系結構組件被特定的技術組件取代）來實現的。高可用性設計：盡管不同的物聯網用例對高可用性的需求差異很大，但一些用例被歸類為任務關鍵型用例，幾乎沒有停機預期，而另一些用例可以適應相當長的停機時間。中央服務器體系結構應該模仿正常運行時間的預期，因為通常情況下，停機時間越少，成本越高。在物聯網的背景下，必須從整體系統的角度考慮高可用性。例如，在可以接受更長的中央服務器停機時間的情況下，終端設備需要具有更高的數據緩沖能力（即更大的存儲空間），以最大限度地減少數據丟失。支持“無限可擴展性”：物聯網部署從少量終端設備開始，但往往在短時間內擴展到大量。因此，通常，在物聯網解決方案中，水平可擴展性優先于垂直可擴展性設備通信注意事項：數據通過網關和中央服務器之間的雙向通信信道進行通信。該信道可以由多種通信技術支持（其中一些常見的技術是蜂窩、Wi-Fi、LoRa和SigFox）。范圍（與中央服務器的物理距離）、有效載荷大小、電池壽命和環境噪聲等因素在最終確定特定物聯網實現的理想通信技術方面發揮著作用。設備側的一些其他考慮因素包括在與中央服務器的連接丟失的情況下存儲/緩沖數據的能力、用于節省電池電量的睡眠/喚醒邏輯以及數據聚合/過濾需求。下圖總結了本節中討論的關鍵體系結構原則/注意事項：