采用Dapr 的IoT 案例

CNCF 釋出了一篇Dapr 的IoT 案例：Tempestive uses Dapr and K8s to track IoT messages | CNCF。Tempestive 是一家物聯網解決方案提供商，其產品 Nuboj 面臨著可延伸性、成本和維護方面的挑戰。為了解決這些問題，Tempestive 采用 Dapr 和 Kubernetes 構建了一個新的架構，實作了以下優勢：

Tempestive 在采用 Dapr 和 Kubernetes 之前，Nuboj 的微服務架構遇到了以下可伸縮性問題：
1. 資源限制: 昂貴的資源: 早期版本 Nuboj 的微服務架構需要昂貴的資源才能實作可伸縮性，這增加了營運成本並限制了其擴充套件能力。
在地化需求: 一些客戶需要一個可以從幾台裝置擴充套件到幾十萬台裝置的本地解決方案，而早期版本 Nuboj 難以滿足這種需求。
2. 擴充套件復雜性: 微服務間依賴: 早期版本 Nuboj 的微服務之間存在復雜的依賴關系，這增加了擴充套件的難度。修改或升級一個微服務可能會影響到其他微服務，導致系統出現故障或效能問題。
手動擴充套件: 早期版本 Nuboj 的擴充套件需要手動操作，這不僅效率低下，而且容易出錯。
3. 運維挑戰: 部署和監控: 早期版本 Nuboj 的微服務架構需要手動部署和管理，這增加了運維成本和復雜性。此外，監控和偵錯微服務也更加困難。
故障恢復: 早期版本 Nuboj 的故障恢復機制不夠完善，這導致系統在出現故障時難以快速恢復，從而影響了系統的可用性。
4. 環境限制: 雲依賴: 早期版本 Nuboj 基於雲的架構限制了其在本地環境中的部署能力，這無法滿足一些客戶對數據安全性和成本控制的需求。

Tempestive 在采用 Dapr 和 Kubernetes 之前，Nuboj 的微服務架構面臨著資源限制、擴充套件復雜性、運維挑戰和環境限制等問題，這些問題限制了其可伸縮性和可用性。遷移到 Dapr 和 Kubernetes 後，Nuboj 的架構發生了以下關鍵變化：
1. 微服務架構:
模組化: Nuboj 從單體套用轉變為微服務架構，將功能劃分為獨立的微服務模組。這提高了系統的可延伸性和可維護性，並允許各個模組獨立部署和升級。
獨立性: 微服務之間透過 Dapr 提供的 gRPC API 進行通訊，無需直接依賴。這提高了系統的靈活性和可移植性，並允許使用不同程式語言開發微服務。
2. 釋出/訂閱訊息傳遞:
解耦: 使用 Dapr 的釋出/subscribe API，Nuboj 可以解耦釋出者和訂閱者。這意味著裝置可以獨立發送訊息，而處理元件可以獨立接收訊息，無需直接相互依賴。
可延伸性: 釋出/subscribe 模式支持訊息代理（如 MQTT、Redis 或 Kafka），這些代理可以有效地處理大量訊息，並確保訊息的可靠傳遞。
負載均衡: 訊息代理可以自動分配訊息到不同的訂閱者，從而實作負載均衡並提高吞吐量。
3. 容器化和自動化部署:
容器化: Nuboj 的微服務被容器化，這允許它們在不同的環境中一致地執行，並簡化了部署和擴充套件過程。
Kubernetes 集群: Nuboj 使用 Kubernetes 集群來管理容器化的微服務。Kubernetes 提供了自動化部署、擴充套件和管理功能，並確保了高可用性和可靠性。
4. 基礎設施抽象:
平台獨立性: Dapr 將底層基礎設施技術（如資料庫和訊息傳遞系統）抽象化，使 Nuboj 可以輕松地在不同的環境中執行，而無需修改程式碼。
靈活的配置: Dapr 允許透過配置檔輕松地更改底層基礎設施技術，例如使用不同的資料庫或訊息代理。
5. 多語言支持:
程式語言獨立性: Dapr 支持多種程式語言，例如 C#、Java、Python 等。這使得 Nuboj 可以使用最適合特定功能的程式語言開發微服務。

總而言之，遷移到 Dapr 和 Kubernetes 後，Nuboj 的架構變得更加模組化、可延伸、可維護和靈活。它現在可以處理海量數據流，並支持多種部署環境。這使得 Nuboj 成為更具競爭力的物聯網平台。Dapr 和 Kubernetes 分別在解決 Nuboj 微服務架構的可伸縮性問題中發揮了重要作用：

Dapr 的作用:

Kubernetes 的作用: