百易傳媒（DOIT）：2020行業云原生應用白皮書（59頁）.pdf

《百易傳媒（DOIT）：2020行業云原生應用白皮書（59頁）.pdf》由會員分享，可在線閱讀，更多相關《百易傳媒（DOIT）：2020行業云原生應用白皮書（59頁）.pdf（59頁珍藏版）》請在三個皮匠報告上搜索。

1、 特此鳴謝參加本次白皮書的編纂的行業和企業專家。 謝長生 華中科技大學武漢光電研究中心教授 吳 非 華中科技大學光電國家研究中心研究員、博導 許 淵 Intel 數據中心產品架構師 吳 棟 浪潮集團云計算高級架構師 林小引 戴爾科技集團售前系統工程部解決方案架構師 張利俊 戴爾科技集團企業技術戰略架構師 傅純一 VMware 大中華區高級產品經理 酈 達 聯想凌拓數據與云架構顧問 李 云（至簡） 阿里云云原生高級技術專家 劉 堯 百度智能云云原生和區塊鏈產品負責人 陳一葦 騰訊云云原生高級技術專家 彭德華 金山云云原生解決方案總經理 朱 瑯 京東智聯云 PaaS 產品負責人 吳 濤 華云數據標

2、準總監 李 魯 網易云資深解決方案架構師 賀洪龍 靈雀云資深解決方案架構師 康 洋 博云解決方案架構師 梁 勝（西瓜哥） 高端存儲知識 CHO 薛 浩 亞信科技平臺產品研發與交付中心總監 Grace Shen 青藤云安全容器安全技術專家 苗遠強 時速云解決方案架構師 莊懷軒 大連華信技術總監（ 原 Portworx 亞太區首席架構師） 周 磊 云徙科技 i-DP 產品總監 邵國健 XSKY 系統架構師 王鵬飛 焱融科技首席技術官 黃雨婷 才云科技智能容器云數字營銷經理 俞仁杰 螞蟻金服金融云產品專家 花 瑞 杉巖數據存儲專家 于 爽 KubeSphere 容器平臺產品經理 葉理燈 UCloud

3、 私有云及容器產品線負責人 侯亞輝 云途騰容器產品總監 宋家雨 百易傳媒（DOIT）編輯部 謝世誠 百易傳媒（DOIT）編輯部 朱朋博 百易傳媒（DOIT）編輯部 崔歡歡 百易傳媒（DOIT）編輯部 張妮娜 百易傳媒（DOIT）編輯部 目錄 一、 前言- 二、 云原生化是 “新基建” 和 “互聯網+” 的技術表達- 2.1傳統行業面臨的挑戰- 2.1.1傳統行業/企業被互聯網無情 “碾壓” - 2.1.2MadeinInternet （新零售、 新制造、 新能源、 新技術、 新物流） - 2.2 云原生（CloudNative）實現 - 2.3云原生與企業競爭力塑造 - 2.4 云原生與企業管

4、理 - 三、容器云原生技術基礎（企業云原生轉型的技術實施）- 3.1云原生應用的技術內涵 - 3.1.1容器化- 3.1.2容器化與虛擬化- 3.1.3微服務 ： 單體化應用和微服務架構的變化- 3.1.4DevOps- 3.1.5持續交付、 頻繁交付、 快速交付、 降低發布風險CI/CD- 3.2容器和微服務化 - 3.3容器和 Kubernetes- 3.4技術應用熱點 - 3.5云原生應用有關思考- 3.5.1 從 Web 訪問接入開始更加穩妥嗎？- 3.5.2數據庫原生化改造- 3.5.3選SaaS服務， 還是自建？- 3.5.4 應用微服務化拆分的一般原則 - 01 04 05 05

5、 05 06 06 07 09 10 10 10 11 14 15 16 16 17 17 17 18 19 19 四、 云原生應用對數據基礎設施的影響- 4.1存儲的變化 - 4.1.1容器數據持久化- 4.1.2CSI 和容器存儲 - 4.1.3容器存儲可視化和管理- 4.1.4 海量數據和容災備份 - 4.1.5 存儲趨勢變化促進容器發展 - 4.2計算、 網絡的變化- 五、 云原生化應用安全的話題- 5.1 安全風險與挑戰 - 5.1.1鏡像風險- 5.1.2 鏡像倉庫風險 - 5.1.3Kubernetes安全風險- 5.1.4容器風險- 5.1.5 主機操作系統風險- 5.2 安全

6、結論 - 六、 總結和展望- 21 22 22 23 24 24 25 25 27 28 28 28 29 29 30 31 32 七、 附錄：容器云原生技術產品和服務- 博云- 戴爾科技集團 - 聯想凌拓 - 英特爾 - KubeSphere開源容器平臺- XSKY- 中興通訊 - 34 35 37 43 46 47 49 50 有數據顯示：2018 年我國云計算整體市場規模達 962.8 億元，增速為 39.2%。預計未來幾 年復合增速在 30% 左右，到 2022 年我國云計算整體市場規模接近 3000 億元。 國外知名分析機構 Gartner 的數據顯示：云計算滲透率將大幅提升，201

7、9 年云計算的市場 滲透率將首次突破 10%，達到 11.3%；到 2021 年全球云計算市場滲透率將達到 15.3%。 數據是冰冷的，會有分類和統計上差異，如云計算滲透率專指公有云嗎？包括私有云在內 嗎？盡管如此，并不影響我們對整體趨勢的判斷。 傳統行業 / 企業應用需要遷移到云平臺，過程不是一蹴而就的，而是遵循演進階段的劃分， 大致可以分為如下 4 個階段： 既然如此，問題來了！ 如今，中國傳統行業 / 企業業務云化已經發展到了哪個階段？ 本白皮書觀點表明，傳統行業 / 企業云計算應用如今已經進入到了第三階段的 PaaS 平臺 階段， 這里PaaS平臺技術非常明確， 以平臺為基礎的云原生化

8、開發， 實現對傳統應用逐步改造。 從技術上看，基于容器 + 新型 PaaS 平臺具有敏捷部署、彈性伸縮、靈活調度的優點，結合、 DevOps 和微服務三駕馬車，企業可以快速走上云原生轉型之路。有數據顯示，在美國，容器 化部署占到了生產應用部署的 48%，2020 年，超過 50% 的全球組織將在生產環境中運行容器 化應用程序，到 2022 年將超過 75%。在中國，截止到 2018 年底，已有 96% 的 IT 企業在生產 環境部署容器化應用。 階段 1：虛擬化整合 +IaaS 階段：這個階段以 IaaS 基礎設施虛擬化應用為主。 階段 2：IaaS+ 簡單 SaaS 應用階段：在虛擬化資源基

9、礎上，開始對外提交簡單 SaaS 服務。在這個階段，傳統行業 / 企業用戶部分業務部門，會脫離開 IT 部門的納管， 嘗試公有云服務，嘗試局部業務的創新。 階段 3：豐富 SaaS 應用 +PaaS 平臺階段：為了能夠提供統一的 IT 服務，增強對于 IT 基礎設施的把控能力，更多傳統行業 / 企業通過構建私有云，對于 SaaS 服務進行集中 管理，開始構建符合行業企業發展需要的 PaaS 平臺。 階段 4：全面云化、自動化管理和服務的階段。 02 白皮書也強調：構建平臺是起點，不是目的，是手段、工具，但不是業務應用，用好容器 + 新型 PaaS 平臺加快云原生化部署才是當務之急。與此同時，傳

10、統行業 / 企業用戶可以直接選 用云廠商提供的云原生服務，也可以通過 ISV 等合作伙伴繼續沿用服務外包方式，依靠第三方 服務商的產品和技術力量，不必事事親力親為。 按照白皮書的判斷，行業 / 企業傳統應用向云上的遷移基本完成，解決了傳統應用在云環 境下的使用問題，也能夠享有 IaaS 基礎設施的資源彈性和易部署的紅利，但效果是有限的，與 類似“雙十一”的互聯網業務支撐系統存在明顯差距。如果說，傳統應用上云解決“能用”的 問題；云原生化改造要解決的就是“好用”的問題。 業界經常用“穩態”和“敏態”來概括行業 / 企業應用的特征，但這種概括是相對意義上的， 是暫時的，因為并不存在絕對意義上的“穩

11、態”，業務創新要打破的就是“穩態”，使其走向“敏 態”，走向云原生化應用。 毫不夸張地說，云原生化改造會成為傳統行業 / 企業新的分水嶺，將決定傳統行業 / 企業 在未來市場上的“生”與 “死”，依靠政策壁壘，也許傳統行業 / 企業還能夠生存，但也僅僅 是生存，甚至“生不如死”，終究會被時代洪流所吞沒。 傳統行業 / 企業需要有足夠的危機意識！ 03 2.1 傳統行業面臨的挑戰 2.1.1 傳統行業 / 企業被互聯網無情“碾壓” 2.1.2 Made in Internet（新零售、新制造、新能源、新技術、新物流） 傳統行業 / 企業面臨互聯網企業無情碾壓，這已經是鐵一樣的事實，也是傳統行業

12、/ 企業 每個從業者的真實感受；新動能替代舊動能，“互聯網 +”或者“+ 互聯網”已是傳統行業 / 企 業新課題。 遺憾的是，幾年時間過去了，很多傳統行業 / 企業仍然沒有找到“互聯網 +”的節奏。從 金融行業的 Open Banking，到電信運營商避免被“ 管道化”，從新能源、新制造到新零售， 傳統行業 / 企業仍然在摸索。新基建部署也提出了新的需求。 傳統行業/企業相比互聯網企業的業務特點不同， 傳統行業/企業注重ROI， 強調投入產出比。 相比互聯網企業的特點是投入大， 風險大， 收益量化有不確定性。 但是從技術需求上， “互聯網+” 實質是數字化轉型的問題，是在 “數據 + 算法”

13、定義的世界中，以智能數據服務的流動，化解 復雜系統的不確定性，優化資源配置效率，構建企業新型競爭優勢。 補足云原生應用上的短板，是傳統行業 / 企業應對互聯網沖擊的首要課題。 新基建和“互聯網 +”或者說“+ 互聯網”從概念上并不難理解，就是利用先進的技術對 傳統產業進行改造，方向就是所謂新零售、新制造、新能源、新技術、新物流，也就是“Made in Internet ”。 “Made in Internet”應該怎么實現呢？在“天貓”、“京東”、“淘寶”、“拼多多”上 開個網店，通過互聯網接受訂單，利用支付寶、微信支付等電子支持手段結算，這算不算“互 聯網 +”呢？ 答案當然算，但不高級。

14、對于傳統行業 / 企業來說，電商、網店就是一種新銷售渠道，因其信息更加透明、物流配 送方便，導致銷售占比不斷提高，如今新舊渠道并存是一個基本現狀。但傳統行業 / 企業也應 該意識到無論是電商渠道， 還是傳統分銷渠道， 無形中都割裂了企業和最終消費者間的信息傳遞。 這種“互聯網 +“僅僅觸及了傳統行業 / 企業銷售這一個環節，更何況，傳統渠道也在積 極探索電商新渠道，因此并不高級?！癕ade in Internet”要改變的是從研發、市場、制造、銷 售到服務的全部環節。按照理想化的設計，“Made in Internet”并不需要電商渠道，全部業務 流程應該完全構建在互聯網平臺上，這才是真正的“

15、互聯網 +”，云原生化應用是首要待解決 的問題。 05 06 2.2 云原生（Cloud Native）實現 2.3 云原生與企業競爭力塑造 互聯網企業應用生來就是云原生化，相比傳統行業 / 企業應按照 Client/Server 或者 Browser/Server 的模式構建，本質是一種集中式計算，沒有辦法支持高并發，也沒有辦法支持 快速迭代。 傳統集中式系統，版本更新以年為單位計算，主要依賴傳統 IT 產品供應商，二者之間是一 種 IT 服務外包方式。相比以分布式為特征的云原生應用，使用微服務化的架構，模塊之間呈現 一種松耦合的模式。 其中， 局部修改并不引發全局， 讓軟件開發以 “迭代”

16、 方式呈現， 以此為依托， 創新業務以持續“試錯”的方式，完成與消費和使用者的磨合。 在迭代模式下，消費者既是使用者，也是新需求和服務的貢獻者，軟件開發人員根據消費 者的需求不斷修改，迭代式創新服務，而不是傳統研發人員的單向驅動，這種新型消費伙伴關 系是傳統模型無法比擬的。 以迭代為結果的微服務化云原生應用開發，將涉及研發體系和結構的變化，從單體結構走 向微服務化。容器是目前使用最為普遍的開發技術，Kubernetes 是最為普遍的容器編排和管理 平臺，是笑到最后的技術，事實上的市場標準。目前容器可以部署在物理機，也可以部署在虛 擬機上。 與虛擬機相比，容器部署的數量更多，顆粒度更細。微服務化

17、、DevOps、容器帶來了云原 生應用研發和管理新方法，讓傳統行業 / 企業能夠更好與開源社區最新的軟件技術進行結合， 支持業務創新和迭代。 業內流傳著這樣一句話：所有企業都是軟件企業，實際上，間接回答了云原生與企業競爭 力關系的問題。 為什么都是軟件企業？ 因硬件產品趨于工業標準化， 更能夠體現企業差別的應該是軟件的能力， 以互聯網廠商為例， 他們就是通過充分使用開源技術，重新塑造了軟件能力。 傳統行業 / 企業多采用購買商業軟件套件，采用 IT 服務外包的模式，傳統模式的特點是初 始購買成本高， 軟件版本更新迭代緩慢。 相比， 互聯網企業初始購買成本低， 軟件版本更新速度快， 幾乎每天都有

18、軟件更新，可以隨時引入新技術，產品技術創新能力強。 07 未來，企業的核心競爭能力更多體現在軟件能力上。 依據企業中企業應用的不同特征，有些專業分析機構和企業將其區分為“穩態”和“敏態”， 劃分的主要依據是軟件使用者數量的劃分，“穩態”業務沒有海量并發訪問的需求，舉例如 ERP，主要局限在生產線相關人員使用，這些業務以往是部署在小型機環境中，強調系統的可 靠性和穩定性；“敏態”業務，類似“雙十一”這樣的促銷活動，預計會有波峰、波谷的劇烈 變動，要求系統具有足夠的彈性、敏捷性和靈活性。有人習慣上將傳統業務應用稱為“穩態”， 而將互聯網創新業務應用稱為“敏態”。 這樣的業務劃分有一定的現實意義。

19、但是站在云原生業務應用的角度上，需要注意到所謂“穩態”和“敏態”只是一個相對的 概念， 并非是一成不變的。 以新制造為例， 與標準工業化、 流程化為特點的傳統批量化制造相比， 新制造更加強調個性化， 從批量化被動的使用者， 要變成為個性化產品制造的創造者和參與者， 消費者需要參與到產品制造過程中。從技術的角度，意味著傳統 ERP 的各個環節需要面向最終 消費者開放，消費者希望了解共享物料、設計、制造以及物流等各個環節信息。 在新制造的環境下，業務需求的變化，也將帶來新的需求，對于系統來說意味著海量的并 發訪問，從某種意義說，新制造就是要打破四平八穩“穩態”的格局，所謂不破不立?；ヂ摼W 企業能夠

20、走通的路，傳統企業沒有走不通的理由，這恐怕也是“互聯網 +”希望傳遞的信息。 從單體結構到微服務化到業務應用創新，軟件更新迭代快，一天 72 變，意味著沒有辦法一 次性購買終身免疫，云原生能力獲得需要方方面面的改變。傳統行業 / 企業以往所采用的 IT 服 務外包模式沒有辦法應對隨時出現的調整和變化，沒有辦法更多從“開源”技術的世界中吸取 能量，為業務創新所使用。 從根本上說，云原生應用的本質不是產品 / 方案，而是一種管理開發體系的改變，是對行 業 / 企業研發體系的重構。 為了實現重構， 傳統行業/企業可以像互聯網一樣， 公開招聘， 廣納人才， 以金融、 電信為例， 他們的研發隊伍規模、實

21、力并不遜色于互聯網廠商，但對于政府、能源、制造、醫療等行業而言， 其技術隊伍的規模、實力比較薄弱，在“全民軟件、全民研發”的大環境條件下，面對面真金 白銀去搶人，對于傳統行業 / 企業難度不小。 傳統行業 / 企業可以繼續沿用傳統的 IT 服務外包的方式，但是應該探索新型合作伙伴關系， 以滿足和適應云原生化轉型和變化的需要。新型合作伙伴關系，需要新的服務和付費方式。對 2.4 云原生與企業管理 但是企業管理問題也是一個系統龐雜的問題， 類似 “一把手” 工程， 需要企業管理者運籌帷幄。 將云原生應用上升到企業管理的高度是恰當的，應該有這樣一個全局高度的把握，然而過度強 調“一把手”工程也會束縛

22、云原生化應用推動的步伐。 目前，公有云、ICT 產品供應商、創新企業等都提供了很多云原生應用技術產品和服務， 可以幫助傳統行業實現業務創新，從而讓云原生化的問題變得沒有那么復雜。 不要被企業管理束縛住手腳。這也是白皮書希望闡述的觀點之一。 在中國，企業發展問題都可以歸結為現代化企業管理，加之云原生應用牽涉企業應用開發 管理體系的重建，因而應該從企業管理的高度重新審視云原生應用和業務創新的問題。 于現有 IT 人員也提出了更高的要求，需要隨時把握開源技術最新動向，并能夠與業務創新加以 結合，需要協調合作伙伴技術力量，構建新的管理和付費方式。 08 10 云原生應用起源應該追溯到 2006 年谷歌

23、 cgroups 容器技術，也有觀點認為這個概念是 Pivotal 公司的 Matt Stine 于 2013 年首次提出的，2013 年 Docker 正式發布讓更多人看到了容 器， 類似于集裝箱技術對運輸業革命， 沒有容器就沒有云原生應用， 容器技術催化了云原生應用， 但是云原生并不等于容器（詳情參見 3.2 容器和微服務化）。 容器應用自帶環境， 可將一致容器化應用運行在各種環境中， 它便于調試、 開發、 部署、 運維、 遷移、 擴容， 從而造福程序員自己。 容器這些特性與云彈性能力相結合， 可最大化發揮云的效能， 發揮云的價值。 云原生的軟件應用生于云上，迭代成長在云上，在云上工作，最

24、后也銷毀在云上。為了高 效管理容器，2014 年，Kubernetes 項目開源。2015 年，谷歌和紅帽牽頭成立了 CNCF 基金會， 并將 Kubernetes 捐獻給了 CNCF。Kubernetes 讓容器技術生態迅速成型，云原生由此進入原 子彈爆炸的狀態。 從以往單體應用到微服務架構應用，部署和管理應用的復雜性大大增加，在 2013 年 Docker 鏡像出現以后，容器變成了黑盒子，使用者只會關心它能做什么，需要一個服務的時候， 啟動一個或者若干容器即可。 容器可以提供很多不一樣的服務，也可以提供很多一樣的服務，也就是橫向擴展，提供控 制系統的彈性伸縮。容器化解決了效率問題，如應用開

25、發、測試、部署、迭代等都發生了天翻 地覆的變化。以互聯網企業為代表，開發人員普遍采用了容器化手段和開發方法。 3.1 云原生應用的技術內涵 3.1.1 容器化 傳統行業 / 企業用戶的數字化轉型也應該采用容器化的技術，傳統應用需要進行容器化改 造。容器技術有共享內核和獨立內核兩種技術，默認都是共享物理機內核，獨立內核的比如 Kata Container。 3.1.2 容器化與虛擬化 容器化需要首先部署虛擬化嗎？ 這個問題始終存在爭論。有輿論認為，容器化替代虛擬化，容器化是虛擬化的大敵。 虛擬化早于容器化，以 VMware vSphere、微軟 HyperV、開源 KVM 等軟件為代表，傳統 行

26、業 / 企業普遍采用虛擬化技術。虛擬化技術重點解決了 CPU 計算資源利用率不高的問題，通 過構建虛擬機，提高計算資源的利用效率。虛擬化技術是云計算技術的基礎，這也是為什么云 計算初期被稱為虛擬化的原因。 在 Intel 處理器支持下，CPU 芯片直接部署虛擬化，虛擬化虛擬物理設備，所謂虛擬機， 其上安裝操作系統，部署應用。 11 3.1.3 微服務：單體化應用和微服務架構的變化 容器化和虛擬化在功能上存在一定程度重合，本意都是屏蔽 CPU 資源調度技術的復雜性和 差異性。 從目前的情況看，容器可以直接部署在物理主機上，也可以部署在虛擬機上，特別對于傳 統行業 / 企業用戶而言，虛擬化技術普遍

27、采用，因此需要同時管理容器和虛擬化，相互之間存 在交集，雖然虛擬化和容器本質上都是一種計算資源隔離技術，但在隔離程度上，虛擬化更高， 安全程度也更高。 云原生應用可以直接部署物理硬件的操作系統中，由于沒有虛擬化的開銷，更加具有成本 效率，它們憑借 Kubernetes 平臺對集群中的容器進行管理，這也是有輿論認為容器化將取代 虛擬化的動議來源。 但是這種開銷也并非絕對。以虛擬化為例，虛擬化內核與跟 Kubernetes 緊密結合在一起， 也就是說，在虛擬化就有對容器調度的 mini 資源嵌入。如此部署容器應用的時候，根本不用考 慮是部署在虛擬機上，還是部署在物理服務器上，根本不用關心底層的基礎

28、設施。 有廠商數據顯示：超過 80% 的容器部署是運行在虛擬機上，其余部署在物理服務器上，很 多用戶希望物理服務器資源的調配管理能夠通過容器編排軟件實現。也有第三方的測試顯示： 借助新的平臺對虛擬機和 Kubernetes 進行管理，相比物理機裸機設備部署有 8% 的性能提升， 這主要得益于虛擬化對于物理資源的高效調配。很多企業已經基于虛擬化技術建立了整套的運 維管理流程，為容器應用建立一套基于物理服務器的運維流程是他們輕易不肯嘗試的，這也是 他們繼續選擇在虛擬化技術平臺上運行容器應用的原因。 微服務是相對于大型單體應用而言的。 傳統的應用開發模式下，隨著用戶對應用陸陸續續提交新的需求，開發人

29、員需要在原來的 應用上不斷添加新的功能，這就相當于在一個船上不斷修修補補的過程，它的功能越多，也就 意味著下次改動需要注意的地方越多，一次改動可能會帶來很大的影響。簡單說，這是一種緊 密耦合的架構。 12 微服務架構與此前的垂直架構、SOA 架構的一脈相承。 通俗地說，微服務是將單體應用拆分為多個組件，如用戶界面、消息隊列、數據庫訪問等， 以電商交易為例，拆分為在線支付、訂單生成、訂單跟蹤等多個微服務，其中，每個微服務也 可以進一步拆分，微服務之間通過接口進行調用，如此，就構建成了松耦合的架構。 微服務彼此獨立，修改、更新、迭代不會牽涉到其他微服務的模塊。 從開發效率來講，傳統單體應用開發模式

30、下，許多人共同面向一個大的應用，就像一群工 人圍在一起組裝一臺汽車一樣，工序之間相互影響，相互干擾，效率不高。 微服務化則把汽車生產變成了工業流水線，一個工人只負責其中一部分，每個工人只需要 熟悉自己負責的那部分就好，每一部分可被獨立完成，獨立部署和更新。 微服務之間通過 RESTful API 進行連接。由于微服務之間以及微服務與客戶端之間的連接 要很快速，而且消耗要盡可能的低，REST API 就非常合適。 Service Mesh 也是如今談論和使用最多的技術，Service Mesh 是用于處理服務間通信的基 礎設施層，用于在云原生應用復雜的服務拓撲中實現可靠的請求傳遞。 Servic

31、e Mesh 與傳統基礎設施層不同之處在于，它形成了一個分布式的互聯代理網絡，以 sidecar 形式部署在服務兩側，服務對于代理無感知。 13 目 前 發 部 分 Service Mesh 只 是 開 源 項 目， 比 較 知 名 的 項 目 有：Linkerd、Istio 和 HashiCorp Consul 等。 Linkerd：2016 年發布，是這些項目中最早的。Linkerd 是從 Twitter 開發的 library 中 分離出來的。在這一領域另一位重量型選手Conduit，已經進入了 Linkerd 項目并構成了 Linkerd 2.0 的基礎。 Envoy：由 Lyft 創

32、建，為了能夠提供完整的 service mesh 功能，Envoy 占據“數據平面” 的部分，與其進行匹配。 Istio：由 Lyft、IBM 與谷歌聯合開發，Istio 可以在不修改微服務源代碼的情況下，輕松 為其加上如負載均衡、身份驗證等功能，通過控制 Envoy 等代理服務來控制所有的流量。此外， Istio 提供容錯、金絲雀部署、A/B 測試、監控等功能，并且支持自定義的組件和集成。 Rancher 2.3 Preview2 版本上開始支持 Istio，用戶可以直接在 UI 界面中啟動 Istio 并且可 以為每個命名空間注入自動 sidecar。Rancher 內置了一個支持 Kia

33、li 的儀表盤，簡化 Istio 的 安裝和配置。這一切讓部署和管理 Istio 變得簡單而快速。 HashiCorp Consul：與 Consul 1.2 一起推出了一項名為 Connect 的功能，為 HashiCorp 的分布式系統添加了服務加密和基于身份的授權，可用于服務發現和配置。 這里重點說說 Istio，它被視為 Service Mesh 最流行的實踐，Istio 一些關鍵性功能包括： 幫助微服務之間建立連接， 幫助研發團隊更好的管理與監控微服務， 并使得系統架構更加安全。 Istio 幫助微服務分層解耦，解耦后的 proxy 層能夠更加專注于提供服務發現、負載均衡、 故障恢復

34、、服務度量、服務監控、A/B 測試、灰度發布、限流限速、訪問控制等基礎架構的能力。 使用微服務需要治理平臺支撐， 經過微服務化拆分之后， 服務從本地調用變為遠程方法調用， 各種不確定因素變多了，必須有微服務治理平臺來應對，常見的有 Spring Cloud 、Apache Dubbo、Spring Cloud Alibaba、Apache Service Comb 等等，其中包括服務發現、服務訂閱、 服務監控、服務追蹤、服務日志等。 在選擇微服務框架時需要有幾個簡單的考慮原則：工具棧豐富度（微服務技術棧的深度和 廣度）、通用性（社區活躍程度、使用比例等）、開放性（與其他開源系統的兼容性和互操作

35、性） 和可移植性（業務代碼無侵入或低侵入）等。 當一切就緒，平臺上發布了成百上千個服務，每個服務或微服務相互連接成網狀，如何讓 這個網絡有序、有邏輯便非常重要，一來便于修改和維護，二來保證穩定和性能。 如何讓網絡變得有序有邏輯呢？ 14 3.1.4 DevOps DevOps 是 Development（開發）和 Operations（運維）的組合詞，DevOps 是一組過程、 方法與系統的統稱，通過一系列自動化流程能使構建、測試、發布變得更加快捷、頻繁和可靠， 可用于促進軟件開發、技術運營和質量保障（QA）部門之間的溝通和協作，最終為軟件產品和 服務的及時交付提供保障。 DevOps 領域最

36、明顯可見的在工具層面，常用的工具包括：監控工具 Prometheus、 Zabbix、Nagios，性能分析 / APM 工具 Newrelic、Oneapm、Pinpoint、Zipkin，批量 + 自 動化運維工具 Puppet、Ansible、Chef、Saltstack，日志分析工具 Graylog、Nagios、Elastic Stack、LOGalyze、Fluentd，持續集成 / 發布工具 Jenkins, 中國自己的開源工具 Cyclone。 AWS 對 DevOps 的定義是：DevOps 集文化理念、實踐和工具于一身?？梢蕴岣呓M織交付 應用程序和服務的能力。與使用傳統軟件

37、和基礎設施管理流程相比，能夠幫助組織更快地發展 治理平臺首先梳理系統對外開放的服務化接口、服務分組以及動態路由等等，然后對拆散 的服務進行歸類、界定，確定服務領域和服務邊界，最后通過服務遷移、切換，對同一領域的 服務接口進行服務整合，提供統一的服務出口，實現服務編排。 領域驅動設計（Domain-Driven Design，DDD）是軟件行業最新的方法，當拿到一個需求 的時候，DDD 強調應該首先考慮要解決什么問題，它的問題域是什么，而不是先考慮用哪種技 術去實現。這里出現了域的概念，域可以簡單地理解為微服務化拆分后的又一個整合，域是同 類功能或者問題的一個集合。 從領域驅動設計的角度來看，

38、探討需求首先應該從問題域出發， 探討關于業務邊界的事情， 梳理要實現哪些功能和需求。下一階段拓展到工作邊界，探討如何分工協作，確定團隊合作的 方式。最后，到達應用邊界，即技術實現的解決問題領域。 微服務也是對大數據、AI、物聯網的有效支撐。 開發運營平臺收集處理數據，用包括數據庫、數據倉庫、數據湖的方式存儲海量數據，采 用各種先進的大數據和人工智能 AI 技術對數據進行挖掘，從數據中心獲取洞察力，為產品優化， 降本增效提供支撐。 大數據、AI、物聯網等都需要各種不同的運算、存儲以及網絡傳輸能力，而基于 Kubernetes 提供容器微服務可以動態提供資源和平臺支撐，微服務在可管理性上、成本、提

39、升 效率和質量上都有明顯優勢。另一方面業務架構的微服務化打破了數據孤島，更方便獲取業務 數據用于大數據分析。 15 和改進產品。這種速度使組織更好地服務其客戶，并在市場上高效地參與競爭。 DevOps追求的是一種理想化的協作狀態， 涉及開發、 測試、 產品、 項目管理、 運維人員等等， 在 DevOps 中，開發人員專注于業務應用的生命周期管理，運維人員專注于自動化環境資源的 維護，QA 人員專注于自動化業務運行環境的供給和質量跟蹤保證。許多人認為，所有能在保持 質量的前提下提高交付效率的方法和方法論都屬于 DevOps 的范疇。 無論國內還是國外，行業內還沒有一個能廣為接受的 DevOps 實踐模型來作為參考， DevOps 本身有很高的實踐性和靈活性的特點，在實踐中，很多企業也確實從 DevOps 中獲益 良多，但對于更多企業來說，沒有成熟的參考模式做起來就會比較困難，這要求企業能提供試 錯的空間，也就意味著會出現意料之外的成本。 一個比較容易接受的路徑是，由實際的業務來驅動，當企業開發一些新興業務的時候，就 以 DevOps 來進行，一味的對原有系統進行改造是得不償失的。 那么如何構建業務流程梳理與度量體系完善 DevOps 呢？ 通過職責梳理。確定流程與職責的對應關系，在實踐中，通過對照制度發現各個部