您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

Azure IoT 参考体系结构

Blob 存储
IoT 中心

本参考体系结构说明了 Azure 上使用 PaaS(平台即服务)组件的 IoT 应用程序的建议体系结构。This reference architecture shows a recommended architecture for IoT applications on Azure using PaaS (platform-as-a-service) components.


IoT 应用程序可描述为发送生成 见解 的数据的 (设备)。IoT applications can be described as things (devices) sending data that generates insights. 这些见解生成 操作 来改进业务或流程。These insights generate actions to improve a business or process. 例如,一个发送温度数据的引擎(物)。An example is an engine (the thing) sending temperature data. 此数据用于评估引擎是否按预期工作(见解)。This data is used to evaluate whether the engine is performing as expected (the insight). 该见解用于主动优先引擎的维护计划(操作)。The insight is used to proactively prioritize the maintenance schedule for the engine (the action).

此参考体系结构使用 Azure PaaS(平台即服务)组件。This reference architecture uses Azure PaaS (platform-as-a-service) components. 在 Azure 上构建 IoT 解决方案的另一个推荐选项是:Another recommended option for building IoT solutions on Azure is:

  • Azure IoT CentralAzure IoT Central. IoT Central 是完全托管的 SaaS(软件即服务)解决方案。IoT Central is a fully managed SaaS (software-as-a-service) solution. 它抽象出技术选择,让你专注于你的解决方案。It abstracts the technical choices and lets you focus on your solution exclusively. 随这种简单性而来的是一种折衷:可自定义的程度会低于基于 PaaS 的解决方案。This simplicity comes with a tradeoff in being less customizable than a PaaS-based solution.

概括而言,处理遥测数据的方式有两种:热路径和冷路径。At a high level, there are two ways to process telemetry data, hot path and cold path. 具体采用哪种方式与延迟和数据访问的要求有关。The difference has to do with requirements for latency and data access.

  • 热路径 在数据到达时以近实时方式分析数据。The hot path analyzes data in near-real-time, as it arrives. 在热路径中,必须以非常低的延迟处理遥测数据。In the hot path, telemetry must be processed with very low latency. 热路径通常是使用流处理引擎实现的。The hot path is typically implemented using a stream processing engine. 输出可能会触发一个警报,或写入为可以使用分析工具查询的结构化格式。The output may trigger an alert, or be written to a structured format that can be queried using analytical tools.
  • 冷路径 以较长的时间间隔(每小时或每天)执行批处理。The cold path performs batch processing at longer intervals (hourly or daily). 冷路径通常处理大量数据,但结果不需要与热路径一样及时。The cold path typically operates over large volumes of data, but the results don't need to be as timely as the hot path. 在冷路径中,原始遥测数据会被捕获,然后馈送到批处理流程中。In the cold path, raw telemetry is captured and then fed into a batch process.


该体系结构包括以下组件。This architecture consists of the following components. 某些应用程序可能不需要此处列出的每个组件。Some applications may not require every component listed here.

IoT 设备IoT devices. 设备可以安全地注册到云中,并且可以连接到云以发送和接收数据。Devices can securely register with the cloud, and can connect to the cloud to send and receive data. 某些设备可能会是在设备本身上或在现场网关中执行一些数据处理的 边缘设备Some devices may be edge devices that perform some data processing on the device itself or in a field gateway. 我们建议将 Azure IoT Edge 用于边缘处理。We recommend Azure IoT Edge for edge processing.

云网关Cloud gateway. 云网关提供一个云中心,以便设备安全地连接到云并发送数据。A cloud gateway provides a cloud hub for devices to connect securely to the cloud and send data. 它还提供设备管理功能,包括设备的命令和控制。It also provides device management, capabilities, including command and control of devices. 对于云网关,我们建议使用 IoT 中心For the cloud gateway, we recommend IoT Hub. IoT 中心是从设备引入事件的托管云服务,充当设备与后端服务之间的消息代理。IoT Hub is a hosted cloud service that ingests events from devices, acting as a message broker between devices and backend services. IoT 中心提供安全连接、事件引入、双向通信和设备管理。IoT Hub provides secure connectivity, event ingestion, bidirectional communication, and device management.

设备设置。Device provisioning. 对于注册和连接许多组设备,我们建议使用 IoT 中心设备预配服务 (DPS)。For registering and connecting large sets of devices, we recommend using the IoT Hub Device Provisioning Service (DPS). DPS 可用于大规模分配设备并将设备注册到特定 Azure IoT 中心终结点。DPS lets you assign and register devices to specific Azure IoT Hub endpoints at scale.

流处理Stream processing. 流处理分析数据记录的大型流,并评估这些流的规则。Stream processing analyzes large streams of data records and evaluates rules for those streams. 对于流处理,我们建议使用 Azure 流分析For stream processing, we recommend Azure Stream Analytics. 流分析可以使用时间开窗函数、流聚合和外部数据源联接大规模执行复杂分析。Stream Analytics can execute complex analysis at scale, using time windowing functions, stream aggregations, and external data source joins. 另一个选项是 Azure Databricks 上的 Apache Spark。Another option is Apache Spark on Azure Databricks.

机器学习 允许通过历史遥测数据执行预测算法,实现预测性维护等方案。Machine learning allows predictive algorithms to be executed over historical telemetry data, enabling scenarios such as predictive maintenance. 对于机器学习,我们建议使用 Azure 机器学习For machine learning, we recommend Azure Machine Learning.

暖路径存储 保留一些数据,这些数据必须可从设备中立即提供,以用于报告和可视化。Warm path storage holds data that must be available immediately from device for reporting and visualization. 对于暖路径存储,我们建议使用 Cosmos DBFor warm path storage, we recommend Cosmos DB. Cosmos DB 是一种全球分布式多模型数据库。Cosmos DB is a globally distributed, multi-model database.

冷路径存储 保留一些数据,这些数据会保留较长时间,用于批处理。Cold path storage holds data that is kept longer-term and is used for batch processing. 对于冷路径存储,我们建议使用 Azure Blob 存储For cold path storage, we recommend Azure Blob Storage. 数据可无限期地以较低成本在 Blob 存储中存档,并且可以轻松访问以进行批处理。Data can be archived in Blob storage indefinitely at low cost, and is easily accessible for batch processing.

数据转换 操作或聚合遥测数据流。Data transformation manipulates or aggregates the telemetry stream. 示例包括协议转换,例如,将二进制数据转换为 JSON,或者合并数据点。Examples include protocol transformation, such as converting binary data to JSON, or combining data points. 如果数据在到达 IoT 中心之前必须转换,我们建议使用协议网关(未显示)。If the data must be transformed before reaching IoT Hub, we recommend using a protocol gateway (not shown). 否则,数据可以在到达 IoT 中心后转换。Otherwise, data can be transformed after it reaches IoT Hub. 在这种情况下,建议使用 Azure Functions,因为它已内置了与 IoT 中心、Cosmos DB 和 Blob 存储的集成。In that case, we recommend using Azure Functions, which has built-in integration with IoT Hub, Cosmos DB, and Blob Storage.

业务流程集成 根据来自设备数据的见解执行操作。Business process integration performs actions based on insights from the device data. 这可能包括:存储信息性消息、引发警报、发送电子邮件或短信,或者与 CRM 集成。This could include storing informational messages, raising alarms, sending email or SMS messages, or integrating with CRM. 我们建议将 Azure 逻辑应用用于业务流程集成。We recommend using Azure Logic Apps for business process integration.

用户管理 限制哪些用户或组可以在设备上执行操作,例如升级固件。User management restricts which users or groups can perform actions on devices, such as upgrading firmware. 它还定义应用程序中的用户功能。It also defines capabilities for users in applications. 我们建议使用 Azure Active Directory 对用户进行身份验证和授权。We recommend using Azure Active Directory to authenticate and authorize users.

安全监视 Azure 安全中心 iot 提供了用于 iot 工作负荷的端到端安全解决方案,并通过提供统一的可见性和控制、自适应的威胁防护以及从叶设备到各个工作负载的跨工作负载的工作负载来简化其保护。Security monitoring Azure Security Center for IoT provides an end-to-end security solution for IoT workloads and simplifies their protection by delivering unified visibility and control, adaptive threat prevention, and intelligent threat detection and response across workloads from leaf devices through Edge as well as up through the clouds.

可伸缩性注意事项Scalability considerations

IoT 应用程序应作为可以独立缩放的独立服务构建。An IoT application should be built as discrete services that can scale independently. 请考虑以下可伸缩性要点:Consider the following scalability points:

IoTHubIoTHub. 对于 IoT 中心,请考虑以下缩放因素:For IoT Hub, consider the following scale factors:

  • 发送到 IoT 中心的消息的最大每日配额The maximum daily quota of messages into IoT Hub.
  • IoT 中心实例中连接的设备的配额。The quota of connected devices in an IoT Hub instance.
  • 引入吞吐量 — IoT 中心可以采用多快的速度引入消息。Ingestion throughput — how quickly IoT Hub can ingest messages.
  • 处理吞吐量 — 可以采用多快的速度处理传入消息。Processing throughput — how quickly the incoming messages are processed.

每个 IoT 中心都在特定层中预配了特定单位数。Each IoT hub is provisioned with a certain number of units in a specific tier. 层和单位数决定了设备可以发送到中心的消息的最大每日配额。The tier and number of units determine the maximum daily quota of messages that devices can send to the hub. 有关详细信息,请参阅“IoT 中心配额和限制”。For more information, see IoT Hub quotas and throttling. 可以纵向扩展中心而无需中断现有操作。You can scale up a hub without interrupting existing operations.

流分析Stream Analytics. 如果流分析作业在流分析管道中的所有方面(从输入到查询到输出)都是并行的,那么它们的扩展效果最佳。Stream Analytics jobs scale best if they are parallel at all points in the Stream Analytics pipeline, from input to query to output. 完全并行的作业使流分析可以将工作拆分到多个计算节点上。A fully parallel job allows Stream Analytics to split the work across multiple compute nodes. 否则,流分析必须将流数据合并到一个位置。Otherwise, Stream Analytics has to combine the stream data into one place. 有关详细信息,请参阅利用 Azure 流分析中的查询并行化For more information, see Leverage query parallelization in Azure Stream Analytics.

IoT 中心自动基于设备 ID 对设备消息进行分区。IoT Hub automatically partitions device messages based on the device ID. 所有来自某一特定设备的消息将始终到达同一分区,但单个分区将具有来自多个设备的消息。All of the messages from a particular device will always arrive on the same partition, but a single partition will have messages from multiple devices. 因此,并行化的单元是分区 ID。Therefore, the unit of parallelization is the partition ID.

函数Functions. 从事件中心终结点进行读取时,每个事件中心分区都有函数实例的上限。When reading from the Event Hubs endpoint, there is a maximum of function instance per event hub partition. 该最大处理速率取决于一个函数实例可以采用多快的速度处理来自单个分区的事件。The maximum processing rate is determined by how fast one function instance can process the events from a single partition. 此函数应成批处理消息。The function should process messages in batches.

Cosmos DBCosmos DB. 若要横向扩展 Cosmos DB 集合,请使用分区键创建集合,并将该分区键包含在你编写的每个文档中。To scale out a Cosmos DB collection, create the collection with a partition key and include the partition key in each document that you write. 有关详细信息,请参阅选择分区键时的最佳做法For more information, see Best practices when choosing a partition key.

  • 如果按设备存储和更新单个文档,那么设备 ID 就是不错的分区键。If you store and update a single document per device, the device ID is a good partition key. 写入操作将均匀分布于这些键。Writes are evenly distributed across the keys. 每个分区的大小是受严格限制的,因为每个键值都有单个文档。The size of each partition is strictly bounded, because there is a single document for each key value.
  • 如果为每个设备消息都存储一个单独的文档,那么使用设备 ID 作为分区键将很快超过每分区 10 GB 的限制。If you store a separate document for every device message, using the device ID as a partition key would quickly exceed the 10-GB limit per partition. 在这种情况下,消息 ID 是更好的分区键。Message ID is a better partition key in that case. 通常仍应将设备 ID 包含在文档中,以便进行索引和查询。Typically you would still include device ID in the document for indexing and querying.

Azure 时序见解 (TSI) 是时序数据的分析、存储和可视化服务,提供的功能包括类似 SQL 的筛选和聚合,从而减轻了用户定义函数的需要。Azure Time Series Insights (TSI) is an analytics, storage and visualization service for time-series data, providing capabilities including SQL-like filtering and aggregation, alleviating the need for user-defined functions. 时序见解 提供数据资源管理器,用于可视化和查询数据,以及 REST 查询 api。Time Series Insights provides a data explorer to visualize and query data as well as REST Query APIs. 除时序数据外,此外还适用于需要对大型数据集进行查询聚合的解决方案。In addition to time series data, TSI is also well-suited for solutions that need to query aggregates over large sets of data. 支持多层存储、丰富的 Api、模型,并与 Azure IoT 生态系统、用于可视化的资源管理器以及通过 Power BI 等进行扩展。对于时序数据存储和分析,有一种建议。With support for multi layered storage, rich APIs, model and it’s integration with Azure IoT ecosystem, explorer for visualizations, and extensibility through Power BI, etc. TSI is our recommendation for time series data storage and analytics.

安全注意事项Security considerations

可信和安全通信Trustworthy and secure communication

从设备接收的所有信息和发送到设备的所有信息都必须都是可信的。All information received from and sent to a device must be trustworthy. 除非设备可以支持以下加密功能,否则它都应限制到本地网络,并且所有网间通信都应经过现场网关:Unless a device can support the following cryptographic capabilities, it should be constrained to local networks and all internetwork communication should go through a field gateway:

  • 采用已证实安全、经过公开分析并且已广泛实现的对称密钥加密算法的数据加密。Data encryption with a provably secure, publicly analyzed, and broadly implemented symmetric-key encryption algorithm.
  • 采用已证实安全、经过公开分析并且已广泛实现的对称密钥加密算法的数字签名。Digital signature with a provably secure, publicly analyzed, and broadly implemented symmetric-key signature algorithm.
  • 支持用于 TCP 或其他基于流的通信路径的 TLS 1.2,或者支持用于基于数据报的通信路径的 DTLS 1.2。Support for either TLS 1.2 for TCP or other stream-based communication paths or DTLS 1.2 for datagram-based communication paths. 支持 X.509 证书处理是可选的,可由在计算方面和传输方面更高效的 TLS 预共享密钥模式替换,该模式可以在具有对 AES 和 SHA-2 算法的支持时实现。Support of X.509 certificate handling is optional and can be replaced by the more compute-efficient and wire-efficient pre-shared key mode for TLS, which can be implemented with support for the AES and SHA-2 algorithms.
  • 可更新的密钥存储和每个设备的密钥。Updateable key-store and per-device keys. 每个设备必须具有唯一的密钥材料或向系统标识其身份的令牌。Each device must have unique key material or tokens that identify it toward the system. 设备应在设备上安全存储密钥(例如,使用安全的密钥存储)。The devices should store the key securely on the device (for example, using a secure key-store). 设备应能够定期更新密钥或令牌,或在紧急情况(例如系统入侵)下响应性地更新密钥或令牌。The device should be able to update the keys or tokens periodically, or reactively in emergency situations such as a system breach.
  • 设备上的固件和应用程序软件必须允许更新,以实现修复已发现的安全漏洞。The firmware and application software on the device must allow for updates to enable the repair of discovered security vulnerabilities.

但是,许多设备太受限制,无法支持这些要求。However, many devices are too constrained to support these requirements. 在这种情况下,应使用现场网关。In that case, a field gateway should be used. 设备通过局域网安全地连接到现场网关,并且网关实现与云的安全通信。Devices connect securely to the field gateway through a local area network, and the gateway enables secure communication to the cloud.

防止物理篡改Physical tamper-proofing

强烈建议设备设计包含防御物理操作尝试的功能,以帮助确保整个系统的安全完整性和可信度。It is strongly recommended that device design incorporates features that defend against physical manipulation attempts, to help ensure the security integrity and trustworthiness of the overall system.

例如:For example:

  • 选择提供安全存储和加密密钥材料(如受信任的平台模块 (TPM) 集成)的微控制器/微处理器或辅助硬件。Choose microcontrollers/microprocessors or auxiliary hardware that provides secure storage and use of cryptographic key material, such as trusted platform module (TPM) integration.
  • 保护启动加载程序并保护软件加载(在 TPM 中定位)。Secure boot loader and secure software loading, anchored in the TPM.
  • 使用传感器检测入侵尝试以及对操纵设备环境的尝试,并在检测到这些尝试时发出警报或可能执行设备的“数字式自破坏”。Use sensors to detect intrusion attempts and attempts to manipulate the device environment with alerting and potentially "digital self-destruction" of the device.

有关其他安全注意事项,请参阅物联网 (IoT) 安全体系结构For additional security considerations, see Internet of Things (IoT) security architecture.

监视和日志记录Monitoring and logging

日志记录和监视系统用于确定解决方案是否正常工作,并且用来帮助排查问题。Logging and monitoring systems are used to determine whether the solution is functioning and to help troubleshoot problems. 监视和日志记录系统帮助回答以下运行问题:Monitoring and logging systems help answer the following operational questions:

  • 设备或系统是否处于错误状况?Are devices or systems in an error condition?
  • 设备或系统是否已正确配置?Are devices or systems correctly configured?
  • 设备或系统是否在生成准确的数据?Are devices or systems generating accurate data?
  • 系统是否满足商业客户和最终客户的预期?Are systems meeting the expectations of both the business and end customers?

日志记录和监视工具通常包括以下四个组成部分:Logging and monitoring tools are typically comprised of the following four components:

  • 系统性能和时间线可视化工具,用于监视系统以及进行基本的故障排除。System performance and timeline visualization tools to monitor the system and for basic troubleshooting.
  • 缓冲的数据引入,用于缓冲日志数据。Buffered data ingestion, to buffer log data.
  • 持久性存储,用于存储日志数据。Persistence store to store log data.
  • 搜索和查询功能,用于在执行详细故障排除时查看日志数据。Search and query capabilities, to view log data for use in detailed troubleshooting.

监视系统提供对 IoT 解决方案的运行状况、安全性和稳定性以及性能的见解。Monitoring systems provide insights into the health, security, and stability, and performance of an IoT solution. 这些系统还可以提供更详细的视图,记录组件配置更改并提供已提取的日志记录数据,以便揭示潜在的安全漏洞、改进事件管理流程并帮助系统的所有者排查问题。These systems can also provide a more detailed view, recording component configuration changes and providing extracted logging data that can surface potential security vulnerabilities, enhance the incident management process, and help the owner of the system troubleshoot problems. 全面的监视解决方案包括在特定子系统中查询信息或跨多个子系统进行聚合的功能。Comprehensive monitoring solutions include the ability to query information for specific subsystems or aggregating across multiple subsystems.

开发监视系统时应首先定义正常操作、法规遵从性和审核要求。Monitoring system development should begin by defining healthy operation, regulatory compliance, and audit requirements. 收集的指标可包括:Metrics collected may include:

  • 报告配置更改的物理设备、边缘设备和基础设施组件。Physical devices, edge devices, and infrastructure components reporting configuration changes.
  • 报告托管语言的配置更改、安全审核日志、请求速率、响应时间、错误率和垃圾回收统计信息的应用程序。Applications reporting configuration changes, security audit logs, request rates, response times, error rates, and garbage collection statistics for managed languages.
  • 报告查询和写入性能、架构更改、安全审核日志、锁或死锁、索引性能以及 CPU、内存与磁盘使用情况的数据库、持久性存储和缓存。Databases, persistence stores, and caches reporting query and write performance, schema changes, security audit log, locks or deadlocks, index performance, CPU, memory, and disk usage.
  • 报告可影响依赖系统运行状况和性能的运行状况指标和配置更改的托管服务(IaaS、PaaS、SaaS 和 FaaS)。Managed services (IaaS, PaaS, SaaS, and FaaS) reporting health metrics and configuration changes that impact dependent system health and performance.

监视指标的可视化,这些指标用于向操作员发出警报,提醒其注意系统的不稳定状况,并促进事件响应。Visualization of monitoring metrics alert operators to system instabilities and facilitate incident response.

跟踪遥测数据Tracing telemetry

跟踪遥测数据使操作员可以跟踪一段遥测数据从创建起在该系统中经历的整个过程。Tracing telemetry allows an operator to follow the journey of a piece of telemetry from creation through the system. 跟踪对于调试和故障排除而言十分重要。Tracing is important for debugging and troubleshooting. 对于使用 Azure IoT 中心和 IoT 中心设备 SDK 的 IoT 解决方案,跟踪数据报可以源自云到设备的消息并包含在遥测数据流中。For IoT solutions that use Azure IoT Hub and the IoT Hub Device SDKs, tracing datagrams can be originated as Cloud-to-Device messages and included in the telemetry stream.


日志记录系统对于了解解决方案执行了哪些操作或活动、已发生的故障而言不可或缺,并可提供帮助来排除这些故障。Logging systems are integral in understanding what actions or activities a solution has performed, failures that have occurred, and can provide help in fixing those failures. 可以对日志进行分析,以帮助了解和纠正错误状况、增强性能特性,并确保符合管控规则和法规。Logs can be analyzed to help understand and remedy error conditions, enhance performance characteristics, and ensure compliance with governing rule and regulations.

虽然纯文本日志记录对前期开发成本的影响较低,但它对于计算机进行分析/读取而言更具挑战性。Though plain-text logging is lower impact on upfront development costs, it is more challenging for a machine to parse/read. 我们建议使用结构化日志记录,因为收集的信息既可供计算机分析,又可供用户阅读。We recommend structured logging be used, as collected information is both machine parsable and human readable. 结构化日志记录会将情况上下文和元数据添加到日志信息。Structured logging adds situational context and metadata to the log information. 在结构化日志记录中,属性是支持所有常见操作的实体,已格式化为键/值对或具有固定架构,以增强搜索和查询功能。In structured logging, properties are first class citizens formatted as key/value pairs, or with a fixed schema, to enhance search and query capabilities.

DevOps 注意事项DevOps considerations

使用基础结构作为代码 (IaC) 。Use the Infrastructure as code (IaC). IaC 是使用声明性方法) 管理基础结构 (网络、虚拟机、负载均衡器和连接拓扑。IaC is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) with a declarative approach. 模板应为版本和发布管道的一部分。Templates should be versioned and part of the release pipeline. 最可靠的部署过程是自动进行的,也是幂等的。The most reliable deployment processes are automated and idempotent. 一种方法是创建 Azure 资源管理器模板 来预配 IoT 资源和基础结构。One way is to create Azure Resource Manager template for provisioning the IoT resources and the infrastructure.

若要自动进行基础结构部署,可以使用 Azure DevOps Services、Jenkins 或其他 CI/CD 解决方案。To automate infrastructure deployment, you can use Azure DevOps Services, Jenkins, or other CI/CD solutions. Azure PipelinesAzure DevOps Services 的一部分,可运行自动化的生成、测试和部署。Azure Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments.

请考虑通过部署到各个阶段并在每个阶段运行验证,然后再转到下一个阶段,来暂存工作负荷;这样,你就可以以高度控制的方式将更新推送到生产环境,并最大程度地减少意外的部署问题。Consider staging your workloads by deploying to various stages and running validations at each stage before moving on to the next one; that way you can push updates to your production environments in a highly controlled way and minimize unanticipated deployment issues. 对于更新实时生产环境,建议使用蓝绿色部署和非配置的部署策略。Blue-green deployment and Canary releases are recommended deployment strategies for updating live production environments. 此外,请考虑在部署失败时为其提供良好的回退策略;例如,你可以从你的部署历史记录中自动重新部署以前的、成功的部署,Azure CLI 中的--error 标志参数就是个好示例。Also consider having a good rollback strategy for when a deployment fails; for example you could automatically redeploy an earlier, successful deployment from your deployment history, the --rollback-on-error flag parameter in Azure CLI is good example.

请考虑使用 Azure Monitor监视解决方案。Consider monitoring your solution by using Azure Monitor. Azure Monitor 是所有 Azure 服务的监视和日志记录的主要来源,它为 Azure 资源提供诊断信息。Azure Monitor is the main source of monitoring and logging for all your Azure services, it provides diagnostics information for Azure resources. 例如,可以监视 IoT 中心内发生的操作。You can for example, monitor the operations that take place within your IoT hub. Azure Monitor 支持的特定指标和事件,以及 Azure 诊断日志的服务、架构和类别。There are specific metrics and events that Azure Monitor supports, as well as services, schemas, and categories for Azure Diagnostic Logs.

有关详细信息,请参阅 Microsoft Azure Well-Architected Framework中的 DevOps 部分。For more information, see the DevOps section in Microsoft Azure Well-Architected Framework.

成本注意事项Cost considerations

通常,使用 Azure 定价计算器 来估算成本。In general, use the Azure pricing calculator to estimate costs. 其他注意事项,请参阅 Microsoft Azure Well-Architected 框架的 "成本" 部分。Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework.

有多种方法可以优化此参考体系结构中使用的服务相关的成本。There are ways to optimize costs associated the services used in this reference architecture.

Azure IoT 中心Azure IoT Hub

在此体系结构中,IoT 中心是从设备引入事件的云网关。In this architecture, IoT Hub is the cloud gateway that ingests events from devices. IoT 中心计费因操作类型而异。IoT Hub billing varies depending on the type of operation. 创建、更新、插入、删除是免费的。Create, update, insert, delete are free. 成功的操作(如设备到云和云到设备的消息)会收费。Successful operations such as device-to-cloud and cloud-to-device messages are charged.

已成功发送的设备到云消息将在进入 IoT 中心的 4 KB 区块中收费。Device-to-cloud messages sent successfully are charged in 4-KB chunks on ingress into IoT Hub. 例如,6 KB 消息将按两条消息收费。For example, a 6-KB message is charged as two messages.

IoT 中心在设备克隆 JSON 文档中维护有关每个连接的设备的状态信息。IoT Hub maintains state information about each connected device in a device twin JSON document. 从设备克隆文档中读取操作需要付费。Read operations from a device twin document are charged.

IoT 中心提供两个级别: 基本标准IoT Hub offers two tiers: Basic and Standard.

如果 IoT 体系结构使用双向通信功能,请考虑使用 标准 层。Consider using the Standard tier if your IoT architecture uses bi-directional communication capabilities. 该层还提供了一个免费版本,最适合用于测试目的。This tier also offers a free edition that is most suited for testing purposes.

如果只需要从设备到云的单向通信,请使用 基本 级别,这会更便宜。If you only need uni-directional communication from devices to the cloud, use the Basic tier, which is cheaper.

有关详细信息,请参阅 IoT 中心定价For more information, see IoT Hub Pricing.

Azure 流分析Azure Stream Analytics

Azure 流分析用于流处理和规则评估。Azure Stream Analytics is used for stream processing and rules evaluation. Azure 流分析按照处理数据所需的计算、内存和吞吐量,按小时 (SU) 的流式处理单元数来定价。Azure Stream Analytics is priced by the number of Streaming Units (SU) per hour, which takes into compute, memory, and throughput required to process the data. 按作业对 Azure IoT Edge 流分析计费。Azure Stream Analytics on IoT Edge is billed per job. 当流分析作业部署到设备时,无论作业状态是 "正在运行"、"已失败" 或 "已停止",都将开始计费。Billing starts when a Stream Analytics job is deployed to devices regardless of the job status, running, failed, or stopped.

有关定价的详细信息,请参阅 流分析定价For more information about pricing, see Stream Analytics pricing.

Azure FunctionsAzure Functions

Azure Functions 用于在数据到达 IoT 中心后转换数据。Azure Functions is used to transform data after it reaches the IoT Hub. 从成本角度来看,建议使用 消耗计划 ,因为只需为所使用的计算资源付费。From a cost perspective, the recommendation is to use consumption plan because you pay only for the compute resources you use. 每次事件触发函数的执行时,将根据每秒资源消耗收费。You are charged based on per-second resource consumption each time an event triggers the execution of the function. 在单个执行或批处理中处理多个事件可降低成本。Processing several events in a single execution or batches can reduce cost.

Azure 逻辑应用Azure Logic Apps

在此体系结构中,逻辑应用用于业务流程集成。In this architecture, Logic Apps is used for business process integration.

逻辑应用定价适用于即用即付模型。Logic apps pricing works on the pay-as-you-go model. 每次运行逻辑应用时,都会计量触发器、操作和连接器的执行。Triggers, actions, and connector executions are metered each time a logic app runs. 所有成功和失败的操作(包括触发器)都视为执行。All successful and unsuccessful actions, including triggers, are considered as executions.

例如,逻辑应用一天处理1000消息。For instance, your logic app processes 1000 messages a day. 5个操作的工作流将成本低于 $6。A workflow of five actions will cost less than $6.

有关详细信息,请参阅 逻辑应用定价For more information, see Logic Apps pricing.

数据存储Data Storage

对于冷路径存储,Azure Blob 存储是最具成本效益的选项。For cold path storage, Azure Blob Storage is the most cost-effective option.

对于热路径存储,请考虑使用 Azure Cosmos DB。For warm path storage, consider using Azure Cosmos DB. 有关详细信息,请参阅 Cosmos DB 定价For more information, see Cosmos DB pricing.

后续步骤Next steps