![](http://img3m3.ddimg.cn/75/4/29667603-1_u_1708592155.jpg)
開本:16開 紙張:膠版紙 包裝:平裝-膠訂 是否套裝:否 國際標準書號ISBN:9787111739982 叢書名:雲計算與虛擬化技術叢書 作者:[美]拉裡·彼得森,[美]斯科特·貝克,[美]安迪·巴維爾,[美]扎克·威廉姆斯,[美]布魯斯·戴維 出版社:機械工業出版社 出版時間:2023年12月 
" 編輯推薦 本書以Aether平臺為例,細致地闡述 從邊緣雲整個平臺的架構設計到每個子繫統的構建與運維的相關內容,使得讀者 可以比較全面地了解邊緣雲的建設與運維。 內容簡介 本書展示了一個邊緣雲開發路線圖,一群工程師在一年的時間裡遵循該路線圖,開發、部署,然後全天候運營一個跨越十幾家企業的邊緣雲,並提供了卓越的雲原生服務(在我們的例子中是通過5G連接提供雲服務)。該團隊利用20多個開源軟件和組件實現了這個邊緣雲和服務,但選擇這些開源組件隻是一個開始。在這個過程中,有幾十個技術決策需要做出,還有幾千行配置代碼需要編寫。這是一個可重復的實踐,作者在本書中對此實現方案進行了詳細闡述。書中的配置文件和源代碼都是開源的,適用於那些想更詳細地研究並實現邊緣雲計算和服務的讀者。 作者簡介 扎克·威廉姆斯(Zack Williams) 英特爾的雲軟件工程師,在英特爾收購ONF工程團隊後加入英特爾。在為ONF工作期間,他參與了Aether項目,並領導了基礎設施團隊。在加入ONF之前,他是亞利桑那大學的繫統程序員。他於2001年獲得亞利桑那大學計算機科學學士學位。 布魯斯·戴維(Bruce Davie) 網絡領域知名計算機科學家、VMware亞太區前副總裁兼首席技術官。他在VMware收購SDN(軟件定義網絡)初創公司Nicira後加入VMware。在此之前,他是Cisco Systems的研究員,領導一個架構師團隊,負責多協議標簽交換(MPLS)。他在網絡行業擁有超過30年的經驗,並合著了17份RFC。他於2009年成為ACM會士,並於2009年至2013年擔任ACM SIGCOMM的主席。他還在麻省理工學院做了五年訪問講師,是多本書的作者,擁有40多項美國專利。 目錄 目錄 譯者序 序 前言 第1章概述 ·································11.1術語 ·········································4 1.2解耦 ·········································9目錄 譯者序 序 前言 第1章概述 ·································11.1術語 ·········································4 1.2解耦 ·········································9 1.3雲技術 ····································111.3.1硬件平臺 ·····················12 1.3.2軟件構建塊 ··················13 1.3.3交換網絡 ·····················15 1.3.4存儲庫 ························16 1.3.5其他選項 ·····················17 1.4繫統管理員的未來 ··················19 第2章架構 ·······························212.1邊緣雲 ····································24 2.2混合雲 ····································25 2.3利益相關者 ·····························27 2.4控制與管理 ·····························302.4.1資源配置 ·····················31 2.4.2生命周期管理 ···············33 2.4.3運行時控制 ··················34 2.4.4監控和遙測 ··················35 2.4.5小結 ···························36 2.5DevOps ···································38 第3章資源配置 ·······················433.1物理基礎設施 ·························453.1.1文檔基礎設施 ···············46 3.1.2配置和啟動 ··················53 3.1.3配置API ·····················56 3.1.4配置虛擬機 ··················58 3.2基礎設施即代碼 ······················59 3.3平臺定義 ································70 第4章生命周期管理 ················734.1設計概述 ································74 4.2測試策略 ································774.2.1測試類別 ·····················78 4.2.2測試框架 ·····················81 4.3持續集成 ································824.3.1代碼庫 ························83 4.3.2構建-集成-測試 ········83 4.4持續部署 ································89 4.5版本控制策略 ·························92 4.6管理密鑰 ································95 4.7GitOps ····································96 第5章運行時控制 ···················995.1設計概覽 ······························101 5.2實現細節 ······························1065.2.1模型與狀態 ·················107 5.2.2運行時控制API ···········108 5.2.3身份管理 ····················110 5.2.4適配器 ·······················111 5.2.5工作流引擎 ·················112 5.2.6安全通信 ····················112 5.3連接服務建模 ·······················1135.3.1企業 ··························114 5.3.2切片 ··························115 5.3.3模板和流量類 ··············118 5.3.4其他模型 ····················122 5.4重溫GitOps ··························122 第6章監控和遙測 ·················1256.1指標和告警 ···························1286.1.1導出指標 ····················128 6.1.2創建儀表盤 ·················129 6.1.3定義告警 ····················131 6.2日志記錄 ······························1336.2.1通用模式 ····················133 6.2.2最佳實踐 ····················135 6.3分布式跟蹤 ···························136 6.4集成的儀表盤 ·······················138 6.5可觀測性 ······························141 關於本書的幾點說明 ·················145 前言 前言 雲計算無處不在。每個人都使用雲來訪問或交付服務,但不一定每個人都會構建和運維雲。那為什麼我們需要關心如何把一堆服務器和交換機變成24×7全天候運行的服務交付平臺呢?這是谷歌、微軟、亞馬遜等雲廠商為我們做的事情,而且它們做得非常好。 我們相信,由於分布式應用不僅在大型中央數據中心運行,也在邊緣運行,因此雲正在以另一種形式變得無處不在。隨著應用的解耦,雲正在從數百個數據中心擴展到數萬家企業。雖然公有雲廠商渴望把這些邊緣雲作為其數據中心的邏輯擴展來管理,但它們並沒有壟斷實現這一目標的專有技術。 本書提供了一個小型工程師團隊可以在一年的時間裡建立並且24×7全天候運維一個邊緣雲的路線圖。這種邊緣雲覆蓋十幾家企業,承載重要的雲原生服務—本書的例子是5G連接服務。該團隊通過使用20多個開源組件來實現這一點,但需要注意的是選擇這些組件隻是一個開始。在整個過程中,我們要做幾十個技術決策,還要寫幾千行配置代碼。我們認為本書描述的路線圖是一個可重復的過程。對於想進一步了解這個主題的讀者,書中列舉的配置文件代碼是開源的,每個人都可以獲得。前言 雲計算無處不在。每個人都使用雲來訪問或交付服務,但不一定每個人都會構建和運維雲。那為什麼我們需要關心如何把一堆服務器和交換機變成24×7全天候運行的服務交付平臺呢?這是谷歌、微軟、亞馬遜等雲廠商為我們做的事情,而且它們做得非常好。 我們相信,由於分布式應用不僅在大型中央數據中心運行,也在邊緣運行,因此雲正在以另一種形式變得無處不在。隨著應用的解耦,雲正在從數百個數據中心擴展到數萬家企業。雖然公有雲廠商渴望把這些邊緣雲作為其數據中心的邏輯擴展來管理,但它們並沒有壟斷實現這一目標的專有技術。 本書提供了一個小型工程師團隊可以在一年的時間裡建立並且24×7全天候運維一個邊緣雲的路線圖。這種邊緣雲覆蓋十幾家企業,承載重要的雲原生服務—本書的例子是5G連接服務。該團隊通過使用20多個開源組件來實現這一點,但需要注意的是選擇這些組件隻是一個開始。在整個過程中,我們要做幾十個技術決策,還要寫幾千行配置代碼。我們認為本書描述的路線圖是一個可重復的過程。對於想進一步了解這個主題的讀者,書中列舉的配置文件代碼是開源的,每個人都可以獲得。 當我們說邊緣雲的時候,是在表達什麼意思?我們需要區分由超大規模雲廠商在其大規模數據中心運行的雲(中心雲)以及由處於邊緣的企業運行(或管理)的雲。邊緣是真實物理世界與雲的交彙處。例如,邊緣(雲)可以是收集和處理來源於傳感器的數據的地方,也可以是因為時延敏感或帶寬要求高而需要讓服務靠近最終用戶的地方。 我們的路線圖可能並不適用於所有情況,但它確實揭示了雲運維過程中涉及的基本挑戰和利弊取舍。基於我們的經驗,這是一個復雜的領域,有太多術語和業務情節需要釐清。 目標讀者 希望本書對任何嘗試構建和運維自己的邊緣雲基礎設施的人來說都有閱讀價值,同時我們希望至少能為另外兩大群體提供有用的信息。 首先是正在對基礎設施選擇做評估,特別是需要在使用雲廠商提供的雲服務和構建自己的邊緣雲(或者是兩者的某種組合,類似混合雲)之間做出選擇的讀者。我們希望為他們揭開邊緣雲的神秘面紗,幫助他們做出合適的決定。 其次是那些需要在其組織選中的雲基礎設施上構建應用和服務的開發人員。我們認為對於開發人員來說,至少在高層次上了解雲的底層機制是一件很重要的事情,這樣就可以幫助開發人員開發出易於管理和可靠的應用程序。開發人員和運維人員之間的互動越來越密切(DevOps運動證明了這一點),我們的目標是促進這種合作。監控和可觀測性等話題對這類用戶尤其重要。 開源導覽 好消息是,有大量開源組件可供選擇,幫助管理雲平臺和為這些平臺構建可伸縮應用程序。不過這也是壞消息,因為從Linux基金會、雲原生計算基金會、Apache基金會和開放網絡基金會(ONF)等開源聯盟中開源的龐大的、與雲相關的項目空間中選擇相應的開源項目來構建我們的雲管理平臺,是我們面臨的最大挑戰之一。這在很大程度上是因為這些項目都在爭奪人們的注意力,所提供的功能有很多重疊,並且彼此之間有額外的依賴。 閱讀本書的一種方法是將其作為雲控制和管理的開源導覽。本著這種精神,我們不會復制那些項目已有的優秀文檔,而是包含特定項目的文檔鏈接(通常包括我們鼓勵大家嘗試的教程)。本書還包括來自這些項目的代碼片段,但選擇這些示例是為了幫助鞏固我們試圖就整個管理平臺提出的要點,它們不應被解釋為試圖記錄個別項目的內部工作。我們的目標是解釋各種拼圖如何更好地組合在一起以構建一個端到端的管理繫統,並在此過程中識別出各種有用的工具以及任何工具都無法消除的難題。 毫無疑問,我們需要解決一些具有挑戰性的技術問題(盡管市場宣傳與之相反)。畢竟,如何運作一個計算機繫統是一個和操作繫統本身同樣古老的問題。運維一個雲隻是這個基本問題的現代版本,隨著從設備管理向上延伸為服務管理,這個問題變得更加有趣。總之這是一個既新潮又基本的話題。 致謝 本書介紹的軟件要歸功於ONF工程團隊及其合作的開源社區的辛勤工作。我們感謝他們做出的貢獻,特別感謝Hyunsun Moon、Sean Condon和HungWei Chiu對Aether控制與管理平臺的突出貢獻,以及Oguz Sunay對Aether整體設計的影響。Suchitra Vemuri對測試和質量保證提供了無價的見解。 本書會不斷完善,感謝每個提供反饋的人。請使用問題鏈接向我們發送你的寶貴意見。另外,可以在Wiki上查看目前我們正在處理的待辦事項列表。 Larry Peterson、Scott Baker、Andy Bavier、 Zack Williams、Bruce Davie 2022年6月 ![](http://img3m3.ddimg.cn/75/4/29667603-2_u_1708592155.jpg) ![](http://img3m3.ddimg.cn/75/4/29667603-3_u_1708592155.jpg) |