吐血整理 | 快速學習大廠們的軟件案例經驗

如有任何問題或建議，歡迎及時交流和碰撞。個人公衆號是 【腦子進煎魚了】，GitHub 地址： https://github.com/eddycjy。

前幾天，煎魚去了趟北京，參加了爲期三天的全球軟件案例研究峯會（TOP 100）。

同時記了一些筆記，整理後分享出來，但願對你們有所幫助，拓展眼界很是重要。

內容比較多（已經精簡過），你們能夠挑本身感興趣的學習，建議三連。

一級目錄以下：

1. 百度內部業務 ServieMesh 實踐。
2. 雲原生開發平臺在騰訊遊戲運營中的實踐。
3. 快狗打車可持續交付實踐。
4. 網易數帆從微服務框架到服務網格架構平滑演進及最佳實踐。
5. 不破不立：企業級研發效能提高的創新實踐。
6. 自如雲原生落地最佳實踐。
7. 研發效能度量的誤區、體系化實踐和效能提高案例。
8. 京東 BDP 的全域監控、管控平臺搭建實踐。
9. 構建發佈效率從10分鐘到秒級的提高 - 雲原生下編程方式的探索和實踐。
10. 全面監控體系建設及智能監控的探索實踐。
11. 低代碼技術在貝殼的實踐。

百度內部業務 ServieMesh 實踐

本場演講內容主要爲微服務到服務網格的過程。其中涉及百度在異構場景下的一系列演進和適配操做。

同時也能得知百度也是本身作了個 bmesh，自此歸納幾乎全一線互聯網大廠，均爲自研（或結合）ServieMesh。

總體演進

1.0 時代

第一代微服務架構（1.0時代），主體是基於 SDK/開發框架的微服務治理體系。

主要存在如下問題：

• 開發成本高：異構語言的問題，每一個語言都要從新開發。
• 升級成本高：框架上線以來業務。
• 管理成本高：服務拓撲和治理沒有統一管理（須要治理）。

2.0時代

第二代微服務架構（2.0時代），主體是基於微服務框架到服務網格，也就是把服務治理能力抽取出來，做爲一個進程（sidecar），與業務邏輯解耦。

從概念上來說，主要分爲如下兩類：

• 數據平面

  • 與業務無關。
  • 與語言無關。
  • 獨立的升級（直接升級 sidecar 的進程），可以解耦。

• 控制平面

  • 可以統一的管控。

百度現狀

各語言在內部勢均力敵，沒有誰強誰弱。各自都有框架，且有可能有多個框架，可自行腦補一下在公司內部一種語言有 N 種框架，且多種協議（含私有協議）的狀況：

存在如下問題：

• 多個語言開發。
• 多個框架改造。
• 多個通信協議。

簡單來說就是 「異構系統」，傳統的微服務框架沒法知足了，成本很是高，甚至不可行。只能經過服務網關的方式來實現微服務治理。

上服務網格的困難

• 改形成本：

  • 各類內部框架的支持。
  • 各類通信協議的支持。

• 性能問題：

  • 通信延遲，有些敏感業務沒法接受，例如：搜索。
  • 資源開源，數十萬機器，每一個服務都加邊車，成本極大。

• 規模問題：

  • 隨着接入的節點越多，規模越大，控制平面下發配置的速度越慢，甚至沒法工做。

百度的解決方案（總體架構）

在開源的技術棧上進行了本身的拓展，用的是 istio+envoy。

而且在 istio 之上作了一層抽象，實現了 Mesh 的管理界面。

另外實際上在調參時，是須要不少實際經驗的，例如：超時的值到底怎麼配，所以又基於此在平臺上提供了智能調參系統。

與目前所知的一線互聯網大廠改造比較相似，區別在於還作了不少自有平臺。

遇到的問題（大規模落地三步走）

解決接入問題

• 流量劫持方案：

  • 社區自有的方案沒法修改服務治理的參數（例如：致使原有的超時重試變成了對邊車重試）。
  • iptables 存在性能問題。
  • 沒法在 mesh 和 非 mesh 下切換：不能徹底信任，掛掉後怎麼處理，流量怎麼切。解決方案是劫持服務發現的過程（邊車劫持的是的服務地址），就可以解決流量劫持的自由問題。
• 自有協議代理：有二十多種協議，解決方案是抽了一層公共 Proxy，實現 codec 就能夠了。但也無法解決所有問題，由於 Mesh 對協議有要求，例如加字段。但有的老協議是無法擴展的。最後解決方案是作協議轉換，業務代碼就不須要修改了。
• 多框架支持：網格對框架有基本要求（治理行爲可拓展，透傳 Trace 信息），但有的老框架無法支持。經過探針邏輯修改框架行爲（探針感知邏輯，修改框架行爲）。

解決性能問題

• 網絡性能優化：

  • envoy 的最大問題是性能不怎麼好，拓展性是第一，性能是他的第二位。
  • envoy 的多線程的競爭是很是厲害的。最後是採起 envoy+brpc 的融合方案（難度很大，組件替換，逐步替換）解決，總體延遲和 CPU 使用率明顯低於原生版本。作了開關，能在原生和融合後版本切換。

• 網絡控制面優化：

  • istio 原生的配置是全量下發的，很是不科學。
  • 改造爲經過獲取關係按需下發。服務發現改成由控制面下發到數據面。簡單來說就是原生 istio 控制面在大規模下有不少問題，爲此改了不少邏輯。

• 網絡性能優化：

  • istio 原生爲 both side 模式，要轉換 2 次，損耗 2 次網絡開銷，2次性能開源，內部認爲不可接受。改成 client side 的模式（架構上的折中，有的業務很敏感，不推薦爲主流方式）。

享受網格的紅利

• 流量可操控：

  • 全部的流量都在本身的手中，能夠去作不少事情。例如作不少動態的事情，全局流控，根據延遲分配請求到不一樣的下游等，帶來的新的問題就是太多配置，太吃經驗，所以作了哥全局智能調參。
  • 結合高級治理，配合自愈和剔除，可用性的修復時間大大的提升，提升了可用性。

• 服務可觀測：

  • 結合框架透傳 Trace 信息，Sidecar 負責上報監控，便可造成追蹤。

• 自動止損

  • 結合監控平臺採集實例、集羣信息，發現異常，上報給控制平面。而後就能夠屏蔽掉某個實例、集羣。實現自動止損。

• 異常注入

  • 混沌平臺負責配置、評估，服務網格負責實施異常注入。

• 容量管理

  • 傳統須要作壓測，對整個系統進行很長時間的壓測（想壓到極限，要構造大量的數據和流量），很是麻煩。
  • 經過服務網格能夠在局部構造出極限的壓力。

落地狀況

百度目前正在逐漸落地，已接入實例數萬。經過高級的服務治理（須要自實現）帶來了很大的收益。

但須要注意，若是隻是單純接入服務網格，並不能帶來上述所說的收益。他的收益更多的是面向後續的一些高級治理等高級場景。

總結

• 服務網格不是微服務治理的銀彈：

  • 徹底無侵入支持全部空間和治理策略的 Mesh 方案是不存在的。
  • 大規模落地必定會涉及已有治理的兼容升級和改造。
• 服務網格確實實現了業務邏輯和服務治理架構的解耦。
• 服務網格的開始是最難的，落地服務網格會很是困難和艱辛。

QA

• 第一個：

  • 新產品能夠上服務網格，但要有一個現成成熟的服務網格，自研工做量是很是之大的。

• 第二個：

  • 和開源社區結合的問題，會不按期更新 envoy，istio 的版本。
  • 服務網格不能只看節省的成本，若是隻是說框架的治理，那是很是小的，最大的收益是把全部的流量都彙總到一塊兒後收益很是大。網格一開始會很是痛苦，須要把流量真正的攔截上去。
  • 邊車的定位是服務於服務之間的通信代理，與業務邏輯比較緊耦合是不適合放進去的。
  • 推廣的目標不是全站覆蓋，核心鏈路上到就能夠，由於有的應用對這類沒什麼訴求。

• 第三個：

  • 是否 SSL 看企業場景。

• 第四個：

  • bmesh 能夠從全局角度監控，現有的監控模式可能你會是本身有問題。

雲原生開發平臺在騰訊遊戲運營中的實踐

• 平臺的指望：提升研發效能，業務落地成長。
• 業務背景：營銷活動，上線活動不少是不報備的，所以伸縮性要求高，日活很容易上千萬。活動多（天天新增 50 個以上），數量量幅度大，服務質量要求高。
• 實際成效：這麼大的規模，如今只須要 3 個 專職運維，晚上 6 點就下班了。

本質需求

• 頻繁發佈：版本發佈更新。
• 動態伸縮：數據量大。
• 持續高可用：常常變動。

運維的任務

以往都是開發提交給運維的，問題是有極多個開發對接有限的運維。面臨的問題：

• 面臨的環境，部署的東西，都是否是固定的。
• 開發須要轉移知識給運維。
• 實際常常會出現意外狀況。
• 對部署的風險：運維本能排斥變化。

呈現的結果是運維忙於救火，開發提個需求，就只能排隊，線上總不穩定。

解決辦法

• 持續交付：

  • 控制產品發佈節奏，需求儘快上線，不積壓。

• 打造部署安全網：

  • 微服務、並行部署，完善的監控。

• 實現可重複性：

  • 控制環境和部署的構建，自動化， 保證輸入輸出的同樣的。

• 變化是必然的：

  • 以故障是常態去設計。

碎片的解決方案

要解決上述所提到的問題，基本目前在業界都有基本的解決方案，但其都是 「碎片化」 的，以下：

「碎片化」 指的是不一樣的組件都分別是解決特定的問題。這就致使了下述問題：

• 各方面的學習成本高。
• 系統自動化程度低。

• 有經驗開發人員有限：

  • 人員招聘成本高，限制發展規模。

• 無生命週期：

  • 總體的上線到下線沒有管理。

雲原生開發平臺的設計

真正的完整解決方案就是作一個 「雲原生開發平臺」，提供一整套的服務來支持軟件的開發和運維，實現各類雲原生軟件的訴求。

從設計角度上來說：

運維不暴露太多的基礎建設，只是開放角度去作。開發人員只須要關注應用程序，不須要關注底層的基礎設施。

不須要讓業務關注你用的是 k8s、envoy、gitlab 什麼基礎設施，不用去學習一些特定的知識體系。

資源評估中心化的運維

開發須要申請資源，運維須要評估，分配，再審覈執行。最快是小時級，是平臺的瓶頸。

解決方案是把資源分片，實現團隊自治，開發就可能承擔了部分運維以往的工做。

此時又會帶來因爲運維部分工做轉移到開發後的成本問題，這部分就須要由平臺來解決，提供下述全流程：

1. 智能的容量評估
2. 自動化提單/審批
3. 自動下線（經過日誌、性能、調用來識別）
4. 自治並釋放資源。

最終的成效是目前全部的審批都是業務團隊本身去作，運維只負責供應資源。

微服務下的依賴問題

思考：服務 A 流量上漲，依賴的服務如何擴容？

利用 istio 作全鏈路分析，實現全自動化，精準識別出入流量，計算差別部分，就能知道改變的服務鏈路和所需放大的倍數。

實現可重複性

應用跑不起來，確定是有東西改變了：

• 環境控制：鏡像。
• 構件控制：全自動化流水線，例如：代碼版本、編譯命令等。
• 運行時配置：提供配置管理，實現版本控制。

控制可運行時容器，就能夠作一系列工做。系統提供默認安全，應用也就安全。

變化是必然的

面向故障設計：

• 多可用區可用（異地多活？）.
• 主機故障自愈/剔除能力。
• 實例守護剔除能力。
• 配置恢復能力。

開發階段如何提高效率

作了個服務市場，業務應用。沉澱利用現有的能力。

總結

基礎設施，團隊自治，統一且自動化的交付。開發運維一體化，轉移到開發的成本，要用平臺來解決。

QA

• 第一個：

  • 故障定位，看基礎設施，如果軟件業務邏輯，軟件業務邏輯是經過平臺來提供工具來支持業務排查，幫助定位，大部分仍是靠業務團隊作的，如果基礎設施基本都是大面積的。

• 第二個

  • 版本一致性，必然存在，發佈有前後順序，能夠走藍綠，業務邏輯也要作一些兼容處理。

• 第三個

  • 去抖動下發的策略，會持續監聽 IP 並收集，配置下發有最小的間隔，例如十秒間隔的統一下發（存在必定延遲）。又或是到了必定數量級也會下發。不會來一發觸發一條。

• 第四個

  • 開發要對利用率關注，壓測，讓平臺上可以自動化去幫他實現，幫助他認識，自動生成出建議的數量和規模。同時服務的流量是分高峯，平峯的，平臺要有提供自動擴縮容的機制（例如：也能夠作定時策略）。支持自定義指標的擴縮容，要有一個超賣的策略。

• 第五個

  • 研發和運維的分界線，版本上線的告警目前都是由業務本身作的，代碼是業務本身寫的，暗含的邏輯運維必然不知道。開發要作全生命週期的跟蹤。
  • 統一網關不包含業務邏輯，更多的是支持公有云私有云，私有協議，一些登錄。業務網關更多的是跟業務相關的。

• 第六個

  • 長鏈接如何作無損發佈，超過 30s 後 ipvs 感知不到鏈接斷開，流量仍是會分過來。存在侷限性，要感知協議類型（內部作了針對性的自動化斷定），判斷流量是否結束，若結束則轉發到新的。四層仍是須要業務本身實現的。

網易數帆從微服務框架到服務網格架構平滑演進及最佳實踐

介紹微服務相關的理念和服務網格的演進，前半部分很是高關注率，聽衆大量拍照。

後半部分主要是網易輕舟的產品和技術介紹，主要是偏向 Java 方向，所以主要是在思想上進行參考，有必定的價值意義。

從 2017 年開始進行 ServieMesh 的研究，不斷進行打磨，直到 2020 年正式釋出網易輕舟這一個技術產品。

爲何要從微服務框架演進至服務網關

在 2012 年正式提出微服務，介紹了微服務的發展史：

• 1.0時代：2011-2017，以框架爲表明的微服務框架。
• 2.0時代：2017-至今，以服務網關爲表明，業務與治理解耦。

微服務框架存在的問題

1. 適用範圍。
2. 升級成本。
3. 侵入性。
4. 治理能力有限。
5. 框架負擔。
6. 架構演進與雲原生相沖突（註冊中心部分）。

服務網格的定義和優點

服務網格定義爲服務間通信的基礎設施層，經過輕量的網絡代理進行攔截和處理。堪稱異構語言的救星。

服務網格的技術升級改形成本

思考：我真的須要服務網格嗎？

1. 業務訴求是否只能用服務網格解決？
2. 業務現狀是否知足網格接入條件？
3. 業務團隊是否可以駕馭得了服務網格？
4. 是否有開發配套的基礎設施？

演進的成本問題

ROI 策略，作成本分析。

接入訴求

要關注業務指望收益是什麼？

微服務框架和服務網格共存

• 微服務框架：面向應用內的服務治理。
• 服務網格：面向服務間的服務治理。

微服務框架和服務網格二者存在重合的區域，但又沒法徹底替代：

網易輕舟的平滑演進主要是針對 Java 系，對此 JavaAgent 作了一些調整（以下業務遷移），以此來實現平滑演進。

業務遷移

微服務框架 =》 融合（過分）期 ：存在流量管理的能力衝突 =》 服務網格

逐步分離，緩慢實現技術升級。方案分爲：

• 經過 JavaAgent 遷移。
• 經過網關作灰度流量遷移。

服務網格與真實的使用場景差別

設計上比較理想化，很難直接拿來給業務直接用，業務真正使用都要作定製化改造：

爲了解決這些問題，網易輕舟作了如下加強：

• 通信協議加強支持（例如：Dubbo、Thrift）。
• sidecar 的管理問題：每次的升級問題，社區方案每次都要重啓 pod。網易輕舟是實現了熱升級。
• 多場景的限流方案：社區方案的性能常被人吐槽，而且場景支持不充足。
• 基於服務網格的能力拓展：例如：監控。

提供微服務框架和服務網格的一體化的控制檯，簡單來說就是經過平臺將用戶的業務改形成本和學習成本和運維成本大幅度下降了。

所以平臺化是解決服務網格 「成本」 的一個出路。

將來

• 中間件 Mesh
• 排障體系建設
• 故障演練體系

總結

認爲落地過程必定是曲折的，服務網格將來必定會是光明的。

細節會是魔鬼。

QA

• 第一個：

  • 微服務框架到服務網格的最大難點：解決服務發現的過分問題，如何把註冊中心打通。

• 第二個：

  • 2017 年開始關注投入，不斷打磨，到 2020 年纔出現網易輕舟。由於官方也不斷在演進，他們也在不斷演進。

• 第三個：

  • 中間件 Mesh，性能影響？目前主要仍是偏向監測，訪問成功，錯誤率，流量，使用的，偏向監控方面的設計。

• 第四個：

  • 如今遇到的業務訴求是否必定要用服務網格去解決？以及內部是否定同服務網格？

不破不立：企業級研發效能提高的創新實踐

會場全場站滿，講師頗有趣，經歷豐厚，是研發效能的出品人。其介紹了許多研發效能和度量相關的知識和理念。

同時駁斥瞭如今業界不少的一些基本的理念，讓人深思。

爲何研發效能火了

爲何之前研發效能都無法塞滿一個會場，爲何如今出現如此盛況？總的來說是時代變了，商業邏輯變了，你們對研發效能有了更大的理解：

靠信息不對稱，對稱後如何在研發這一側如何快速的交付，同時要高質量，既要又要。

研發效能的五大 「靈魂拷問」

歸納研發領域的現象，以下圖：

拉車的人（代指：老闆）沒空看輪子，不知道輪子是否是方的，而推輪子的人是咱們工程師。你知道不知道輪子是什麼形狀？

第一問：研發團隊的忙碌可以表明高效率嗎？

例如：凌晨半夜三點修 BUG 的人必定是最好的嗎？BUG 頗有多是他埋的，他不修誰修？

建議方向：

• 架構的長期規劃。
• 中臺的持續沉澱。

第二問：敏捷是研發效能提高的銀彈嗎？

敏捷指的是能更快速的嘗試，有問題的話立刻調頭。敏捷是要作小船。

第三問：自動化測試真的提高軟件質量了嗎？

若是卡死自動化測試的覆蓋率沒意義，最後會變成覆蓋率很高，走的很慢，由於讓覆蓋率變高有很是多種方法。

而卡死自動化測試，就會致使沒有精力去作探索性測試，更多的測試。需求變了，自動化測試又變了，又要花時間繼續作新的自動化測試。。

自動化測試只是個手段，不是目標。新功能不該該作自動化，功能自己趨向穩定了，才應該去作自動化測試，成本才低，成就感才高。

第四問：沒有度量就沒有改進，這是真的嗎？

研發效能很難在真正意義上度量，軟件研發是創造性的勞動，不一樣的人來作是不同的，硬要作，就會變成你度量什麼，工程師就作什麼。

你度量釘子，那你獲得的就是釘子。你度量什麼，就必定會獲得什麼。

不要用來考量 KPI，不然千行就會變成萬行，要慎重。

第五問：研發效能的提高必定是由技術驅動的嗎？

不要陷入局部思惟，真正的問題不是單點的問題。

例如：看醫生，真正掛號多久，但你真正花時間的是排隊，看完醫生1分鐘，又開單驗血，又等。所以等待時間是最大的。

在軟件領域中，也是在等待時常上花的時間最久的。是部門牆，信息不對稱致使的問題。

研發效能究竟是什麼？

先有的現象，再有的結果，定義。

研發效能提高的案例

• 前端代碼的自動化生成。

  • 工程師在白板上畫 UI，自動識別並生成出代碼和界面（利用了 AI 的相關技術）。

• 臨界參數下的 API 測試

  • 自動的測試數據生成。

• 微服務架構下的環境困局。

  • 公共基礎環境的問題，高效的方法是作公共基礎環境，也就是如今的雲端環境。天天和生產環境同步。

研發效能的第一性原理

順暢，高質量地持續交付有效價值的閉環。

• 作有價值的東西，作用戶須要的，不要作用戶不要的。
• 凡事作的事情能讓這五個 「持續」 提升，就算研發效能。
• 全部的過程改進要用數聽說話，但不要用來考覈。

「研發效能」 的點點滴滴

研發效能的點點滴滴，作這些都能提升，針對性舉例：

• 例如：雲 IDE，很是方便。
• 例如：（舉例 sonar）sonar 的機制爲時已晚，沒什麼意義。能夠在本地就去跑 linter，走得快質量還高。
• 例如：代碼複雜度，最終呈現的就是軟件和架構的腐化。研發工程師就開始複製粘貼改，最後沒幾年就廢了。
• 例如：代碼遞交規範，你會把需求id帶進去嗎？不帶的話，後面全部的度量都無法作，追蹤都無法作，拿不到需求 id 都沒作。
• 例如：分佈式編譯，各個模塊分散到分佈式去編譯，從十分鐘變 10 秒。

研發效能提高的一些經驗和實踐

推薦看書，用 MVP 思想作，和作通用工具徹底不同。

研發效能要先發現釘子，再去找錘子。和作通用工具不一樣，工具是拿錘子找釘子。

研發效能通常採用逐漸扎小孔，一層層作的模式。每次給的功能點足夠小，但每一次給的都有價值。

作 MVP 不是橫切一刀，是包含各方面的斜切。

這部份內容太太太多了，講師也沒有講完。下方爲根據講了的部分整理：

• 從痛點入手：

  • 測試數據的搭建統一到測試數據中臺去作。
  • 如研發度量的數據獲取是最重要得，例如由工具自動觸發狀態的改變，而不須要研發工程師去調整，且得到的數據是真實有效的。

• 從全局切入：

  • 例如：一個 BUG，真正修復的時間是多少？

• 用戶獲益：

  • 讓用戶獲益，是研發效能的核心
  • 不要你覺得業務團隊要，業務團隊關心的是溫飽問題。例如：你就看看業務團隊本身有沒有在搞，他們有在搞，這就說明是真的需求。
  • 結構很重要，若是設計的體制要每一個人都大公無私是必然失敗。每一個人越自私越自利越能成功。舉了和尚分粥的例子。
  • 誰接入了多少不是最重要的，是業務獲得了什麼。
  • 服務意識，早期保姆式服務，沉澱後，就是共贏，

• 持續改進

  • 例如：GitHook 直接調 JIRA API 不是最好的方案，沒有版本管理，規模大了絕對不是好方法。
  • 應該走消息隊列，揭藕。平臺化。

• 全局優化

  • 下層提出，上層承認。

• 杜絕掩耳盜鈴

  • 虛榮性指標 vs 可執行指標
  • 例如 sonar 接了多少個項目，就是虛榮性指標。應該考察可執行指標，例如嚴重 BUG 存在了多久。

• 吃本身的狗糧：

  • 本身的產品你都不用，別人更不可能。

研發效能的將來

表達核心觀點：「敏態」 和 「穩態」 必定是齊頭並進的。

快狗打車可持續交付實踐

主要面向測試環境治理的演講，Devops 不是單純的技術問題，總體來看 Devops 是一個複雜的混合問題。

理想與現實

快狗打車前期是存在固定的多套測試環境，測試環境相互影響。測試同窗 A 用完環境，次日給了測試同窗 B，B 同窗發現有問題，又找回 A。A 同窗又認爲不是本身的問題：

測試環境V1

早期測試環境的具體表現，主體爲穩定環境全量部署，下分四套環境，根據需求部署：

早期幾十個集羣還沒什麼問題，等到規模變大後幾千個集羣后問題就會很嚴重。同時測試人人都有管理權限，第二套變動後，會同步到穩定環境，那麼其餘幾套環境的同步由誰負責（他們早期是手動維護）。

另外並行需求多了就會發現固定的測試環境不夠用。呈現的結果是投入產出比差別過大，各配置互相影響，穩定性不好，最終形成的測試結果也不穩定。

理想的測試環境是怎麼樣的？

• 即點即用

  • 任什麼時候間均可以部署，並不須要排隊。

• 自動隔離

  • 任何環境都是相互隔離的。

• 依賴關係

  • 系統自動解析，根據配置自動部署依賴上下游，使用者無需關注。

• 縮放自如。

  • 資源池管理，資源彈性伸縮。

• 獨立閉環

  • 獨立部署，無需跨部門溝通（不用找運維要資源）。

第一輪的優化實踐

核心要點：規範、格式、自動。

針對各服務作依賴關係的自動解析。細則以下：

• 制定了配置文件的格式規範，用於掃描上下游依賴，層層掃描，最終得出總體的依賴圖。
• 規範要符合公司現狀，絕大部分都能適配，只有讓小部分的人要改。
• 服務按照類型優先級部署，這裏結合了應用信息（上層應用服務，底層應用、數據庫、Redis 等）。

測試環境 V2

只有一套穩定環境，剩餘的均可以按照需求來拉環境。但存在服務直連的狀況，致使出現流量攔截和調動有問題。

屬於企業內部自身的債務問題了，不展開贅述。

測試環境 V3

結合基礎架構組，最後實現按需部署，誰開發誰部署，不改動不部署。

屬於企業內部自身的歷史債務問題了，不展開贅述。

總結

在治理優化實踐上一共作了以下：

• 測試環境的服務按需部署。
• 依賴環境的自動解析。
• 部署資源池管理：評估部署所需資源，再經過資源管理平臺，統一資源的調度。
• 自動流轉與執行：Nginx（vhost、location）、域名（獨立域名、泛解析）、MQ、堡壘機等的自動申請、審覈。
• 資源自動回收：需求完成上線後，需求所關聯的都自動釋放，又或是回收到資源池。

總體上來說，技術不是難點，最難的是人與人的溝通，例如：跨部門的溝通，最重要的是方向、堅持、執行力。

QA

• 第一個：

  • 測試環境數據庫也沒有采用按需，由於測試環境數據庫不是主要痛點（矛盾點），主要權衡的是投入產出比，由於並非建起數據庫就能解決的，還要造數據，各類成本很高，結合權衡沒往這個方向作。

• 第二個：

  • 資源低於 60%，則針對於已經完成上線的機器，並非資源池內的。

• 第三個：

  • 部署的互相依賴和網狀結構，經過打標籤的方式，若已經部署了則不會再部署了。

• 第四個：

  • 資源平臺優化策略，目前正在轉向 K8S 這類雲平臺，後續再也不自行關注。

• 第五個：

  • 公共組件是否也是從新部署，目前 redis 是從新部的，主要是針對 mysql、redis。kafka 這類是沒有獨立部署的。

• 第六個：

  • 最大的困難是什麼，是 「人」，人的認知，達成全員的共識，爲何作這件事情，講清楚，比作什麼更重要。

自如雲原生落地最佳實踐

主要演講內容是自如的雲原生演進之路，以下：

當時存在大量的問題，進行了調研。結果提示低 NPS（-44%），也就是 100 個裏有 52 我的對 CI/CD 系統不滿意。

具體的痛點：

• 運維人肉運維。
• 生產、測試環境不同。
• 分支合併漏發代碼、漏發配置。
• 上線發佈一臺臺點。
• kvm CPU 使用率低。

進過調研和選型，發現開源的均有缺點，最終選擇自研一站式研發平臺。主體功能結構：

• 上層的平臺服務：面向開發同窗。
• 下層的 K8S 等：面向 Ops 同窗。

平臺在總體的設計邊界和原則上以下：

• 邊界：只作無狀態應用的容器化。
• 原則：能放到平臺的操做堅定不用人。

容器化後遇到的問題

容器化後一堆新的知識 pod、ingress、service，網絡模式也變了，開發同窗都不懂，產生了大量的成本（學習、運維等）。

所以就決定了作應用平臺，也就上面提到的平臺服務。流程圖以下：

CI/CD

• 定規範，統一環境。

• 定分支，統一分支模型。

  • 在各個 feature 分支上進行開發。
  • release 分支環境用於集成和發佈。

• Dcoker/Deployment 零配置

  • 根據建立應用所填寫的信息自動配置，研發不須要關心。

• 工具-跳板機

  • 在平臺上作跳板機，不須要關心 IP，也不用登錄。

總結

• 雲原平生臺化，運維 0 參與。公司標準化（環境、分支等）。
• 不要閉門造車，統一思想，走 MVP（步子不要邁的太大）、持續運營、持續關注 NPS。

QA

• 第一個

  • 流量染色，是爲了動態的的調控服務調用。

• 第二個

  • 數據庫污染，利用帳戶體系來作。同時注意 mq 這類須要隔離。

• 第三個

  • webshell 建立 bash 不要太多，超過 32 個會有問題。產生殭屍進程。

• 第四個

  • 微服務到雲原生的成本，學習成本必然，把 dev 和 ops 放到一塊兒。

• 第五個

  • 目前自如是讓業務在平臺上配一個專門的探活接口，再去探活。

• 第六個

  • 最大的阻力，就是人，CTO 把基礎架構把運維放到了一塊兒，造成了互補。組織結構要先調整。

研發效能度量的誤區、體系化實踐和效能提高案例

Devops 專題的出品人，會場火爆，所有站滿。開局表示如今已經再也不是討論要不要 Devops，而是討論怎麼去作。

講的很好，會場人員承認度高。

研發效能的狀況

• 你的研發效率在業界屬於什麼水平？與競爭對手差距？
• 敏捷轉 Devops 的轉型有沒有效果？是否能夠量化評估嗎？

軟件交付效能的度量指標

• 部署頻率。
• 變動前置時間。
• 服務恢復時間。
• 變動失敗率。

研發效能評估（願景）

阿里（211）

• 需求 2 周內交付。
• 變動 1 小時內完成發佈。
• 需求 1 周內開發完畢。

騰訊

• 項目團隊規模擴張控制在 20 人如下
• 迭代週期在 1 周內

研發效能度量的原則

• 結果指標 > 過程指標。
• 全局指標 > 局部指標。
• 定量指標 > 定性指標。
• 團隊指標 > 我的指標。
• 指導性，可牽引行動。
• 全面性，可互相制約。
• 動態性，按階段調整。

工具鏈網絡

• Devops 工具鏈網絡：強調 「網絡」，工具與工具的關聯，代碼與需求，代碼與合併，與編譯，各類信息能不能追溯到下面全部的環節（把工具串聯集成起來）。而不是單單管理某一個領域。

  • 項目協做域。
  • 開發域。
  • 測試域。

• 價值流的交付模型：要從用戶、客戶的視角去看，從端到端的角度去看，而不是開發、測試的角度。要從完整的一個用戶需求提上來每一步的具體步驟。

  • 工做流。
  • 生命週期。
  • 流動效率（不是資源的佔用率）。

• 效能度量分析模型：軟件研發效果，最終思考的是組織效能、業務結構。

  • 交付效率：需求前置時間、產研交付週期、需求吞吐量。
  • 交付質量：變動成功率、線上缺陷密度、故障恢復速度。
  • 交付能力：變動前置時間、部署頻率。

給出了分析模型裏的大量的度量考察指標，並表示企業內部有更多，幾百個。但要注意度量指標不在於多，在於精。不一樣階段也不同，要有北極星指標。

你作的實踐不必定表明有用，但要不斷地思考和實踐並改善。例如單元覆蓋率，有個公司永遠在 80%+，後面發現是對 KPI 戰法，甚至單元測試裏沒有斷言（多個講師提到）。

不只要關注創造價值的工做，還要關注保護價值的工做：

• 業務需求。
• 產品需求。
• 研發需求。

企業內部實踐

展現了京東內部的研發度量系統，看上去很是完善，能夠進行多層次的下鑽（事業部 -> 項目組 -> 研發人員）：

總結和避坑

• 成本問題：看板裏的數據，如何讓度量更準，那就是標準，那就須要大量培訓。讓需求和代碼有關聯，自動觸發變動狀態。自動化。
• 避免平均值陷阱：相似長尾問題，儘可能用分位數。
• 度量不是爲了控制，而是指導改進：若是是 KPI，你度量什麼就會獲得什麼，只是否是以你所但願的方式獲得的（古德哈特法則）。

總結：那些不懂數字的人是糟糕的，而那些只看數字的人是最最糟糕的。應該走下去看具體是什麼達成的，走到工做現場，看看是否真的有改進。

京東 BDP 的全域監控、管控平臺搭建實踐

基本介紹

基於 Prometheus 生態進行了大量的改造：

• 採集端改造：PushGateway 會推數據到 Kafka，再另外消費。

• 模塊拆解，做爲不一樣的角色，讀寫分離，便於擴展。

  • 數據採集。
  • 預計算。
  • 數據分析。
  • 監控告警，
• 多級緩存：監控數據的數據是短期內不會變的，會進行緩存（不一樣業務可配不一樣）。
• kongming 服務：基於不一樣的 promql 決定執行什麼策略，例如：實時做業、離線任務、集羣調度等。至關因而一個拓展了，高級監控治理了。

監控實踐

• 單點監控：常見面板，
• 組監控：業務提供黃金指標，自動生成對應的組監控，能夠作到千人前面。
• 關係鏈監控：父級節點和大表盤。

平臺實踐

平臺提供讓業務選擇，業務不須要關注底層的表達式：

在更具體的實踐上：

• 告警通知：支持父子節點的通知。
• 告警通知：支持告警人的動態通知，支持業務在上報指標時指定的。
• 高級治理：利用所拓展的 kongming 模塊，作了許多基於歷史數據和現狀的干預，例如：實時做業干預、智能調度（削峯、自愈等）。也就是至關於 「人工智能」 的那一塊相關內容了。

整體來說，作自動化也會是相似的思路，要拓展出一個模塊。這樣子你作什麼均可以，只要基於 Prometheus 的一些表達式和數據源就能夠了。

總結

監控系統不只要能發現，還要哪能解決問題，監只是手段，控纔是目標。

解決各類人力問題。

淘寶系 - 雲原生下編程方式的探索和實踐

淘寶現狀

• 中心化：微服務化。
• 去中心化：FatSDK，以 SDK 的方式提供能力。可以保障穩定性和性能。淘系絕大部分都是採起的第二種模式。出問題的話，就只有你本身的服務有問題，不會影響其餘依賴方。

在 SDK 上他們只提供 Java，其餘你本身想辦法，常見的能夠作個代理。

通用能力下沉

把原有 SDK 的能力剝離到獨立的進程，而不是像本來那樣沉澱在應用中：

利用雲原生的容器，提供運維能力容器，業務能力容器，解決中心化的問題。在此書實際上是參照了 ServiceMesh 的方式，走 Sidecar 就行了。

解決多語言問題

加多一層，提供 GRPC API 來進行對接。對於業務來說只須要面對標準化的 API 就能夠了：

業務不會直接對外對接暴露，全部東西都是經過對外/對內的中間層來進行銜接：

開發市場

作了一個應用市場，業務開發能夠提供組件能力上去，避免重複造輪子：

全面監控體系建設及智能監控的探索實踐

PPT 內容比較抽象，簡單來說：AIOps = 大數據+算法+運維場景。

經過各項能力，建設了對於歷史數據的分析，作了各類分析和告警合併等場景。每一個模塊都大體講了，但均沒有深刻講，只能大概聽個響，與原有所知的監控思路基本一致。

智能運維業界目前沒有開源方案，都是一線大廠分享的經驗。放一張 PPT 圖：

按分層自下往上看，基本是基於數據進行智能化的預示來達到效果。

低代碼技術在貝殼的實踐

更具體的演示效果可看平臺方發的視頻（指望/現狀）。

提效

能覆蓋到的場景基本把前端功效給去掉了，但同時後端的工做量會加大。

現狀

• 河圖1.0：已開源。定製化需求，一開始想讓客戶本身開發插件化，效果不行。最終決定走向智能化。

• 河圖2.0：智能化。

  • 指望：自動識別設計稿，國外有，支持多端。

  • 目前：

    • 貝殼如今支持的是上傳 sketch 設計稿，支持不一樣的 iOS，安卓，Flutter 以及本身的小程序。
    • 支持後臺管理增刪改查，小程序，中後臺等。

  • 將來：

    • 後期會引入智能化，將會持續開源。

投入的人力

• 第一期：最初是3我的，作了兩年，從 2019.1 作到 2020.12。
• 第二期：目前投了 10 我的。

複雜場景

• 第一類通用類：

  • 目前能夠解決。
  • 例如配置系統能夠用。

• 第二類定製化：

  • 要靠智能識別。
  • 目前的確只能解決一些通用常見的問題，複雜問題還須要人來解決。

總結

目前業界中其實存在着大量的方案和思路，不少大廠其實更多的會根據目前公司內的實際狀況進行選型和設計。聽這類會議/培訓，必定要關注的是其解決思路和途中的思考，是爲何這麼作，踩過什麼坑，比較重要。

但願你們在看完後都能有進入心流的深度思考時間，那樣你才能消化到知識，並轉換到你實際的工做中去。

個人公衆號

分享 Go 語言、微服務架構和奇怪的系統設計，歡迎你們關注個人公衆號和我進行交流和溝通。

最好的關係是互相成就，各位的點贊就是煎魚創做的最大動力，感謝支持。