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