写点什么

物联网的一种参考架构(第二篇)

2016 年 6 月 20 日

在我们一月中旬发布的文章中,曾经介详细绍过 IoT 参考架构 RILA(Reference IoT Layered Architecture)的方方面面。当时介绍了该架构的每个层面,并提到后续将有另一篇文章介绍如何将该架构的不同层面对应到现实用例中。

当时承诺的后续文章终于有下文了,本篇我们将侧重于这一参考架构中的架构和概念实现。需要注意的是,我们不能随便挑选一个参考架构并立刻“尝试实现”,而是需要将其作为一种“样式”,据此定义要在 IoT“系统”中使用的不同组件。乍看之下具体实现的结果可能与参考架构本身的结构有较大差异,但如果谨慎地将架构与所要实施的组件一一对应,最终将获得完全相同的结果。

为了将 RILA 与实际用例相互对应,我们从不同行业挑选了两个用例,这两个用例可能很快就会变为现实。下图展示了第一个用例,就叫它“冰箱”用例吧:

这个用例的基本想法是在可能出现电力峰值(电网丢负荷)的时候自动触发(全城或部分地区的)电冰箱的制冷操作,借此降低电力峰值对电厂造成的危险。因此该用例的目标在于由电厂触发大量智能电冰箱的“制冷”操作。上图显示的虚线代表冰箱到电厂的(可选)反馈环路,借此电厂可以评估共可以触发多少电冰箱进行制冷,并借此确定冰箱的数量是否足以降低峰值,或是否有必要采取其他(可选)措施。下表列出了该用例涉及的对象,用例想要实现的目标,前提条件,成功场景概括,以及后续情况:

涉及的对象 最终用户,冰箱制造商,供电局,冰箱的板载系统,电厂的控制系统 目标 _ 电厂控制系统 _ 向 _ 冰箱板载系统 _ 发送制冷工作信号,让冰箱在某个同一控制的集中时间点开始制冷,避免出现电网丢负荷的情况。 前提条件 _ 冰箱制造商 _ 和 _ 供电局 _ 共同制定一套通信协议,通过这个协议让冰箱接收控制信号,并发送相关状态信息。 成功场景概括 1. _ 最终用户 _ 购买 _ 冰箱制造商 _ 生产的冰箱。
2. _ 最终用户 _ 配置冰箱连接到互联网。
3. 冰箱的板载系统 _ 连接到 _ 电厂的控制系统
4. _ 供电局的电厂控制系统 _ 发现出现电力峰值,向 _ 冰箱的板载系统 _ 发送控制信号。
5. _ 冰箱的板载系统 _ 收到这个信号,判断冰箱内部温度是否足够低。
6. 冰箱的板载系统 _ 将即将制冷的信息发送给 _ 电厂控制系统
7. _ 电厂控制系统 _ 收到 _ 冰箱板载系统 _ 发送来的信息,对其进行处理并保存起来。
8. _ 冰箱板载系统 _ 启动冰箱压缩机开始制冷。

后续情况 _ 冰箱板载系统 _ 开始制冷,_ 电厂控制系统 _ 知道冰箱已经开始制冷了。冰箱板载系统和电厂控制系统需要构建并监视相关的上下文情境条件。这个用例中主要涉及两种条件:

  1. 电厂控制系统的上下文情境
  2. 冰箱板载系统的上下文情境

冰箱板载系统需要管理的上下文情境更为简单一些,通过这种上下文,冰箱板载系统可以决定是否需要制冷。电厂控制系统的上下文情境更为复杂,需要通过冰箱的上下文情境做出相应决策。然而在这个场景中,电厂的上下文情境无需对外发布,只要将操作命令发送至冰箱即可。

看过第一个用例后,可以考虑将我们的参考架构 RILA 与其进行对应。我们定义了包含下列 6 层内容的架构:

  1. 应用程序集成(Application Integration)
  2. 物件集成(Thing Integration)
  3. 上下文管理(Context Management)
  4. 数据管理(Data Management)
  5. 设备管理(Device Management)
  6. 设备集成(Device Integration)

下图展示了架构中不同层与这个用例的对应关系。

上图不同层使用不同颜色显示,分为黑色和灰色。灰色层通常可以用非常简单的方式设计而来,甚至在某些场景中是不需要的。

大致来看,两端都存在所有 6 层内容,冰箱和电厂需要通过某种方式实施这 6 层。然而具体实现的复杂度取决于可用条件和用例要实现的功能。为确定每种物件每层的设计和实施范围,需要对每种物件(或每种物件对应的领域,如果采用 领域驱动的设计方法的话)都有所了解。这里需要注意,上图所示场景在具体描述上可能有所差异,对冰箱的上下文情境进行管理只是一个范例,实际情况可能更加复杂,因此用黑色表示。这个用例中需要使用“智能”的冰箱,而本例中我们设想的冰箱是相当“笨”的。参考架构与场景的映射是一回事,每一层的设计是另一回事。下文将介绍该场景中不同层面的具体设计。

在这个场景中,我们假设用户可以使用自己的智能手机与冰箱通信。为了与智能手机应用通信,冰箱必须具备应用程序集成层。另外可能还需要在供电局一端实施某种程度的应用程序集成。不过依然有必要考虑该用例是否需要涉及这个问题(毕竟本例只需要考虑电厂控制系统向冰箱发送控制信息)。

两端都需要实现物件集成,具体方式并不复杂。在这样一个原型中,物件发现模块可能相当简单,我们可以假设冰箱随时都能与电厂通信。最终通信连接的建立则可以使用成熟的规范。

在上下文管理方面,首先需要在冰箱的上下文情境和要向冰箱发送的操作指令之间达成一致。电厂端的上下文管理略显复杂,但冰箱端相对简单一些。电厂端在这里可以视作一个黑盒子,大部分情况下我们只需要将其与检测和预测峰值的现有系统集成即可。一旦检测到峰值便触发冰箱执行制冷操作,并通过物件集成将指令下发至已注册的冰箱。冰箱接到操作指令后开始判断是否需要制冷(在首个原型中可通过简单的时间约束实现)并将判断结果发回给电厂。

类似的数据管理机制在冰箱上实现起来很简单,但在电厂端略微复杂。冰箱基本上只需要记录什么时候温度足够低,什么时候需要再次制冷(可通过温度传感器实现)。电厂需要决定冰箱制冷到足够低的温度之后所耗费的电力是否可以降低峰值。如果还不够,则需要进一步执行后续的其他操作。

冰箱端还需要设备管理和设备集成层。电厂端可以假设已具备负责处理峰值预测和决策的系统,但该系统需要与我们的架构集成在一起(可通过应用程序集成或物件集成的方式实现)。

这里需要注意,为了让这个方案设计投入实用,还需要与两端(电冰箱制造商和供电局)的领域内专家进行合作,才能更好地理解这两个领域并开发出足够好的设计。

尽管我们的设计距离完善还很远,不过依然可以先来看看实现方面的创意(也许可以开始快速创建第一个原型)。上文提过,我们希望最开始的设置尽可能简单。目前已经有装备显示器和各种功能的冰箱,例如新一代 Samsung Family Hub ,此类型号的功能已经远远超出需求(不过依然可以用)。在这个场景中,制造商并没有为冰箱提供完整的平台,但提供了可与冰箱通信的智能手机应用。这样的冰箱需要具备:

  1. 自带互联网连接和通信接口,这样才能随时与电厂通信(物件集成)。
  2. 供用户通过智能手机访问的接口,这样才能让用户打开或关闭与电厂通信的功能(应用程序集成)。
  3. 相关传感器和逻辑,这样才能让冰箱在接到电厂指令后决定是否可以开始制冷。

实现首个原型的平台可以考虑配合使用 Google App Engine 和 Google Brillo。虽然 Brillo 尚未正式发布,但已经可以开始设想基于 Brillo 操作系统的冰箱了。这里可以使用 Google Cloud Messaging 在智能手机、云冰箱,以及电厂之间实现通信。下图展示了使用 Google Brillo 和 Cloud Messaging 搭建的简化环境。请注意,在这里 Google 只是范例,使用 Apple HomeKit、Windows Azure 或开源平台也可以实现类似的效果。

在冰箱端我们将整个栈打包到 Brillo 中。对于物件集成层的通信,可以使用 Cloud Messaging API。不过电厂在这里依然被看作黑盒子,因为电厂具体使用什么技术无关紧要(反正电厂里通常已经具备现成的系统),我们只需要确保电厂的控制系统(或以此为基础的集成组件)能够实现 Brillo 和 Cloud Messaging API 所实施的通信标准即可。

当然整个系统也可以用相互独立的方式实现。拆箱即用的标准化,是诸如 Google Brillo 这样的平台所提供的优势之一,用户可以借此对整个系统轻松进行缩放。

至此已经完整介绍了第一个用例。为了证明这套参考架构的灵活性,下文将介绍第二个用例。从中也可以看到 RILA 所定义的“必备 IoT 组件”是如何融入整个场景的。

在第二个用例中,有一家销售汽车保险的保险公司希望更清晰地预测(从保险业务的角度来看)哪些客户是“良性”的,哪些是“恶性”的。这家保险公司希望使用驾驶行为数据实现这一目标(也就是所谓的数据科学)。该用例的大致情况如下图所示。

在第一个场景中,这家保险公司需要获得大量数据,并通过数据科学为保险业务定义“良性”和“恶性”司机的类别。这些数据并不需要对应到具体司机,匿名数据就够了。数据越多结果越精确。因此这家保险公司希望与汽车制造商合作以获得所需数据。

在第二个场景中,(通过对第一个场景进行扩展)这家保险公司需要根据投保人的个性化驾驶行为进一步定制每份车险的保险策略。这一过程由上图中虚线箭头所代表。

下表描述了该用例涉及的对象,用例想要实现的目标,前提条件,成功场景概括,以及后续情况:

涉及的对象 保险公司、保险公司的系统、汽车制造商、汽车制造商的系统、车主、车载计算机 目标 _ 保险公司 _ 收集有关具体车型尽可能多的匿名驾驶行为数据,借此针对具体车型的驾驶行为数据调整保险策略。 前提条件 _ 保险公司 _ 和 _ 汽车制造商 _ 确定数据交换策略和涉及的车型。_ 保险公司 _ 为 _ 汽车制造商 _ 提供的数据支付一定费用。_ 车主 _ 通过匿名分享自己数据得到一定好处(例如 _ 汽车制造商 _ 提供的低价维修服务)。 成功场景概括 1. _ 车主 _ 购买一辆车。
2. 车载计算机 _ 询问 _ 车主 _ 是否要将驾驶行为数据匿名分享给 _ 汽车制造商(以及可能的第三方)。
3. _ 车主 _ 同意分享某些数据。
4. 车载计算机 _ 按照预定义的时间间隔,定期将匿名驾驶行为数据发送到 _ 汽车制造商的系统
5. _ 汽车制造商的系统 _ 存储驾驶行为信息,并通知 _ 保险公司的系统 _ 某一车型有新数据可用。
6. _ 保险公司的系统 _ 通过 _ 汽车制造商的系统 _ 收集驾驶行为数据,并将其存入决策工作使用的数据池。
7. _ 保险公司 _ 的系统将新数据以功能的形式集成于保险策略使用的预测模型。

后续情况 _ 保险公司 _ 可以使用驾驶行为数据更详细地计算保险策略。(随后即可将其用于为保险公司销售人员提供指导等用途。)这里我们打算专注于第一个场景。与冰箱的用例类似,我们可以将 RILA 的不同层面映射为下图所示的系统组件。

对于保险公司的用例,只需要在汽车中实施完整的 RILA 堆栈,因为需要集成的设备都在汽车中,其他操作都是在数据传输层面上进行的。在这里可能有人会质疑我们对“物件”的定义。只有设备才算是“物件”吗?我们的定义并不这样认为,并非只有设备才是物件。不过此处的合理推论是,并非所有物件都必须具备设备集成和设备管理层(没有设备,当然也就不需要进行设备集成和管理)。

汽车需要在应用程序集成层具备一些接口,这样车主才能与系统通过某种形式通信(车载系统通常已经具备这样的能力)。数据传输至汽车制造商的系统后,只需要进行少量的上下文情境管理、数据管理,以及物件集成工作即可实现用例需求。保险公司(以及汽车制造商的系统)可能也需要进行应用程序集成,因为还需要使用这些数据执行某些任务,例如运行预测模型的软件必须能通过某种方式访问这些数据。

这个保险公司用例的实现想法在于:汽车的车载计算机可以充当一种应用平台。随后用户即可下载保险公司(与汽车制造商合作)提供的应用,借此让用户控制什么可以分享,什么不能分享。取决于用户的分享意愿,可以由保险公司或汽车制造商为车主提供一定的好处(这就为我们提供了一种理想的业务模式)。一旦实现最终的个性化,就可以通过了解上下文情境的保险策略实现“驾驶即付费”的业务模式,并进一步扩展为“按照驾驶方式付费”的模式。

本文介绍的这两个用例较为宽泛,除了所描述的场景外,通过本文提供的用例还可以构思出很多不同使用场景。为了针对不同用例打造真正实用、有价值的设计,还需要对相关领域有所了解。

确定用例场景后,就可以确定要在参考架构(例如 RILA)中使用哪些 IoT 组件。通信和安全措施的实施方式所实现的标准化程度越高,就能越容易地将 IoT 系统与以后部署的其他 IoT 系统相集成。无论其他保险公司或汽车制造商打算使用保险公司用例,或其他电厂或冰箱(制造商)打算使用冰箱用例,只要具备确认有效的合适结构(例如类似 Google Brillo 这样的机制),集成工作就会变得更简单。参考架构只是为了向大家提供一种通用的模式,帮助大家避免在实际开发中“漏掉”某个重要的组件或设计因素。

总之需要强调的是,最重要的第一步始终是一开始就从功能层面上定义要实现的用例,随后再考虑具体的技术规范细节。

为了确定希望通过系统实现的最终目的,还要明确定义涉及的对象和想要实现的目标。虽然这是一种众所周知的范式,但对 IoT 世界中的应用程序和系统开发工作,这一点尤为重要,因为具体用例通常更复杂,包含的场景也更多样。领域驱动的设计指南可以帮您实现更有价值的灵活设计。

通过诸如RILA 等参考架构,我们可以了解实现IoT 应用程序的过程中必不可少的一些组件。通过明确具体用例所要实现的功能规范,就可以确定参考架构中不同组件的具体设计方式。通过功能层面上对用例和设计进行结合,即可确定最终的技术规格和实现方法。随后便可结合专业技能确定将现有平台用于何处才能提供一个或多个参考架构组件所要实现的功能,甚至如何使用现有平台组成某些用例所需的整个技术堆栈。

关于本文的作者

Hannelore Marginean是德国 Senacor Technologies 公司的开发人员。她喜欢探索技术领域的创新,已经在 IoT 的可行性、安全风险,以及收益方面展开了大量研究。业余时间她喜欢绘画和演奏吉他。

Daniel Karzel是德国 Senacor Technologies 公司的技术顾问。早在取得移动计算领域硕士学位过程中,他就已经在研究情境感知计算和物联网。除了思考未来的软件架构,他还喜欢在闲暇时间演奏手风琴以及在中国旅游。

Tuan-Si Tran是德国 Senacor Techologies 公司的软件开发者。他是一位奋战在第一线的技术爱好者,非常热衷于“尖端”技术。闲暇时他喜欢打网球。

查看英文原文: A Reference Architecture for the Internet of Things (Part 2)

2016 年 6 月 20 日 18:442986
用户头像

发布了 283 篇内容, 共 84.6 次阅读, 收获喜欢 34 次。

关注

评论

发布
暂无评论
  • Vivint 联合 Cloudera 对来自智能家居的大数据进行分析

    Vivint最近宣布与Cloudera合作,以期对那些来自智能家居传感器的数据进行更加有效地分析。来自住宅的传感器种类从温控装置到面向安全的设备,纷繁多样。通过对这些数据的集中分析,Vivint可以为用户提供各种可操作的洞见与建议,从而为用户带来节能的效果。

  • 物联网技术周报第 73 期: Google 推出 Android Things 新物联网平台

    Google推出Android Things新物联网平台;物联网Cortana小娜诞生;OCF集众厂商力推物联网互联;在 Raspberry Pi 3 运行 Android Things;设计和构建安全的 IoT 解决方案:保护 IoT 设备和网关;如何将 Arduino 连接到 LabView。

  • 第 145 讲 | 李列为:技术人员的商业思维

    “劳心者治人,劳力者治于人。”

    2018 年 12 月 25 日

  • 未来电动汽车的软件架构

    西门子在近期发表的一篇新闻中强调了新兴信息与交互技术对于未来的电动汽车的重要性。一项由德国政府资助的项目正研究适合于这类汽车的软件架构。

  • 构建 Dashboard

    2019 年 9 月 27 日

  • 物联网的一种参考架构

    本文是两篇系列文章中的第一篇,我们在将这一系列文章中首先从一个抽象的角度了解IoT的参考架构,然后分析具体的架构与所选择的用例的实现。第一篇文章将涵盖更具体与完整的架构中的各种定义,而第二篇文章将通过实际的用例应用这种架构。

  • 在自动驾驶汽车的开发软件中使用模型

    在类似无人驾驶汽车这样自治动力系统的软件开发中,模型发挥着重要的作用——模仿及验证人们的驾驶行为,记录系统日志并生成代码。在2016年度的GOTO Amsterdam大会上,美国亚利桑那大学电气与计算机工程专业的副教授Jonathan Sprinkle就无人驾驶汽车的软件开发主题发表了演讲,他认为:无人驾驶汽车的软件起初都是单一整体式的,但如今逐渐向着可组合的拼装式方向发展,新的软件可根据需求进行功能拼装。此外,之前大量的数据都来自诸如雷达、GPS和摄像机等传感器,但如今通过传感器融合,并朝着可感知的方向发展,这些数据都合并到了同一张地图上。这意味着如今的汽车不再将周边整个世界视为静态数据,而是主动去感知,并根据新增类型的传感器推断这些事物会如何移动。

  • AWS 与 SAP 宣布推出 IoT 互操作性解决方案

    今天,SAP 宣布与 Amazon Web Services IoT 开展合作,并正式宣布 SAP Leonardo IoT 与 AWS IoT Core 之间实现互操作性。

  • 安全、快捷、简单,一瞥 re:Invent 上六项 IoT 新发布

    在11月29日的AWS re:Invent大会上(拉斯维加斯时间),Andy Jassy一口气发布了AWS IoT 1-Click、AWS IoT Device Management、 AWS IoT Device Defender、AWS IoT Analytics、 Amazon  FreeRTOS、Greengrass ML Inference 等六项与IoT有关的新服务或新设备。

  • 智能家居应用程序框架权限模型的安全影响

    本文分析了流行的智能家居编程框架SmartThings,发现很多智能家居应用会自动获得过高特权,导致用户面临远程攻击的风险,进而可能造成人身、财物,以及心理伤害。

  • 后工程化时代的通天塔

    演讲嘉宾 侯振宇,支付宝前端技术专家。 内容介绍 工程化通常都会经历两个阶段,工具化和自动化。第一个阶段中,通过创造足够多的工具能让一些比较繁琐的、重复性强的工作变得容易起来。有了足够多的工具后,自然就会朝着研发中各个环节的自动化上努力。在我的团队工程化实践中,对其中的一些难点做了技术上的突破,甚至将设计也纳入到自动化的环节中,这些突破将在此演讲中分享给大家。 同时,在完成了自动化之后,如何进一步提升研发效能仍然是我们要思考的问题。我们在探索中发现,通过设计结构化的语言,是能够将“需求”这最初的一环也纳入到整个研发工程化体系中的。并且可以预见将需求纳入之后,现行的人工智能技术可以以极小的成本接入其中,很快就能在 web 领域实现让机器写代码。 演讲大纲 工具化和自动化时代的关键问题 后工程化时代的突破

    2018 年 9 月 12 日

  • 2016 物联网版图:物联网奇点是否已经来临?

    物联网是世界上最让人觉得疑惑的科技趋势吗?一方面,我们了解到它将要成为史诗般的存在,并且所有的预言都说它将带来数百亿互联的设备,创造多达万亿美元的经济价值。但是,在另外一方面,终端用户呈现出的主要感觉是“无聊”——现在的IoT感觉就是新互联产品的说辞,其中很多似乎是用来解决平常的贵族问题的:其昂贵的设备使得它更倾向于“最好有”的类型,而非“必须有”的类型。而且,从所有的关于技术趋势的演讲来看,事情似乎以非常慢的速度在发展,每年的进展非常小。

  • 借助平台互操作性打造物联网生态

    物联网的碎片化和互操作性的缺乏使得物联网生态难以被更广泛地接受。旨在促进整个生态进一步发展的BIG IoT(Bridging the Interoperability Gap of the IoT,弥补物联网互操作性鸿沟)项目应运而生。

  • 行业视角:产品经理眼中的人工智能

    你理解人工智能,知道人工智能的产业发展现状如何吗?人工智能产品经理的人才结构又是怎样的呢?

    2020 年 12 月 14 日

  • APNs:聊一聊第三方系统级消息通道的事

    如何在App关闭或网络功能受限的情况下,仍然成功发送消息到接收人设备呢?

    2019 年 10 月 2 日

  • 面向 IoT 软件工程的关键抽象

    本文概述了复杂IoT系统和相关应用程序的关键一般特征。基于此,本文作者找出了可以为面向IoT的软件工程提供基础的软件抽象,其中包括系统利益相关者、用户、需求、虚拟身份以及联盟。

  • 桌面开发的未来

    桌面开发的未来是什么?从终局的视角来看,桌面开发的终极目标,是让儿童可以轻松编写出生产级的应用。

    2019 年 7 月 16 日

  • Juval Löwy:为什么每个类都应该是一个服务

    Juval Löwy开创了一种构建面向服务的应用程序的新方法。在这种方法中,每个类本身都代表一个服务。虽然这些应用程序乍一看可能像“类爆炸”,但它们实际上真是系统分解的结果,经过了恰当的分析和设计。Juwal说明了他的意图,并描述了开发团队如何从这个过程中获得提升。

  • 使用 LoRaWAN 将您的设备连接到 AWS IoT

    对于许多 IoT 使用案例而言,传感器只需要以较低的频率和比特率传输数据。

  • “老司机”成长之路:自动驾驶车辆调试实践

    本文介绍自动驾驶系统的调试、集成实践。

发现更多内容

计算机操作系统基础(五)---Linux的进程管理

书旅

php 线程 多线程 操作系统 进程

SpringBatch系列之Remote-Chunking

稻草鸟人

大数据 Spring Boot SpringBatch 批量任务

IM聊天教程:发送图片/视频/语音/表情

GoEasy消息推送

websocket 即时通讯 聊天室 聊天

架构师训练营第四周作业

张明森

如何成为一名合格的 C/C++ 开发者?

张小方

c++ Linux 编程语言 架构设计 后端开发

对直播带货的一点思考

Neco.W

直播 直播带货

从0开始设计Flutter独立APP | 第二篇: 完整的国际化语言支持

渔子长

flutter 前端

科学计算软件被禁,阿里达摩院能研发Matlab?

飞哥

阿里巴巴 matlab

极客大学架构师训练营第四周学习总结

竹森先生

极客大学 极客大学架构师训练营

【写作群星榜】6.20~6.26 写作平台优秀作者 & 文章排名

InfoQ写作平台官方

写作平台 排行榜

如何学 Java,我说点不太一样的学习方式

四猿外

学习 程序员 个人成长 程序员成长

告别静默式看房 融云音视频助力上海中原 App 上线 VR 带看服务

Geek_116789

了不起的 TypeScript 入门教程 [1.2 w字]

阿宝哥

Java typescript 前端 Web

创新管理体系标准ISO56002介绍

涛哥

数字化转型 创新

深入浅出kubernetes之WorkQueue详解

博文视点Broadview

Kubernetes 源码分析 k8s 队列 延迟队列

海阅优品致力打造新零售蓝海

Geek_116789

架构师训练营第四周学习总结

张明森

架构师训练营第四周课后作业

竹森先生

极客时间 极客大学架构师训练营

融云年中大促钜惠来袭 IM+RTC 超值套餐最低6折起

Geek_116789

Dart vs Swift

柠檬水

swift dart

来了!8M/S+速度,Pdown复活!

程序员生活志

谈谈架构和微服务<一>

Gabriel

架构 微服务 微服务架构 领域驱动设计 软件设计

为什么建议你使用枚举?

王磊

Java 枚举

MySQL实战45讲笔记(1)

王传义

msyql

聊一聊程序员如何增加收入

张小方

程序员 互联网 面试 副业赚钱 薪资

大型互联网架构与集群技术

xzm

一二线城市知名 IT 互联网公司名单(新版)

程序员生活志

互联网 IT 大厂

实现简单的"纤程"

Near

架构演化

满山李子

一群龙舟划手 “拍了拍” 你:端午节安康~

BonreeAPM

MySQL系列 - SQL查询与修改执行过程

俊俊哥

MySQL 性能优化 关系型数据库 存储

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

物联网的一种参考架构(第二篇)-InfoQ