Categories
程式開發

用圖知識庫設計有狀態雲原生應用程序架構


本文要點:

  • “狀態是好的”;實時數據能夠支持響應式應用程序,並協調端到端流程。
  • 許多企業用例面臨的障礙是缺乏對有狀態雲原生應用程序的支持。
  • 圖知識庫是一個古老的概念,現在又被重新撿了起來,用來建模複雜的分佈式域。
  • 將高級抽象與雲原生設計原則相結合,可提供高效的“上下文即服務”,作為無狀態服務的補充。
  • 基於圖知識的系統可以將雲原生服務組合到事件驅動的數據流程中。

雲端的興起促使人們以自下而上的視角重新看待應用程序的基礎架構——進而催生了小型、無狀態、隔離和容器化的微服務,和可獨立擴展並移植的無服務器函數。反過來,將應用程序打包到容器中,可以實現大規模的部署編排和DevOps風格的自動化。雲原生服務本身並不是解決方案,而是要成為高度模塊化的客戶端應用程序的可擴展構建塊。

雲原生架構中隔離的“無共享”設計是對傳統的單體軟件實現的回應,後者將自身的功能緊密耦合到了數據庫上,因此必須作為一個整體來擴展、分佈和進化。

但是,企業仍然需要符合自身環境需求、互相之間緊密關聯的各種解決方案來支持自己的核心使命。將應用程序簡化為離散的“包”和隔離的“負載”是很容易的,但產生價值的是跨解決方案元素的端到端業務邏輯,這些方案元素可以是基於容器、VM或是基於服務器的。除非你是主流IT供應商或云託管廠商,否則基礎架構只是實現目標和管理成本的一種手段。

在最近的InfoQ演講”超越微服務:流,狀態和可擴展性“中,Gwen Shapira指出了在雲原生負載之間建立上下文的困難之處——“我想念狀態,因為有時我的規則是動態的。我無法硬編碼這些規則,我必須在某處查找它們。有時,我的事件包含其中一些我需要的數據,比如說一個ID,但沒有包含他們需要的那些數據,因此我必須在某處查找它。有時我必須聯接多個事件。 ”本質上來看,無狀態雲原生服務之所以可擴展,是因為它們將狀態和信息管理問題推給了使用它們的客戶端應用程序。

能快速有效地訪問信息(也就是建模的、可尋址和持久的實體)的應用程序有著更高的智能化程度,並且應用程序之間的“共識”促進了互操作性、協作和流程自動化。每個人都希望能以數據為中心,但是沒有人希望回到臃腫且緊密耦合的單體架構上。這種明顯的矛盾需要得到解決。缺乏對有狀態雲原生應用程序行為的支持,是擴展雲用例道路上的一大障礙。

外殼遊戲

這裡要明確的一點是,“無狀態”並不意味著沒有狀態。這是一種誇張的表述。微服務和無服務器函數通常會保持某種狀態,往往是一份配置文件和它們離散活動的日誌。

通常,無狀態應用程序不會在請求或事件之間保留任何客戶端應用程序狀態。 “無狀態”解耦了雲原生服務與客戶端應用程序,以實現所需的隔離。微服務和無服務器架構的宗旨明確禁止保留會話狀態或全局上下文的做法。但是,儘管狀態不在容器中,但它還是必須處在某個地方。畢竟,無狀態函數要將狀態作為輸入。應用程序狀態沒有消失,它只是移動到了其他位置上。這裡的代價是每次執行時都必須重新加載狀態以及所有全局上下文。

無狀態在實踐中帶來的後果是網絡使用量的激增,從而帶來了大量零碎的、帶寬和I/O密集的進程間通信。這是有代價的,體現在雲服務支出的增長,以及客戶端應用程序的延遲與性能影響。

分佈式計算作為一種久經考驗的設計原則已經弱化了數據重力的約束,迫使應用程序與越來越多地與外部數據源集成在一起。雲原生架構則完全顛覆了規則——現在是數據傳遞給函數。應用程序被從內至外翻轉了過來。對於雲原生服務而言,狀態和信息管理已經外部化了——正所謂“Intel Outside”。

分離數據和函數是很好的設計,但是沒有針對分佈式域中共享狀態和架構的應用程序層抽象,開發人員就要針對每個微服務,對這些問題進行一次性、點對點的處理,這種操作是不可擴展的。

轉變應用程序層

傳統的3層應用程序正在迅速消失。隱式的雲原生模型要抽象得多。從概念上講,應用程序正在轉變為一組帶有關係的分佈式數據源和功能的集合——也就是一幅“應用程序圖”,它處理起來則是一條管道。這聽起來可能很簡單,甚至像田園詩歌般愜意,但是如何將所有這些離散元素以一致的端到端流程組合在一起,而又不用將它們之間的關係硬編碼為一個CRUD大球呢?

儘管最近出現了很多關於Kubernetes中有狀態應用程序的文章,但它們大多討論的是部署、配置和管理數據庫的存儲原語的主題,而不是應用程序層所關注的狀態重建和信息管理主題。共享內存和邏輯數據訪問領域出現了一些很有想法的方法,例如UC Berkeley的Anna db項目和Zhamak Dehghani提出的分佈式數據網格架構。但是,它們一般不包含用於跨服務推理的一致性層。在以數據為中心、事件驅動的應用程序中將鬆散耦合的雲原生服務連接起來,以融合微服務和無服務器函數的解決方案,需要的不止是讓應用程序高效訪問狀態。

為了實現分佈式解決方案元素與異構解決方案元素之間的互操作性,需要用某種方式將它們的不同架構映射到更高級別模型的共享概念、數據類型和關係上。在這樣的需求推動下,將多個數據源聚合在單個API下的GraphQL流行了起來。 GraphQL在戰術上是很方便的,但是其範圍和功能很有限——它實際上只是一組特定的集成服務上的靜態、分層數據模型(在任何層面上都算不上是一個圖)。就像被扔掉的腳本一樣,它是一種一次性的手動解決方法,不能提供更好的透明度、復用性、自動化能力或治理能力。

為了解決端到端問題,並實現IT生產力提升和業務敏捷性增強等戰略目標,我們需要的是更強大的抽象,而不是一個瘦實體服務。它需要為負責開發跨企業孤島、IT層和生態系統合作夥伴的企業範圍解決方案的開發人員服務,為具備良好可讀性的代碼與依賴項,以及清晰的組合提供支持。它必須是一個靈活、可擴展和適應性強的模型,以適應各種變化,並隨著時間的推移而進化。

回到未來

在這樣的背景下,人們重新拾起了圖知識庫這個起源於1970年代的專家系統概念,以支持複雜分佈式環境中的高層抽象。

根據維基百科的介紹,知識庫(KB)是一種用來顯式存儲複雜信息的技術,它是一組事實及它們與其他事實和規則(也就是一個圖)的鬆散耦合(而非強制性的)的集合。 “知識庫的理想表示是一個具有類、子類和實例的對像模型(在人工智能文獻中通常稱為本體)。 ”這一術語是為了和之前的常規數據庫區分開來而出現的,後者一般來說是自然分層的。圖知識庫是原始的NoSQL數據庫!

圖是靈活的、可擴展的和可適應的,是用來對複雜的現實世界域建模的理想數據結構。此外,圖具有眾所周知的數學特性(關聯性、鄰接性等),並支持很多計算優化方法(最快路徑算法等)。

專家系統將知識庫與推理引擎結合在一起,後者將利用圖對像模型來解決複雜問題。 “知識庫提供有關世界的事實和規則……推理引擎則可以推斷出新的知識。最常見的是,它可以採用IF-THEN規則的形式,再加上前向或後向鏈接方法。”早期的基於知識的系統(KBS)的作用範圍有限——它們一般用來回答特定的科學和醫學問題。它們模仿了人類的決策過程來自動化處理專家任務。但它們不是事務性的,計算任務被固定在單台計算機上,並且描述一個複雜域所需的存儲資源對當時的技術來說太龐大了。

隨著互聯網的興起,人們對知識庫有了新的興趣;因為人們普遍意識到,分佈式信息源已被鏈接和索引起來,因此可以輕鬆地進行導航和查詢。 Tim Berners-Lee爵士等人在“語義Web”中應用了這些概念,語義Web通過術語和數據結構的標準化實現了信息概念之間顯式標準化的關係,從而改善了發現、推薦和分析能力。十年後,谷歌發布了其知識圖譜,其願景是建立一個豐富的信息對象網絡——“不是字符串的事物”。

雲擴展了互聯網的使用範圍,超越了以人為中心的Web,並公開了一眾服務和功能,讓系統可以通過API訪問它們。知識庫再次成為一種理解複雜性的方法。 eBay最近宣布了一個知識圖項目——使用知識圖管理eBay Vast服務架構

eBay圖中的建模關係為他們提供了複雜和分佈式環境的整體表示。但是,與基於語義Web的技術一樣,它通常側重於數據發現和分析,而不是系統的互操作性和自動化,這也是OLAP與OLTP的古老分歧的體現。

要真正啟用雲原生應用程序層,需要對圖知識庫進行概念的擴展;將眾多模式映射到一個統一的更高級別的模型(也就是有界上下文的並集)是不夠的。為了使數據在服務之間無縫地流動,需要使用豐富的分佈式對象聲明式模型來處理雲原生(“12要素”)問題,包括:發現(地址、唯一ID等)、連接性(端口、密鑰、驗證等)和語法(協議、格式)。

此外,知識庫應該為參與的元素(不僅是瘦描述符和一堆YAML配置)建模接口和軟件協定。如果應用層正在協調部署和配置,則知識庫還必須針對基礎架構需求(也就是計算、存儲和網絡)、約束(依賴項、affinity等)、應用程序生命週期管理操作(啟動、停止、擴展、移動等)和目標主機端點來建模。類似的要求也適用於工業物聯網,這種網絡必須實例化、監視和控制眾多傳感器和執行器,以實現智能製造、智能城市和智能供應鏈。

結果將誕生一系列分佈式解決方案元素組成的的豐富模型,這些模型可以靈活地組合成更高級別的服務,並可以在事件驅動的數據流程中鏈接起來。知識庫將提供共享的域語義和元數據,以實現運行時自動化和基於策略的管理。通過抽象高級別的域和低級別的技術細節,圖知識庫可以作為一類新的實時分佈式應用程序的基礎,並用於“上下文即服務”。

總結一下:

  • 圖知識庫提供了端到端域的透明、圖連接的模型。
  • 基於圖的設計以靈活、可擴展和適應性強的方式支持複雜現實世界域的建模。
  • 擴展圖知識庫以建模分佈式系統域,用來支持雲原生應用程序需求。
  • 圖知識庫提供了一個支持對話式API和動態UI的信息模型,該模型允許交互式探索一組圖關係。
  • 圖具有很多數學特性,可以優化複雜關係的處理,從而在很大程度上抵消了在較大範圍內推理的典型“成本”,讓方法易於處理。
  • 圖知識庫支持可讀的代碼和依賴項,並能為負責跨企業孤島、IT層和生態系統合作夥伴開發企業範圍解決方案的開發人員提供簡潔的組合。
  • 基於圖知識的系統可以提供有效的“上下文即服務”,從而高效混合無狀態的雲原生服務,並支持以數據為中心、事件驅動的分佈式應用程序。
  • 基於圖知識的系統支持基於模型、事件驅動和策略控制的編排。

虛擬化分佈式系統域

實現這類基於圖知識的系統的關鍵是一些重要的設計注意事項。雲原生應用程序的設計對運營會產生影響,因為它迫使開發人員處理所有關於數據爭用、一致性和安全性的問題,這些問題以前是由單體負責為每個參與的微服務和無服務器函數管理的。它暴露了互操作性、狀態管理和消息傳遞方面的問題,這些問題現在必須由開發人員明確處理,這正是分佈式系統在技術上如此復雜的原因所在。為了使這個IT領域自動化,知識庫必須虛擬化環境。

聲明式語言

如上所述,圖知識庫是對分層數據庫和命令式編程的一種回應。圖知識庫顯式化了域,讓域更易於檢查和導航。它們的機器可讀數據結構和分類模式天然支持聲明式語言進行映射,而不是單獨編碼對象內部和對象之間的所有關係。

聲明式建模提供了一種標準化解決方案元素的方法;對像被自我描述為指向知識庫中共享域概念、類型和策略的一組指針。這種高級抽象實現了針對異構元素的通用方法。它創建了一個一致性層,在其中可以發現、組合、協調、配置和管理各種對象,將這些對象視為同樣的存在。底層實現的複雜性(連接、通信、語法等)可以從開發人員那裡抽像出來,讓他們可以專注於組合和應用程序邏輯。互操作性問題由語言運行時處理。

在運行時,圖知識庫可作為機器可讀的唯一事實來源,用於自動化端到端IT和業務流程。但是,知識庫的擴展角色(用於建模分佈式系統域)意味著人們必須重新設計最初構想的,以查詢為中心的推理引擎,以加入對協調和狀態管理(命令和轉換)的支持。

這種聲明式建模方法將對象的模型與實現對象所需的面向消息的中間件(MoM)功能區分開來。這些函數可以通過圖知識庫中的“類型”來附加,並可以在運行時編排。將類型映射到領域概念,使基於圖知識的系統能夠驅動基於模型、事件驅動和策略控制的自動化過程,從而實現以數據為中心的實時行為。這使基於知識的圖系統更接近於應用程序圖的函數式組合視圖,但是狀態管理和消息傳遞問題仍然需要得到解決。

不變性

有狀態與無狀態的爭論是無意義的二元對立;組織希望用狀態來理解事件、自動化決策並優化流程。除了數據結構外,圖知識庫的基礎設計是像數據庫一樣來存儲信息。但是,用於無狀態分佈式應用程序和Web級流程的數據服務需要一個不變的持久模型。

不變性是一種將信息存儲為針對具有唯一標識符的持久實體的帶日誌事件流的方法。與傳統數據庫那樣通過替換值來“更新”狀態的做法不同,現在事件是”插入(insert)”,用來創建一個鏈接的歷史記錄。對像或應用程序的狀態是從不可變存儲的歷史記錄中預測的;狀態是從事件中派生的。

這種方法算不上什麼全新的方法,也沒那麼玄妙,只是和過去的方法略有區別。它是基於分類帳的會計處理和全球銀行系統的基礎。銀行帳戶這個概念具有唯一標識符,它的當前狀態,也就是銀行餘額,是一種從借記和貸記活動歷史中計算出來的要素。

不變性將狀態與對象區分開來,以專注於可靠地記錄轉換狀態的事務。不變性將計算狀態的責任轉移到運行時,從而讓開發人員更容易推理事件驅動的應用程序。

不可變對像天然支持事務的異步與並發處理、多步操作和長期運行的工作流。它們為持久性實體提供了一個名稱空間,這些持久實體可以存儲參與服務的中間結果、充當流程狀態的集合,並提供日誌(事務跟踪或歷史記錄)以備調試和審核。

聲明式模型和不可變對象共同為實時分佈式應用程序的協調提供了基礎支持,但是它們並不能解決異步環境中缺乏保證的問題。

冪等

解耦的應用程序會將網絡插入所有解決方案元素之間,這會導致網絡延遲和故障。連接服務的分佈式應用程序必須適應後期的響應和非響應,以確保安全性和彈性。儘管許多Web和移動應用程序對一致性的要求可能較低,但企業級應用程序往往依賴“正確和當下”。為了確保正確性,開發人員必須替換掉丟掉的數據庫保證(ACID)。

與分佈式系統中的其他內容一樣,類似事務的語義也被提升到了應用程序層。不變的持久性提供了持久的實體和權威的歷史記錄,但是不可靠的網絡通信需要消息傳遞保證,以確保請求及其效果不會重複。接收者可以預期自己會“至少一次”收到消息。

已有的計算機科學原理“冪等”解決了這個問題,該原理允許請求操作重複,而不會重複其效果。一個最合適的例子是常見的電梯按鈕,有人不耐煩地反复按下電梯鍵,並不會讓電梯多次到達該樓層(或讓其盡快到達)。具有冪等性的“至少一次”消息傳遞語義能夠模擬出“恰好一次”的消息傳遞保證,以支持用於配置重試、超時和補償的業務邏輯。

冪等將關注點分離開來;以前是數據庫事務語義的內容,現在可以在應用程序層工作流中模仿一大部分。這就產生了一個圖知識庫,通過提供更高級別的控件和管理(低於ACID但高於BASE)來原生部署為NoSQL,以降低最終一致性的不確定性。基於圖知識的系統可以是雲原生的!

結合使用時,不變的持久性和可靠的冪等消息傳遞可以共同在固有的非確定性分佈式系統上支持確定性的抽象,以確保圖知識庫是一個穩定且權威的計算環境。

總結

通過擴展圖知識庫以建模分佈式系統域,並對其運行時引擎進行工程改造以支持不變的持久性、異步和並發的方法,以及可靠的冪等消息傳遞,我們就能創建一種新型的信息系統,這種系統專為應對當今的IT挑戰而生。

圖知識系統的概念擴展涵蓋了雲原生的思想,可部署為雲原生解決方案,並為努力交付智能、可連接的適應性企業應用程序的開發人員提供了他們急需的支持。這裡的目的是為共享的企業模型和元數據提供直觀的開發人員界面,以實現高效、高性能和可擴展的上下文即服務。

它提供了“好高騖遠的”API網關的一種替代方案,後者會演變為膨脹且不透明的企業服務總線,或稱“上帝”服務。基於圖知識的系統具有天然的可檢查性和開放性。聲明式建模將模型與實現清晰地分離開來,並且類型化的對象支持事件驅動的無服務器函數的後期綁定,從而在動態管道(即數據流過程)中執行所需的任何中間件服務。同樣,服務組合可以調用編排服務以跨一組服務進行協調,從而實現多步操作或端到端流程。這樣以來,圖知識庫就可以在無需規定實現的情況下實現基於模型、事件驅動和策略控制的編排和自動化。相反,持久實體通過一個中央協調器的跟踪和管理來支持編排的靈活性。簡而言之,圖知識庫的結構經過優化,可支持無狀態和事件驅動的無服務器函數。

當然,要簡化本質上很複雜的事情是很困難的。但是,只有解決了分佈式應用程序的基本建模、處理和通信難題,業界才能讓有狀態雲原生應用程序的設計、部署和管理變得切實可行。

隨著IT環境變得愈加複雜,業界開始意識到了對更高級別抽象的需求。雲原生應用程序必須從根本上簡化。應用程序開發人員不想關心容器編排或網絡連接微服務的方式,也不想了解分佈式系統工程的所有變數。

本文所述的基於圖知識的系統為下一代平台的設計提供了一種可能的方法。它們為整個企業用例提供了確定性和一致的開發人員抽象,以為複雜的分佈式系統和應用程序帶來秩序。

作者介紹:

Dave Duggal是Enterprise Web的創始人兼首席執行官。 Enterprise Web是一家總部位於紐約的軟件公司,提供混合集成和自動化應用程序平台。 Duggal是一位經驗豐富的業務領導者,當行業專注於基礎架構層時,他看到了應用程序層所面臨的挑戰和機遇,意識到應用層需要抽像日益分散、異構化和快速發展的IT資產中不斷增長的複雜性。他創立了Enterprise Web來推動業務的數字化。 Duggal構思並設計了一個屢獲殊榮的平台,該平台已獲得9項美國專利。他撰寫了許多學術論文、書籍章節和行業文章;他還偶爾會寫博客。 Duggal是行業會議(例如Layer 123、Structure、CloudExpo、SemTech、EDW、GoToCon、TM論壇、BPMnext、IWPC和電信理事會)的定期演講者,並為許多標準組織(例如ETSI、TMForum、工業互聯網聯盟)做出了貢獻。他的LinkedInTwitter

原文鏈接:

Graph Knowledge Base for Stateful Cloud-Native Applications