面向控域的体系结构：一种智能万物互联的体系结构风格

徐志伟 曾 琛 朝 鲁 彭晓晖

(中国科学院计算技术研究所 北京 100190) (中国科学院大学 北京 100049)

《计算机研究与发展》已创刊60年，可喜可贺！

自ENIAC问世，世界计算机事业已有了70余年的发展历史.图灵奖得主Butler Lampson以计算机应用为主线，将计算事业发展进程划分为3个阶段[1].他认为：每隔30年会出现一波计算机新应用(“Every 30 years there is a new wave of things that computers do”).1950年到今天是第一波，称为模拟(simulation， model)，其特征是对物理世界和人类社会的各种活动建模计算，如核武器数值模拟、蛋白质折叠、公司工薪系统、计算机游戏等.1980年到今天是第二波，称为互联通信(communication， connect)，其特征是通过计算机实现人的互联(“connect people”)，如电子邮件、电子商务、搜索引擎等.2010～2040年正在出现第三波，称为具象(embodiment，engage)，其特征是计算机被赋予各种具体的物理器物形态，使得计算机密切融入物理世界(“engage with the physical world in a non-trivial way (embodiment—giving them bodies)”)，初步的例子包括无人车、机器人、智能微尘等.

中国科学院的《中国至2050年信息科技发展路线图》研究提出了相近的观点[2-3].这项2007年启动的研究判断，到2035年，中国将初步实现普惠计算(computing for the masses)，计算模式将实现从人机共生向人机物社会的过渡，即从人机二元计算拓展到人机物三元计算(human-cyber-physical ternary computing)，其中“物”指的是三元计算中的物理世界(computing in the ternary universe of the human society, the cyberspace, and the physical world)[3].这个判断启发了中国科学院设立新一代信息技术战略性先导专项，产出了海云计算、寒武纪深度学习处理器等创新成果[4].

未来计算机应用将兼有模拟、互联、具象特征，是人机物融合的三元计算应用系统.我们将这个宏观应用趋势称为智能万物互联趋势，并将2010～2040时段称为智能万物互联时代.业界已经出现了新的研究方向，例如物联网(Internet of things)、智能万物互联网(smart Internet of things, intelligent Internet of everything, smart Web of everything等)、海云计算(cloud-sea computing)、边缘计算(edge computing)、物端计算系统[4-10]等.

这些系统的“智能”是什么呢？Jordan最近将智能研究分为3类方向[11]:

1) 模仿人的智能(human-imitative AI， AI)，如下棋赢了世界冠军.

2) 增强人的智力与创造力(“intelligence aug-mentation” ， IA)，如搜索引擎拓展了人的记忆力.

3) 智能基础设施(intelligent infrastructure， II)，“whereby a web of computation, data and physical entities exists that makes human environments more supportive, interesting and safe.” Jordan教授特别指出，智能基础设施(II)远不是当今的物联网，它需要发展出“far higher level of abstraction”去应对“far grander set of challenges”[11].

产业界已经做了大量将计算机拓展到物理世界的工作.根据BI Intelligence公司的市场研究，全球物联网设备(不含智能手机)装机量在2017年已经超过90亿个，在2025年将超过550亿个[12].同时，2个生态问题也日益明显：1)昆虫纲悖论，即物联网生态严重碎片化；2)用户数据过度集中，尤其是集中到大厂商，以至于万维网(WWW)发明者Tim Berners-Lee大力呼吁“重新去中心化”(redecentralize)[13]，并在2018年9月正式发起了名为Solid的新平台[14].

这些问题不只是商业模式和管理学问题，也是计算机科技问题.我们需要协调的、甚至统一的分布式系统体系结构抽象，同时支持解决3个难点问题：创新自由、安全隐私、合规治理，从而应对上述2个生态问题.借鉴面向服务的体系结构(service-oriented architecture， SOA)[15]和REST(representational state transfer)体系结构风格的成功经验[16]，本文提出这样一种体系结构风格，称为面向控域的体系结构(zone-oriented architecture， ZOA).

ZOA是一种面向智能万物互联、针对智能基础设施(II)的体系结构风格，其核心学术概念是控域，用以划分人机物三元世界并界定其子集范围.控域的基本思想是：像苹果智能手机那样用一套控制策略支持全球移动互联网的方式，难以支持全球智能万物互联网；但可将全网划分成多个控域，每个有自己的统一或相容的控制策略.控域各有利弊，需要用计算机科学的方法将控制权及其范围刻画并揭示出来，以分析和指导设计分布式计算体系结构，供开发者、运维者、用户选择使用.ZOA只是提供底层体系结构风格支撑，它本身并不能解决智能万物互联系统所面对的2个生态问题与3个难点，需要开发者、运维者、用户积极参与.

1 控域研究问题分析

ZOA瞄准2个生态问题：昆虫纲悖论和数据集中问题.这2个问题出现的本质原因之一，是难以同时解决创新自由、安全隐私、合规治理3个难题.这些问题表面上看是商业模式和管理模式问题，而不是计算机科学技术问题.但是，历史经验表明，有些貌似经济学和管理学的问题，本质上需要新技术的支持.例如，分时(time sharing)技术支持了从批式计算到交互式计算的使用模式转变；DevOps技术支持了云计算服务快速迭代，改变了软件开发的管理流程；应用商店(app store)技术将PC应用开发使用模式变革为更加适合移动互联网和智能手机的开发使用模式，也改变了应用软件的销售模式.

1.1 昆虫纲悖论

借鉴Lampson博士的思想，我们将互联通信时代的连接人的设备称为人端设备，如PC机、智能手机；将具象时代(智能万物互联时代)融入物理世界的设备称为物端设备.另外我们还有不直接与人和物连接的云端设备.以物端设备为主的计算模式称为物端计算，相应的软硬件系统称为物端计算系统.

学术界和产业界已有多个预测，显示未来我们将有万亿级数量的物端设备(trillions of things, smart devices)[17].每个物端设备都会有处理器芯片，运行系统软件和应用软件.也就是说，智能万物互联时代将需要万亿套处理器芯片与系统软件.即使每套设备平均只售1美元，那也是上万亿美元的市场.这还不包括应用软件与服务的市场.

但事实上，每个厂商的物端市场都比较小.物联网已经提出了近20年，全球市场上还没有一家年出货量上亿台的物端设备公司.这与智能手机市场形成了鲜明对比.

这个矛盾现象被业界称为碎片化.我们称其为昆虫纲悖论：

1) 正题.未来我们将有万亿级数量的物端设备.

2) 反题.多年来没有出现一种年出货量上亿台的物端设备.

3) 解释和意义.日本东京大学的坂村健教授认为，人端设备市场像哺乳动物纲(5 000个物种)，物端设备市场像昆虫纲(5 000 000个物种)[7].我们可能会面临这样一种未来，开发者要为上百万种异构物端设备开发应用，用户将面对这些设备不能自动实现互操作互理解的难题.这是一个巨大的挑战，需要发展新的技术应对.

1.2 数据集中问题

数据过度集中问题在PC互联网和移动互联网时代就已经出现了.全球数十亿用户的大量数据集中在少数互联网厂商手中，包括跨国公司手中，带来了隐私泄露、创新受阻、巨头垄断乃至国家主权问题.

数据集中在互联网厂商手中，有利于各个厂商更好地提升科技和业务水平，快速推出更好的产品和服务，对产业和用户都有益处.但这不是唯一的模式，更不能认为用户数据过度集中是理所当然的.

欧盟在2016年发布的《通用数据保护条例》(general data protection regulation， GDPR)[18]，就是从法律层面纠正数据过度集中现象的一项举措.Tim Berners-Lee在2018年正式发起的Solid平台，则是从科技层面纠正数据过度集中的行动，其核心概念是“个人在线数据”(personal online data， POD)，目的是将用户数据去中心化[14].

在智能万物互联时代，数据过度集中问题变得更加重要，因为计算机应用拓展到了物理世界，而物端设备是人机物三元世界中感知与控制物理世界的数据出入口，位置十分关键.物端设备数据的过度集中，不仅影响用户的信息空间体验，还影响用户的物理世界体验.

1.3 创新自由难题

创新自由难题，就是创新自由与无缝智能的矛盾.这里“自由”意味着不需要别人批准.创新自由度最大的一个例子是公域软件(public domain software).这类开源软件可以随意使用并修改，不需要原开发者的批准，甚至不需要告知他/她.这类生态称为无羁绊(tetherless)生态，是Tim Berners-Lee和Jim Hendler等WWW和Semantic Web创新者大力提倡的.

创新自由度很小的一个例子是联网电器，例如空气净化器.假如某位第三方开发人员想创新一个新应用，融合城市空气质量监测站的数据，使得空气净化器能够更加智能地自动调节室内空气质量.这必须得到空气净化器厂商的同意.这类生态称为有羁绊(tethered)生态.

羁绊生态流行的科技原因，是物端设备系统领域尚未找到一种技术，既能像WWW中增添网页那样无羁绊，又能保证无缝智能的用户体验[19].一个物端设备厂商要支持第三方应用开发者的创新自由，又要支持与其他厂商的设备互操作，可能导致显著增加开发成本，甚至降低自己产品的用户体验.

近年来，亚马逊公司针对其Echo智能音箱产品线，提出了Alexa Skills概念，允许第三方开发智能音箱的App，改进了创新自由度.腾讯公司的微信系统提出的订阅号与小程序概念，是移动互联网领域的类似例子.但是，这些生态仍然是有羁绊生态.Alexa Skills绑定在了亚马逊智能音箱，不能被小米公司的智能音箱所用.这与WWW形成鲜明对比，很多网页不用修改，就能被多个厂商的浏览器渲染出来.

1.4 安全隐私难题

安全隐私难题，难在解决或平衡安全隐私与开放分享的矛盾.这个难题在PC互联网和移动互联网时代就已经存在.在智能万物互联时代，由于物端设备位于感知与控制物理世界的数据出入口位置，安全隐私难题变得更有挑战性和迫切性.

如果物端设备不开放，或其用户数据不分享，安全隐私问题就不会这么严重，但智能万物互联就难以实现.在移动互联网时代，苹果公司在iPhone生态中，其技术栈采取了多种措施来改善安全隐私防护，例如App Store的审计机制、不准第三方开发者修改硬件和系统软件(只能开发应用软件)等.但是，iPhone生态的开放程度远不如安卓生态，也使得安卓手机更加鼓励竞争，后来居上，造福了更多用户.

支付宝等移动支付技术的成功，为解决安全隐私难题提供了一个值得借鉴的案例，毕竟它们涉及实体经济体验，以及用户最需要安全隐私保护的一个对象：钱.昆虫纲悖论带来了新挑战.今天我们只需要扫3种二维码(对应3个支付生态)：支付宝、微信或银联.智能万物互联时代，我们很可能会应对百万量级的生态，在分享交换万亿级物端设备的多种多样的数据资产时，难道需要扫百万种二维码吗？

1.5 合规治理难题

合规治理难题，难在平衡依法监管与合规成本的矛盾.其中，“规”包括社区规范、企业自律、政府依法监管等.

欧盟的《通用数据保护条例》(GDPR)是政府依法监管的例子.谷歌公司近期出于内部员工的抗议，退出美国防部100亿美元云计算项目竞标，是企业自律的例子.这些都需要增加企业成本.

社区规范的一个例子是Linux开源软件社区.Linux社区向全世界开放，内部有一套规范，以保障全球开发者能够生产出高质量代码.Linus Tovarlds发明的Git技术以及github,gitlab等系统，由于提供了lightweight branch,pluggable merge等技术能力，提升了Linux开源社区的分布式开发创新自由度和代码迭代速度，降低了合规成本[20].

中国的一个例子是云账户公司，它已为上千万自由职业者提供了一个自动纳税云服务，降低了多达上亿成员的自由职业者社区依法纳税的合规成本[21].

1.6 控域的需求特征

从计算机科学技术角度看，上述2个生态问题与3个难点的本质是需要一个计算机系统抽象，规定控制权及其范围，我们称之为控域(zone of control，zone of rights，zone of governance).用程序设计语言的术语说，这个抽象最好是原生抽象(native citizen，first-class citizen).

利用控域概念与面向控域的体系结构，有助于分析、设计和优化智能万物互联系统，揭示并避免不必要的生态碎片化.控域的基本创新思想借鉴了物理世界和人类社会的现实.例如，人的生活空间包括公共空间(小区和小区外)与私人空间(家里的客厅、盥洗间等),它们的自由度、安全隐私、治理策略是不一样的.盥洗间一般不会安装监控器，警察也不能随意进入公民家庭的私人空间.

从需求看，控域需要具备FAST特征：

1) 有限描述(Finite description).对用户和开发者而言，控域的策略和范围描述足够精准易懂(例如Unix文件的路径名和访问控制属性).最好的情况是用户感受不到控域(描述为空集).最坏的情况下，每一个控域可被有限状态自动机描述,不需要艰深的专家知识，不涉及扯皮打官司.

2) 自动实施(Automatic enforcement).控域的策略实施能够被计算系统自动执行.

3) 选择自由(Selectivity freedom).面向控域的体系结构需要描述和支持多种多样的控域策略与范围，提供足够多的选项供开发者和用户选择，在创新自由、用户体验、安全隐私、开放共享、依法治理、合规成本等方面做合适的平衡.也就是说，用户总能选择到满足自己需求的控域.

4) 终止保证(Terminating).涉及控域的操作，包括对控域计算性质的判定，都会停机.即使出现少量不停机的情况，也要设定并抛出超时异常.

2 面向控域的体系结构

本节借鉴关系数据库[22]和REST体系结构风格[16]的成功经验，提出面向控域的体系结构，作为一种智能万物互联的体系结构风格.在设计智能万物互联系统时，需要考虑该系统应有多少控域、各个控域的组成以及满足哪些范式，并尽量遵守体系结构设计原则(又称为体系结构约束，即architectural constraints).

2.1 可访问与可交互

本文定义设备间具备2个层次的操作能力：可访问、可交互.

1) 可访问.设备存在接口、权限及连接方式使其能被至少一种其他设备访问.

2) 可交互.设备存在至少一种开放接口及协议.

可访问里的“访问”一词强调从设备外访问本设备的可达性，可访问通常体现为：1)设备自身可访问，如设备提供TCP端口，其他设备使用私有的应用层协议对该设备进行访问；2)设备经过一系列连接中转使其接口暴露在另一个设备上，从而可被访问.例如，物联网设备通过Zigbee协议[23]连接到小型网关，小型网关连接入云并最终将设备的功能暴露在云端的TCP端口.目前，物联网设备普遍采用第2种访问方式，对于厂商来说，其主要好处是设备连接方式易集中管理、协议接口可统一设计、可沿用成熟的云计算架构方案.

可交互里的“交互”一词强调不同厂商间对接口和协议的互理解和互操作能力，可交互通常体现为：1)统一接口和协议，如不同厂商设备间约定采用DLNA[24]接口及协议，则遵从该统一接口协议的设备间可任意交互.2)开放接口和协议，如厂商A可开放自产设备的全部接口协议文档信息，则厂商B和厂商C的开发人员可以针对厂商A的协议进行转换和适配，从而使厂商B与C的设备能够与厂商A的设备实现交互.目前各物联网厂商主要采用开放接口和协议的方式实现可交互能力.在某些碎片化不是太严重的单个应用领域，如装备制造、医疗器械等领域通常采用行业规范的方式制定统一接口和协议.

综上所述，可交互是可访问的提升，实现可交互的设备一定可访问，但实现可访问的设备不保证可交互.

2.2 控域及其范式理论

2.2.1 控域代数

控域代数是由如下定义的元素和算子组成的闭包.元素是控域.算子是对控域的操作，其结果也是控域.

定义计算设备集D={di}，其中物端设备集为TD，符合TD⊂D.若设备dj的可访问性需要依赖于设备di传递而来，则称dj可访问依赖于di，记为dj→di，其对应的集合记为可访问依赖集|→.可访问依赖关系是一种偏序关系，满足非对称性和传递性.与严格偏序关系不同的是，若一个设备di的可访问性存在且不依赖任何其他设备，则该设备的可访问依赖具有自反性，记为di→di，也可称该设备为接入设备.接入设备是网络接入点，也是可访问依赖关系经过多级传递后必须抵达的终点.若2个接入设备间可交互，则存在I(di,dj)，反之则不存在该关系.

控域(zone,简称Z)是一组计算设备及其可访问依赖偏序的集合，记为Z=(D,|→).若控域Z中存在以设备di为起点并以接入设备为终点的可访问依赖关系，则称使得设备di具备可访问性的最精简控域子集为设备di的控元(zone unit of control, 简称为ZU)，记为Z|di.其中最精简的含义是，移除控元中的任意设备都将导致设备di的可访问性失效.单一设备允许存在不同的控元中.

控域代数是基于集合理论构建的代数系统，并借鉴了关系代数的部分概念[22]，包含的基本算子有4种：

1) 控域并.控域Z1和控域Z2的并集，记为Z1∪Z2=(D1∪D2,|→1∪|→2).该算子用于2个控域的融合及控域的创建.例如，若D={d1,d2}，|→={d1→d2,d2→d2}，则Z=∅∪(D,|→)表示创建一组包含设备D和可访问依赖关系|→的控域；若Z1={d1,d2|d1→d2,d2→d2}，Z2={d2,d3|d3→d2,d2→d2}，则Z1∪Z2={d1,d2,d3|d1→d2,d3→d2，d2→d2}.

2) 控域交.控域Z1和控域Z2的交集，记为Z1∩Z2=(D1∩D2,|→1∩|→2).该算子用于2个控域共有设备的查询.例如，Z1={d1,d2|d1→d2，d2→d2}，Z2={d2,d3|d3→d2,d2→d2}，则Z1∩Z2={d2|d2→d2}.

3) 控域差.控域Z1与Z2的差集，记为Z1-Z2=(D1-D2,|→1-|→2).该算子用于从控域中移除指定设备.例如，Z=Z-{di|di→di}表示从控域Z中移除设备di.若Z1={d1,d2|d1→d2，d2→d2}，Z2={d2,d3|d3→d2,d2→d2}，则Z1-Z2={d1|d1→d2}，而实际上由于d2及d2的自反性可访问依赖已经不存在，d1→d2的可访问依赖失效，控域差结果可化简为Z1-Z2={d1}.

4) 控域投影.对于约束C及其集合映射函数πC，控域Z在约束C下的投影可记为ZC=πC(Z)，并满足ZC⊂Z.约束C可包含安全策略、延迟、能耗、功能、时空范围等多重含义.例如，将控域Z投影至家庭环境范围约束Chome，表示为Z′=πChome(Z)；将控域Z投影至最大允许100 ms的延时范围约束C100ms，表示为Z′=πC100ms(Z).

2.2.2 控域范式

控域可形成3个逐层相容的控域范式(normal form，NF)：

1) 控域第一范式(1NF)——访问范式

如图1所示，从左向右依次列举了可能的4组不同控域示例情况.最左边一组描述了云设备d1和物端设备d2各自作为控元的情况，即设备能独立联网且可访问，该控元分别记为Z|d1={d1|d1→d1}和Z|d2={d2|d2→d2}；第2组情况描述了d4必须经过d3才能可访问，则d4的控元记为Z|d4={d3,d4|d4→d3,d3→d3}；第3组情况描述了d7设备通过私有协议连接d6网关设备，经过d6的协议转换后连接到云设备d5可访问，d7的控元为Z|d7={d5,d6,d7|d7→d6,d6→d5,d5→d5}；最后一组情况描述了，2个设备d9和d10共同需要通过d8实现可访问，设备d9和d10的控元分别为Z|d9={d8,d9|d9→d8,d8→d8}以及Z|d10={d8,d10|d10→d8,d8→d8}.在本示例中，由于所有设备均在控元中，不存在不可访问的设备，因此控域Z满足第一范式.在物联网场景中，现有大部分设备基本都符合控域第一范式要求，主要方式是端云间通过私有协议互联，云端暴露私有接口，最终手机端通过访问云端接口实现对物联网设备的访问.

Fig. 1 The 1st normal form of zone图1 控域第一范式示意图

2) 控域第二范式(2NF)——交互范式

如果控域Z∈1NF且Z内的接入设备间均可交互，即∀di→di,dj→dj∈Z，均存在I(di,dj)，则Z∈2NF.第二范式的约束含义是2NF控域内任意设备间均存在交互操作的能力.

如图2所示，相对于图1而言，各控元间通过两两的开放协议方式实现了控元间的可交互能力，因此Z满足了第二范式.在针对物联网场景中，少数物联网厂商间初步形成了第二范式，例如亚马逊物联网云与各厂家设备云之间通过开放文档和计算服务的方式实现了交互能力.

Fig. 2 The 2nd normal form of zone图2 控域第二范式示意图

3) 控域第三范式(3NF)——互联范式

如果控域Z∈2NF且Z内的任意物端设备所在的控元中仅包含物端设备，即∀di∈Z∧di∈TD，均存在Z|di的设备集都属于物端设备集TD，则Z∈3NF.第三范式的约束含义是3NF控域的设备不需要依赖于云设备便具备可交互能力.

如图3所示，在图2的基础上，我们大幅缩减了物端设备的可访问依赖关系长度，即设备自身就能够提供可访问和可交互能力，使得物端设备的控元范围内仅包含物端设备.因此，控域可以在更多的小型化控元上进行构建，丰富了控域的多样化程度.例如图3可以构建任意物端设备间的控域，其中Z1和Z2就是满足控域第三范式的一种可能划分.在针对物联网场景中，仅有极少数厂商的设备能够满足第三范式，例如遵从DLNA协议[24]的多厂商智能设备、飞利浦Hue系列的智能灯泡等.

Fig. 3 The 3rd normal form of zone图3 控域第三范式示意图

2.2.3 控域范式验证

本节将通过3个观察角度，阐述如何利用机器判别控域范式满足性.图4展示不同视角下的案例来源于图1～3.

Fig. 4 The criteria of normal forms in zone based on 3 observations图4 基于3个观察视角的控域范式判别方法

观察1. 若控域Z中的每个设备都存在至少一个以设备自身开始的可访问依赖偏序关系，则可判定Z∈1NF.如图4(a)所示，验证1NF只需要验证图中不存在孤立的实心黑点.

观察2. 在满足观察1的前提下，若控域Z中的所有接入设备具备全连通的交互能力，则可判定Z∈2NF.如图4(b)所示，验证2NF需要在1NF的基础上重点关注图中具备自反性可访问依赖的黑色圆形均被交互虚线两两连接.

观察3. 在满足观察2的前提下，若控域Z中的所有控元中只含有同类型设备，则可判定Z∈3NF.如图4(c)所示，验证3NF需要在2NF的基础上重点关注图中各控元内的设备是否为一种颜色.

2.3 面向控域的架构风格原则

面向控域的架构风格原则是基于控域代数理论构建的软件体系结构约束集，而如何基于这些约束指导设计体系结构是面向控域架构体系的关键研究问题.本文提出基于控域代数理论的2类架构约束：1)推荐原则.设计控域架构所须遵守的关键原则.2)可选原则.建议采纳的原则，采纳这些原则在带来好处的同时也潜在地在特定场景下引入少数缺陷.

2.3.1 推荐原则

1) 互联约束

互联约束，即面向控域第三范式进行架构设计，具体含义指的是：①设备应存在最少的访问依赖关系，并尽可能地在物端设备上提供可访问能力；②应尽可能地在物端设备上提供可交互能力.

提供多样化的控域组合能力是实现不同目标计算架构的关键.符合第三范式的分布式架构由于满足最小控元和可访问依赖关系，提供了自由完备的组合能力，即可以通过任意控元组合构成满足指定安全、隐私、性能等需求的专有控域.通过互联约束，控元可从现有端云等垂直式架构演变为物端设备直接互联的架构，控元的数量将呈数量级增长，它们之间可形成更多满足第三范式的控域组合.

实现控域第三范式约束的关键技术途径是采用统一或开放协议的去中心化架构，使得物端设备可以直接在无中心服务器依赖的情形下提供可访问能力和可交互能力.在物端计算中，利用Web使能方式将设备的各项能力开放为Web服务[10]，是一条实现该约束的可行技术途径.

2) 有状态的控域上下文

面向控域的体系结构需要针对控域的全生命周期管理维护过程显式地设置有状态的控域上下文，包括控域的注册登记、控域属性及成员的动态调整和控域的销毁回收.

由多设备构成的控域可视为一个较为封闭的“控域计算机”，在设备间无状态管理情形下，发生在彼此独立的设备间的高频无序交互将造成冗余的权限授权、操作低效化、任务间冲突干扰.因此，对控域内的设备进行有状态的上下文记录，是控域计算机内各松散组件协调工作的前提条件.控域上下文的有状态性可确保设备间不会因为彼此不可见的控域状态而进行大量冗余查询，有效降低控域内组件的协调开销.实现有状态控域上下文的主要途径分为中心化管理和分布式管理2种，通常后者具备更好的分布式容错能力，Paxos[25]，RAFT[26]等一致性算法可以为不同设备间的控域上下文的一致性管理提供理论依据.

2.3.2 可选原则

1) 无状态通信

无状态通信约束要求设备间的交互以不维护彼此通信上下文的方式进行.

基于有状态通信的传统物联网架构，通过精准匹配上层厂商定制的具体应用情景，设备链接数少，访问方式固定，因此设备可采用TCP/IP,MQTT[27]等方式达到工作稳定、开发成本低廉的设计目标.但在面向控域的体系结构中，设备自身作为可访问、可交互核心，意味着设备需要在自身资源有限的情况下承受数量更大计算服务请求，有状态通信导致的上下文维护成本造成了资源大量消耗，并容易导致设备工作状态不稳定.无状态通信约束可降低通信上下文管理维护的复杂度，有助于提高访问请求数.Roy Fielding的REST架构风格[16]通过无状态约束成功支持了全球网络资源的无限可扩展性的共享访问模式.同理，将REST架构风格与面向控域的架构相结合是一种可行的研究思路.但需要指出的是，设备间的无状态通信约束与实时交互需求能否同时满足存在一定争议，例如，实时通信协议Websocket[28]，可以通过有状态通信优化实时通信的延时开销.因此，本文建议将其作为一种可选的架构风格约束.

2) 松耦合架构

松耦合架构要求架构设计过程中避免对软硬件系统做出强假设，包括但不限于设备位置、网络连接方式、操作系统、硬件类型和计算任务的下发方式等.

一方面，该约束可保持面向控域的架构始终是面对多样化的软硬件而设计，而面向控域架构本身将作为中间件，将成为底层软硬件系统与上层网络协议的桥梁；另一方面，该约束可确保应用开发者开发的计算任务尽可能地具备通用性，有助于降低应用开发的劳动复杂度.例如，T-REST[29]将REST架构风格推广到物端计算系统，提供了由厂商以及第三方社区通过脚本语言动态部署设备端服务的能力.同时其松耦合特性允许设备底层部署任意操作系统和使用各类新兴网络及通信协议.松耦合架构作为可选原则，可作为未来面向控域架构的持续演化方向.

3) 有序化资源管理

有序化资源管理要求控域设备间的计算、存储、网络等资源是以统一管理的方式进行申请、使用和调度的.

在面向时延敏感的计算任务中，用户总是希望分布在多个位置的设备能够如一台计算机总线上的设备相互协调，降低冲突，并最终提高用户体验.有序化资源管理约束的具体含义是：①在控域注册登记时跨设备预留多种资源，形成控域专用的资源池；②在任务或事件执行时，动态地从资源池内提取资源进行使用；③在任务执行完毕后归还资源.资源预留可采用静态分配或者服从优先级安排的动态分配等机制，以实现不同层级、不同粒度的资源有序化管理.该约束在云计算或分布式集群管理中已经得到广泛使用，诸如kubernates[30]，mesos[31]等任务资源管理框架的成功经验将有助于探索面向控域的有序化资源管理研究.采用该约束的缺点是，资源管理会潜在地增加设备资源的管理开销，特别是现阶段资源受限的物联网设备难以通过隔离、虚拟化技术进行资源池化管理.

2.4 面向控域架构约束下系统演化场景

本节将通过图5展示如何利用控域代数理论与面向控域的架构约束来推演和优化现有的物联网体系结构.本示例将展示作者于伦敦家庭中通过亚马逊智能音箱Echo控制小米台灯的情景，即用户通过“Alexa，turn on the light”语音命令Echo打开小米台灯.该场景是智能家庭物联网中一种典型的交互模式.多次测试结果表明，从用户发出指令到Echo确认“灯已开启”平均耗时3.7 s.经过分析该场景的系统架构，如图5左半部分所示，Echo仅能连接亚马逊云(位于美国)，小米台灯仅能连接小米云(位于新加坡).小米云依据亚马逊云Alexa开放文档，在亚马逊云上部署了转换函数，从而使得亚马逊云可以将语音信息解析为开灯指令后派发给小米云.最终，小米云将指令传输给小米台灯，并执行开灯动作.在指令处理完毕后，应答信息原路重新传回Echo设备.不同厂商设备之间的交互隔离造成了：1)同一家庭环境下的交互操作需要跨越多个云端服务器.在本例中，请求和响应跨越了上万公里的物理空间，增加了耗时.2)用户数据被迫传输并放置于云端.因此，若要实现用户隐私保护的依法治理，厂商与政府将产生显著的合规成本.

Fig. 5 The architectural revolutions based on ZOA in the scenario of smart speaker controlling lamp图5 受面向控域的体系结构风格约束的智能音箱控制台灯场景架构演化示例

利用控域代数理论分析图5中的左半部分，可以得出Echo和亚马逊云形成了一个控元，小米台灯和小米云形成了另一个控元.因此在本例中，用户的控域包括这2个控元，也即是全部的4个设备.这形成了满足第二范式的控域.但该控域涉及的物理范围已经远远超出了家庭本地的物理空间.

图5中的右半部分演示了该系统体系架构的未来演化方向.我们依次使用5条架构约束对左半部分的原始架构进行约束：1)通过互联约束，将原有控元中的非物端设备移除，使得小米云与小米台灯、亚马逊云与Echo形成无羁绊的互联形态.在本例中，使Echo和小米台灯设备自身转变为Web服务器，并开放它们之间的通信交互协议，从而控域的物理空间范围可以缩小至家庭空间范围.另外云端服务器也可转化为独立的控元和控域，物联网设备与云端服务器之间仍然可以进行授权的数据分享操作.2)通过无状态通信约束将云服务器和物联网设备原有的有状态持久化通信方式进行重塑，本例利用REST架构风格可实现最基础的无状态交互协议.3)通过松耦合架构约束将云服务器和物联网设备的功能从软硬件架构上解耦.本例使用了T-REST架构风格，开发者可以通过开发与软硬件架构无关的脚本代码动态赋予2个物联网设备不同的功能.4)通过有状态控域上下文约束，2个物联网设备可保持同步的控域状态上下文，因此彼此间的权限、状态相互可见.5)通过有序化资源管理约束，2个物联网设备都将在自身维护可用资源池，因此设备可配合不同的任务和事件需求锁定或者优化资源的调度分配.

以上约束带来3种好处：1)数据的安全隐私得到了更好的保护，数据的所有权掌握在物端设备，数据分享至云端的操作需要得到用户的授权和批准，可有效降低依法治理的合规成本.2)无障碍的物端设备直接交互，初步带来了亚秒级访问延迟交互的可能性.若进一步配合有序的资源管理机制，延迟有望实现从亚秒级到毫秒级的突破.3)松耦合的架构约束有望实现设备上功能函数的可重用能力.例如，语音识别函数可以被第三方社区开发而无需考虑如何适配碎片化的软硬件生态.另外，函数可作为移动计算负载实现边缘计算理念[8]中多设备间的计算任务自动迁移，从而使得任务执行获得数量级的能效提升.

3 面向控域的车联网应用场景

控域代数和面向控域的体系结构可作为针对智能万物互联应用场景的理论分析工具与架构设计的指导原则.本节以车联网应用场景为例，分析和探索控域理论及其架构与车联网相结合，所产生的新研究方向并评估其发展潜力.车联网是需要实现车内设备、车与人、车与车、车与路、车与服务平台全方位连接的一体化网络和系统[32].它是智能化交通、无人驾驶等新兴服务的关键辅助技术.

车联网作为一种特殊的物联网应用场景，具有多种互联方式.本文主要关注其中的2种：车云互联和近邻互联.1)车云互联指车辆需要通过云端连接实现信息共享的互联方式.其主要存在于需要大量数据沉淀融合的惠民服务中，例如车主信息服务、厂商质量监管、交管部门辅助办公以及为租赁和二手交易提供信用服务等.这类服务通常要求互联方式具备尽量可靠的连接通信，对延时等指标要求不高.2)近邻互联指车与车、车与路面基础设施之间的信息分享，主要用于路障规避、路径规划、超视距拓展等服务目标，这类服务要求互联方式具备低延时、高可用等特性.设计一种能同时支持车联网以上2种互联形态的高效系统架构存在2个技术难点：1)车云与近邻互联的目标均为实现互联，但截然不同的服务要求造成车联网架构的冲突及冗余设计，进一步加剧了“碎片化”设备接口适配的代价以及最终恶化了车联网的应用生态.例如，相同的传感器数据需要针对车云互联使用HTTP协议及设计对应RESTful接口.而针对近邻互联则需要使用自组织网络架构的专用实时交互协议.2)缺乏有效的车内和车间运行时抽象及分布式架构.传统的车联网系统设计注重单机架构，对“碎片化”设备所需的分布式系统协同设计重视不足.然而，边缘计算领域的研究已证实，对多台设备进行架构上的联合设计并让任务能够在设备间进行计算迁移(computing offloading)，可在延时与能耗上带来数量级的优化[33].例如，传输经视频识别后的路况分析结果要比直接传输视频帧能更有效地节约车与车间的有限带宽，从根本上提高服务质量.

从控域范式角度来看，车联网发展经历了3个阶段：

Fig. 6 The 1st normal form of zone in connected cars图6 符合控域第一范式的车联网场景

1) 车云直连(第一范式).即车通过连接厂商云服务的方式，使得车载的传感器和控制器可以被用户通过互联网随时随地访问.目前部分厂商已经采取这种架构实现了初级的车联网形态，达到了用户和厂商间信息共享的目的.常见用途包括车辆状态监控、车辆远程控制等.如图6所示，每辆车都和其厂商云形成了控元，因此符合控域第一范式.但不同厂商云之间因不存在开放接口和协议而无法交互，因此不满足控域第二范式，车与车之间协同受阻.在图6中，车A1与A2可通过厂商云A交互分享前方紧急路况信息，而隶属于不同厂商的车B1将无法获得厂商A车辆传递的信息.

2) 车云交互(第二范式).即在车云直连的基础上提供了开放的接口和协议，使得厂商云之间能彼此交互，因此满足了控域的第二范式.在图7中，厂商云A与厂商云B可协同交互并融成了一个联合控域Z.车辆A1可通过云A和云B最终与B1协同交互，分享前方紧急路况信息.虽然该方式是一种实现车与车之间协同技术的简易途径，但通过云中转的通信开销不可避免地造成了延迟的优化瓶颈.另外，在诸如隧道、山区等信号缺失的场景下，车云交互存在车辆对路况反应失灵的风险.因此，仅满足第一范式和第二范式的系统在延时敏感、网络易失的场景中缺乏可用性，无法支持无人驾驶、紧急路线规避等敏感任务.

Fig. 7 The 2nd normal form of zone in connected cars图7 符合控域第二范式的车联网场景

3) 车云互联交互(第三范式).即在车云交互的基础上，使车辆自身直接具备可访问和可交互能力，因而符合控域第三范式.在图8中，车辆A1,A2,B1和B2之间均可在脱离厂商云的情况下，享紧急路况信息.同时在该范式下，数据的持有者始终是车辆自身，数据仅在获得许可的情况下进行传输和共享.

Fig. 8 The 3rd normal form of zone in connected cars图8 符合控域第三范式的车联网场景

该交互方式与车联网端管云模型[34]的目的相似，均是实现汽车与各类设备的互联.差异是端管云模式关注车联网基础计算、异构化网络设施与服务提供能力.而面向控域的互联交互注重基于端管云等基础设施上的整体架构风格.例如，在何处部署服务接口提供可访问能力、以何种原则构建开放接口与协议提供可交互能力、以何种通信模式实现车辆间安全可控的查询访问、如何协同多车之间设备实现计算任务迁移获得毫秒级请求响应等.

控域代数理论和面向控域的架构约束可进一步对符合第三范式的车联网交互提供优化建议.在安全管理方面，可基于车辆设备的不同安全属性利用控域投影算子构建多重控域.例如刹车、油门、方向盘、无人驾驶引擎等关键设备可形成安全级别最高的驾驶控域，由设备自身而非汽车中控、云服务器等外围计算设备控制.通过安全自治，最大程度避免了外围低安全等级设备被入侵破坏，造成安全事故的可能性.在运行时及架构方面，控域自身可按照地理空间、功能、安全等级等属性划分的同时，可基于有状态的控域上下文及有序化资源管理约束，形成专有运行时环境.例如无人驾驶车辆的驾驶控域应始终以最高优先级处理驾驶类任务，相应的CPU,GPU资源应该被预留.而车载娱乐、监控等非关键任务与驾驶控域交互时，应当避让使用核心资源.若车联网控域架构进一步采用无状态通信约束，例如使用REST架构风格，则不同车载设备开发者可以自由创作多样化的前端接口和后台计算逻辑，可一定程度避免各设备互联交互时的架构冲突.而使用符合松耦合架构约束的T-REST则可进一步允许计算任务函数在不同设备间迁移.

综上所述，控域代数理论及面向控域的架构风格与车联网相结合可带来3种好处：1)符合第三范式的车联网架构有望以一套系统、接口和协议同时满足车云信息共享和车与车之间信息协同这2种有明显差异化的服务；2)基于控域代数理论，用户、厂商可依照各自的安全期望，自由划分不同的车载设备间及多车设备间的控域，实现设备的安全自治和控域内多设备间的安全互通，降低隐私外泄风险，在数据源头控制数据隐私依法治理的合规成本；3)为碎片化设备提供一种既具备灵活设计空间，又能保持多设备间和谐统一的运行时及架构设计风格，使得不同厂商设备的研发人员能够以较小沟通代价实现架构兼容乃至设备间任务协同优化.

4 尚未解决的研究问题

本节从理论、实现技术、生态3个方面提出开放问题(open problems).

1) 本文的控域集合中的基本元素是设备，包括云端设备、人端设备、物端设备.是否应该采用REST体系结构风格的思路，使用更广义的万维网“资源”概念作为控域的基本元素？Solid平台的POD是另一个选项.

2) 能否给出控域理论中关键概念的定性或定量的度量(qualitative or quantative metrics)？例子包括创新自由度、无缝智能程度、安全隐私度量、合规度、数据集中度、多样性散度(diversity，也是碎片化程度)等.

3) 在智能万物互联网中引入控域概念，肯定会带来新的开销.如何设计一套低开销的实现技术？一个可借鉴的先例是REST，它通过改造URI，HTML，HTTP得以实现.此处的开销包括运行时开销，也包括新引入的开发成本和运维成本.理想的情况是，控域带来的功能益处明显大于新引入的开销，甚至会降低原有系统的开销.

4) 面向控域的体系结构风格能否启发新的具体技术，例如兼顾隐私保护与规范共享的新的访问控制模型，并评判新技术的利弊？

5) ZOA如何与现有互联网和物联网生态配合？如何与新的体系结构(如T-REST[29])和新的Web平台(如Solid[35])分工合作？

5 结 论

本文针对智能万物互联时代控制策略多样性需求，提炼了2个生态问题和3个科技难点，提出了一种面向控域的体系结构(ZOA)风格.

从智能万物互联网全网架构角度看，ZOA可被认为是一种构建于全网分散物端设备上的抽象计算机，打破了传统物联网设备间简单的对等或层级式(设备-边缘-云)访问关系，形成了因势而变、物以类聚的一组局部动态计算机.也就是说，在安全隐私、用户体验、物理区域等不同目标的驱使下，ZOA可在一组碎片化设备上按需划分出不同场景下的专用虚拟计算机.

从单个设备角度看，ZOA提供一种面向设备开发者的去中心化架构设计思想，以独立遵从必要架构约束的方式，缓解厂商的碎片化系统与智能万物互联互通愿景的矛盾.ZOA提供2个推荐约束促成不同设备间能够形成控域，以及3个可选约束，有助于为不同的服务目标提供无状态通信能力、自由创新能力和低延迟用户体验.

从理论分析角度看，ZOA中的控域代数与范式理论为其控制策略与范围提供了一种形式化的界定手段.控域代数有利于精确刻画现有智能万物互联架构的可访问和可交互能力，而基于控域范式理论的3个观察，提供了真实繁杂系统情景下控域范式的机器自动化检查方法.