面向控域的體系結構：一種智能萬物互聯的體系結構風格

徐志偉 曾 琛 朝 魯 彭曉暉

(中國科學院計算技術研究所 北京 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個觀察，提供了真實繁雜系統情景下控域范式的機器自動化檢查方法.