我們的用例涉及一個類，該類必須遠程初始化另一個類的多個實例（每個實例都在不同的 IoT 設備上），并且必須從每個實例中獲取特定結果。最多，我們需要每秒從每個遠程客戶端接收 30 條消息，每條消息都相對較小。你們會推薦什么類型的架構來解決這個問題？我們在想，位于 IoT 設備上的每個類都將充當服務器，而接收結果的類將是客戶端，那么我們是否應該為每個 IoT 設備創建一個服務器，每個服務器都有自己的通道？或者是否可以讓每個 IoT 設備在同一臺服務器上使用相同的服務（意味著同一臺服務器上的同一服務會有多個實例，但在不同的設備上）？
1 回答
手掌心
TA貢獻1942條經驗 獲得超3個贊
該問題將受益于其他詳細信息以幫助指導答案。
gRPC（及其對 HTTP/2 的使用）是比 MQTT 等“更重”的協議。MQTT 更常用于 IoT 設備，因為它占用空間更小。REST/HTTP（即使比 MQTT 更重）也可能比 gRPC/HTTP2 對您有好處。
如果您致力于 gRPC，我想知道反轉您提議的架構并讓 IoT 設備成為客戶端是否會更好？這似乎提供了額外的安全性，因為客戶端發起與您的服務器的通信而不是公開服務。無論哪種方式（如果您決定使用 MQTT），希望您將使用 mTLS。我假設（！？）客戶端實現小于服務器實現。
無論方向如何，客戶端和服務器都可以（獨立地）流式傳輸消息。IoT 設備（客戶端或服務器）每秒可以傳輸 30 條消息。服務器可以流式傳輸管理|控制消息。
我沒有管理物聯網設備群的經驗，但我認為，遠程管理|監控和無線升級|修補對您來說是重要的要求。gRPC 不限制任何這些功能，但調試可能更具挑戰性。使用例如 REST/HTTP，卷曲端點是微不足道的，但是使用 gRPC（即使是優秀的grpcurl）你將被限制在所實現的服務上。是的，您也不能調用不存在的 REST API，但我發現遠程調試 gRPC 服務比 REST 更具挑戰性。
添加回答
舉報
0/150
提交
取消