某些组织可能会受益于从边缘设备直接连接到 Pub/Sub，而不是实现特定架构来将设备连接到分析应用。对于具有少量已连接的设备的组织，我们推荐使用此方法（这些已连接的设备汇总来自本地网络或内部网络中大量设备和传感器的数据）。如果您的组织连接了更安全的环境（例如工厂）中的设备，我们也建议您使用此方法。本文档概述了在将设备连接到 Google Cloud 产品时需要考虑的高级架构注意事项。
本文档是系列文档中的一篇，该系列介绍了 Google Cloud 上的 IoT 架构。本系列中的其他文档包括以下内容：
将数据注入到 Pub/Sub 主题后，可供在具有相应凭据和访问权限的 Google Cloud 上运行的应用使用。除了应用中的 Pub/Sub API 之外，无需其他连接器。您可以让消息可用于后端基础架构中的多个应用，以进行并行处理或用于提醒，以及进行归档存储和其他分析。
使用场景
以下部分介绍了从设备到 Pub/Sub 的直接连接非常适合连接设备的使用场景。
从本地数据历史进行批量数据注入
设备到 Pub/Sub 的连接最适合具有少量需要传输大量数据的端点的应用。操作数据历史记录是本地系统的一个很好示例，该系统存储大量需要传输到 Google Cloud 的数据。对于此使用场景，只有少量端点必须进行身份验证（通常是一到几个已连接的设备），这在服务账号身份验证的典型参数内。这些系统通常还具有模块化架构，可让您实现与 Google Cloud 通信所需的 Pub/Sub API 连接。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2024-08-09。"],[[["\u003cp\u003eThis document outlines architectural considerations for connecting devices directly to Google Cloud Pub/Sub, particularly suitable for organizations with a small number of connected devices aggregating data from a local network.\u003c/p\u003e\n"],["\u003cp\u003ePub/Sub supports REST (HTTP) and gRPC APIs for message ingestion, with gRPC often being more efficient for low-bandwidth, connected device scenarios due to its use of serialized protocol buffers.\u003c/p\u003e\n"],["\u003cp\u003eDevice authentication can be managed through workload identity federation for architectures with external identity providers or service account keys, although service account keys are recommended for smaller deployments due to security and quota limitations.\u003c/p\u003e\n"],["\u003cp\u003eDirect device-to-Pub/Sub connections are well-suited for use cases like bulk data ingestion from on-premises data historians and local gateway data aggregation in secure environments like factories.\u003c/p\u003e\n"],["\u003cp\u003eOnce data is sent to a Pub/Sub topic, the data is available to any application that runs on Google Cloud that has the appropriate credentials and access privileges.\u003c/p\u003e\n"]]],[],null,["# Device on Pub/Sub connection to Google Cloud\n\n\u003cbr /\u003e\n\nRather than implementing a specific architecture to connect devices to analytics\napplications, some organizations might benefit from connecting directly to\nPub/Sub from edge devices. We recommend this approach for\norganizations that have a small number of connected devices that aggregate data\nfrom a larger number of devices and sensors in a local or on-premises network.\nThis approach is also recommended when your organization has connected devices\nthat are in a more secure environment, such as a factory. This document\noutlines the high-level architectural considerations that you need to make to\nuse this approach to connect devices to Google Cloud products.\n\nThis document is part of a series of documents that provide information about\nIoT architectures on Google Cloud. The other documents in this series include the\nfollowing:\n\n- [Connected device architectures on Google Cloud overview](/architecture/connected-devices)\n- [Standalone MQTT broker architecture on Google Cloud](/architecture/connected-devices/mqtt-broker-architecture)\n- [IoT platform product architecture on Google Cloud](/architecture/connected-devices/iot-platform-product-architecture)\n- [Best practices for running an IoT backend on Google Cloud](/architecture/connected-devices/bps-running-iot-backend-securely)\n- Device on Pub/Sub architecture to Google Cloud (this document)\n- [Best practices for automatically provisioning and configuring edge and bare metal systems and servers](/architecture/connected-devices/best-practices-provisioning-configuring-bare-metal)\n\nArchitecture\n------------\n\nThe following diagram shows a connected aggregation device or gateway that\nconnects directly to Pub/Sub.\n\nThe flow of events in the preceding diagram is as follows:\n\n- You use the Identity and Access Management API to create a new key pair for a service account. The public key is stored in IAM. However, you must download the private key securely and store it in the gateway device so that it can be used for authentication.\n- The aggregation device collects data from multiple other remote devices and sensors located within a secure local network. The remote devices communicate with the gateway using a local edge protocol such as MODBUS, BACNET, OPC-UA, or another local protocol.\n- The aggregation device sends data to Pub/Sub over either HTTPS or gRPC. These API calls are signed using the service account private key held on the aggregation device.\n\n### Architectural considerations and choices\n\nBecause Pub/Sub is a serverless data streaming service, you can\nuse it to create bidirectional systems that are composed of event producers and\nconsumers (known as publishers and subscribers). In some connected device\nscenarios, you only need a scalable publish and subscribe service to create an\neffective data architecture. The following sections describe the considerations\nand choices that you need to make when you implement a device to\nPub/Sub architecture on Google Cloud.\n\nIngestion endpoints\n-------------------\n\nPub/Sub provides prebuilt\n[client libraries](/pubsub/docs/reference/libraries)\nin multiple languages that implement the REST and gRPC APIs. It supports two\nprotocols for message ingestion:\n[REST (HTTP) and gRPC](/pubsub/docs/reference/service_apis_overview).\nFor a connected device to send and receive data through Pub/Sub,\nthe device must be able to interact with one of these endpoints.\n\nMany software applications have built-in support for REST APIs, so connecting\nwith the Pub/Sub REST API is often the easiest solution. In some\nuse cases, however, gRPC can be a more efficient and faster alternative. Because\nit uses serialized protocol buffers for the message payload instead of JSON,\nXML, or another text-based format, gRPC is better suited for the low-bandwidth\napplications that are commonly found in connected device use cases. gRPC API\nconnections are also faster than REST for data transmission, and gRPC supports\nsimultaneous bidirectional communication. One study found that gRPC is up to\n[seven times faster than REST](https://medium.com/@EmperorRXF/evaluating-performance-of-rest-vs-grpc-1b8bdf0b22da#:%7E:text=gRPC%20is%20roughly%207%20times,of%20HTTP%2F2%20by%20gRPC.).\nAs a result, for many connected device scenarios, gRPC is a better option if a\ngRPC connector is available or can be implemented for the connected device\napplication.\n\n### Device authentication and credential management\n\nPub/Sub supports a number of\n[authentication methods](/pubsub/docs/authentication)\nfor access from outside Google Cloud.\n\nIf your architecture includes an\n[external identity provider](/iam/docs/workload-identity-federation#providers)\nsuch as Active Directory or a local Kubernetes cluster, you can use\n[workload identity federation](/iam/docs/workload-identity-federation)\nto manage access to Pub/Sub. This approach lets you create\nshort-lived access tokens for connected devices. You can also grant\nIAM roles to your connected devices, without the management and\nsecurity overhead of using service account keys.\n\nIn cases when an external identity provider is not available, service account\nkeys are the only option for authentication. Service account keys can become a\nsecurity risk if not managed correctly, so we recommend that you follow security\nbest practices for deploying service account keys to connected devices. To learn\nmore, see\n[Best practices for managing service account keys](/iam/docs/best-practices-for-managing-service-account-keys).\nService accounts are also a limited resource and any cloud project has a limited\nquota of\n[user-managed service accounts](/iam/docs/service-accounts#user-managed). Consequently, this approach is only an option for\ndeployments that have a small number of devices that need to be connected.\n\n### Backend applications\n\nAfter data is ingested into a Pub/Sub topic, the data is available\nto any application that runs on Google Cloud that has the appropriate\ncredentials and access privileges. No additional connectors are necessary other\nthan the Pub/Sub API in your application. Messages can be made\navailable to multiple applications across your backend infrastructure for\nparallel processing or alerting, as well as archival storage and other\nanalytics.\n\nUse cases\n---------\n\nThe following sections describe example scenarios where a direct connection\nfrom devices to Pub/Sub is well suited for connected device use\ncases.\n\n### Bulk data ingestion from an on-premises data historian\n\nA device to Pub/Sub connection is best suited for applications\nwhich have a small number of endpoints that transmit large volumes of data. An\n[operational data historian](https://en.wikipedia.org/wiki/Operational_historian) is a good example of\nan on-premises system that stores a lot of data which needs to be transmitted to\nGoogle Cloud. For this use case, a small number of endpoints must be\nauthenticated, typically one to a few connected devices, which is within the\ntypical parameters for service account authentication. These systems also commonly\nhave modular architectures, which lets you implement the Pub/Sub\nAPI connection that you need to communicate with Google Cloud.\n\n### Local gateway data aggregation for a factory\n\nAggregation of factory sensor data in a local gateway is another use case well\nsuited for a direct Pub/Sub connection. In this case, a local data\nmanagement and aggregation system are deployed on a gateway device in the\nfactory. This system is typically a software product that connects to a wide\nvariety of local sensors and machines. The product collects the data and\nfrequently transforms it into a standardized representation before passing it\non to the cloud application.\n\nMany devices can be connected in this scenario. However, those devices are\nusually only connected to the local gateway and are managed by the software on\nthat device, so there's no need for a cloud-based management application. Unlike\nin an MQTT broker architecture, in this use case, the gateway plays an active\nrole in aggregating and transforming the data.\n\nWhen the gateway connects to Google Cloud, it authenticates with\nPub/Sub through a service account key. The key sends the aggregated\nand transformed data to the cloud application for further processing. The\nnumber of connected gateways is also typically in the range of tens to hundreds\nof devices, which is within the typical range for service account\nauthentication.\n\nWhat's next\n-----------\n\n- Learn [best practices for managing service account keys](/iam/docs/best-practices-for-managing-service-account-keys).\n- Read [an overview of identity federation for external workloads](/iam/docs/workload-identity-federation).\n- Learn more about [Pub/Sub](/pubsub/docs/overview)\n- Explore reference architectures, diagrams, and best practices for Google Cloud. Take a look at our [Cloud Architecture Center](/architecture).\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]
