本文將通過對幾個項目的介紹，讓讀者完全了解并掌握如何架構物聯網。幾周前我們在捷克的Linux大會“OpenAlt”上提出了這樣的觀點：物聯網（IoT）是基于微服務的。我們打算覆蓋所有實現層級，將難題放到一起。也就是說，使用所有從邊緣設備中所收集的數據，經過數據集成與分析之后，得出完整的物聯網解決方案。

　　物聯網架構

　　下面的架構圖是對我們觀點的高度概括。其中，很容易找到與物聯網網關連接的所謂邊緣設備。

　　一般情況下，網關會將設備所傳輸的任何硬件與供應商特定協議轉化為一致而更易集成的東西，方便在集成時使用，類似TCP和任何頂端的標準化信息協議之類的。

　　一直只有一個網關嗎？這個網關只使用硬件特定協議嗎？兩者的答案都是否定的。在不同位置上可能會有各種類型的多個網關，如果邊緣設備足夠智能的話，其中一些甚至使用的是TCP協議。更重要的是負責數據聚合的網關，其邏輯功能可能就是簡單的路由器與消息轉換器。

　　再來看集成組件，也是核心業務邏輯所在之處。這個架構類似于優秀的經典SOA（服務導向架構）。這里可以/應該使用SOA原則。

　　稍后，集成組件可以與復雜的系統（如JBoss業務流程管理系統）進行通訊，并進行決策與高等數據分析。

　　那么網關與集成組件之間具體有什么不同呢？我們在其原理中提過這種區別。不過在具體的實現上，是否有什么不同呢？

　　令人驚訝的是，并沒有區別。使用我們的辦法，通過Bulldog、Silverspoon和SilverWare所提供的微服務實現工具，兩者實現的基礎結構模塊完全相同。

　　想要區分特定微服務的含義，有多個維度的抽象。其中包括數據協議（低級硬件協議、簡單的信息傳遞、TCP等），服務層（也就是來自優秀經典SOA架構）以及特定服務所需的計算能力。

　　正是如此：微服務的目的及其規范是在系統創建時由開發者設定的。可以說微服務就像是干細胞。微服務與干細胞一樣，是根據所使用的地方以及用法來發揮具體功用的。

　　概念

　　我們為什么會認為自己的解決方案“正確”呢？

　　首先，我們希望覆蓋所有級別的抽象。我們有物聯網架構所有層面的組件與開發工具。將傳感器與Arduino相連很有趣，但下一步是什么呢？如何整合才能存儲大數據并執行分析呢？

　　其次，我們是開放的，依靠現有標準，只是協助集成現有的解決方案。因此，無需學習全新的東西，只要理解單個結構模塊，任何人都可以馬上動手去開發復雜的系統。同時，我們嘗試避免供應商的封鎖。所有的相關組件、系統、設備等任何東西都可以很容易地替換。

　　最后，我們希望達到最簡，可以用簡單、容易理解的服務來構建復雜的系統。這些服務可以在基于ARM的設備上與云端小型虛擬機上運行。啟動更多服務實例可以讓性能更強，因此擴展也很簡單。

　　實現

　　我們的解決方案包括三個要素。

　　使用Bulldog庫來控制以及與邊緣設備通訊。這個庫提供了一定程度的抽象，允許開發者修改邊緣設備與ARM board而無需重構代碼。

　　為了將代碼轉化成有意義的協議，我們使用了Silverspoon——這是一套Apache Camel組件。這些提供了設備特定協議與外部世界間的網關。我們認為，鑒于其具有路由功能、可擴展性、集成性及發送消息的能力，Apache Camel非常適合扮演物聯網網關。因此我們在Apache Camel中加入了Bulldog組件。

　　為了發展網關、集成與業務邏輯，我們創建了SilverWare——這是一個極簡的微服務平臺。微服務可以按照Apache Camel路由、CDI組件、信息隊列/主題、Vert.x還有很多其他的（其中一些還沒有實現）來進行創建。因此在你的公司里，這些結構模塊的任何一個都可能已經存在了，而且能夠很容易地轉換或直接按照微服務部署。讓我們受益的還有：簡單的Maven項目依賴、一些容易理解的注釋、小型可執行jar文件、部署以創建Docker鏡像的能力。

　　為了方便分析，我們推薦用NoSQL或時序數據庫（比如InfluxDB）現代化分析工具（比如ElasticSearch、Grafana、Kibana）來進行集成。

　　此外，一個完整的系統肯定應當包含以業務流程與規則的形式存在的高級業務邏輯。為此，用JBoss業務流程管理系統來集成也是可行的。

　　應用架構如下圖：

?

?