本文作者：AIOps智能運維 作者簡介 運小堯 百度高級研發工程師 負責百度運維大數據存儲平臺的設計和研發，致力于追求大規模存儲系統的高性能和高可用。 萬億架構設計 在百度監控系統 TSDB 的常態工作負載下，單機每秒處理 20 多萬 數據點，集群每秒處理 數萬次 查詢，每天有 幾萬億 的數據點在 TSDB 中穿梭，這樣強悍的性能除了得益于 HBase 本身的性能優勢外， 架構層面 的針對性設計同樣功不可沒。 面對已是萬億級別卻仍持續增長的數據規模，我們設計了讀/寫分離且無狀態的 “彈性”架構 ；為了在高負載下仍保證低延遲的寫入和查詢，我們將數據進行 分層 ，分別存入 Redis、HBase 和 Hadoop；為了不間斷地為業務提供可靠的服務，我們設計了具備 分鐘級自愈能力 的 異地冗余 架構；為了節約存儲成本，我們引入并改進了 Facebook 的時序數據 壓縮算法 。 TSDB 的整體架構如圖 1 所示。 圖1 TSDB 整體架構 可擴展 我們希望通過簡單地 增加節點 就使系統的處理能力線性提升，如果節點之間完全對等、互不影響，那么對整個集群而言，增加節點沒有額外的資源消耗，就可以使處理能力隨著節點數 線性增長 。 根據時序數據 寫多讀少 的特點，我們將讀、寫操作分離，設計了無狀態的查詢模塊 Query-engine 和寫模塊 Saver，使得 Query-engine 或 Saver 的每個實例完全對等，并在上游應用輪詢或者一致性哈希進行 負載均衡 。 實例的部署是基于百度內部的容器方案 Matrix ，一則可以合理地分配資源，二則由于寫入和查詢隔離開來、互不干擾，其各自的性能均得到充分發揮?；?Matrix 的虛擬化方案也使 TSDB 能夠在分鐘級完成任意數量的實例擴容。 高性能 在 上一篇文章 中介紹的“水平分表”的策略(圖 2)中，存在 HBase 里的數據被按時間劃分到了不同的 Slice，老的 Slice 訪問壓力相對較小，減輕了系統處理這部分數據的負載，然而最新的一個 Slice 仍然會保持很高的熱度，相對集中的負載仍然給 HBase 集群帶來不小的壓力。因此，我們利用內存緩存了部分 熱點數據 (查詢量相對更多的數據)，以空間換取更低的查詢響應時間，同時 分流 HBase 的查詢壓力。 圖2 按時間水平分表 緩存能力由百度運維部 DBA 團隊的 BDRP 平臺提供。但由于數據量太大，緩存一小時的數據需要較多的內存資源，我們在性能和成本之間做了權衡，選擇只將 核心指標 數據寫入緩存。 在大批量查詢歷史數據的場景中，查詢的頻率不高，對數據時效性的要求也較低，其目標數據通常是 冷數據 ，因此我們把這部分數據從 Saver 的流量中復制出來，定期地灌入獨立的 Hadoop 集群，將此類查詢壓力從 HBase 分流出去。 經過 Hadoop 和 Redis 的查詢分流，HBase 仍然存儲全量的數據，但其只承接常規的趨勢圖查詢請求以及從緩存穿透的請求。 低成本 為了降低數據的 存儲成本 ，我們引入了 Facebook 在論文《Gorilla: A Fast, Scalable, In-Memory Time Series Database》中介紹的一種時序數據壓縮算法（見圖 3），它能夠達到 10 倍的壓縮比，我們將其進行改造后應用到了緩存中。 圖3 Facebook Gorilla 中的壓縮算法示意圖 Gorilla 中的壓縮算法較容易理解，其核心思想是 增量壓縮 ，不僅針對數據點取值進行壓縮，且對時間戳應用了一種 Delta-of-Delta 壓縮方法。經過壓縮的數據點，其存儲空間占用可以“bit”計，算法對于周期穩定、取值變化幅度較小的數據的壓縮效果尤其好。 然而，這種增量壓縮的算法中，后一個數據點的壓縮結果依賴前一個數據點的壓縮結果，這要求在集群中為每個時間序列維護壓縮的狀態，論文未對其分布式實現做詳細的介紹，我們將數據壓縮成 Byte 流 ，以 Key-Value 的方式存儲在 Redis 中。此外，論文中的算法僅支持浮點型數值，而我們改造后的算法還支持整數型和統計型數值（即上文提到的 StatisticsValue，每一個具有 max、min、sum、count 四個統計值）。 數據壓縮的整體方案在實際使用中為我們節省了 80% 的存儲空間，額外的 CPU 消耗不超過 10%。 高可用 冗余是高可用的一大法寶，我們使用了簡單有效的 異地互備 的方案，即冗余出一整套集群和數據來實現高可用。寫入時，客戶端將數據 雙寫 到兩個集群，查詢時通過動態路由表或百度名字服務（Baidu Naming Service, BNS）訪問到其中一個集群（圖 4），在此基礎上我們具備故障自愈機制，可以實現分鐘級的單機房故障自愈。 圖4 異地互備 總結 近年來，TSDB 在智慧城市、物聯網和車聯網等等領域都有著十分廣泛的應用，更是成為監控場景的標配基礎服務。在 《百度大規模時序數據存儲》 系列的四篇文章中，我們為讀者介紹了大規模 TSDB 從模型到功能再到架構的設計實踐，但從實際的需求出發，我們認為 TSDB 的架構設計思路和功能側重點并不局限于文中所述。 技術上，在大規模的時序數據存儲系統中，我們選擇了 HBase 作為底層存儲，但并不代表 HBase 在任何場景下都是最合適的選擇。在應用上，TSDB 也會與分布式計算、數據挖掘、異常檢測甚至 AI 技術進行深度結合，將會面臨更加復雜和富有挑戰的場景。 我們設想將 TSDB 抽象成各種 功能組件 ，能夠根據不同場景的特點，靈活地搭配各個功能組件，以滿足不同的需求。例如在數據量級較小的時候可以基于 MySQL 進行單機存儲；或者作為緩存層直接基于內存存儲；或者利用 Elasticsearch 的強大檢索能力做多維度聚合分析等等。 目前我們已經進行了一些 組件化 的工作，并在這些工作的基礎上實現了對 Cassandra 的支持，后續還將豐富框架和組件，引入新的功能，并逐步實現對 Elasticsearch、MySQL 等存儲系統的支持。 限于篇幅，系列文章并未在細節處展開探討，對于有興趣參與到 TSDB甚至是其它大規模分布式系統的研發同學，歡迎加入我們。 若您有任何疑問或想進一步了解 百度大規模時序數據存儲 問題，歡迎給我們留言！ 原文鏈接地址： https://developer.baidu.com/topic/show/290321

本文作者：AIOps智能運維 作者簡介 運小堯 百度高級研發工程師 負責百度運維大數據存儲平臺的設計和研發，致力于追求大規模存儲系統的高性能和高可用。 干貨概覽 閱讀了前面的文章，想必讀者對百度大規模 TSDB 的使用場景和技術選型有了基本的了解，本文將著重介紹在 TSDB 中起了重要作用的兩個 核心功能 的設計。 一 簡介 基本功能方面，我們的 TSDB 在數據的收集上提供了 HTTP、Thrift 等 API；對查詢，除了提供 API 之外還提供了命令行工具（CLI Tool），這些基本功能的設計在不同的 TSDB 中大同小異，因此本文不再贅述。 由于數據規模龐大且出于業務數據隔離和定期清理的需要，我們設計了 分庫分表 功能；為了提升歷史數據存儲和查詢效率，同時節省存儲成本，我們又設計了 多級降采樣 功能。這些針對性的功能設計為支撐萬億級數據寫入和高并發查詢打下了堅實基礎。 二 分庫分表 談及大規模數據庫的性能優化，分庫分表是一個繞不開的思路，設計得當可以大幅緩解數據庫的壓力和性能瓶頸，那么分庫分表能幫我們解決什么問題？如何解決？ 回顧前文提及的挑戰，我們的系統需要滿足業務數據需要隔離 保存策略 的個性化需求，在單表結構中實現這樣的需求相對復雜，維護成本也較高。通過“垂直分庫”，可以將不同業務的數據存儲在不同的數據庫中，每個數據庫可以應用不同的數據保存策略（圖 1）。 圖1 垂直分庫 另一方面，由于數據規模增長迅速，單表結構使得在 HBase 執行 Compaction 時會產生可觀的 I/O 負載 ，以至于拖累整個系統的性能。通過“水平分表”，按照某種規則將原本較大的數據表中的數據劃分到相同結構的較小的表中，如圖2，可以一定程度上減小 Compaction 時的 I/O 負載。 圖2 水平分表 1 基于HBase的“垂直分庫” 在監控系統中我們使用“Product”這個字段作為業務的 唯一標識 （“Product”相當于租戶），并為不同的“Product”建立邏輯上的“Database”，每一個“Database”包含一套 TSDB 所需的完整的表（包含前文提到的數據表和維度索引表），見圖 3。之所以從邏輯上建立數據庫的概念，是為了同具體的存儲實現解耦，以便在不同的底層存儲系統上都能夠實現這個機制。 在 HBase 0.9x 版本中尚沒有類似“Database”的概念，可以通過約定表的命名規則來實現，比如以前綴來標識不同的“Database”的數據表 ${Product}-data，在數據寫入 HBase 之前，根據“Product”字段拼接出對應的表名即可： 圖3 按產品線分庫 為不同分庫對應的數據表設置不同的 TTL，便實現了差異化的數據保存策略。 2 基于HBase的“水平分表” 根據監控時序數據按 時間順序 以 穩定頻率 產生的特點可以知道，相同長度的時間內產生的數據量是近似相等的，據此我們能夠輕易地將數據按照時間相對均勻地劃分到不同的 時間窗口 內。隨著時間的推移，舊的時間窗口內的數據表逐漸被“冷落”，不再承載寫入請求，只承載較低頻率的訪問請求，新的時間窗口內數據表將接力頂替（圖 4）。 圖4 按時間分表 分表只在某個“Database”內部進行，且只對數據表有效。每個分表是一個“Slice”，同分庫一樣，在 HBase 中按時間分表也可以通過約定表的 命名規則 來實現，我們以表內數據的起始時間 startTime 作為表名后綴 ${Product}-data-${startTime}，相鄰分表之間的 startTime 間隔固定的長度，比如 86400 秒（1 天）： Database1: Slice1: product1-data-1510000000 Slice2: product1-data-1510086400 ... Database2: Slice1: product2-data-1510000000 Slice2: product2-data-1510086400 ... “水平分表”帶來的另外一個好處是可以方便地實現 數據批量清除 （即 TTL 的功能），假如某個“Database”的數據保存一年，那么到期時可以根據 startTime 直接刪除其中一年以前的 Slice，干凈利落。 三 多級降采樣 業務對于監控數據的使用需求多種多樣，有查最新數據的異常告警，也有查看一整年指標數據的趨勢圖展示，數據量越大查詢耗時就越久，如果放在瀏覽器端處理也要耗費大量的內存。這不但對系統造成了很大的壓力，也給用戶帶來了難以忍受的查詢體驗。鑒于此，我們引入了多級的降采樣機制來應對 不同跨度 的數據查詢。 降采樣（Downsampling）在此是指對時序數據進行降頻，將原本較細粒度的數據降頻后得到較粗粒度的數據。這樣一來可以成倍減少數據規模，使得粗粒度的數據能夠以更小的成本保存更長時間。 降采樣后的數據點只保留原始數據的一些 統計特征 ，我們保留了四個統計特征，由四個統計特征取值共同構成一個統計值 StatisticsValue * max ：采樣周期內樣本值的最大值 * min ：采樣周期內樣本值的最小值 * sum ：采樣周期內樣本值的和值 * count ：采樣周期內樣本數 可見降采樣會造成 原始數據失真 ，而不同場景對數據失真的容忍程度不同，在查詢一年趨勢的場景下，數據只需要大致的趨勢正確即可；但在異常檢測等一些場景中，則需要細粒度的原始數據來提供更多的信息。 1 預降采樣（Pre-downsampling） 預降采樣是在數據寫入之前就按照預定的周期（Cycle）對其進行降采樣，采樣后的數據與原始數據同時保留。 在預降采樣時將采樣固定分為兩個 等級 ，包括 Level 1 降采樣和 Level 2 降采樣，每一級將上一級的數據按照更大的周期求出一個統計值（圖 5）。 圖5 兩級預降采樣 預降采樣與數據寫入并行進行，降采樣后的數據定期寫入對應表中，不同級別的采樣表使用不同粒度的分表策略，表的數據保存時長（TTL）隨著降采樣級別遞增，見圖 5（略去了分表的細節）（圖 6）。 圖6 原始數據表與不同級別的降采樣表 2 后降采樣（Post-downsampling） 后降采樣則是指在查詢數據時，實時地根據用戶指定的 查詢周期 （Period）對查詢結果數據進行降采樣，與預降采樣原理類似且更為靈活，可以按照任意周期進行降采樣，但后降采樣的結果不會被寫回存儲。 后降采樣通常與預降采樣配合使用，可以高效地完成一些原本困難的查詢任務。例如，在查詢一年的數據趨勢圖時，可以直接拉取 Level 2 降采樣的數據，使得查詢結果的數據量級降低數百倍，查詢的響應時間也成倍地減少。 總結 本篇為大家介紹了我們 TSDB 中兩個重要的功能：分庫分表和多級降采樣，這使我們從功能的設計上消除了在大規模場景下系統遇到的一些性能瓶頸。在下一篇文章中，我們將介紹 TSDB 在 架構層面 如何設計，以提升系統的性能和保障系統可用性。敬請期待~~ 若您有任何疑問或想進一步了解 百度大規模時序數據存儲 問題，歡迎給我們留言！ 原文鏈接地址： https://developer.baidu.com/topic/show/290320

本文作者：AIOps智能運維 作者簡介 運小堯 百度高級研發工程師 負責百度運維大數據存儲平臺的設計和研發，致力于追求大規模存儲系統的高性能和高可用。 干貨概覽 在 百度大規模時序數據存儲（一）| 監控場景的時序數據 文章中，我們簡要地介紹了百度監控場景時序數據的特點，且分析了在每天 萬億級 的數據規模下，時序數據的存儲所面臨著的諸多挑戰。本篇將介紹 TSDB 在 方案選型 和 存儲模型 設計上的實踐。 一 簡介 TSDB （Time Series Database，時間序列數據庫）是一種日趨流行的數據庫，從 DB-Engines 提供的最近一年各類數據庫流行趨勢來看，最近一年TSDB 的增長勢頭強勁，遠超其它類型的數據庫。 圖1 數據庫分類流行趨勢 二 底層存儲選型 為了更好地適應業務需求，我們選擇自研 TSDB，由于時序數據的規模很大，我們在底層存儲的選型上需要慎重考量。在 百萬級 指標的規模下，用 MySQL 來實現就可以滿足需求，如開源監控系統 Zabbix 的底層存儲方案。 隨著業務的快速發展，我們的數據規模也從百萬級漲到了千萬級以至于現在的 萬億級 ，此時傳統關系型數據庫愈顯乏力。我們嘗試過的一些集群方案在讀/寫延遲上并沒有顯著的提升，其擴展能力也只是差強人意，這迫使我們尋求新的方案。 重新審視我們對存儲系統的核心需求： 高吞吐、低延遲、可擴展 。對于監控場景來說，關系型數據庫的強一致模型、事務機制以及聯合查詢等強項并不是我們關注的重點，單個數據點的丟失并不影響監控指標的整體趨勢，數據的偶發延遲也可以接受。 近兩年開源的 TSDB 項目不斷涌現（見圖 2），許多優秀的項目也成為我們調研和學習的對象，我們發現這些項目在底層存儲的選型上各有偏好，這里列舉一些： OpenTSDB ：著名的老牌 TSDB，底層存儲最初只支持 HBase，后來增加了對 Cassandra 的支持 InfluxDB ：基于自研的 TSM 存儲引擎，集群方案未開源 KairosDB ：發源于 OpenTSDB，早期底層選用 HBase，目前主打使用 Cassandra，還支持H2（用于非生產環境） Prometheus ：Google 監控系統 Borgmon 的開源版本，基于 LevelDB和本地存儲 圖2 TSDB排名變化趨勢 然而無論是 HBase、Cassandra、LevelDB 還是 InfluxDB 的 TSM 存儲引擎，他們的一個重要共同點就是都基于 LSM-tree 實現（Log-Strutured Merge-tree，日志結構合并樹）。如圖 3 所示，LSM-tree 這種樹形結構可以像打印日志一般，以追加的方式順序寫入數據，并且不斷地將較小的數據塊合并成更大的塊，最終將數據批量地刷寫到磁盤。 圖3 LSM-tree 使用 LSM-tree 有什么實際的意義？在上一篇文章中我們提到，監控數據的寫入量非常大（每秒數千萬數據點），存儲時長最長可達數年，從成本角度考慮，廉價的磁盤自然是合適的選擇。然而，磁盤的機械結構使得其隨機 I/O 性能在面對每秒數千萬的寫入請求時顯得力不從心。LSM-tree正是能夠借助內存緩沖將大量的隨機寫入轉化成 批量的順序寫入 ，使得最終磁盤承載的寫入次數對數級減少，極大地 提升了寫入吞吐量 。 綜合來看， NoSQL 數據庫 是更合適的選擇。在諸多 NoSQL 數據庫中，我們選擇了基于 LSM 實現的 HBase ，主要出于如下考慮： 高吞吐、低延遲，滿足讀/寫性能需求 數據存儲在 HDFS，支持多副本冗余，滿足可靠性需求 表格存儲，模型簡單、業務開發較為方便 支持橫向擴展，可線性擴容，能夠適應業務增長 成熟的代碼、活躍的社區和廣泛的應用案例 三 基于HBase的存儲設計 HBase Table 中的數據按照 RowKey 的字典序排列，在行的方向上數據可以分布到多個 HRegion中，而 HRegion 可以分布在不同的節點上，因此只要能夠使數據均勻地分布在 HRegion 中，就可以實現存儲的負載均衡。 圖4 HRegion的分布 容易看出，RowKey 的設計是負載均衡的關鍵。如果 RowKey 設計不好，就容易形成熱點HRegion，導致其所在節點負載過重，進而集群的整體性能下降。 接下來重點介紹 TSDB 中最關鍵的兩張表的設計：數據表和維度索引表。前者支撐了所有時序數據的存儲和查詢，后者是多維度聚合查詢的基礎。 1 數據表 前文介紹過，監控時間序列構成如下： 時間序列 = 監控對象 + 標簽列表 + 監控項 + 數據點 為方便講解，換一種形式表述： ts = (object + tags) + metric + [(timestamp, value), (timestamp, value), ...] 可見，由 object + tags + metric + timestamp 可以唯一定位一個數據點的取值。為了充分利用HBase 的特性，我們借鑒了 OpenTSDB 的做法，將 RowKey 設計如下： RowKey = entity_id + metric_id + timebase entity_id 是由 object 和 tags 的經過 hash 得到的一個固定長度的值，hash 后原始字符串的自然順序被打亂，使得 RowKey 能夠相對均勻地分布在不同 HRegion 中。 metric_id 為 metric 的字符串 hash 值，同樣是固定長度。 timebase 為 Unix 時間戳按照 1 小時（3600 秒）取整得到的數值，固定 4 個字節的長度 這樣的設計有如下好處： entity_id 和 metric_id 的散列使得數據相對均勻分布 timebase 置于 RowKey 的字節低位，使得同一個時間序列數據的 RowKey 連續分布，可以高效地按時間進行范圍掃描 固定長度的 RowKey 減少了空間浪費，同時前綴式的設計可以充分利用 HBase 的前綴壓縮機制，進一步節省 RowKey 所占空間 RowKey 代表的行包含 1 小時的數據，行中數據點按照當前時間在 1 小時內的偏移量進行存儲，最終的表結構示意如表 1： 表1 數據表 RowKey 設計 2 維度索引表 在數據表的設計中，tags 被編碼進固定長度的 entity_id 中，同時 HBase 并沒有對索引的原生支持，這導致無法通過 tag 找到對應的 entity_id，也就無法滿足數據的多維度檢索聚合需求。為此我們引入了一張索引表，建立從 tag 到 entity_id 的映射，以支持通過 tag 篩選數據。 如圖 5 所示，通過指定一個 tag: k1=v1 ，可以查到所有包含這個 tag 的 entity_id1、entity_id2 和entity_id3。 圖5 維度索引 RowKey 的構造比較簡單： RowKey = key + value 索引對應的 entity_id 直接作為 Column 的 Qualifier 存儲，對應的 Column Value 留空，最終的表結構： 表2 索引表設計 總結 底層存儲選型和數據模型設計是 TSDB 設計中的兩個重要的基礎環節，前者決定了后者的設計思路，后者的設計影響上層功能的設計實現，二者又與集群的架構設計和性能表現息息相關。然而，影響系統性能和可用性的設計環節還有很多，接下來的文章將逐步為讀者介紹百度 TSDB 在 功能 和 架構 上的設計實踐。敬請期待~~ 若您有任何疑問或想進一步了解 百度大規模時序數據存儲 問題，歡迎給我們留言！ 原文鏈接地址： https://developer.baidu.com/topic/show/290319

本文作者：AIOps智能運維 作者簡介 運小堯 百度高級研發工程師 負責百度運維大數據存儲平臺的設計和研發，致力于追求大規模存儲系統的高性能和高可用。 干貨概覽 百度運維大數據平臺的 時序數據存儲系統 （Time Series Database，TSDB）是智能運維團隊于 2014 年自研的一套分布式監控數據存儲系統。發展至今，經歷過幾次大的架構更迭，現在 TSDB 作為百度監控系統的底層存儲服務，承載了公司諸多核心產品線的監控數據存儲和查詢需求，日均寫入數據點 數以萬億 計，承載 50K QPS 的查詢請求。百度大規模時序數據存儲系列文章將介紹 TSDB 在監控場景的應用和系統設計實踐，本文將介紹 TSDB 在監控場景下的應用以及系統設計面臨的技術挑戰。 一 監控時序數據 百度的監控時序數據來源于監控系統在全網數十萬臺服務器上部署的 Agent ，Agent 采集各類監控對象的監控項，并以不同的頻率向 TSDB 上報這些監控項的測量值。通過一張 CPU 空閑率趨勢圖可以直觀地看到監控時序數據。 圖1 CPU 空閑率趨勢圖 1 監控對象（Object） 監控對象可以分為三類： 機器級 ：物理機、虛擬機、操作系統等 實例級 ：容器、進程、日志等 服務級 （邏輯對象）：服務、服務組、集群等 圖2 監控對象 2 監控項（Metric） 監控對象的一些需要關注的 指標 ，如機器的 CPU 空閑率、內存使用率、網卡帶寬以及磁盤 I/O等，稱為監控項。除了這些通用的機器監控項以外，根據不同的需求還可以自定義監控項，比如數據服務的緩沖對列長度、查詢請求的平均響應時間等。 3 標簽（Tag） 標簽是一對 Key-Value ，標識了監控對象在某個 維度 （Key）的 特征 （Value），一個監控對象也可以從多個維度來標識，比如部署在多地域、多運營商的服務可以有地域和運營商兩個維度，根據不同的維度取值可以生成不同標簽，如 (“機房=杭州”, “運營商=電信”) 和 (“機房=北京”, “運營商=聯通”)。 4 時間序列（Time Series） 把監控對象的監控項測量值，按照時間的順序排列起來就構成了時間序列： 時間序列 = 監控對象 + 標簽列表 + 監控項 + 數據點 其中數據點由時間戳和取值構成，每個時間序列對應到趨勢圖上的一條曲線。 二 監控時序數據的特點 1 數據的使用場景 通過 Web 頁面、HTTP API 或命令行工具 ，用戶可以方便地從 TSDB 種獲取到自己關注的數據： 在日常運維工作中，運維工程師通過 Web 頁面人工查看趨勢圖、同環比報表和熱力圖等來了解系統的最新或歷史狀態 一些自動化的服務通過高頻、批量地查詢時序數據來進行數據分析，進一步地挖掘數據的價值，如異常檢測、匯聚計算、根因定位等 2 數據的讀寫特點 在時序數據的大多數使用場景中，我們更加關注最近一段時間的數據，而這些數據的產生卻是 7 *24 小時不間斷的，這就導致時間序列的讀請求與寫請求特征迥異且量級懸殊： 隨機寫 ：不同的時間序列按照不同頻率各自寫入數據點 順序讀 ：指定時間范圍讀取一段連續的數據點 寫多讀少 ：寫入請求量占比達九成以上 3 數據的多維度 前面提到，可以使用標簽來從多個維度標識一個監控對象，在獲取數據時，也可以通過標簽，將監控對象按維度進行篩選聚合。如，對于一個多地域、多運營商部署的服務，獲取其在某段時間內、不同地域相同運營商的總流量： 圖3 多維度聚合查詢 三 面臨的挑戰 1 高負載和高可用 在百度，有數千萬的監控對象，時間序列的總量近 10 億 。監控項的采集周期通常為 10s，在高時效性要求的場景下要求 5s 的采集周期，這意味著每一秒鐘都有數千萬個數據點要寫入 TSDB，每天產生的數據點規模達到 萬億量級 。與此同時，TSDB 每秒鐘還要處理 數萬次查詢 請求，由于查詢有一定的突發性，峰值的查詢流量可達到常態流量的數百倍，且根據業務的需求，絕大多數的請求都應該能在 500ms 返回結果給用戶。 在處理 7 * 24 小時持續高并發寫入的同時，還要應對高并發的查詢請求，負載不可謂不重，高吞吐和低延遲是對 TSDB 的基本要求。此外，打鐵還需自身硬，作為監控系統自身的基礎服務，其可用性必須有所保障，根據業務需求，我們制定的可用性目標至少是 99.99% 。 2 復雜的數據保存策略 前文提到監控時序數據的使用場景有很多，包括匯聚值報警、查看指標的歷史趨勢圖、實時的數據報表（天/周/季/年的同/環比）、趨勢異常檢測以及歷史數據離線分析等，這些場景分別有著獨特的查詢特點： 場景 時間范圍 查詢數據量 查詢頻率 時效性要求 匯聚值報警 最近數分鐘或數小時 小 高 高 異常檢測 實時報表 歷史趨勢圖 離線分析 多個時間區間 最近數小時或數天 自定義時間范圍 數天、數周或數月 小 大 小 大 高 高 低 低 高 低 低 低 可以看到，每種場景的查詢數據量、數據的分布以及對數據時效性的需求不盡相同，TSDB 需要在這些場景下都能夠高效地獲取數據。 3 不斷增長的業務規模 百度的產品線數量、業務規模在不斷地增加，相應地，監控系統的體量也隨著增長，TSDB 的規模也勢必增長，必然會面臨容量、成本和可用性的壓力。低成本地換取系統容量的增加和可用性的提升，是在系統設計時需要考慮的重點之一。 4 多樣化的數據保存需求 不同的業務對監控數據的保存時長有不同的要求，不同的場景對數據的粒度也有不同的要求，例如，想要知道某服務過去一天的總流量相比去年同期的變化，需要數據至少保存一年，但數據的粒度可以是天級；而對于最近一個小時的流量，希望能夠支持更細粒度的監控數據，以便能夠發現短暫的流量突變。 總結 本文主要介紹了 監控場景時序數據 的特點，以及我們在設計時序數據存儲時面臨的挑戰，對于百度在應對這些挑戰時的 設計實踐 ，敬請期待下期文章。 若您有任何疑問或想進一步了解 百度大規模時序數據存儲 問題，歡迎給我們留言！ 原文鏈接地址： https://developer.baidu.com/topic/show/290318

本文作者：AIOps智能運維 作者簡介 餓馬搖鈴 百度云高級研發工程師 負責百度云智能運維產品（Noah）數據采集和計算方向架構設計和研發工作，對分布式系統架構有一定實踐經驗。 干貨概覽 本文是我在實時數據計算系統的設計、開發、運維生涯的一部分經驗總結。主要介紹一些設計思路和常見問題的解決方案，不關注具體計算框架的使用。 本人主要致力于 監控系統數據計算 方向，主要業務場景有：監控數據的ETL、數據匯聚、分析、異常檢測等。由于監控系統對 時效性 有較高需求，所以我們的計算系統更偏向實時系統，根據業務場景的不同，延遲從數百毫秒到分鐘不等。下文提到的計算架構更多是指整個計算處理通路，主要以監控場景下的系統設計為例，相信與其他場景下的架構也有相通之處。 文章從以下幾個方面展開。 首先，在第1節，我們簡述不同數據規模和場景下，監控系統計算 架構的可選方案 。在公司、業務發展的不同階段，主要矛盾不同，能夠投入人力物力資源不同，需要選擇合適的架構方案。 實時計算系統的設計有一個 核心問題 ：如何同時滿足高時效性和數據準確性？在現實環境中，高時效性和準確性很難同時達到，第2節中介紹了Watermark機制以實現兩者的平衡。 第3節介紹百度監控系統的 實時計算系統架構 ，描述了其基本組成、思路和實現中一些常見問題的解決方案。 最后，簡單討論了實時計算系統 可用性建設 。 監控系統計算架構選型 對于包含數百到千級別節點的小集群，數據規模有限，所有采集、存儲、計算邏輯都可以集成在一個模塊中實現，這種多為 領域專用系統 。監控系統中，典型的有Prometheus，其采用單服務節點架構，提供簡單的HA模式進行容錯，這種架構的優點是 部署使用簡單 。受限于單機資源，適合部署自治的多個實例，每個實例監控不同服務。大規模集群情況下，要實現全局的監控，需要合并多個監控實例的數據，在配置分發、可用性、容錯、自動化部署管理等方面都需要更多的工作。從開發角度考慮，由于 功能耦合嚴重 ，不利于開發升級。 比起領域專用系統，還有一種架構是使用通用性更強的OLAP系統來實現實時或者近實時的計算功能，如TSDB、ElasticSearch等系統都有一定的聚合計算能力。這些分布式系統都有 水平擴展能力 和 容錯能力 ，但難以實現復雜業務計算，同時延遲不可控，復雜查詢或大批量數據查詢的延遲可能會達到分鐘級別。 更多的情況下我們采用 存儲計算分離 的方案，以便存儲和計算的各自演進和平臺化。通常由一個提供精細查詢能力的存儲服務與一個計算模塊組成。計算模塊根據計算規則從存儲系統中拉取數據并進行計算，這個架構的瓶頸在于存儲系統能夠支持的查詢規模。根據我們的經驗，基于精心設計的內存數據庫集群，能夠承受百萬級別的并發查詢。這種架構下計算任務多為 周期性調度 ，當查詢性能下降時會造成任務的堆積。這個模型不方便處理延遲數據，需要一定機制預測數據完整時間，調度任務進行重算，任務調度的復雜度高?；谒饕樵兊挠嬎阆到y的延遲取決于計算輪詢的周期，適用于聚合類的涉及時間窗口的運算操作。 在 更高數據量 和計算規則的情況下，流式計算是一個自然的選擇，降低了寫存儲、索引、查詢的消耗，計算延遲大幅降低。 當數據量進一步上升，需要的網絡吞吐、計算能力驟增，后端的算力難以跟上數據量的增長。這時候可以將計算能力 分散到全鏈路 ，將計算提前到數據產生端。在監控系統中，通過在采集端進行預計算和ETL操作，提取或整合有用信息，對于實時日志采集，能大幅度降低傳輸到后端的數據量。放到更大的視角上，這種將算力下放到數據源的思想，是目前大熱的邊緣計算的一個主要思路。 近年來，以AWS Lambda為首的Serverless計算架構得到了更多的重視。這個模型將計算抽象為事件以及觸發的 計算邏輯 ，計算邏輯實際由框架調度、分配資源執行。用戶只需要編寫計算邏輯，而不用關心可用性、可擴展、負載均衡等后端代碼，極大的降低了開發成本。通過 按需調度 ，自動擴縮容，業務運維方不再關心容量規劃等問題。私以為當前常見計算框架的Serverless化是一個值得嘗試的方向。目前的Serverless框架還存在很多問題，例如調度初始化虛機、容器的成本高，缺乏狀態存儲等，比較適用于無狀態的計算。 一般來說根據場景需求，通常對不同的架構會組合使用。例如百度監控系統內部是以流式計算與近線計算相結合的方式提供服務的，近線計算從時序數據庫（TSDB）中拉取數據進行計算。對于Trace、在線數據分析等具有比較復雜查詢需求但是相對比較低頻的操作，更適合基于索引查詢的架構。 準確性與時效性 對于實時系統，我們對時效性有更嚴格的需求，但是通常高時效性伴隨著 低準確度 ，二者不可兼得。在分布式環境下，天然存在長尾的延遲數據，這可能是原始數據自身的延遲，也可能是由采集點異常、網絡延遲、網絡抖動、數據通路中負載等造成的延遲。數據源越多，分散的越廣，這個長尾效應就會越嚴重，等待數據完整所需要的時間也越長。我們需要在最終數據的準確性和時效性間做折中。 不同場景對兩者的需求不一致，通常來說報警、自動止損等操作需要最高的時效性，能夠容忍一定的精度缺失，在審計、訂單等數據上我們更多的追求準確性，時效性可以適當放寬。解決這個折衷的常用機制是 Watermark 。 Watermark是在數據流中 增加標志信息 ，用以指示一個窗口內的數據已經“完全”到達，可以進行計算。 示例：假設我們要統計10s內到達的事件數目，以事件時間（Event Time，即事件攜帶的時間，多為事件產生時間）作為時間基準。如下圖所示，橫線為Wall Time時間線，單位為s。圓球表示事件，圓球里面的數字為事件時間，其虛線指向產生時間，圓球正對的Wall Time時間線上的點為被計算系統處理的時間（Process Time），兩個時間之間的差值為實際延遲。每個事件都或多或少存在延遲，其中數字為45的圓球延遲最大。對于事件時間[40, 50]這個匯聚窗口，假設我們將Watermark線畫在53處，則我們認為數據在53之前已經完全到達，已經接收到的那些數據可以參與匯聚，Watermark之后到來的事件則忽略。 具體怎么確定Watermark通常取決于需求，對于數據點數量級比較穩定的場景，可以設置一個到達的數據點的比例，在某一個判斷周期內，只要到達的數據點比例滿足閾值則可添加Watermark。主流開源計算框架對Watermark的實際定義不盡相同，具體使用參考對應計算框架的定義。 私以為Watermark機制隱含的一個重要思想是 將數據準確性的定義交還給用戶 ，讓用戶決定。產品或者架構上的功能，存在多種方案的情況下，選擇最泛化的那個方案，暴露出參數然后讓用戶來選擇，不要自己替用戶做決定。當然為了簡化實現成本和用戶使用成本，可以設置固定的一些選項，并選擇一個需求最大的作為默認值。 通常Watermark之后的過期數據點會被丟棄。經常的，除了滿足高時效性需求外，我們也需要在之后保證數據的最終準確性，即在一定時間段之后的數據是準確的。常用思路是部署兩套計算系統，流式計算用以實現低延遲但是準確性低的需求，批量計算用于補償計算數據的準確性，這就是Lambda架構。最典型的使用Lambda架構的場景是從日志中統計PV/UV，通常是一個流式采集系統和流式計算框架進行實時的PV/UV計算，同時有一套離線系統，定期拉取原始日志，通過批量計算系統統計準確的PV/UV數值。通常這種架構的缺點是兩套系統的資源消耗， 開發運維成本高 。 當前主流計算框架如Spark和Flink對流式和批量計算進行了統一抽象?？梢砸欢ǔ潭冉档蛢商紫到y的開發運維成本，降低了不同框架的開發運維成本，兩次計算的的資源消耗依舊存在。 對于滿足交換率和結合率的算子，如常見的統計方法(MAX/MIN/SUM/COUNT)，在存儲側支持相同運算的情況下，可以將兩次運算合并成一次。我們內部稱這個方案為多版本，即數據生產一部分就匯聚一部分，每次匯聚產生一個數據版本，由存儲在寫入時合并，或者在查詢時合并。本質上，這是將匯聚的功能遷移了一部分至存儲。 百度監控實時計算系統架構 百度監控系統的實時計算系統承擔了監控系統數據處理棧的主要計算功能，每天 處理數千億條 消息。本節在實際系統的基礎上，進行了一定的抽象，介紹一個較為通用的系統架構。 如圖所示，架構主要包含以下組件： 接入模塊： 包括數據拉取和數據接收，前者主動拉取數據，后者接收由上游模塊推送的數據。 分發模塊： 根據配置的計算規則，過濾訂閱的數據，并根據調度策略、集群狀態將規則對應的數據分配到一個或多個處理單元進行計算。 處理單元： 包括一個物理計算模塊和對應的輸入輸出消息隊列。物理計算模塊執行實際的業務計算邏輯，不同處理單元間可以是同構的也可以是異構的，根據不同的業務場景和用戶需求，可以使用不同的技術棧。 控制模塊： 接收用戶提交的計算規則和管理操作，分配調度資源，產生對其他模塊的控制信息。 數據推送模塊： 拉取計算結果，根據計算規則將數據分發到下游模塊。 每個物理計算模塊都對應一個輸入和輸出消息隊列，以將數據接入、據輸出與計算層隔離，增加一個新的第三方系統的交互不會影響計算功能。升級變更物理框架不會影響其他組件。 由于大數據處理框架，在其數據規模、節點數目達到一定規模時，其處理性能以及異?；謴退俣榷紩陆?。我們將一個固定計算能力以及配套的資源（如消息隊列）抽象為一個處理單元，每個處理單元處理一部分的數據，取決于計算功能的物理實現，這個處理單元可以對應一個集群或者一個作業。一個處理單元的具體規模取決于具體的 技術選型和硬件條件 。確認處理單元的好處是便于容量規劃，可以以一個處理單元作為粒度進行擴縮容。如果需要嫌粒度過大，分層次進行擴縮容，先在一個處理單元內部擴展直到極限，之后啟動一個新的處理單元。 實現中需要考慮以下幾個點： 1 負載均衡 負載均衡發生在系統的每一個層次。 數據接入層與和分發模塊之間的采用隨機發送的策略以 均衡分發模塊 的壓力 。 數據拉取和數據推送模塊需要動態平衡每個實例上的拉取或推送任務，常用的策略是一致性哈希，以每個任務的實際數據量作為權重。 計算過程是最需要考慮負載均衡的場景，聚合計算通常會遭遇數據傾斜問題，即某些key的數據量遠大于其他，這就造成匯聚該Key的任務OOM。下面提供幾種常用解決思路： 對于滿足交換率和結合率的計算方法，如MAX/MIN/SUM/COUNT等，可以添加多層預聚合，降低最終聚合的數據量。預聚合層次間可以隨機方式，最終匯聚之前按Key哈希。 負載均衡或者說任務調度對應Bin Packing等一系列等價的最優化問題。這些問題是NP-Hard的，可以通過近似算法來逼近，典型的有First Fit算法。實現時一般需要自定義計算框架的分區邏輯，如Spark可以通過自定義Partitioner來實現。 2 控制節點扇入扇出規模 無論是具備狀態副本的分布式存儲系統、基于DAG的分布式計算系統還是Stateless的接入集群，當集群規模持續增大時，節點間交互會顯著增大，最差的情況下全連接，擴容節點會有指數級的連接增長。這會嚴重影響系統對水平擴容能力，擴容帶來的收益跟不上單機資源消耗的增長。 對于分布式系統，通過 控制集群或者作業規模 可以實現一定程度的控制，對于接入模塊，可以限制下游連接到上限。 可用性 對于可用性要求高的服務可以多集群熱備的方式，在上述架構中，可以通過運行多個并行的處理單元處理相同的數據流來實現。也可以部署整個集群，通過采集端多寫的方式復制數據流。最后需要根據輸出結果的延遲、準確度等判斷策略選擇一個計算結果輸出。 服務無損升級 ，可以通過啟動一個新的計算單元，并行處理數據，待數據“預熱”后，進行切換。 在部署時，接入模塊盡可能的靠近數據源，保證每個地域一套。系統多地域部署，每個地域內部模塊間盡量自治。接入端發送數據時優先發送本地域，異常時嘗試其他地域。模塊間交互可以打 QoS （服務質量）標簽增加網絡優先級以降低網絡丟包。 監控上，除了基礎資源、流量等監控外，最重要的是 全通路時延監控 ，常見方案是構造業務流量，統計在系統中的延遲。這個延遲指標通常是多維度的，根據部署和業務使用情況可能需要關注不同地域，不同業務，不同處理通路的延遲。這些延遲指標，可以指示系統進行流量調度或者資源的重分配。 總 結 本文簡單介紹了百度的分布式監控計算系統架構的演進和當前的實時計算架構，并提供了部分常見問題點解決思路。架構是不斷在演進的，我們的系統僅僅是“夠用”，還有更多的工作需要開展，如架構的輕量化，統一易用的計算表示層，計算的自動優化等。 由于個人水平有限，如果行文中有錯誤，或者有需要進一步探討的，請在留言中指出。 原文鏈接地址： https://developer.baidu.com/topic/show/290317

本文作者：AIOps智能運維 作者簡介 運小軍 百度高級研發工程師 負責百度運維部大規模日志處理、海量事件數據存儲相關設計研發工作，在分布式系統架構、大數據存儲計算、高性能網絡服務和即時通訊服務有廣泛實踐經驗。 干貨概覽 本文主要介紹百度運維部監控架構團隊在處理 大規模日志計算任務 時，為保證任務分配均勻性和穩定性，對原始 一致性哈希 算法進行改進。新算法在保持原始一致性哈希算法穩定性的同時，通過設置 不均衡因子 來控制分配的不均勻范圍，達到負載分配均勻性與穩定性有效兼容。 一 業務場景 分布式系統中我們經常會面對如下業務場景： 計算系統每分鐘有大量的定時任務需要及時調度并按時完成，單機在處理能力和時效性上都無法滿足要求，需要將任務分配到大量Work節點上進行并行計算，我們如何均勻分配這些任務，并且在任務增減，Work節點退出/加入(伸縮能力)時保持任務分配的穩定性(不會引起大量任務遷移)。 分布式存儲系統，海量數據被分片存儲，那么如何讓每個Data節點上分片更加均勻，并且在Data節點退出/加入時保持數據分片的穩定性。 高并發Web系統中，架構上幾乎都是一個或多個反向代理服務器(如Nginx)來做七層負載均衡，后端使用應用服務器集群(如Tomcat)提供服務，這種架構具備水平伸縮能力，那么反向代理如何均勻分配請求，并且盡量保證請求Session粘性。 二 問題分析 上述問題可以抽象為對分配算法如下幾個方面的要求： 公平性 ：即算法的結果要盡可能地公平，不能造成分配不均問題，這點在分布式系統中尤其重要，公平性就是要盡可能避免由于負載過重/過輕導致系統出現慢節點/饑餓節點影響系統整體性能和資源利用率。 穩定性 ：分布式系統中，集群節點維護、故障、宕機、重啟、擴縮容是非常常見的，穩定性就是要保證計算任務、數據、請求在節點加入/退出時盡可能保持穩定，不引起大量計算任務重分配、數據遷移、請求轉移，這對系統整體可靠性、穩定性、高性能至關重要。 可行性 ：算法在工程實踐上一定是可行的，具體體現在這兩個方面：時間復雜度、空間復雜度，時間復雜度要求一定要快，滿足業務場景對響應時間的要求，空間復雜度要求占用資源少，滿足業務在資源投入和收益上的平衡。 三 常見算法 面對這些問題我們有很多常見處理方法，例如 輪詢(Round-Robin)、取模哈希、一致性哈希、按ID范圍分段、自定義分段策略 ，下面我們選擇幾種常見分配算法，分析它們在公平性，穩定性及可用性方面的能力： 從上面表格對比可知這幾種常見算法都無法兼具三種特性，那么有沒有一個算法，能同時具備公平性、穩定性以及可行性？接下來介紹的這個算法能在保持原始一致性哈希穩定性的同時還具備可控的均勻性，已經實際應用于我們的分布式近線計算系統中用于分配定時計算任務，目前來看效果還不錯。 四 有界負載一致性哈希 有界負載一致性哈希 (Bounded-Load Consistent Hash)算法是對原始一致性哈希算法的改進，相對于原始一致性哈希算法的不均勻問題，新算法能通過設置一個不均衡因子，來控制整個分配的不均衡范圍。 算法描述 1. 假設計算節點數為n，任務數為m，則每個計算節點的平均任務數t=?m/n?(取上界是為了保證t*n >= m，保證所有任務都能被分配執行)； 2. 設置不均衡因子c(取值范圍為1 < c < ∞)用于控制最大不均勻范圍，則每個節點分配的最大任務數為c*t； 3. 使用一致性哈希算法為任務尋找計算節點，當所選節點已有任務數大于tc時，順序尋找下一個已有任務數不大于tc的節點，直到找到并將任務分配給該節點； 4. 重復步驟3直到所有任務分配完成； 不均衡因子c越接近1整個分配越均衡(整個分配過程耗時會變長)，跟輪詢算法效果一樣了，c無窮大時跟原始一致性哈希效果一樣了。 實現 下面通過Java偽代碼對該算法進行實現： 1. public String getTargeNode (String key) { 2. // imbalanceFactor為不均衡因子，取值范圍為1 < imbalanceFactor < ∞ 3. // 單節點最大分配任務數 4. maxAssignedSize = ?(totalOfSlice / totalOfNode)?* imbalanceFactor; 5. // nodes中key是依據node名字產生的hash值，value是node的名字 6. SortedMap tail = nodes.tailMap(hash(key)); 7. long indexKey; 8. if (tail.isEmpty()) { 9. indexKey = nodes.firstKey(); 10. } else { 11. indexKey = tail.firstKey(); 12. } 13. String targetNode= nodes.get(indexKey); 14. //getTask獲取該節點已分配任務數 15. if (getTask(targetNode) > maxAssignedSize) { 16. // 該節點超過最大任務數，繼續順序尋找下一個節點. 17. do { 18. SortedMap tailMap = nodes.tailMap(indexKey, false ); 19. if (tailMap.isEmpty()) { 20. indexKey = nodes.firstKey(); 21. } else { 22. indexKey = tailMap.firstKey(); 23. } 24. targetNode = tailMap.get(indexKey); 25. } while (getTask(targetNode) > maxAssignedSize); 26. } 27. return targetNode; 28. } 因為maxAssignedSize*totalOfNode>=totalOfSlice，所以上面的算法不會導致死循環，每次分配必然有一個計算節點能接受這個任務；最終結果就是每個節點分配的任務數都不會超過maxAssignedSize，不均勻問題通過imbalanceFactor參數來控制；當計算節點退出時，其上面的任務遷移也只限于跟它相鄰的一個或多個節點，并不會導致大范圍重分配。 效果 下面通過對比近線計算分配算法分別選擇輪詢、一致性哈希、有界負載一致性哈希時的業務指標，從分配均衡性，計算節點加入/退出的穩定性兩個方面來衡量這三種算法的效果： 圖1 單個計算節點分配任務數(輪詢、一致性哈希、有界負載一致性哈希(c=1.1)) 圖2 節點加入/退出時遷移任務數(輪詢、一致性哈希、有界負載一致性哈希(c=1.1)) 很明顯可以看到，輪詢在任務分配上非常均勻，但是當計算節點變動時，導致大量任務重分配，而一致性哈希解決了任務大量重分配問題，但任務分配不均勻而且無法控制這種均勻性，而有界一致性哈希在 任務分配均勻性 和 重分配 都表現非常好，通過不均衡因子來限制不均勻范圍，本身一致性哈希又有效避免了大量任務重分配。 總結 分布式近線計算系統的任務分配算法在業務需求驅動下，經歷了從最初的均勻輪詢(防止分配不均導致慢節點)，到使用一致性哈希(防止任務因為計算節點加入/退出導致重分配，為了達到盡可能均勻優化虛擬節點個數)，再到有界負載一致性哈希通過參數控制解決原始一致性哈希 分布不均勻問題 ，每次分配算法改進都極大提高了 系統整體穩定性 ；有界負載一致性哈希算法具有通用性，可以有效解決任務分配，數據分片，請求分發等業務場景中分配均勻性與穩定性問題。 原文鏈接地址： https://developer.baidu.com/topic/show/290316

本文作者：AIOps智能運維 作者簡介 運小羴 百度云高級研發工程師 負責百度云Noah智能監控產品數據采集子系統相關研發工作，在分布式監控系統架構、服務器客戶端研發等方向有著較為廣泛的實踐經驗。 干貨概覽 在百度云Noah智能監控產品中，我們提供了多維度數據聚合計算、智能異常檢測、數據可視化、智能報警合并、逐級通告等豐富功能。今天，我們追根溯源，講講所有這些能力的基礎，數據的來源， 監控數據采集（入門篇） 。 不同業務場景下都有著不同的監控需求，比如服務器的運行時信息、服務進程信息、日志信息、網絡狀態信息以及服務狀態信息等。與之對應的，數據采集也需要提供豐富的采集方式來滿足這些需求，一般地，針對應用場景的不同，可分別通過 本地客戶端采集 和 遠程服務采集 的方式來實現。 圖1 監控平臺架構簡化圖 本地客戶端采集主要負責服務器自身的信息采集以及服務器上運行程序的信息采集，遠程服務采集則通過遠程發起探測的方式進行域名監控、網絡監控、死機探測等，本文也將從這幾個方面來闡述。當然，除此之外，還有更高級的數據采集方式，暫不在本文（入門篇）討論范疇內。 本地客戶端采集 本地客戶端采集提供 基礎的機器信息采集和用戶服務信息采集 。機器信息采集主要關注機器硬件信息、機器資源使用、機器負載情況等。服務信息采集則通過插件的形式提供服務，包括進程采集、日志采集、自定義腳本采集、自定義HTTP采集等。 圖2 本地客戶端架構圖 機器數據采集 服務器信息采集我們可提供數百個監控指標，其中大家常用的如CPU、內存、磁盤、網絡等指標，一般要提供高頻度的采集，比如Noah監控提供了 最細粒度5秒采集頻率 ， 采集延時小于1秒 的采集能力；對于系統內核等信息，由于不常變化，一般會使用小時級或天級的采集頻率。主要指標如下表： 服務數據采集 1 進程采集 服務進程信息采集，最簡單粗暴的指標莫過于采集 進程是否存活 ，另外，就要通過進程的資源消耗來一窺服務運行狀態。關于進程采集，我們提供了CPU使用、內存使用、FD使用信息、磁盤IO讀寫信息近30個監控指標，大多數信息都可以從/proc/${pid}/下的各個文件獲取并計算得到。 在采集客戶端設計研發的過程中，我們發現，很多場景下 FD 資源 會成為一個緊缺資源，因此，部署到所有機器的采集客戶端，對于機器資源占用都有著比較嚴格的要求，通常FD數量占用也不宜過高，避免影響機器其他服務的運行。因此，對于進程的FD使用監控顯得尤為重要，為了進一步了解服務使用的FD信息，我們還提供了塊設備FD數、字符設備FD數、管道FD數、網絡FD數、文件FD數、FD總數、FD上限的監控。 圖3 進程采集的數據 圖4 進程FD監控 2 日志采集 服務的運行狀況通?？梢酝ㄟ^ 打印日志方式來記錄 ，業務的指標也可以通過分析這些日志得到。比如服務流量指標、異常請求指標、響應時間指標等都是服務的重要業務指標，通過客戶端提供的日志采集插件可以統統滿足。對于基本的流量指標，我們可以用正則匹配等較簡單的方式來進行采集，當然還有很多復雜的需求，需要進行多維度數據分析或故障診斷的時候，就需要提供高級版的功能，通過提取日志中的具體字段構成數據的維度信息，從多維度的角度來計算、查看、分析這份數據。 簡單的多維度日志數據采集舉例 一個最典型的多維度日志數據采集的例子，就是通過提取日志中請求來源IP，來生成各地域、運營商等的流量信息。 通過提取日志中的IP字段，并進一步 反解該IP 所屬的省份、運營商信息，便于直觀的統計來源請求。當然，要支持海外流量的統計需求，還需要監控系統支持海外的IP國家歸屬信息查詢。 如下圖所示，我們可以將日志中各個字段的值進行提取，如關注的URI字段、IDC字段、IP字段等，進一步，還以可將某些字段進行二次解析，例如，將IP字段所屬的省份運營商進行解析。 圖5 日志維度提取 再進一步，我們將數據按照提取的維度進行 聚合 ，可以查看機房維度的流量信息，如下圖所示： 圖6 維度數據展示 3 自定義采集 為了應對某些定制化的場景，比如服務的指標并不在日志中體現，那么我們還提供了一些常見自定義采集插件來滿足業務需求。包括通過自定義腳本進行數據的采集，以及服務提供的HTTP接口進行數據采集。比如服務的某些信息不適合通過日志的方式采集，那么此時便可以通過自定義腳本或者HTTP接口的形式將該數據吐出來，通過配置自定義監控來采集這些數據便可以方便的查看這些數據以及后續的聚合計算以及報警配置。 一種簡單的自定義腳本輸出形式： 圖7 自定義腳本輸出 對應的監控輸出如下： 圖8 自定義腳本監控 遠程服務采集 服務監控 遠程探測的形式是從監控機向用戶機器發起探測請求，并校驗返回的結果，根據返回結果來判斷服務是否正常。根據請求內容的類型我們主要提供以下三種功能： 端口監控： 探測目標端口是否存活； 語義監控： 發送請求到目標機器，校驗返回的數據是否符合預期，支持各種文本類型的協議，如HTTP/HTTPS； 結構體監控： 對于二進制等文本形式難以描述的服務接口，則通過結構體監控來解決二進制內容的監控。 死機檢測 機器故障或者死機是線上的一個常見問題 ，死機檢測功能則可以幫助用戶及時 發現故障機器 ，進行服務的 遷移 或者 降級 來保障服務可用性。死機檢測往往很難通過單一手段來判斷，這里，我們通過分別檢測本地客戶端的 存活狀況 、 SSH 等常用端口來判斷機器是否故障以及故障的類型。 總結 本文主要介紹了百度云Noah智能監控中的數據采集（入門篇），數據采集需要針對不同的應用場景，通過不同的方式進行采集?；A的數據采集，可以通過部署本地客戶端和遠程服務采集兩種方式來完成。通用化的服務器信息、進程信息等，可以通過預置方式進行采集，無需用戶操心或干預；而針對不同業務的個性化情況，則提供靈活的插件形式進行采集，由用戶來靈活配置采集的形式，滿足定制化的需求。 原文鏈接地址： https://developer.baidu.com/topic/show/290315

基本介紹 經常遇到一些開發者問： 1.我們播放的時候，會有黑邊怎么處理？尤其是在類似于抖音，直播這樣的場景下，如果視頻有黑邊，很影響畫面的視覺效果。而阿里云播放器提供了縮放功能，用來去除黑邊，達到視頻全屏的效果。 2.直播時攝像頭采集經常會遇到反向的問題，就是采集出來的視頻畫面中的字是反的，對于這種情況怎么處理呢？阿里云播放器提供了鏡像的功能，可以水平和垂直鏡像，讓畫面變成你想要的樣子。 3.對一些橫屏拍攝的視頻同時我們提供了旋轉功能，可以選擇90、270度，旋轉之后就可以實現全屏渲染了。 渲染模式設置 Android接口 播放器提供了 setVideoScalingMode 方法提供去改變畫面的大小。它可以設置兩種方式： 1. VIDEO_SCALING_MODE_SCALE_TO_FIT 按照視頻的寬高比，放到SurfaceView（TextureView）中。不會剪裁視頻畫面，畫面的內容是完整的。比如我的SurfaceView是1920:1080的，然后播放一個1280x720的視頻，如果使用FIT模式，最終顯示的話，播放器把1280x720這個視頻按照原始比例放大，直到寬或者高跟SurfaceView的寬或者高一直，最終只有上下有黑邊或者左右有黑邊。 2. VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING 按照視頻的寬高比，將畫面鋪滿SurfaceView（TextureView）中。此時會剪裁視頻的畫面，可能兩邊有部分內容不會被顯示。crop方式肯定是沒有黑邊的。 播放器默認的縮放效果為：VIDEO_SCALING_MODE_SCALE_TO_FIT。 VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING 是以犧牲畫面的完整性為代價，從而實現了沒有黑邊。所以，當畫面的寬高比與實際的寬高比相差太大時，不太合適使用此配置。 我們來看具體的顯示效果，比如播放一個豎屏的視頻。 1.設置VIDEO_SCALING_MODE_SCALE_TO_FIT。即按照視頻的寬高比，放到SurfaceView（TextureView）中。 if (aliyunVodPlayer != null) { aliyunVodPlayer.setVideoScalingMode(IAliyunVodPlayer.VideoScalingMode.VIDEO_SCALING_MODE_SCALE_TO_FIT); } 可以看到，有明顯的黑邊，但是畫面會被完整的顯示出來。 2.設置VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING。即：按照視頻的寬高比，將畫面鋪滿SurfaceView（TextureView）中。 if (aliyunVodPlayer != null) { aliyunVodPlayer.setVideoScalingMode(IAliyunVodPlayer.VideoScalingMode.VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING); } 可以看到，黑邊沒有了，但是畫面的部分內容已經看不到了。 iOS接口 iOS提供了一個屬性來獲取和設置渲染模式 @property(nonatomic, readwrite) ScalingMode scalingMode; enum { scalingModeAspectFit = 0, scalingModeAspectFitWithCropping = 1, }; typedef NSInteger ScalingMode; 和Android類似，scalingModeAspectFit對應Android的VIDEO_SCALING_MODE_SCALE_TO_FIT，scalingModeAspectFitWithCropping對應Android的VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING，具體接口說明和效果和Android一樣，在這里不在贅述。 鏡像設置 iOS接口 iOS提供了如下接口來實現鏡像的設置，支持水平和垂直鏡像。 -(void) setRenderMirrorMode:(RenderMirrorMode)mirrorMode; enum { renderMirrorModeNone = 0, renderMirrorHorizonMode, renderMirrorVerticalMode, }; typedef NSInteger RenderMirrorMode; 水平鏡像 垂直鏡像 Android接口 public void setRenderMirrorMode(VideoMirrorMode mirrorMode); enum VideoMirrorMode { VIDEO_MIRROR_MODE_NONE(0), VIDEO_MIRROR_MODE_HORIZONTAL(1), VIDEO_MIRROR_MODE_VERTICAL(2); } 旋轉設置 iOS接口 iOS提供了如下接口來實現旋轉的設置，旋轉支持0、90、180、270度的旋轉。 -(void) setRenderRotate:(RenderRotate)rotate; enum { renderRotate0 = 0, renderRotate90 = 90, renderRotate180 = 180, renderRotate270 = 270, }; typedef NSInteger RenderRotate; Android接口 public void setRenderRotate(VideoRotate rotate); public static class VideoRotate { public static VideoRotate ROTATE_0 = new VideoRotate(0); public static VideoRotate ROTATE_90 = new VideoRotate(90); public static VideoRotate ROTATE_180 = new VideoRotate(180); public static VideoRotate ROTATE_270 = new VideoRotate(270); } 作者： 雋阜 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

本文作者：AIOps智能運維 作者簡介 小拳拳 百度云高級研發工程師 負責百度云智能運維Noah外網質量監測平臺的系統和策略研發，在網絡監控方向有廣泛實踐經驗。 干貨概覽 在此前介紹百度云智能運維Noah外網質量監測平臺文章《百度網絡監控實戰：獵鷹一戰成名（上）》中，我們簡要介紹了一種網絡異常類型—— 機房側異常 （百度側設備/鏈路異常）。該故障在數據上表現為多個省份訪問某個百度機房服務不通暢，因此在獵鷹（百度外網監控平臺）外網判障中，可以通過設置訪問某機房出現異常的省份比例超過給定閾值，來判定機房側異常的發生。 在外網故障統計中我們發現，運營商 骨干網鏈路 出現故障同樣會導致多個省份到特定機房訪問異常，在現有外網判障框架中，會將骨干網鏈路異常也判定為機房側異常。然而，機房側異常與骨干網鏈路異常無論是從起因還是數據表現上，都是存在一定差異的，兩者的止損方式也不相同。因此，我們需要設計 判障策略 來區分兩類異常，以便自動止損系統根據異常類型執行合適的外網止損方案。 在下文中，我們將為大家介紹骨干網鏈路及其異常表現，以及判障策略的設計思路。 什么是骨干網鏈路？ 骨干網是運營商用來連接多個地域或地區的高速網絡，因此骨干網的一個重要作用就是 承載跨地域傳輸的網絡數據 。若干條跨地域連接的骨干網鏈路，共同組成了完整的運營商骨干網。 圖1所示是用于連接南北地域的一條骨干網鏈路——第二京漢廣鏈路。各省份跨南北地域傳輸的網絡數據，首先會匯聚到該鏈路上北京、武漢、廣州等核心 城市節點 ，然后經由該鏈路傳輸至 目的位置 。 圖1 第二京漢廣鏈路 當構成這條骨干網鏈路的 網絡設備 ，如交換機、光纖等，出現擁塞、損毀等異常狀況時，流經鏈路故障位置的網絡數據會受到影響，通常表現為 丟包 甚至 數據斷連 。 骨干網異常對百度外網質量的影響 如圖2所示，外網監控系統獵鷹通過在各省份的探測點，實時監控百度各機房的網絡連通性狀態。 圖2 獵鷹外網監控圖示 在每個判定周期，每個省份都會上報若干條對百度各機房的探測數據。假設某省份對特定機房的探測，共上報了m條數據，其中n條數據為異常狀態，那么 異常率 n/m可以用于衡量省份到機房的外網質量。 骨干網鏈路發生異常時，會使得百度外網質量受損。具體表現為，用戶跨地域訪問百度機房時異常率升高，而用戶訪問同地域的百度機房服務時異常率不受影響。 圖3(a)(b)分別展示了某次南北骨干網鏈路異常發生時，全國各省份訪問百度南北兩地機房的異常率，其中，不同省份顏色對應的異常率如圖中左下角所示。 圖3(a) 南北鏈路異常發生時，全國訪問北京機房異常率 圖3(b) 南北鏈路異常發生時，全國訪問廣州機房異常率 從圖3(a)中可以看出，河南-山東線以南的省份，訪問百度北京機房普遍出現異常率升高，而以北的省份訪問北京機房異常率則較低。圖3(b)中各省份訪問廣州機房也出現了跨南北地域訪問異常、同地域訪問正常的情況。 骨干網異常與機房側異常的區別 圖4展示了機房側異常發生時的各省份網絡異常率。對比圖3和圖4可以看出，連接兩個地域的骨干網鏈路異常發生時，異常省份通常聚集于同一地域，并且各省份都會出現訪問跨地域的機房異常，訪問同地域的機房正常的現象。而機房側異常發生時，異常省份會分散于全國各地，沒有明顯的 分布規律 。這個差異是區分兩類異常的關鍵所在。 圖4 機房側異常發生時，全國訪問異常機房的異常率 由于兩類異常表現不同，因此對應的止損方案也存在差異。對于機房側異常，可以直接將異常機房的所有流量全部調度至正常機房。而對于骨干網鏈路異常，由于異常只在跨地域訪問時發生，因此需要處理所有 跨地域訪問流量 ，可以將所有跨地域的訪問流量調度至同地域正常機房。為了使自動止損系統能對骨干網異常執行合適的外網止損方案，為骨干網鏈路異常設計判障策略是有必要的。 另外，由于運營商的骨干網拓撲主要連接的是南北向各核心城市，骨干網異常也都發生在南北向骨干網鏈路上，因此后續的策略設計都將圍繞 南北骨干網鏈路 （下文簡稱南北鏈路）展開。 判障思路分析 根據南北鏈路異常的特點以及問題的性質，我們嘗試從以下兩個思路來考慮解決方案。 1 基于南北劃分線進行判定 南北鏈路異常最顯著的特點，就是跨地域訪問機房異常率高、同地域訪問異常率低，且高異常率與低異常率省份間存在明顯的南北劃分。根據這個特點，一個直觀的想法就是根據歷史數據總結出一條 南北劃分線 ；通過觀察劃分線兩側省份異常狀況，從而確定異常類型。 然而，通過觀察歷史上多次南北鏈路異常我們發現，劃分線沒有固定的位置。它是隨著骨干網鏈路異常的位置動態變化的，根據劃分界線位置的變化，異常省份也存在著差異。如下圖所示，(a)與(b)分別是異常鏈路存在于河北、河南境內時，用戶訪問百度北京機房的異常率展示。 圖5(a) 河北境內鏈路故障 圖5(b) 河南境內鏈路故障 從圖5(a)可以看出，當異常鏈路位于河北時，河北以南的省份，訪問北京機房異常率普遍較高，即劃分線位于河北-山東線附近。而圖5(b)異常鏈路位于河南時，劃分線緯度則下移至陜西-河南線以下，該線以南的省份異常率較高，異常省份個數也由于劃分線位置下移而少于(a)圖。 因此，找到一個合適的南北分界線，觀察分界線兩邊省份的異常狀態，來判定是否有南北鏈路異常發生，這個想法難以直接落地。 2 利用分類器模型進行判定 如概覽中所說，我們希望對已經判定為機房側異常的數據做二次處理，正確將機房側異常與南北鏈路異常區分開來。顯然，這是一個 二分類 問題，利用分類器模型解決也是一個思路。 如果在每個判定周期，都能獲得大陸31個省份到各機房的探測數據，那么可以通過積累歷史數據，訓練一個接受62維特征數據（南北兩地機房各自對應的31個省份異常狀態）的分類器，用于區分南北鏈路異常和機房側異常。 然而由于探測數據回傳延遲、回傳鏈路故障、單省份探測點少等原因，難以保證每個判定周期都能拿到31個省份到機房的完整探測數據，即特征數據大概率存在缺失值。另外南北鏈路故障發生次數較少，可用于訓練分類器的數據樣本不足，訓練出的模型極易過擬合。 根據對這兩個思路的分析，可以發現它們由于存在一些問題而難以直接應用。因此，我們綜合了這兩個思路中有用的部分，設計了骨干網判障策略。 骨干網異常判定策略 綜合考慮上述兩個方案，我們嘗試在判障策略中采用分類器模型，并人為設計特征來減少特征維度，減少模型過擬合的風險。 判障策略的具體步驟如下： 1 確定省份異常狀態真值 我們根據各省份異常率以及人為設定的閾值，判定該省份到機房的異常狀態，并且以此狀態作為省份異常狀態的真值。 2 尋找劃分線位置 在判定各省份到某機房的異常狀態后，對所有省份按照緯度進行排序，并將每個省份都作為可能的劃分位置進行遍歷，尋找使得“ 劃分誤差 ”最小的位置，作為劃分線位置。 每個可能劃分位置都會將省份集合分為劃分位置以南的集合與劃分位置以北的集合。根據南北鏈路異常的特點可知，若異常機房為南方機房，則應為正常省份的集合，而應為異常省份的集合。若異常機房為北方機房，則為相反情況。 對于每個省份，若由劃分得到的省份狀態與省份異常狀態真值不符，則認為該省份被劃分錯誤，劃分誤差可以通過劃分錯誤的省份數/總省份數得到。 如圖6示例，假設8個省份被劃分，且上半部分為正常省份集合，下半部分為異常省份集合。根據異常狀態真值，可計算得到劃分誤差為2/8=0.25。 圖6 劃分誤差計算示例 在遍歷所有可劃分位置后，即可得到最小劃分誤差及對應的劃分位置了。 3 特征提取 根據對歷史數據的觀察得知，南北鏈路異常對應的劃分誤差相對較小，且劃分線在地圖中部位置上下變化。而機房側異常劃分位置和誤差沒有規律可循。圖7展示了兩類異常數據的散點圖。 圖7(a) 線性劃分結果 圖7(b) 非線性劃分結果 從圖7(a)與(b)可以看出，僅使用兩維特征的情況下，無論是線性分類還是非線性分類，都很難將兩類異常數據較好地劃分開來。 為了提高分類效果，我們需要引入其他輔助分類的特征，具體如下： 機房位置、異常省份緯度中位數 兩者的相對位置關系在南北鏈路異常時具有明顯特征，因此這兩維數據的引入增強了南北鏈路異常的可識別性。例如，南北鏈路異常發生時，到南方機房異常的省份通常在緯度上遠大于機房所在的廣東省。取中位數為了消除極端點和噪聲帶來的影響。 劃分位置兩邊省份異常率均值 機房側異常發生時，異常省份的分布通常是較為均勻分布于全國各地，因此劃分線兩邊省份的異常率均值差距通常不會很大。因此這兩維特征有助于分類器識別機房側異常。 4 分類器訓練 為了區分兩類異常類型，我們將訓練一個 二分類器 ，訓練數據正例為南北鏈路異常按上述步驟提取到的特征，反例為對機房側異常提取的特征。在分類器的選取上，我們選擇了 支持向量機 （SVM）這一常用的分類器模型，并根據實驗回溯效果選擇了RBF核函數。 通過以上步驟，我們實現了骨干網鏈路異常的判定策略。自上線運行以來，取得了極佳的異常判定效果。 總 結 本文從外網異常監控遇到的實際問題出發，介紹了骨干網鏈路異常以及判定策略的設計思路。該策略有效地解決了骨干網異常與機房側異?；煜膯栴}，使得百度云智能運維產品Noah具備了骨干網鏈路異常的監測能力。 原文鏈接地址： https://developer.baidu.com/topic/show/290314

本文作者：AIOps智能運維 作者簡介 運小海 百度高級研發工程師 從事網絡監控、可用性建設相關工作，負責百度外網監控平臺 獵鷹 、百度內網監控平臺 NetRadar 等系統的研發和優化工作。在網絡采集、網絡異常檢測、系統可用性方面有廣泛的實踐經驗。 干貨概覽 我們在上一篇文章《 百度網絡監控實戰：獵鷹一戰成名 》（上）中，初步介紹了百度外網質量監控的典型場景與需求，本篇文章將從外網監控的實現原理及系統架構兩個方面系統詳細介紹百度外網質量監控平臺 獵鷹 。 一 外網監控實現原理 通過上一篇文章的需求調研，我們可以知道，業務線運維工程師希望外網監控平臺能夠真實反映用戶到百度IDC（Internet Data Center，互聯網數據中心，又稱機房）間的網絡質量，并能夠及時快速地發現機房側故障、骨干網故障以及單省份故障，這里面有幾個關鍵問題： 1 監控數據反映的是網絡質量 對于業務線運維工程師來說，他們關注的是外網質量，因此，需要通過一種探測手段來實時反映網絡質量。而探測協議有很多種，比如ICMP、TCP、HTTP，那么哪種協議更適合呢？我們選擇了TCP和HTTP來作為探測協議，原因有以下兩點： 首先，網絡設備在轉發請求時，是根據請求的源IP、源端口、目的IP、目的端口、網絡協議這五個信息決定請求的Next Hop所經過的鏈路或者設備。TCP和HTTP協議有請求端口，而ICMP協議只有源IP、目的IP以及網絡協議這三個信息。那么對于一個監測點和一個被監測目標來說，由于TCP和HTTP探測請求的源端口可以不斷的變化，因此TCP和HTTP探測方式能夠比ICMP探測方式夠覆蓋更多的鏈路。 其次，用戶訪問百度服務的請求大多數是基于TCP和HTTP方式的，因此，TCP和HTTP方式更接近于用戶的訪問方式。 在確定了探測方式之后，我們需要有探測指標來衡量網絡質量的好壞，為了更加真實反映用戶到百度服務之間的網絡質量，我們將網絡連接是否建立成功、連接建立的時延作為衡量網絡質量的指標。對于HTTP探測方式，我們不關心HTTP Code，只要連接建立成功，即使HTTP Code為500，我們也認為網絡正常。 2 監控數據反映用戶到百度IDC的網絡訪問質量 為了能夠真實反映用戶到百度IDC間的網絡質量，需要從用戶側向百度的的VIP（Virtual Internet Address，百度多臺服務器形成的一個虛機地址）發起探測。因此，我們在全國三大運營商各個省份部署了若干監測點，用于執行具體的探測任務。 3 能夠及時快速地發現網絡故障 為了盡可能快地發現網絡故障，我們設計了基于數據驅動的網絡故障檢測模型。已有的故障檢測模型大多是固定周期檢測模式，比如檢測周期是1min，那么檢測模型每兩次相鄰的檢測需要間隔1min，這種模式比較適用于流水數據、PV數據的檢測。但是對于網絡異常檢測的場景，實際上每兩次相鄰的檢測并不一定需要間隔1min，看下面這個例子： 假如Tn周期的檢測時間點是10:00:00，按照固定周期檢測模式，Tn+1周期的檢測時間點則是10:01:00，而實際很有可能在10:00:35的時候就已經收集夠了相對充足的探測樣本，足夠判斷出當前是否存在網絡異常，那么在10:00:35就可以進行故障檢測了，這樣能夠將故障發現時間提前25秒。 因此，在我們的基于數據驅動的網絡故障檢測模型中，我們對固定周期檢測模式進行了改進，加入了探測樣本數判斷，如果提前收集到了足夠的探測樣本，則提前進行故障檢測，盡可能地加快故障發現速度。 4 能夠準確區分網絡故障類型 當出現網絡故障時，業務線運維工程師需要知道網絡故障的類型，以便于采取對應的止損策略進行止損。我們針對機房側故障、骨干網故障、單省份故障的表現特點分別設計了三種故障發現策略。 圖1 外網監控原理示意圖 如上所述，我們通過在每個省份部署若干采集點，這些采集點周期性地向百度機房的VIP發起探測請求（HTTP請求和TCP請求），并將探測結果進行上報，然后對探測結果進行故障判定，得到實時的網絡質量和狀態（如圖1所示）。 二 系統架構 獵鷹 整體系統架構如圖2所示，主要包括采集服務、任務分發、數據分析與告警、元數據管理、存儲以及可視化展示等六部分。 圖2 獵鷹整體架構圖 1 元數據管理 元數據管理是整個系統最基礎的一部分，它負責不同的實體映射關系維護，主要包括VIP→機房歸屬關系、機房→VIP的映射列表以及VIP→域名歸屬關系。 在上一小節中提到， 獵鷹 部署在各個省份的采集點需要周期性地向百度機房的VIP發起探測請求，服務端接收到探測結果之后，需要把每個VIP的探測樣本在VIP所屬的機房維度進行匯聚計算，得到機房粒度的探測質量數據。因此，我們必須要維護VIP→機房歸屬關系以及機房→VIP的映射列表。 另外，在檢測出故障后，我們需要判斷出受損的業務線，因此需要維護VIP→域名歸屬關系，比如檢測出廣東機房出現故障，我們根據機房→VIP的映射列表得到所有受到影響的VIP，然后再根據VIP→域名歸屬關系分析出受影響的域名，從而得到受損的業務線列表。 2 任務分發 任務分發負責將采集任務分發到采集點，這里的采集任務主要指VIP探測列表，采集任務會指定探測目標（即VIP）、探測協議（HTTP or TCP）、探測周期、超時閾值等。 3 采集服務 采集服務在采集點上運行，負責執行具體的采集任務。采集任務包括HTTP探測任務和TCP探測任務兩種，在執行完探測之后，會將探測結果上報給上層的數據分析與告警服務，用于后續的數據處理與實時分析。探測結果包括兩個指標：失敗率和連接時延。 4 數據分析與告警 數據分析與告警是整個系統最核心的部分，包括數據收集、故障判定以及影響分析與告警。 數據收集用于接收采集服務上報的探測結果，并對探測結果進行一些清洗、去噪以及匯聚計算。 故障判定用于對清洗匯聚后的探測結果進行故障判定，通過三種故障發現策略來判斷當前是否存在某種網絡故障。 影響分析與告警用于進行故障通告和報警，當故障判定判斷存在網絡故障時，會通過元數據信息分析出受到此次故障影響的業務線，然后給這些業務的運維工程師發送報警。 4 存儲 存儲包括三部分：指標時序數據存儲、異常事件存儲以及元數據存儲。指標時序數據存儲主要存儲實時的探測指標（失敗率和連接時延），異常事件存儲主要存儲網絡故障事件，元數據存儲主要存儲基礎的數據歸屬映射關系。其中指標時序數據存儲和異常事件存儲使用的是百度通用的數據存儲平臺，元數據為內存存儲。 5 可視化 可視化視圖部分的展現非常重要，這個是對用戶最直接的呈現。 獵鷹 的可視化視圖主要包括三部分：全局網絡視圖、業務線網絡視圖、機房視圖。 全局網絡視圖用來展現實時的全局網絡狀況，圖3展示的是全局網絡視圖，包括故障公告、機房全局概覽和產品線概覽。故障公告展示的是最近一段內的網絡故障通告。機房全局概覽展示的是全百度所有機房的網絡狀況，如果有異常，會進行飄紅顯示。產品線概覽展示的是接入 獵鷹 的所有產品線的網絡狀況，如果該產品線受到網絡故障影響，則會飄紅顯示。 圖3 全局網絡視圖（示意圖） 業務線網絡視圖展示的是各個業務線的域名以及VIP的網絡質量視圖，各業務線運維工程師可以很直觀地觀察到自己所負責的域名和VIP的網絡訪問質量。圖4展示的是百度搜索產品線的域名網絡質量視圖，主要包括兩部分： 圖4 業務線網絡視圖 1 域名網絡連通性質量趨勢圖 展示的是某一段時間內全國所有省份訪問某個域名的連通性情況，按運營商維度分別展示。 2 域名分省網絡連通性視圖 以地圖的形態分運營商展示域名在每個省份的網絡連通性質量，地圖的每個省份的顏色會隨著網絡質量的好壞而變化，并且如果網絡質量持續異常，地圖上的省份會有紅圈閃動。每個省份鼠標懸浮停留會展示該省份的網絡連通性質量，包括探測異常率和響應時間兩個指標。 機房視圖展示的是全國各個省份到全百度各個機房的詳細外網質量數據。這個視圖包括兩部分： 1 機房網絡連通性趨勢圖 展示某個時間段內全國所有省份到某個機房的網絡連通性狀況。 2 可視化機房-省份連通性視圖 機房-省份連通性視圖以地圖的形態細致地展現了每個省份到每個機房的外網訪問質量，地圖的每個省份的顏色會隨著網絡質量的好壞而變化。同時，地圖上的省份可以和趨勢圖聯動，點擊地圖的某個省份，右邊趨勢圖展示的內容會變成選中的省份到該機房出的網絡連通性數據。 圖5 機房視圖 總結 獵鷹 已經多次幫助發現重大網絡故障，及時挽回了數千萬可能的PV Loss，在業務線日常運維工作中發揮著越來越重要的作用。接下來我們會繼續秉承著“科技改變世界、技術改變生活”的理念將 獵鷹 打造成更加智能化的網絡監控平臺，讓網絡問題無處遁形。 若您有任何疑問或想進一步了解 獵鷹 ，歡迎給我們留言！ 原文鏈接地址： https://developer.baidu.com/topic/show/290313

本文作者：AIOps智能運維 從事網絡監控、可用性建設相關工作，負責百度外網監控平臺 獵鷹 、百度內網監控平臺 NetRadar 等系統的研發和優化工作。在網絡采集、網絡異常檢測、系統可用性方面有廣泛的實踐經驗。 干貨概覽 百度外網質量監控平臺 獵鷹 實時監控百度的外網訪問質量，已實現分鐘級的外網故障發現和告警，保障每日數百次億次用戶請求的響應?！?百度網絡監控實戰：獵鷹一戰成名 》系列文章將詳細介紹百度面臨的典型外網監控場景、需求及百度實現外網監控的原理和百度外網質量監控平臺獵鷹的系統架構、核心功能。 背景介紹 百度服務器每天會收到數百億次來自用戶的請求，這些請求在到達百度服務器之前，需要在百度外的公共網絡上經過多層網絡設備（如運營商接入交換機等）和鏈路（如運營商骨干網鏈路、省網鏈路等）的轉發及傳輸。公共網絡中的設備或者鏈路故障，會導致部分用戶無法正常訪問百度的服務，影響用戶體驗。因此，需要對用戶到百度的外網連通性進行實時監控，在故障時引導用戶流量繞過故障設備／鏈路，從而提高用戶體驗。 獵鷹 作為百度外網質量監控平臺，對整個百度的外網訪問質量進行實時監測，實現了分鐘級的外網故障發現和告警，同時提供豐富的數據可視化展示，為百度服務的可用性保駕護航，成為百度運維工程師日常工作的必備利器之一。 接下來， AIOps智能運維 將分上、下兩篇對百度外網質量監控平臺 獵鷹 進行介紹，本篇主要介紹外網監控概述、外網故障場景以及相關需求。 一 外網監控概述 在之前的文章《 百度網絡監控實戰：NetRadar橫空出世（上） 》中，運小貝提到百度擁有數十萬臺服務器，這些服務器分布在不同地理位置的IDC中。當用戶訪問百度服務的時候，域名解析服務（DNS，Domain Name System）會給用戶返回一個VIP地址（Virtual IP Address, 百度多臺服務器形成的一個虛機地址），然后用戶的請求會被轉發到這個VIP地址上。用戶的請求在到達這個VIP地址之前，依次會經過用戶本地接入設備（比如ADSL）→用戶所在地域的網絡運營商接入設備→運營商骨干網鏈路→百度IDC所在地域的運營商接入設備→百度IDC的VIP，如圖1所示： 圖1 用戶訪問百度服務的請求示例 用戶請求在到達百度服務器之前，經過的任何一條鏈路或者設備出現故障，都有可能會導致用戶訪問百度服務的體驗受到影響（如延時變大或者訪問失?。?。如圖1所示，湖北電信訪問www.baidu.com時，默認會被DNS解析到南京機房電信入口的VIP地址。如果南京電信運營商接入設備故障，那么湖北電信用戶就無法正常訪問了。這時，我們可以將www.baidu.com的域名解析映射關系更改到北京機房電信入口的VIP地址上，則可恢復用戶的正常訪問。 因此，準確快速地發現這些外網故障，對于保證用戶訪問體驗的重要性不言而喻。 二 外網故障場景 我們將用戶請求在外部網絡途經的設備和鏈路按照它們所在的位置劃分為三級：用戶側鏈路及設備、骨干網鏈路及設備、百度側鏈路及設備，如圖2所示： 圖2 外網設備及鏈路位置劃分 用戶側的鏈路和設備主要負責一個省份的網絡通信。而骨干網主要負責若干相鄰省份的網絡通信，骨干網絡與省份的覆蓋關系由運營商確定。不同位置的鏈路/設備的故障會表現出不同的現象，具體如圖3所示： 圖3 外網故障場景舉例 外網故障場景如果用戶側設備/鏈路出現故障，即用戶所在省份的網絡設備/鏈路出現故障，則表現出的現象是該省份到百度機房入口的訪問不通暢。 如果骨干網設備/鏈路出現故障，則表現出的現象是多個省份到百度機房入口的訪問不通暢。 如果是百度側設備/鏈路故障，則表現出的是全國絕大部分省份到百度機房入口的訪問不通暢。 為了便于后文的描述，我們稱這三種故障為： 單省份故障（用戶側設備/鏈路故障） 骨干網故障（骨干網設備/鏈路故障） 機房側故障（百度側設備/鏈路故障） 三 需求調研 那么對于百度的運維工程師和網絡組工程師來說，日常工作中對外網監控系統有哪些通用需求呢？通過對運維工程師和網絡組工程師進行相關調研，整理需求如下： 1 真實反映用戶到百度IDC間的網絡訪問質量 對于運維工程師來說，他們真正關注的是會影響到用戶訪問體驗的網絡故障，因此，真實反映用戶到百度IDC間的網絡訪問質量是外網監控系統進行網絡質量監測的基礎。 2 覆蓋全國三大運營商的各個省份 百度服務每天會收到數百億次來自三大運營商各個省份的用戶請求，為了盡可能多地發現用戶端到百度IDC間的網絡問題，監測點應當盡量覆蓋三大運營商的各個省份。 3 準確快速地主動告警，確定故障類型及影響范圍 當出現網絡故障時，需要能夠快速檢測出故障并進行主動告警，而且需要確定故障類型（機房側故障 or 骨干網故障 or 單省份故障），以便于采取何種策略進行止損，并且需要確定故障影響范圍（即哪些業務線受到影響了），沒有受到影響的業務線的運維工程師不需要收到故障告警。同時，為了盡可能地縮短服務受網絡故障影響的時間，需要盡可能快地檢測出故障。 4 支持不同視角的可視化展示 運維工程師通常情況下只關注與其服務相關的網絡質量視圖，而網絡組工程師通常需要關注全局的網絡質量視圖，因此需要提供多種不同視角的網絡質量視圖，讓運維工程師和網絡組工程師都能夠快速地獲取到其關心的網絡質量視圖。 總結 本文從宏觀上介紹了百度外網質量監控的意義、外網故障場景分類以及百度運維工程師對外網監控系統的需求。在《百度網絡監控實戰：獵鷹一戰成名（下）》中，我們將詳細介紹外網監控的實現原理以及獵鷹的系統架構，請持續關注 AIOps智能運維 。 若您有其他問題或者想進一步了解 獵鷹 ，歡迎通過留言與我們交流！ 原文鏈接地址： https://developer.baidu.com/topic/show/290312

本文作者：AIOps智能運維 對于運維可視化，在前面的文章 《運維可視化 | 漫談內網監控可視化》 中詳細介紹了能將內網監控中的異常情況可視化的 事件流圖 。本文將從可視化角度繼續分析，百度內網監測系統（NetRadar）如何通過可視化手段展示在某個時刻內網中存在哪些異常，從而讓運維工程師直觀地知道內網的哪些部分受到了異常的影響。 機房連通性可視化 當運維工程師發現自己的系統出現異常，并通過事件流圖得知內網存在異常后，他需要進一步得知這些異常影響了內網的哪些部分，從而判斷內網的異常是否造成了自己系統的故障。在這種情況下，運維工程師希望能夠有一個視圖直觀地展示異常的影響范圍。具體來說影響范圍包括： 哪些機房之間的 連通性 有異常 哪些機房的 內部網絡 存在異常 連通性異常是否是 地域性 的 備注：一個區域包含多個機房，比如有華北區域包括4個機房，華東區域包括4個機房，華南區域包括3個機房。區域之間通常用跨區域的鏈路連接?？鐓^域鏈路出現故障時，會導致兩個區域中的機房互相不能連通。 可視化網絡狀態的方法包括兩種：圖（graph）和連通性矩陣。在圖中，每個節點代表一個 網絡實體 ，比如交換機、路由器、主機等，每條邊代表網絡實體之間的 鏈路 。在連通性矩陣中，網絡實體對應矩陣的 行和列 ，矩陣中的元素表示所在行和列對應的網絡實體之間的鏈路。根據上述的需求，我們可以看出工程師們主要關注機房之間的連通性情況。如果用圖的方式表達，就會形成一個 全連通圖 ，圖中大量的邊不利于工程師掌握網絡總體狀態。因此，我們決定使用連通性矩陣的可視化方法。 1 連通性矩陣 假設有a1, a2, a3, a4四個機房，可以用一個4行4列連通性矩陣來表示，其中機房ai對應矩陣中的第i行和第i列。矩陣中第i行第j列的元素描述的就是機房ai到機房aj的連通性狀態，如下圖： 圖1 連通性矩陣 我們不妨用bij來表示矩陣中位于第i行第j列的元素。圖中存在一個紅色的圓點，位于b32，以及一個灰色的三角形，位于b44。 b32的紅色的圓點代表機房a3到機房a2的鏈路出現了異常。在矩陣中，與b32對稱的元素b23代表的是機房a2到機房a3的鏈路狀態。b23和b32說的都是機房a2和機房a3之間的鏈路，只是方向不同，這正好可以表達內網監控系統的探測方向。為了探測網絡連通性，監控系統在服務器之間發送 探測包 。比如，服務器x給服務器y發送了一個探測包，y收到探測包后給x發送一個 響應包 。如果x收到了響應包，就認為x到y的鏈路沒有問題。反過來，y也可以給x發送探測包，x發送響應包。這說明內網監控系統的探測是存在方向性的。所以圖中b32有紅點，b23沒有點的意思就是：機房a3的服務器主動發送探測包探測機房a2中的服務器，存在大量丟失響應包或者延遲顯著增大的情況，連通性有異常；而機房a2的服務器主動發送探測包探測機房a3中的服務器，響應包基本都能正常到達。兩個探測方向結論不一致主要是由機房的網絡出口和入口設備不同，并且單一設備出故障導致。 b44的灰色三角形代表的是機房a4的機房內網絡存在異常。連通性矩陣的主對角線元素bii都代表機房內網絡的狀態。為了能夠與機房間網絡有更直觀的區分，我們選擇了三角形來表示。 最后，顏色代表了異常的程度，紅色代表異常程度比較嚴重，灰色代表異常程度比較輕微。所以圖1中a3到a2的機房間網絡存在比較嚴重的連通性異常，而a4的機房內網絡則存在比較輕微的連通性異常。 當連通性矩陣中存在多個異常點時，這些點可以形成 特定的模式 ，分別代表不同的網絡問題。下面，我們就來分析幾種常見的模式。 2 單機房出/入口鏈路問題 在連通性矩陣圖中，可能會出現整行紅色圓點。 圖2.1 單機房出口鏈路問題 圖2.1存在三個紅色的圓點，分別位于b31, b32, b34位置。這就是整行紅色圓點的情況。 每個點的含義如下：b31代表的是a3到a1的鏈路有異常，b32是a3到a2的鏈路有異常, b34 表示a3到a4鏈路有問題, 從這幾個鏈路問題來看，鏈路都是從a3出來的，所以a3的出口鏈路出現了故障。 當然有可能出現整列紅色圓點的情況，如下圖所示： 圖2.2 單機房入口鏈路問題 圖2.2的三個紅色圓點，分別在b13, b23, b43位置， 同理： b13表示a1到a3的鏈路有問題, b23說明a2到a3鏈路有故障, b43呈現a4到a3的鏈路問題，這一列的鏈路問題，說明a3的入口鏈路出現的異常。 是不是有整行，整列的紅點情況呢？ 圖2.3 單機房出入口鏈路問題 圖2.3包含了6個紅色圓點，是圖2.1與圖2.2的集合， 整行與整列的異常代表a3的出/入鏈路都出現異常。 3 單機房核心設備問題 圖2.1，圖2.2，圖2.3都看到b33這個點是沒有狀態的，那如果在b33的點的異常情況也加上有表示什么呢？看如下可視化方式： 圖3 單機房核心設備問題 圖3所示，除了圖2.2中的6個紅色圓點，還在b33中有個紅色的三角， b33位置的三角剛好在矩陣圖的主對角線上，代表a3機房內網絡出現故障。圖3的6個紅色圓點說明a3的出/入鏈路出現網絡異常，紅色三角說明a3單機房核心設備也出現故障。 4 區域鏈路問題 通常，網絡不是只在某一個區域，有可能同時有華北區域a1, a2, a3, a4四個機房，華東區域b1, b2, b3, b4四個機房，華南區域c1, c2, c3, c4四個機房，如下圖所示。 圖4.1 區域鏈路問題 圖4.1，我們可以看出機房分別用三個顏色來標識：紫色，藍色，綠色。這幾個顏色在右上角有說明分別代表華北區域，華東區域與華南區域。同時，圖中在藍色區塊的華東區域（b1, b2, b3, b4機房）兩個區塊有大批紅點出現，呈現兩個矩陣形狀的圓點，這說明華東區域的鏈路問題導致機房互相不能連通。那如果，我們想對區域進行篩選，只查看華北，華南的區域之間的情況呢？如下圖所示： 圖4.2 區域篩選鏈路問題 如圖4.2中只有一個紅色三角與紅色圓點，與圖4.1相比，這里篩選掉了圖4.1華東區域的所有異常， 我們從圖4.2中，能看到一個細節問題，鼠標移動到異常點的時候，出現“進入c3-a4機房詳情頁 ”tooltip信息，點擊這個異常點，可以進一步查看這倆機房間的異常事件與相關的指標趨勢。如果想要知道a4機房內的詳情情況，可以點擊這個異常點詳情查看，然后我們可以進一步觀察a4內部集群之間的網絡連通性， 集群的網絡連通性跟機房連通性矩陣的方式是一樣的，就不詳細展開了。 總 結 矩陣圖的最大優點在于， 尋找對應元素的交點 很方便，而且不會遺漏， 顯示對應元素的關系 也很清楚。所以是一種很好的方式來可視化機房連通性的異常狀況。從內網連通性矩陣圖來看，可視化能讓運維由繁化簡，關鍵是我們如何從業務角度出發，用可視化手段來表達運維數據，在智能運維場景中，我們結合業務，抽象出這些可視化組件，單獨看這些可視化組件沒那么神奇，如果我們把它們放在一起，就得到了運維通用的解決方案。后面我們還會持續發布可視化相關的文章，請持續關注百度的AIOps智能運維公眾號。 原文鏈接地址： https://developer.baidu.com/topic/show/290311

本文作者：AIOps智能運維 干貨概覽 運維可視化 ，核心是將所運維的服務、資源、設備的狀態和正在發生的事件通過可視化的手段呈現出來，指導運維人員或者產品研發人員做出正確的運維決策。某種程度上，運維與可視化相輔相成， 可視化程度越高，運維就越簡單，運維效率也就越高 。 在運維的工作范疇中， 實時監控 對故障的發現和診斷起到至關重要的作用。今天，我們以監控中的一個重點場景－內網監控，來介紹可視化起到的重要作用。內網指的是一個公司的內部網絡，包括 機房內部網絡和機房間的網絡 。 異常事件可視化 當運維工程師發現自己負責的系統出現故障時，檢查網絡連接是否有異常，是故障排查流程當中的標準步驟。在這個場景中，工程師需要知道自己的系統所在的機房以及所依賴的網絡通路是否存在故障，所以希望內網監控系統提供一個 網絡故障概覽 ，展示在給定的時間段中相關機房的異常事件。 最簡單的方式是將所有的網絡故障展示在表格當中。如上表所示，每一行代表一個故障事件，第一列表示故障關聯的機房，第二列是故障的起止時間，第三列是故障的嚴重程度。這種展現方式存在以下三個問題： 不能第一眼看出哪些故障嚴重，哪些故障輕微； 不能直觀感受到每個故障的持續時長； 很難知道在某一時刻哪幾個機房同時存在故障。 當時間段很長，篩選出的故障事件很多時，表格會變得很長，就更加不利于工程師了解網絡狀況了。 為解決以上問題，我們需要在 機房、時間、 程度 三個維度上都能直觀的展示故障事件。從時間跨度來想，有點事件流的感覺，似乎可以用事件流圖來展示。 圖1 事件流圖 如圖1所示，事件流圖用一條事件河流來表示事件。河流被橫向切分為若干條色帶， 每條色帶代表一個類別的事件 。色帶的高度（河流的寬度）代表在某個時刻，各類別包含事件的個數。事件越多，河流越寬，反之越窄。 這種事件流圖適合展示在一段時間內事件群體的統計變化，而我們需要能夠展示每個事件的個體信息。因此，我們對事件流圖作了幾個修改： 每個故障事件用一個矩形條表示，矩形條左右兩邊的位置對應事件的起止時間； 矩形條的顏色用來區分事件的嚴重程度，而不是事件的類別； 關聯到某一個機房的故障事件矩形條放在河流的同一個高度位置。如果事件在時間上能完全錯開，則將矩形條左右放置。如果事件在時間上有重疊，則拓寬機房所占河流的寬度，將矩形條上下放置。 圖2 異常事件流圖 圖2展示了我們的事件流圖方案。圖中展示了三個機房的異常，其中機房一有一個嚴重的異常事件（用紅色來標識），這個異常事件是一個時間跨度比較長的嚴重異常事件，機房二有4個輕度的異常事件（用黃色標識），這4個異常是時間跨度比較短的輕度異常事件，機房三有12個輕度的異常事件（用黃色標識），這12個異常事件中也有三個時間跨度比較長的時間。如果鼠標放置在異常事件矩形塊上，能查看哪個機房出現異常。通過這個圖，工程師可以很方便地看到每個機房的 每個故障事件的詳細信息 ，比表格的方式直觀得多。 總 結 事件流圖， 從機房、時間、異常程度三個維度都能直觀的展示故障事件，幫助工程師快速查看異常情況。其實，事件流圖還可以用于 展示變更事件 ，甚至可以將變更事件與異常事件組合，讓工程師能一眼查看異常事件可能是由哪些變更事件引起的。我們從智能運維場景中抽象出一些可視化組件，比如這里的事件流圖組件，再通過前端工程化工具把這些子元素串聯起來，構建出前端統一展現層框架， 后面我們會逐一介紹這些可視化組件與框架其他細節，請持續關注我們的AIOps智能運維公眾號！ 原文鏈接地址： https://developer.baidu.com/topic/show/290310

作者：Dan Meyer 譯者：羅廣明 審校：馬若飛 英文原文地址： https://www.sdxcentral.com/articles/news/kongs-kuma-service-mesh-climbs-the-kubernetes-wall/2019/09/ 轉載自： https://www.servicemesher.com/blog/kong-open-sources-kuma-the-universal-service-mesh/ 編者按 2019年9月10日，Kong正式宣布開源一款Service Mesh：Kuma。此消息一出，立即在云原生社區引起反響，各大媒體爭相報道。讓我們跟隨SDxCentral的總編輯，一起來看看Kong的CTO如何介紹Kuma這款Service Mesh產品以及對于SMI的看法。關于Kuma的具體功能介紹可以閱讀 官網博客 以及 Github 。 翻譯一下其Github關于Kuma功能特性的簡介如下，方便讀者了解： 通用的控制平面 : 易于使用，分布式，可以在任何平臺運行。 輕量的數據平面 : 基于Envoy，可處理任意類型流量。 自動化 : 在K8s平臺上部署無需任何代碼改動，也可在虛擬機上靈活部署。 多租戶 : 可在一個集群與同一個控制平面上部署多套服務網格。 網絡安全 : 自動mTLS加密。 流量分割 : 靈活的ACL規則。 流量追蹤 : 與Zipkin和Jaeger自動集成。 流量指標 : 與Prometheus/Splunk/ELK自動集成。 代理配置模版 : 方便進階(收費)用戶配置Envoy。 標簽選擇器 : 可應用不同地域的、特定于云的和面向團隊的策略。 平臺中立 : 支持K8s, 虛擬機和裸機。 強大的APIM Ingress : 與Kong網關集成。 簡介 Kong正在將其服務網格平臺Kuma打造成一個日益復雜的生態系統，在過去幾個月里，許多新加入者和選擇涌現出來。 該公司聲稱Kuma是“一個通用的服務網格”。Kong CTO和聯合創始人Marco Palladino解釋說，這意味著Kuma不同于市場上的大多數服務網格項目，它的設計初衷是在 Kubernetes 生態系統內部和外部都能工作，這包括虛擬機(VMs)、 容器 、legacy環境以及Kubernetes。 Kuma包括一個基于Envoy服務代理的通用控制平面。它結合了數據平面和進階的控制平面，允許用戶使用本地自定義資源定義(CRDs)或RESTful API設置權限、獲取指標和設置路由規則。Palladino解釋說，早期第一代的服務網格產品大多缺乏成熟的控制平面，需要大量的二次開發或手工定制。 他解釋說：“我們希望90%的 用例 都易于使用，并且能夠快速升級。對于另外10%用例的用戶，我們有一個允許用戶深入使用的策略，”他補充說，盡管Kuma的設計是為了方便使用，“但Kuma是為企業設計的，而不是業余愛好者?！? Kuma的特性包括 software-defined security ，它支持所有四層通信流的 mTLS 身份驗證；能夠實現追蹤(trace)和日志(log)記錄，從而更好地分析指標；提供流量控制能力，如斷路器和健康檢查，以增強四層路由。 Palladino說，Kuma保護底層網絡的能力提供了可靠性和更深層次的可觀察性，并且無需修改任何代碼。 Palladino說：“我們努力為Kuma構建一個非常平滑漸進的學習曲線。它的復雜度不會在早期壓垮開發人員，并且也不會阻止開發人員走得更遠。我們確實為高級用戶提供了一個策略來配置底層代理數據平面?！? Kuma還利用了Kong同名的 開源API網關 。該網關管理組織與部署現代 微服務 的各種方法之間的信息流。 Kuma加入服務網格競爭行列 Kuma加入了服務網格競爭行列，這個群體與日俱增，聲稱可以更容易地支持微服務的部署。 Palladino說：“每個人都告訴我們，他們想要使用服務網格，但實際上沒有一種服務網格易于使用，而且真正適用企業生產環境。許多企業專注于Kubernetes，但對他們來說，這成為了云原生探索之旅的終點。我們提供了一個產品，允許他們擁有一個可以更早實現并支持他們遷移的服務網格?！? 一個已經引起廣泛注意的服務網格平臺是 Istio 。它定位于網絡層，使用底層進行微服務開發和維護。這允許將管理運維與應用程序開發分離開來。 Palladino說，Istio幫助照亮了這片天空，但它仍然“非常復雜，有很多活躍的部件”。它在Kubernetes上運行得很好，但并不是所有人都在運行Kubernetes?！? 他說，這種關注還會影響Linkerd和Containous等其他服務網格的選擇，比如最近推出的 Maesh平臺 。 “Maesh、Linkerd和其它控制平面網格都高度關注Kubernetes，”Palladino解釋說?！爸挥挟斊髽I采用Kubernetes時，它們才會被采用。我們通過在這一過程的早期建立安全和可觀察性，實現了向Kubernetes的過渡?！? 還需要努力協調服務網格平臺之間的互操作性。其中之一由微軟牽頭，它在今年早些時候率先推出了服務網格接口 SMI 規范。它的目標是為開發人員提供運行在Kubernetes上的不同服務網格技術的互操作性。 Palladino將這種努力淡化為邊緣化服務網格功能。 “我們根本不相信SMI，”他說?！斑@是將接口標準化的另一種嘗試，讓它變得平庸而不優秀。它采用整個社區所有服務網格的公分母，從而降低了它們對最終用戶的價值。它界限很寬，但并不深入?！? Palladino認為Kuma才真正實現了可以在所有平臺進行互操作。 Kong以Mashape的名字成立于2009年。2015年，它將Kong平臺發布到 開源 社區，并于去年對旗下所有業務產品 正式啟用 了該平臺的名稱。該公司已通過5輪融資 籌集 了6,910萬美元資金，最近一次是在3月份的C輪融資，總額4,300萬美元。 編者后記 當Istio因其性能表現疲軟之際，會涌現一個又一個的新玩家，給市場帶來競爭與多樣性，這也是用戶喜聞樂見的。Kong涉足服務網格并不算太意外，我們可以了解到除了市面上的傳統云廠商打造的和開源的各項服務網格產品，Consul Service Mesh的出現也讓人眼前一亮。Consul Service Mesh與Kuma背后的廠商均有其成熟的開源產品做強力支撐：Consul的服務發現與注冊產品，Kong的網關產品。他們各自在開源社區擁有一片天下，此時推出服務網格產品自然會有一大批“擁躉”。 Kuma的性能較之Istio以及其它服務網格產品的優劣尚未可知，但是其平臺中立的思想還是值得借鑒。當前市場上，K8s并未完全普及，很多公司的產品都是部署在虛機甚至裸機上，如果此時又想嘗試下服務網格技術，Kuma的出現不失為一種驚喜。 ServiceMesher 社區是由一群擁有相同價值觀和理念的志愿者們共同發起，于 2018 年 4 月正式成立。 社區關注領域有：容器、微服務、Service Mesh、Serverless，擁抱開源和云原生，致力于推動 Service Mesh 在中國的蓬勃發展。 社區官網： https://www.servicemesher.com

最近這幾年不知道大家有沒有發現，就是傳統的PC不在是企業辦公時的唯一選擇了，有很多的企業開始慢慢的把傳統PC換成了更為小巧的 云終端 來進行上網辦公的，換成云終端后真的可以達到傳統PC一樣的使用效果的嗎，把傳統PC換成云終端后，有怎樣的不同體驗的。 首先桌面的運算不同，雖然說我們使用云終端登錄后系統界面和我們使用傳統PC時是一樣的，都是我們熟悉的Windows系統界面，但是在使用時我們會發現，登錄云終端后系統桌面所顯示的配置和云終端本身的配置并不是一樣的，桌面性能的強弱更多的是取決于服務器所分配該終端用戶所使用虛擬機資源的強弱。 第二數據的存儲不同，雖然說有些片子高一點的云終端本身有一定的硬盤容量具備存儲數據的功能，但是系統桌面所運行的數據并不是存儲在云終端本地的，所有的數據都是存儲云端服務器上，通過服務器進行統一的管理和運行，任何人訪問重要數據或者想通過云終端來拷貝數據都需要得到授權才可以。 第三外設的支持不同，毫無疑問對于U盤等存儲工具和打印機等常用的外設設備，云終端是完全可以支持的，但是對于一些其他的比較特殊或者不常用的外設設備如U盾等一些設備，由于桌面系統使用的是服務器上的虛擬機，所以對于這些外設設備，云終端的支持力度是沒有使用傳統PC時這么好用的。 第四故障的維護不同，那么傳統PC換成云終端后對于故障的維護又有什么不一樣的體驗的呢？換成云終端后因為使用的都是服務器上分配的虛擬機系統，所以一旦系統出現故障，只需要在服務器上就可以完成系統的維護，而硬件方面由于云終端本地不就行運算和存儲，當硬件出現故障后，直接換一個就可以，不用擔心因更換設備而擔心性能和數據這些問題的。 雖然一直都在說云終端的用戶體驗和傳統的PC基本無差別的，但是真正使用和對比之后會發現，他們兩者之間還是有不一樣的體驗的。 來源禹龍云

本文作者：AIOps智能運維 在之前的系列文章《百度網絡監控實戰：NetRadar橫空出世》中，我們介紹了百度內網質量監測平臺NetRadar的原理和架構，其中， 判障算法 是內網監測系統的重要一環，今天我們將詳細介紹在NetRadar中實際使用的一種判障算法——基于二項分布的網絡判障算法。 業務場景 我們的內網監測系統 NetRadar 實時對百度內網連通性進行探測并根據探測數據判斷是否存在網絡故障。以探測機房A到機房B的連通性為例，如下圖所示，首先從機房A和B中選擇n個服務器對 ，機房A中的服務器 去探測機房B中的服務器 ，每次探測有 成功/失敗 兩種結果。在每個探測周期內，我們會收到n個探測數據，其中m個數據探測成功，(n-m)個數據探測失敗。 理論上，在網絡狀態正常的情況下，m/n=100%。但實際中，由于服務器自身問題（發起探測的服務器負載過高、被探測的服務器重啟等）以及一些偶然因素，少量的探測失敗是不可避免的，所以需要設定一個判斷網絡是否故障的 閾值 。 閾值設定 在實際設定閾值的過程中，我們遇到兩個問題： 單服務器故障導致產生探測數據的噪聲 如前面所述，當服務器a探測服務器b時，如果服務器b自身故障（負載過高或者遇到機器重裝、重啟等）或遇到其他偶然因素，探測也可能失敗，但并不能說明此時存在網絡問題，這種情況我們稱為 數據噪聲 。 雖然單臺服務器故障的概率不高，但在大量服務器參與的網絡探測中，服務器故障產生數據噪聲幾乎是常態。 不同探測任務樣本數差距大，受噪聲影響，小樣本的探測任務更難進行準確判障 由于網絡結構的多樣性，不同探測任務的 樣本數 差距很大。例如在機房A到機房B的探測中，樣本數與機房內服務器數量相關，如果A機房內服務器數量少，則探測樣本也少。實際中，不同任務的樣本數變化范圍從幾十到幾千。 對樣本量大的探測任務，數據噪聲對判障結果影響不大，但 小樣本 的探測任務卻非常容易受噪聲影響。 例如某探測任務有100個樣本，某個周期收到60條成功數據，40條失敗數據，成功率只有60%，顯然，此刻的網絡存在故障。但如果另一個探測任務只有5個樣本，在某個周期收到3個成功樣本，2個失敗樣本，成功率同樣為60%，但我們很難判斷這2條數據是探測數據噪聲還是真的存在網絡問題，所以不能直接使用固定的閾值判斷網絡故障。 另外，如之前的文章《百度網絡監控實戰：NetRadar橫空出世》所述，NetRadar的探測任務數量很大，判障算法要求是 通用的 、 低開銷的 、 高魯棒性的 。因此，也不能針對具體的探測任務訓練專門的閾值，這樣會給系統的后期維護增加很大成本。 基于二項分布的網絡判障算法 在本文描述的網絡判障場景中，每個探測任務每周期收到相互獨立的n個成功/失敗樣本，其中在網絡正常的情況下每次探測以一定的概率p返回成功，這正符合概率統計中 二項分布 的定義。 1、二項分布 首先，簡單回顧一下概率統計中的二項分布。 二項分布是n個獨立的 伯努利試驗 中成功次數的 離散概率分布 ，其中每次試驗成功的概率為p。 如果隨機變量X服從二項分布，那么在n次試驗中，恰好得到m次成功的概率為： 其中， 累積分布函數 可以表示為： 2、二項分布在判障中的應用 回到我們的場景中，對于一個探測任務來說，在一個周期內收到n個樣本，其中m個成功樣本，同時，根據歷史數據可以確定在網絡正常的情況下，一次探測成功的概率為p（由于服務器本身的問題和其他客觀原因，在網絡正常的情況下也有可能得到探測失敗的樣本， p值就是描述在網絡正常的情況下探測成功的概率 ）。一個周期內的樣本相互獨立。很顯然探測樣本X服從 參數為n和p的二項分布 。 當一個周期內收到的n個樣本中包含m個成功樣本，如何判斷此時網絡是正常還是異常呢？我們實際上是 通過判斷m是否太小了來確定是否有網絡故障 。也就是，可以通過計算累積分布函數 判斷： 如果 過低（ ，其中 是我們預先設定的一個概率閾值），說明在正常的網絡狀態下，n個樣本中收到小于等于m個正常樣本的概率很低，可以判斷這時網絡是異常的。 然而當n很大時， 需要多次計算 ，在每個周期有上百萬數據需要計算的情況下，對CPU資源消耗很大。 不過根據 中心極限定理 ，我們知道： 二項分布當n足夠大時， 近似服從期望為0，方差為1的正態分布，即 標準正態分布 。 以此為依據，計算 Z-score ： 根據對歷史數據的標注和訓練可以得到z的閾值，使用閾值進行網絡判障。 3、實際效果 實際運行中的一組網絡正常和異常時成功率和Z-score分別如下圖所示，可以看到，如果在成功率上設置閾值，很難找到一個較好區分網絡正常和異常的閾值，但使用二項分布則可以很容易確定區分正常與異常的閾值。 算法的擴展和應用 ：本文介紹的基于二項分布的判障算法，應用場景并不僅限于網絡監控，實際上這個算法可以應用于所有的成功率檢測，只需針對固定場景確定參數p和閾值。 總結 本文從網絡監測中遇到的實際問題出發，介紹了基于二項分布的判障算法，在內網監測系統中有效地解決了不同探測任務樣本數差異大且可能存在數據噪聲等實際問題，尤其在小樣本的判障中表現優異。 若您想進一步了解內網監測問題，歡迎給我們留言！ 原文鏈接地址： https://developer.baidu.com/topic/show/290309

Author: xidianwangtao@gmail.com 摘要：Kubernetes的資源編排調度使用的是靜態調度，將Pod Request Resource與Node Allocatable Resource進行比較來決定Node是否有足夠資源容納該Pod。靜態調度帶來的問題是，集群資源很快被業務容器分配完，但是集群的整體負載非常低，各個節點的負載也不均衡。本文將介紹優化Kubernetes集群負載的多種技術方案。 Kubernetes為什么使用靜態調度 靜態調度，是指根據容器請求的資源進行裝箱調度，而不考慮節點的實際負載。靜態調度最大的優點就是調度簡單高效、集群資源管理方便，最大的缺點也很明顯，就是不管節點實際負載，極容易導致集群負載不高。 Kubernetes為什么會使用靜態調度呢？因為要做好通用的動態調度幾乎是不可能的，對，是通用的動態調度很難都滿足不同企業不同業務的訴求，結果可能適得其反。那是不是我們就沒必要去往動態調度做技術嘗試呢？未必！平臺根據托管的業務屬性，可以適當的通過scheduler extender的方式擴展Kubernetes Scheduler來做一定權重的動態調度決策。 集群資源構成 以cpu資源為例，一個大規模Kubernetes集群的資源組成結構大致如下： 由以下幾部分組成： 每個節點的預留資源，對應kubelet的system-reserved, kube-reserved, eviction-hard配置的資源之和，Kubernetes計算Node的Allocatable資源時會減去這部分預留資源。 目前我們集群的平均資源碎片大概在5%~10%左右，根據不同規格的CVM機型略有不同。這些資源碎片分散在集群中的各個節點，以1c1g, 2c2g, 3cxg為主，平臺提供用戶選擇的容器規格都很難match到這些碎片，經常存在這這種情況：要調度某個Pod時，發現某個節點上的cpu足夠，但是mem不足，或者相反。 剩下的就是可以被業務Pod真正分配使用的資源了，業務在選擇容器規格時帶有一定的主觀性和盲目性，導致業務容器的負載很低，這樣的業務占比一大就容易導致集群低負載的情況，但是集群按照Kubernetes靜態調度策略又無法再容納更多的業務容器了。如上圖中所示的，集群分配cpu水位線很高，但是實際cpu利用率不高的情況。 提升集群負載的方案 除了借助強大的容器監控數據做一定權重的動態調度決策之外，是否還有其他方案可以用于解決靜態調度帶來的集群低負載問題呢？下面我將給出一整套技術方案，從多個技術維度來嘗試提升Kubernetes集群負載。 Pod分配資源壓縮 前面提到，研發同學部署業務選擇容器資源規格時，帶有一定的盲目性，而且Kubernetes原生也不支持實時無感知的修改容器規格（雖然這可以通過Static VPA方案解決），導致業務容器負載低。為了解決這個問題，我們可以給Pod Request Resource做一定比例的壓縮（Pod Limit Resource不壓縮）。注意壓縮Pod Request Resource只發生在Pod創建或者重建的時候，比如業務做變更發布之時，對于正常運行中的Pod不能做這一動作，否則可能導致對應Workload Controller重建Pod（取決于Workload的UpdateStrategy）對業務帶來影響。 需要注意的是： 每個Workload負載變動規律不同，因此Pod分配資源壓縮比例也對應不一樣，需要支持每個Workload自定義配置，而且這是對用戶無感知的。這個壓縮比，我們設置到Workload的Annotation中，比如cpu資源壓縮對應Annotation stke.platform/cpu-requests-ratio ； 壓縮比，誰去設置？自研組件(Pod-Resource-Compress-Ratio-Reconciler)基于Workload的歷史監控數據，動態的/周期性去調整壓縮比。比如某Workload連續7d/1M的負載持續很低，那么可以把壓縮比設置的更大，以此讓集群剩余可分配資源更大，容納更多的業務容器。當然實際上壓縮比的調整策略并不會這么簡單，需要更多的監控數據來輔助。 Pod分配壓縮特性一定要是可以關閉的和恢復的，通過Workload Annotation stke.platform/enable-resource-compress: "n" 針對Workload級別disable，通過設置壓縮比為1進行壓縮恢復。 何時通過壓縮比去調整Pod Spec中的Request Resource？Kubernetes發展到現階段，直接改Kubernetes代碼是最愚蠢的方式，我們要充分利用Kubernetes的擴展方式。這里，我們通過kube-apiserver的 Mutating Admission Webhook 對Pod的Create事件進行攔截，自研webhook(pod-resource-compress-webhook)檢查Pod Annotations中是否enable了壓縮特性，并且配置了壓縮比，如果配置了，則根據壓縮比重新計算該Pod的Request Resource，Patch到APIServer。 Node資源超賣 Pod資源壓縮方案，是針對每個Workload級別的資源動態調整方案，優點是細化到每個Workload，能做到有的放矢，缺點是業務不做變更發布，就沒有效果，見效慢。 Node資源超賣方案是針對Node級別的資源動態調整方案，根據每個節點的真實歷史負載數據，進行不同比例的資源超賣。 每個節點的資源超賣比例，我們設置到Node的Annotation中，比如cpu超賣對應Annotation stke.platform/cpu-oversale-ratio 。 每個節點的超賣比例，誰去設置？自研組件（Node-Resource-Oversale-Ratio-Reconciler）基于節點歷史監控數據，動態的/周期性的去調整超賣比例。比如某個Node連續7d/1M持續低負載并且節點已分配資源水位線很高了，那么可以把超賣比例適當調高，以此使Node能容納更多的業務Pod。 Node超賣特性一定要是可以關閉和還原的，通過Node Annotation stke.platform/mutate: "false" 關閉Node超賣，Node在下一個心跳會完成資源復原。 何時通過壓縮比去調整Node Status中的Allocatable&Capacity Resource？同樣的，我們通過kube-apiserver的 Mutating Admission Webhook 對Node的Create和Status Update事件進行攔截，自研webhook(node-resource-oversale-webhook)檢查Node Annotations中是否enable了超賣并且配置了超賣比，如果配置了，則根據安超賣比重新計算該Node的Allocatable&Capacity Resource，Patch到APIServer。 Node資源超賣，表面上看起來很簡單，但實際上要考慮的細節還很多： Kubelet Register Node To ApiServer的詳細原理是什么，通過webhook直接Patch Node Status是否可行？ 當節點資源超賣后，Kubernetes對應的Cgroup動態調整機制是否能繼續正常工作？ Node status更新太頻繁，每次status update都會觸發webhook，大規模集群容易對apiserver造成性能問題，怎么解決？ 節點資源超賣對Kubelet Eviction的配置是否也有超配效果，還是仍然按照實際Node配置和負載進行evict? 如果對Evict有影響，又該如解決？ 超賣比例從大往小調低時，存在節點上 Sum (pods' request resource) > node's allocatable 情況出現，這里是否有風險，該如何處理？ 監控系統對Node的監控與Node Allocatable&Capacity Resource有關，超賣后，意味著監控系統對Node的監控不再正確，需要做一定程度的修正，如何讓監控系統也能動態的感知超賣比例進行數據和視圖的修正？ Node Allocatable和Capacity分別該如何超賣？超賣對節點預留資源的影響是如何的？ 這里涉及的Kubernetes技術細節比較多，我將在下一篇文章中詳細介紹。 優化AutoScale能力 提起Kubernetes的彈性伸縮，大家比較熟悉的是HPA和HNA，一個對Workload的Pod進行橫向伸縮，一個對集群中Node進行橫向伸縮。社區中還有一個VPA項目，用來對Pod的資源進行調整，但是需要重建Pod才能生效，VPA存在的意義就是要快速擴容，如果像HPA一樣，需要重建Pod啟動應用來擴容，其實已經失去了價值。 Kube-controller-manager內置的HPA-Controller存在以下問題： 性能問題：一個goroutine中循環遍歷集群中所有的HPA對象，針對每個HPA對象獲取對應的Pod監控數據、計算新Replicas，這對于大業務是比較耗時的。 核心配置不支持Workload自定義：HPA伸縮響應時間是每個業務都可能不一樣的，有些業務期望能5s進行響應，有些業務覺得60s就夠了。而內置HPA Controller在響應時間控制上只能配置全局的啟動參數 horizontal-pod-autoscaler-sync-period 。還有每個業務對負載的抖動容忍是不一樣的，在內置的HPA Controller中只能通過 horizontal-pod-autoscaler-tolerance 做全局配置，無法提供業務級的自定義。 Kubernetes目前對custom metrics的支持，只能注冊一個后端監控服務，如果集群中有些業務通過prometheus來expose應用自定義指標，也有一些業務通過Monitor來監控應用自定義指標，這個時候就做不到All in了，這在for自研上云的場景中，是一定存在的場景。 我們自研了HPAPlus-Controller組件： 每個HPA對象會啟動一個goroutine協程專門負責該HPA對象的管理和計算工作，各個協程并行執行，極大的優化了性能。HPAPlus-Controller獨立部署，其資源需求可以是集群規模和HPA數量進行合理調整，相比于原內置HPA-Controller有更大的靈活性。 HPAPlus-Controller支持各個HPA對象自定義伸縮響應時間，支持自動感應業務是否在變更發布并決定是否要禁用HPA（某些業務有這樣的需求：升級時禁止觸發彈性伸縮），支持基于pod resource limit為基數進行Pod資源利用率計算，從而推導出擴縮容后的期望replicas，這一點對于節點超賣和Pod資源壓縮后的集群非常重要。 支持業務級別對負載的抖動容忍度的個性化配置。 支持基于更多維度的監控數據進行Scale決策，比如Pod歷史7d/1M的cpu負載。 支持CronHPA，滿足規律性擴縮容的業務訴求。 通過Extension APIServer的方式對接公司Monitor監控，保留Prometheus-Adaptor的方式來支持基于Prometheus的應用監控，滿足基于多種應用監控系統的custom metrics進行HPA。 注意：HPAPlus-Controller與Kubernetes buit-in HPA-Controller存在功能沖突，上線前需要disable kube-controller-manager的HPA-Controller控制器。 除了HPA的優化和增強之外，我們也在進行 Dynamic VPA 技術研發，后續再單獨文章介紹。 其他技術方案 另外，通過scheduler extender的方式開發動態調度器、基于業務級的配額動態管理組件、基于業務優先級和配額管理的在線離線業務混部能力、主動探測節點資源碎片信息并上報到控制器進行Pod的再漂移進行資源碎片管理等方案，也是我們正在進行實踐的方向，對應方案及實現復雜度更高，后續再單獨文章介紹。 總結 本文介紹了Kubernetes靜態調度帶來的集群資源分配水位線高但集群實際負載低的問題進行了技術方案上的探討，詳細介紹了Pod資源動態壓縮、節點資源動態超賣、優化AutoScale的能力的技術方案，后面會再對動態調度、動態業務配額管理、在線離線業務混部方案進行介紹。所有這些集群負載提升方案，要做到動態，都強依賴于強大的容器監控系統。我們正與騰訊云監控產品團隊深入合作，更好的服務于騰訊自研業務上云。

本文作者：HelloDeveloper HTTPS 常見問題解答 1、前言 百度從 14 年開始對外開放了 https 的訪問，并于 3 月初正式對全網用戶進行了 https 跳轉。 很多用戶看到這個新聞都比較好奇，在新聞站點，微博，微信和貼吧，知乎等站點進行了熱烈的討論，這里我們也從一個普通用戶容易理解的角度來看看大家的問題。 2、https 是什么？我有沒有用到 https ？ https 是 http over ssl(Secure Socket Layer)，簡單講就是 http 的安全版本，在 http 的基礎上通過傳輸加密和身份認證保證了傳輸過程中的安全性。你通常訪問的網站大部分都是 http 的，最簡單的方法可以看看網址是以 http:// 開頭還是 https:// 開頭。 以下幾個截圖就是 chrome,firefox,IE10 在使用 https 時的效果。 注意圖中綠色的部分 , 我們后面詳細說說。 想進一步了解 HTTPS，可以閱讀《大型網站的 HTTPS 實踐（一）-- HTTPS 協議和原理》 3、https 為什么比 http 安全 ?https 加密 是不是需要我在電腦上安裝證書 / 保存密碼 ? http 不安全，主要是因為它傳輸的是明文內容 , 也不對傳輸雙方進行身份驗證。只要在數據傳輸路徑的任何一個環節上，都能看到傳輸的內容，甚至對其進行修改。例如一篇文章”攻下隔壁女生路由器后 , 我都做了些什么” 中，很多攻擊的環節，都是通過分析 http 的內容來進行。而在現實生活中呢，你很有可能泄露你的論壇高級會員賬號 / 密碼，游戲 vip 賬號 / 密碼，隱私的聊天內容，郵件，在線購物信息，等等。 https 之所以安全，是因為他利用 ssl/tls 協議傳輸。舉個簡單的例子，電影風語者中，美軍發現密碼經常被日本竊聽和破解，就征召了 29 名印第安納瓦霍族人作為譯電員，因為這語言只有他們族人懂。即使日本人竊聽了電文，但是看不懂內容也沒用；想偽造命令也無從下手，修改一些內容的話，印第安人看了，肯定會說看（shen）不（me）懂（gui）?？吹竭@里，你肯定發現了，這是基于兩邊都有懂這個語言（加密解密規則）的人才行啊，那么我的電腦上需要安裝什么密鑰或者證書嗎？一般情況作為普通用戶是不用考慮這些的，我們有操作系統，瀏覽器，數學家，安全和網絡工程師等等 , 幫你都做好了 , 放心的打開瀏覽器用就好啦。 如果你實在好奇，想知道雙方不用相同的密鑰如何進行加密的，可以搜索下” 公鑰加密”（非對稱加密）,”RSA”,” DH 密鑰交換”, “ssl 原理” “數字證書” 等關鍵詞。 有朋友會想了，不就是加密嗎，我 wifi 密碼都能破，找個工具分分鐘就破解了。這個想法可不對 , 雖然沒有絕對的安全，但是可以極大增加破解所需要的成本，https 目前使用的加密方式是需要巨大的計算量（按照目前計算機的計算能力）才可能破解的，你會用世界上最強的超級計算機花費 100 年（只是一個比喻）去解密，看看 100 年前隔壁老王在百度上搜什么嗎。 4、 百度為什么要上 https? 我們每天會處理用戶投訴，比如說: 頁面出現白頁 / 出現某些奇怪的東西 返回了 403 的頁面 搜索不了東西 搜索 url 帶了小尾巴 , 頁面總要閃幾次 頁面彈窗廣告 搜索個汽車就有人給我打電話推銷 4s 店和保險什么的 … 各種千奇百怪的情況 , 查來查去，很大一部分原因是有些壞人在數據的傳輸過程中修改百度的頁面內容，竊聽用戶的搜索內容。悄悄告訴你，https 就是能解決這樣問題的技術哦 , 趕緊把瀏覽器首頁改成 https://www.baidu.com 吧。 從方向上來說，HTTPS 也是未來的趨勢，目前大家使用的 HTTP 還是 1.1/1.0 版本的，新的 HTTP2.0 版本的標準已經發布了。標準中涉及了加密的規范，雖然標準中沒有強制使用，但是已經有很多瀏覽器實現聲稱他們只會支持基于加密連接的 HTTP2.0( https://http2.github.io/faq/#does-http2-require-encryption)。 5、https 不就是在 http 后面加個 s ，很難么？ 難，又不難。 它包含證書，卸載，流量轉發，負載均衡，頁面適配，瀏覽器適配，refer 傳遞等等等等。反正我指頭肯定不夠數。 對于一個超小型個人站點來說，技術宅 1 天就能搞定從申請證書到改造完成。如果是從零開始建設，會更容易。 但是對于百度搜索這種大胖紙來說，可就難了。 它一開始并不是為 https 設計的 內容豐富（內容本身的表現形式很多：圖片，視頻，flash，form 等等），種類豐富 (頁面上除了自然結果，有視頻，圖片，地圖，貼吧，百科 , 第三方的內容 , app 等等)。 數據來源復雜，有幾十個內部產品線的內容，幾百個域名，成千上萬個開發者的內容 百度在全國，甚至世界范圍都有很多 idc 和 cdn 節點，都得覆蓋到。 還不能因此拖慢了百度的速度 (國內使用 https 的銀行 , 在線交易的站點，有沒有覺得很慢？) 上 https 本來就是為了更好的體驗，可不能導致大家使用不穩定。 … 想了解更詳細的內容，可以閱讀《大型網站的 HTTPS 實踐（四）-- 協議層以外的實踐 [1]》 Google 部署 https 花費了 1-2 年，13 年將證書從 1024 位升級到 2048 位花了 3 個月。百度也是去年就開放了入口和小流量，但是今年 3 月才進行全量上線，可以想像整體的復雜性。 6、 如何看待百度搜索支持全站 https ？ 國外的幾個大型站點都 https 化了，這是未來互聯網的趨勢 (有興趣的同學可以搜索下’http/2’ )。 對百度自身來說，https 能夠保護用戶體驗，減少劫持 / 隱私泄露對用戶的傷害。 很多人會有疑惑，我沒有被劫持，百度上 https 有什么作用，反而讓我變慢了一些。從我們的第一手數據可以看到，劫持的影響正越來越大，在法制不健全的環境下，它被當成一個產業，很多公司以它為生，不少以此創業的團隊還拿到了風投。等它真正傷害到你的時候，你可能又會問我們為什么不做些什么。所以，我們寧愿早一些去面對它。 https 在國內的大型站點目前還只用在部分賬戶的登陸和支付等環節。百度也是國內第一個全站 https 的大型站點，它的用戶非常多，流量也很大。百度能夠上線 https 會打消大家的疑慮，對其他國內的站點是很好的示范，這個帶頭作用會顯著加速國內互聯網 https 的進程，有助于中國互聯網的網絡安全建設。百度作為搜索引擎，是流量的入口和分發的渠道，后續如果對 https 的站點內容的抓取，標記，權值傾斜，那么更能引導互聯網的網站向 https 進行遷移。 7、https 慢不慢 ? 如果什么優化都不做，https 會明顯慢很多。在百度已經進行過很多速度優化的條件下，如果站點本身已經做過常規優化，但是不針對 https 做優化，這種情況下我們實測的結果是 0.2-0.4 秒耗時的增加。如果是沒有優化過的站點，慢 1 秒都不是夢。至于現在慢不慢呢，大家已經體驗了這么多天了，有感覺嗎？ 答案：A 慢死了，你們在做啥 ? B 有些慢啊 C 還行 , 基本無感 D 啥 , 我已經用了 https 了？ 是不是選的 C 或者 D？喂喂，選 A 的那位 你打開別的網站慢么 , 以前沒有上 HTTPS 的時候慢么。。。隔壁老王在蹭你網呢。 所以，不是慢，是沒有優化。 8、https 耗性能嗎 ? 答案是，握手的時候耗，建好連接之后就不太耗了。按照目前加密強度的計算開銷，服務器支撐握手性能會下降 6-8 倍，但是如果建立好連接之后，服務器就幾乎可能撐住打滿網卡的 https 流量了。所以連接復用率的提升和計算性能的優化都是重點?？梢蚤喿x《大型網站的 HTTPS 實踐（三）-- 基于協議和配置的優化》 9、 劫持有些什么樣的途經 ? 你的電腦，你設置的 dns，你的瀏覽器，你用的網絡，都有可能被劫持。 簡單和大家介紹下運營商的內容劫持是如何進行的，運營商會分析你的網絡請求，它可以先于網站回包，也能修改數據包的內容。所以它可以讓你跳轉一次，在網址上加上小尾巴，也能在你訪問的頁面彈出小廣告。 感興趣的話，還可以通過這篇文章看看你的電腦如何被 lsp 劫持的《暗云木馬》 10、https 解決了所有劫持問題嗎？ 俗話說有終有始，我們來說一說文章開始說的瀏覽器上的綠色標記。它標志著這個安全連接可信賴的級別。綠色通常是好的，黃色則是說明有些不安全，例如在 https 的頁面中加載了 http 的資源，這樣 http 的資源還是有被劫持的風險。 其實客戶端，局域網的風險也很大，惡意插件，木馬可以做很多事情，你使用的路由器，DNS 也比較脆弱。如果某個大型網站被標記為了紅色，那你就更要小心了 (當然也可能是某個猴子忘記了續費替換證書，導致證書過期了)，你有可能遭受了 ssl 劫持 (中間人攻擊的一種)，特別是遇到如下圖提示的時候（訪問一些自己簽名的站點也會有類似的提示）。中間人攻擊還有其他種類的，比如代理你的通信讓你退化 http, 還可以利用注入根證書，可以讓你瀏覽器還是綠色的標記，就問你怕不怕？ 還是那句話，沒有絕對的安全，但是我們可以盡量降低風險。 https 能夠在絕大部分情況下保證互聯網訪問數據傳輸的安全，這是目前我們力所能及的工作。 原文鏈接地址： https://developer.baidu.com/topic/show/290306

本文作者：HelloDeveloper 大型網站的 HTTPS 實踐（四） -- 協議層以外的實踐 前言 網上介紹 https 的文章并不多，更鮮有分享在大型互聯網站點部署 https 的實踐經驗，我們在考慮部署 https 時也有重重的疑惑。 本文為大家介紹百度 HTTPS 的實踐和一些權衡 , 希望以此拋磚引玉。 協議層以外的實踐工作 全站覆蓋 https 的理由 很多剛接觸 https 的會思考，我是不是只要站點的主域名換了 https 就可以？答案是不行。 https 的目的就是保證傳輸過程的安全，如果只有主域名上了 https，但是主域名加載的資源，比如 js，css，圖片沒有上 https，會怎么樣？ 從效果上來說，沒有達到保證網站傳輸過程安全的目的，因為你的 js，css，圖片仍然有被劫持的可能性，如果這些內容被篡改 / 嗅探了，那么 https 的意義就失去了。 瀏覽器在設計上早就考慮的這樣的情況，會有相應的提示。具體的實現依賴瀏覽器，例如地址欄鎖形標記從綠色變為黃色 , 阻止這次請求，或者直接彈出非常影響用戶體驗的提示 (主要是 IE)，用戶會感覺厭煩，疑惑和擔憂安全性。 很多用戶看見這個鏈接會習慣性的點” 是”，這樣非 https 的資源就被禁止加載了。非 ie 的瀏覽器很多也會阻止加載一些危害程度較高的非 https 資源（例如 js）。我們發現移動端瀏覽器的限制目前會略松一些。 所以這里要是沒做好，很多情況連網站的基本功能都沒法正常使用。 站點的區別 很多人剛接觸 https 的時候，覺得不就是部署證書，讓 webserver 支持 https 就行了嗎。 實際上對于不同的站點來說，https 的部署方式和難度有很大的區別。對于一個大型站點來說，讓 webserver 支持 https，以及對 webserver 在 https 協議特性上做一些優化，在遷移的工作比重上，可能只占到 20%-40%。 我們考慮下以下幾種情況下，部署 https 的方案。 簡單的個人站點 簡單的定義：資源只從本站的主域或者主域的子域名加載。 比如 axyz 的個人 blog，域名是 axyzblog.com。加載主域名下的 js 和圖片。 這樣的站部署 https，在已有證書且 webserver 支持的情況下，只需要把主域名替換為 https 接入，然后把資源連接修改為 https:// 或者 //。 復雜的個人站點 復雜的定義：資源需要從外部域名加載。 這樣就比較麻煩了，主域資源容易適配 https，在 cdn 上加載的資源還需要 cdn 服務商支持 https。目前各大 cdn 的服務商正在逐漸提供 https 的支持，需要遷移的朋友可以看看自己使用的 cdn 是否提供了這項能力。一些 cdn 會對 https 流量額外收費。 Cdn 使用 https 常見的方案有： 網站主提供私鑰給 cdn，回源使用 http。 cdn 使用公共域名，公共的證書，這樣資源的域名就不能自定義了?；卦词褂?http。 僅提供動態加速，cdn 進行 tcp 代理，不緩存內容。 CloudFlare 提供了 Keyless SSL 的服務，能夠支持不愿意提供私鑰 , 不想使用公共的域名和證書卻又需要使用 cdn 的站點了。 簡單的大型站點 簡單的定義: 資源只從本站的主域 , 主域的子域，或者自建 / 可控的 cdn 域名加載，幾乎沒有第三方資源。如果網站本身的特性就如此，或愿意改造為這樣的類型，部署 https 就相對容易。Google Twitter 都是非常好的范例。優點：已經改成這樣的站點，替換 https 就比較容易。缺點：如果需要改造，那么要很大的決心，畢竟幾乎不能使用多樣化的第三方資源了。 復雜，訪問速度重要性稍低的大型站點 復雜的定義：從本站的非主域，或者第三方站點的域名有大量的第三方資源需要加載，多出現在一些平臺類，或者有復雜內容展現的的網站。 訪問速度要求：用戶停留時間長或者強需求，用戶對訪問速度的耐受程度較高。比如門戶，視頻，在線交易類（比如火車票 機票 商城）網站。 這樣的站點，可以努力推動所有相關域名升級為支持 https。我們用下圖舉例說明下這樣修改會導致一個網站的鏈接發生怎樣的改變。 負責流量接入的團隊將可控的接入環境改造為 http 和 https 都支持，這樣前端工程的工作相對就少一些。大部分時候將鏈接從 http:// 替換為 // 即可 . 在主域名是 https 的情況下，其它資源就能自動從 https 協議下加載。一些第三方資源怎么辦？一般來說只有兩種選擇，一遷移到自己的 cdn 或者 idc 吧，二強制要求第三方自己能支持 https。 以全站 https 接入的 facebook 舉例。第三方廠商想在 facebook 上線一個游戲。facebook：請提供 https 接入吧。第三方想：能賺錢啊，還是提供下 https 接入吧。所以，足夠強勢，有吸引力，合作方也有提供 https 的能力的話，這是完全可行的。如果你的平臺接入的都是一些個人開發者，而且還賺不到多少錢的情況下，這樣就行不通了。 優點：前端改動相對簡單，不容易出現 https 下還有 http 的資源問題。 缺點：通常這樣的實現下，用戶的訪問速度會變慢，比如從5 秒變為 3 秒，如上述的理由，用戶還是能接受的。對第三方要求高。 復雜，訪問速度有嚴格要求的大型站點 復雜的定義：同上。 訪問速度要求：停留時間不長，用戶對訪問速度的心理預期較高。 但是如果用戶把網站當作工具使用，需要你很快給出響應的時候，這樣的實現就不好了。后續幾個部分我們介紹下這些優化的抉擇。 域名的選擇 域名對訪問速度的影響具有兩面性：域名多，域名解析和建立連接的時間就多；域名少，下載并發度又不夠。 https 下重建連接的時間成本比 http 更高，對于上面提到的簡單的大型站點 , 可以只用 1-3 個域名就能滿足需求，對于百度這樣富展現樣式較多的搜索引擎來說，頁面可能展示的資源種類太多。而不同類型的資源又是由不同的域名 (不同的產品 或者第三方產品) 提供的服務，換一個詞搜索就可能需要重新建立一些資源的 ssl 鏈接，會讓用戶感受到卡頓。 如果將域名限制在有限的范圍 (一般 2-6 個左右)，維持和這些域名的連接，合并一些數據，加上有 spdy，http2.0 來保證并發，是可以滿足我們的需求的。我們的現狀是：百度搜索有數百個資源域名在加載各類的資源。這就變成了如何解決這樣的問題：如何用 2-6 個有限的域名提供數百個域名的服務，這就涉及了下一節，代理接入與 cdn。 代理接入 當域名從數百域名縮減到個位數的時候，就不可避免的需要談到統一接入，流量轉發和調度等內容。通常的站點資源大都是從主域名 +cdn 進行加載，所以我們可以把域名分為這兩類，進行替換。 替換后的幾個 cdn 域名都指向相同的 cname，這樣的話意味著用戶訪問的途徑變為如下的方式。 這樣 ssl 的握手只在用戶和兩類節點之間進行，維持連接相對容易很多，也不需要每個域名都去申請證書，部署 https 接入。 這個方式會遇到域名轉換，數據透傳，流量調度等一系列的問題，需要進行整體設計架構，對很多細節都需要進行優化，在運維和研發上都有不小的投入。 理想的方式：這樣就只需要和 cdn 節點進行 https 握手，大幅縮短了握手的 rtt 時間 (cdn 節點一般廣泛的分布在離用戶很近的地方，而主域節點一般都比較有限). 這樣部署會對 cdn 的運維和研發能力有更高的要求。 大家有沒發現，這樣的接入就把一個復雜的站點變為簡單的站點了？ 連接復用 連接復用率可以分為 tcp 和 ssl 等不同的層面，需要分開進行分析和統計。 連接復用的意義 HTTP 協議 (RFC2616) 規定一個域名最多不能建立超過 2 個的 TCP 連接。但是隨著互聯網的發展，一張網頁的元素越來越多，傳輸內容越來越大，一個域名 2 個連接的限制已經遠遠不能滿足現在網頁加載速度的需求。 目前已經沒有瀏覽器遵守這個規定，各瀏覽器針對單域名建立的 TCP 連接數如下： 表格 1 瀏覽器單域名建立的最大并發連接數 從上表看出，單個域名的連接數基本上是 6 個。所以只能通過增加域名的方式來增加并發連接數。在 HTTP 場景下，這樣的方式沒有什么問題。但是在 HTTPS 連接下，由于 TLS 連接建立的成本比較高，增加并發連接數本身就會帶來較大的延遲，所以對域名數需要一個謹慎的控制。 特別是 HTTP2 即將大規模應用，而 HTTP2 的最大特性就是多路復用，使用多個域名和多個連接無法有效發揮多路復用和壓縮的特性。 那 HTTPS 協議下，一張網頁到底該有多少域名呢？這個其實沒有定論，取決于網頁需要加載元素個數。 預建連接 既然從協議角度無法減少握手對速度的影響，那能不能提前建立連接，減少用戶可以感知的握手延遲呢？當然是可以的。思路就是預判當前用戶的下一個訪問 URL，提前建立連接，當用戶發起真實請求時，TCP 及 TLS 握手都已經完成，只需要在連接上發送應用層數據即可。 最簡單有效的方式就是在主域下對連接進行預建，可以通過請求一些靜態資源的方式。但是這樣還是不容易做到極致，因為使用哪個連接，并發多少還是瀏覽器控制的。例如你對 a 域名請求一個圖片，瀏覽器建立了兩個連接，再請求一張圖片的時候，瀏覽器很大概率能夠復用連接，但是當 a 域名需要加載 10 個圖片的時候，瀏覽器很可能就會新建連接了。 Spdy 的影響 Spdy 對于連接復用率的提升非常有效，因為它能支持連接上的并發請求，所以瀏覽器會盡量在這個鏈接上保持復用。 其它 也可以嘗試一些其他發方法，讓瀏覽器在訪問你的網站之前就建立過 https 連接，這樣 session 能夠復用。HSTS 也能有效的減少跳轉時間，可惜對于復雜的網站來說，開啟需要考慮清楚很多問題。 優化的效果 從百度的優化經驗來看看，如果不開啟 HSTS，用戶在瀏覽器直接訪問主域名，再通過 302 跳轉到 HTTPS。增加的時間平均會有 400ms+，其中 302 跳轉和 ssl 握手的因素各占一半。但是對于后續的請求，我們做到了對絕大部分用戶幾乎無感知。 這 400ms+ 還有很多可以優化的空間，我們會持續優化用戶的體驗。 HTTPS 遷移遇到的一些常見問題。 傳遞 Referrer 我們可以把自己的網站替換為 https，但是一般的站點都有外鏈，要讓外鏈都 https 目前還不太現實。很多網站需要從 referrer 中判斷流量來源，因此對于搜索引擎這樣的網站來說，referer 的傳遞還是比較重要的。如果不做任何設置，你會發現在 https 站點中點擊外鏈并沒有將 referrer 帶入到 http 請求的頭部中（ http://tools.ietf.org/html/rfc7231#section-5.5.2）?，F代的瀏覽器可以用 meta 標簽來傳遞 refer。( http://w3c.github.io/webappsec/specs/referrer-policy ) 傳遞完整的 url 只傳遞站點，不包含路徑和參數等。 對于不支持 meta 傳遞 referrer 的瀏覽器，例如 IE8, 我們怎么辦呢？ 可以采用再次跳轉的方法，既然 HTTPS 下不能給 HTTP 傳遞 referer，我們可以先從 HTTPS 訪問一個可控的 http 站點，把需要傳遞的內容放到這個 http 站點的 url 中，然后再跳轉到目標地址。 form 提交 有時需要將 form 提交到第三方站點，而第三方站點又是 http 的地址，瀏覽器會有不安全的警告?？梢院?referrer 的跳轉傳遞采取相似的邏輯。 但是這樣對 referer 和 form 等內容的方案，并不是完美的解決方法，因為這樣還是增加了不安全的因素（劫持，隱私泄露等 ）。理想情況需要用戶升級符合最新規范的瀏覽器，以及推進更多的站點遷移至 https。 視頻播放 簡單來說，如果你使用 http 的協議來播放視頻，那么瀏覽器仍然會有不安全的提示。所以你有兩種選擇，1 讓視頻源提供 https。2 使用非 http 的協議，如 rtmp 協議。 用戶異常 在 https 遷移的過程中，也會有不少熱心的用戶向我們反饋遇到的各種問題。 常見的有以下的一些情況： 用戶的系統時間設置錯誤，導致提示證書過期。 用戶使用 fiddler 等代理進行調試，但是沒有添加這些軟件的根證書，導致提示證書非法。 用戶使用的 Dns 為公共 dns 或者跨網設置 dns，一些請求被運營商作為跨網流量攔截。 連通性有問題，我們發現一個小運營商的 https 失敗率奇高，又沒法聯系到他們，只能不對他們進行 https 的轉換。 慢。有時由于網絡環境的因素，用戶打開其他網站也慢，ping 哪個網站都要 500-2000ms。這時 https 自然也會很慢。 結束語 對于復雜的大型網站來說，HTTPS 的部署有很多工作要完成。 面對困難和挑戰，有充足的動力支持著我們前進：https 上線后，劫持等原因導致的用戶功能異常，隱私泄露的反饋大幅減少。 熱心的用戶經常會向我們反饋遇到的各種問題。在以前，有時即使我們確定了是劫持的問題，能夠解決問題的方法也非常有限。每當這種時候，自己總會產生一些無力感。 HTTPS 的全站部署，給我們提供了能解決大部分問題的選項。能讓一個做技術的人看到自己的努力解決了用戶的問題，這就是最棒的收獲。 HTTPS 沒有想像中難用和可怕，只是沒有經過優化。與大家共勉。 原文鏈接地址： https://developer.baidu.com/topic/show/290305

本文作者：HelloDeveloper 大型網站的 HTTPS 實踐（三） -- 基于協議和配置的優化 前言 上文講到 HTTPS 對用戶訪問速度的影響。 本文就為大家介紹 HTTPS 在訪問速度，計算性能，安全等方面基于協議和配置的優化。 HTTPS 訪問速度優化 Tcp fast open HTTPS 和 HTTP 使用 TCP 協議進行傳輸，也就意味著必須通過三次握手建立 TCP 連接，但一個 RTT 的時間內只傳輸一個 syn 包是不是太浪費？能不能在 syn 包發出的同時捎上應用層的數據？其實是可以的，這也是 tcp fast open 的思路，簡稱 TFO。具體原理可以參考 rfc7413。 遺憾的是 TFO 需要高版本內核的支持，linux 從 3.7 以后支持 TFO，但是目前的 windows 系統還不支持 TFO，所以只能在公司內部服務器之間發揮作用。 HSTS 前面提到過將用戶 HTTP 請求 302 跳轉到 HTTPS，這會有兩個影響： 不安全，302 跳轉不僅暴露了用戶的訪問站點，也很容易被中間者支持。 降低訪問速度，302 跳轉不僅需要一個 RTT，瀏覽器執行跳轉也需要執行時間。 由于 302 跳轉事實上是由瀏覽器觸發的，服務器無法完全控制，這個需求導致了 HSTS 的誕生： HSTS(HTTP Strict Transport Security)。服務端返回一個 HSTS 的 http header，瀏覽器獲取到 HSTS 頭部之后，在一段時間內，不管用戶輸入baidu.com還是http://www.baidu.com，都會默認將請求內部跳轉成https://www.baidu.com。 Chrome, firefox, ie 都支持了 HSTS（ http://caniuse.com/#feat=stricttransportsecurity）。 Session resume Session resume 顧名思義就是復用 session，實現簡化握手。復用 session 的好處有兩個： 減少了 CPU 消耗，因為不需要進行非對稱密鑰交換的計算。 提升訪問速度，不需要進行完全握手階段二，節省了一個 RTT 和計算耗時。 TLS 協議目前提供兩種機制實現 session resume，分別介紹一下。 Session cache Session cache 的原理是使用 client hello 中的 session id 查詢服務端的 session cache, 如果服務端有對應的緩存，則直接使用已有的 session 信息提前完成握手，稱為簡化握手。 Session cache 有兩個缺點： 需要消耗服務端內存來存儲 session 內容。 目前的開源軟件包括 nginx,apache 只支持單機多進程間共享緩存，不支持多機間分布式緩存，對于百度或者其他大型互聯網公司而言，單機 session cache 幾乎沒有作用。 Session cache 也有一個非常大的優點： session id 是 TLS 協議的標準字段，市面上的瀏覽器全部都支持 session cache。 百度通過對 TLS 握手協議及服務器端實現的優化，已經支持全局的 session cache，能夠明顯提升用戶的訪問速度，節省服務器計算資源。 Session ticket 上節提到了 session cache 的兩個缺點，session ticket 能夠彌補這些不足。 Session ticket 的原理參考 RFC4507。簡述如下： server 將 session 信息加密成 ticket 發送給瀏覽器，瀏覽器后續握手請求時會發送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。 顯然，session ticket 的優點是不需要服務端消耗大量資源來存儲 session 內容。 Session ticket 的缺點： session ticket 只是 TLS 協議的一個擴展特性，目前的支持率不是很廣泛，只有 60% 左右。 session ticket 需要維護一個全局的 key 來加解密，需要考慮 KEY 的安全性和部署效率。 總體來講，session ticket 的功能特性明顯優于 session cache。希望客戶端實現優先支持 session ticket。 Ocsp stapling Ocsp 全稱在線證書狀態檢查協議 (rfc6960)，用來向 CA 站點查詢證書狀態，比如是否撤銷。通常情況下，瀏覽器使用 OCSP 協議發起查詢請求，CA 返回證書狀態內容，然后瀏覽器接受證書是否可信的狀態。 這個過程非常消耗時間，因為 CA 站點有可能在國外，網絡不穩定，RTT 也比較大。那有沒有辦法不直接向 CA 站點請求 OCSP 內容呢？ocsp stapling 就能實現這個功能。 詳細介紹參考 RFC6066 第 8 節。簡述原理就是瀏覽器發起 client hello 時會攜帶一個 certificate status request 的擴展，服務端看到這個擴展后將 OCSP 內容直接返回給瀏覽器，完成證書狀態檢查。 由于瀏覽器不需要直接向 CA 站點查詢證書狀態，這個功能對訪問速度的提升非常明顯。 Nginx 目前已經支持這個 ocsp stapling file，只需要配置 ocsp stapling file 的指令就能開啟這個功能： False start 通常情況下，應用層數據必須等完全握手全部結束之后才能傳輸。這個其實比較浪費時間，那能不能類似 TFO 一樣，在完全握手的第二個階段將應用數據一起發出來呢？google 提出了 false start 來實現這個功能。詳細介紹參考 https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。 簡單概括 False start 的原理就是在 client_key_exchange 發出時將應用層數據一起發出來，能夠節省一個 RTT。 False start 依賴于 PFS（perfect forward secrecy 完美前向加密），而 PFS 又依賴于 DHE 密鑰交換系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以盡量優先支持 ECDHE 密鑰交換算法實現 false start。 使用 SPDY 或者 HTTP2 SPDY 是 google 推出的優化 HTTP 傳輸效率的協議（ https://www.chromium.org/spdy），它基本上沿用了 HTTP 協議的語義 , 但是通過使用幀控制實現了多個特性，顯著提升了 HTTP 協議的傳輸效率。 SPDY 最大的特性就是多路復用，能將多個 HTTP 請求在同一個連接上一起發出去，不像目前的 HTTP 協議一樣，只能串行地逐個發送請求。Pipeline 雖然支持多個請求一起發送，但是接收時依然得按照順序接收，本質上無法解決并發的問題。 HTTP2 是 IETF 2015 年 2 月份通過的 HTTP 下一代協議，它以 SPDY 為原型，經過兩年多的討論和完善最終確定。 本文就不過多介紹 SPDY 和 HTTP2 的收益，需要說明兩點： SPDY 和 HTTP2 目前的實現默認使用 HTTPS 協議。 SPDY 和 HTTP2 都支持現有的 HTTP 語義和 API，對 WEB 應用幾乎是透明的。 Google 宣布 chrome 瀏覽器 2016 年將放棄 SPDY 協議，全面支持 HTTP2，但是目前國內部分瀏覽器廠商進度非常慢，不僅不支持 HTTP2，連 SPDY 都沒有支持過。 百度服務端和百度手機瀏覽器現在都已經支持1 協議。 HTTPS 計算性能優化 優先使用 ECC ECC 橢圓加密算術相比普通的離散對數計算速度性能要強很多。下表是 NIST 推薦的密鑰長度對照表。 對稱密鑰大小 | RSA 和 DH 密鑰大小 | ECC 密鑰大小 ----|------|---- 80|1024|160| 112|2048|224 128|3072|256 192|7680|384 256|15360|521 表格 2 NIST 推薦使用的密鑰長度 對于 RSA 算法來講，目前至少使用 2048 位以上的密鑰長度才能保證安全性。ECC 只需要使用 224 位長度的密鑰就能實現 RSA2048 位長度的安全強度。在進行相同的模指數運算時速度顯然要快很多。 使用最新版的 openssl 一般來講，新版的 openssl 相比老版的計算速度和安全性都會有提升。比如 openssl1.0.2 采用了 intel 最新的優化成果，橢圓曲線 p256 的計算性能提升了 4 倍。( https://eprint.iacr.org/2013/816.pdf ) Openssl 2014 年就升級了 5 次，基本都是為了修復實現上的 BUG 或者算法上的漏洞而升級的。所以盡量使用最新版本，避免安全上的風險。 硬件加速方案 現在比較常用的 TLS 硬件加速方案主要有兩種： SSL 專用加速卡。 GPU SSL 加速。 上述兩個方案的主流用法都是將硬件插入到服務器的 PCI 插槽中，由硬件完成最消耗性能的計算。但這樣的方案有如下缺點： 支持算法有限。比如不支持 ECC，不支持 GCM 等。 升級成本高。 出現新的加密算法或者協議時，硬件加速方案無法及時升級。 出現比較大的安全漏洞時，部分硬件方案在無法在短期內升級解決。比如 2014 年暴露的 heartbleed 漏洞。 無法充分利用硬件加速性能。硬件加速程序一般都運行在內核態，計算結果傳遞到應用層需要 IO 和內存拷貝開銷，即使硬件計算性能非常好，上層的同步等待和 IO 開銷也會導致整體性能達不到預期，無法充分利用硬件加速卡的計算能力。 維護性差。硬件驅動及應用層 API 大部分是由安全廠家提供，出現問題后還需要廠家跟進。用戶無法掌握核心代碼，比較被動。不像開源的 openssl，不管算法還是協議，用戶都能掌握。 TLS 遠程代理計算 也正是因為上述原因，百度實現了專用的 SSL 硬件加速集群?；舅悸肥牵?優化 TLS 協議棧，剝離最消耗 CPU 資源的計算，主要有如下部分： RSA 中的加解密計算。 ECC 算法中的公私鑰生成。 ECC 算法中的共享密鑰生成。 優化硬件計算部分。硬件計算不涉及協議及狀態交互，只需要處理大數運算。 Web server 到 TLS 計算集群之間的任務是異步的。即 web server 將待計算內容發送給加速集群后，依然可以繼續處理其他請求，整個過程是異步非阻塞的。 HTTPS 安全配置 協議版本選擇 SSL2.0 早就被證明是不安全的協議了，統計發現目前已經沒有客戶端支持 SSL2.0，所以可以放心地在服務端禁用 SSL2.0 協議。 2014 年爆發了 POODLE 攻擊，SSL3.0 因此被證明是不安全的。但是統計發現依然有 0.5% 的流量只支持 SSL3.0。所以只能有選擇地支持 SSL3.0。 TLS1.1 及 1.2 目前為止沒有發現安全漏洞，建議優先支持。 加密套件選擇 加密套件包含四個部分： 非對稱密鑰交換算法。建議優先使用 ECDHE，禁用 DHE，次優先選擇 RSA。 證書簽名算法。由于部分瀏覽器及操作系統不支持 ECDSA 簽名，目前默認都是使用 RSA 簽名，其中 SHA1 簽名已經不再安全，chrome 及微軟 2016 年開始不再支持 SHA1 簽名的證書 ( http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)。 對稱加解密算法。優先使用 AES-GCM 算法，針對0 以上協議禁用 RC4（ rfc7465）。 內容一致性校驗算法。Md5 和 sha1 都已經不安全，建議使用 sha2 以上的安全哈希函數。 HTTPS 防攻擊 防止協議降級攻擊 降級攻擊一般包括兩種：加密套件降級攻擊 (cipher suite rollback) 和協議降級攻擊（version roll back）。降級攻擊的原理就是攻擊者偽造或者修改 client hello 消息，使得客戶端和服務器之間使用比較弱的加密套件或者協議完成通信。 為了應對降級攻擊，現在 server 端和瀏覽器之間都實現了 SCSV 功能，原理參考 https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00。 一句話解釋就是如果客戶端想要降級，必須發送 TLS_SCSV 的信號，服務器如果看到 TLS_SCSV，就不會接受比服務端最高協議版本低的協議。 防止重新協商攻擊 重新協商（tls renegotiation）分為兩種：加密套件重協商 (cipher suite renegotiation) 和協議重協商（protocol renegotiation）。 重新協商會有兩個隱患： 重協商后使用弱的安全算法。這樣的后果就是傳輸內容很容易泄露。 重協商過程中不斷發起完全握手請求，觸發服務端進行高強度計算并引發服務拒絕。 對于重協商，最直接的保護手段就是禁止客戶端主動重協商，當然出于特殊場景的需求，應該允許服務端主動發起重協商。 結束語 HTTPS 的實踐和優化涉及到了非常多的知識點，由于篇幅關系，本文對很多優化策略只是簡單介紹了一下 . 如果想要了解協議背后的原理，還是需要詳細閱讀 TLS 協議及 PKI 知識。對于大型站點來說，如果希望做到極致，HTTPS 的部署需要結合產品和基礎設施的架構來進行詳細的考慮，比起部署支持 HTTPS 的接入和對它的優化，在產品和運維層面上花費的功夫會更多。本系列的下一篇文章將進一步進行介紹。 原文鏈接地址： https://developer.baidu.com/topic/show/290304

本文作者：AIOps智能運維 作者簡介 喻友文 百度高級前端研發工程師 負責百度智能運維產品（Noah）的前端研發工作，在前端框架、前端工程化等方向有廣泛的實踐經驗。 干貨概覽 在前面的文章中為大家介紹了百度智能運維團隊研發的各類運維管理平臺，包括百度內部的系統監控、 外網質量監控獵鷹 、 內網質量監控NetRadar 、 單機房故障自愈 ，對外開放的 標準運維管理平臺NoahEE 、 百度云監控 、 智能異常檢測 等產品。這些平臺覆蓋了故障管理、變更管理、容量管理、服務臺等多個運維場景。如此繁多的運維管理平臺所涉及的前端開發工作量是特別龐大的，特別是運維管理平臺的復雜性還很高，涉及大量的前端業務邏輯開發（如操作交互、數據處理、數據可視化展現等）。那么智能運維前端研發團隊是如何在人員有限的情況下開發出完善的覆蓋百度內外的各類運維管理平臺呢？這主要得益于團隊根據多年的實踐經驗推出的 NoahV運維前端研發框架 。下面我們就來詳細介紹下NoahV框架是如何提升運維平臺前端研發效率，從而幫助團隊快速高效的研發運維管理平臺。 從運維業務場景出發，尋找解決方案 通過對大量的運維管理平臺調研總結，我們發現雖然運維場景是多種多樣的，但對應Web平臺展現場景其實是可以 收斂 的?；究梢苑譃槿缦聝深悾?1 運維操作類 運維操作一般包括程序部署上線、監控任務創建、故障Case記錄、機器上架管理等，這些場景一般都需要輸入一些參數用來確認操作的具體過程以及記錄操作的一些概要信息，所以這類展現場景采用最多的是使用 表單 方式，運維操作者根據需要輸入或者選擇一些信息，最后提交，將操作任務交給程序來執行，從而完成一次運維操作。 如圖1所示為變更管理中新建部署任務示例，指定上線內容，上線模塊，上線之后運行賬戶、部署路徑等信息，提交之后，部署程序將會根據提交信息執行部署上線操作。 圖1 新建部署任務示例 2 數據展示類 除上述運維操作之外，另外一個最常見的運維展現場景是數據展示類，如展示歷史上線任務信息、監控任務信息、機器域名等資產信息、最常見的展現方式就是使用 表格 將任務展示出來。如圖2所示為監控任務列表頁面，通過表格一行一行展示監控任務的概要信息。 圖2 監控任務列表 另外像監控業務場景中，常常需要比表格更直觀的展現數據形式，通?？梢圆捎?趨勢圖、柱狀圖、餅圖、事件流圖 等數據可視化展現形式。如圖3所示為某服務在一段時間內的PV情況，使用趨勢圖展現可以很清晰地看出數據隨時間變化和波動的情況。 圖3 可視化數據展示示例 既然展現形式是收斂的，那我們可以將這些收斂的展現形式做成 固定的頁面模板 ，針對相同的展現形式我們只需復用同一個頁面模板。同時通過簡化模板的使用，以達到研發效率提升的目標。 頁面模板-簡化運維前端研發利器 如圖4所示為頁面模板的構成示意圖，在UI組件的基礎上通過添加相應的 業務邏輯處理 將運維場景中高頻的展現形式做成頁面模板，如表單模板、列表模板、數據可視化模板等。 圖4 頁面模板構成 一般需要在組件基礎上添加如下業務邏輯處理： 數據獲取、處理、渲染 ：根據數據請求地址和請求參數，通過異步的方式請求到需要展示的數據，并對數據進行過濾、篩選等處理，最終渲染到模板指定區域。 組件布局控制 ：按照不同模板的 使用場景 對模板中所包含的組件進行合理布局展示。 交互事件處理 ：關聯處理不同組件的 交互行為 ，如點擊查詢或者提交按鈕時自動獲取表單填寫的內容并執行查詢更新展示數據等。 配置解析 ：主要解析用戶提供的模板配置信息，如表單模板項名稱、輸入類型（輸入框、單選框、多選框、下拉框、時間選擇框等）、需要執行的操作類型（提交、重置等）。 經過這些業務邏輯處理之后產出的頁面模板，只需提供 JSON配置信息 就能輕松產出我們需要的前端展示頁面。 1 列表頁面模板使用示例 如圖5所示為列表模板的使用示例，只需提供如圖6所示JSON數據用來描述需要展示的運維對象，就能生成如下圖所示的列表頁面，開發者不再需要編寫復雜的JS代碼來處理繁雜的前端業務邏輯，也不需要關心如何獲取表格展示數據，如何獲取用戶填寫的表單內容，也不需要關心分頁和數據展示的邏輯，極大降低了運維管理平臺開發的難度，提升了運維管理平臺的開發效率。 圖5 列表頁面模板示例 圖6 JSON配置數據 2 數據可視化模板示例 針對運維業務中數據可視化展現的需求，我們提供了可以 自定義布局 的可視化頁面模板，通過與表單模板、列表模板結合從而構成完整的儀表盤功能。儀表盤主要提供頁面布局自定義配置(包括組件位置、大小、排版自定義)、組件基礎信息的可視化配置（包括數據來源、外觀、交互等）、自定義頁面的展示和管理等功能。如圖7所示為使用儀表盤創建的一個可視化展示頁面。 圖7 儀表盤示例 3 使用效果 有了這些頁面模板，自定義頁面布局，儀表盤模板之后，開發者不再需要編寫復雜JS處理邏輯，只需提供對應的 配置數據 就可以很方便快捷地搭建出想要的運維管理平臺，極大的降低了研發成本，避免了重復編寫相同代碼邏輯造成的研發效率低下問題。 通過評估：使用頁面模板開發相較于直接使用UI組件開發能 提高2-3倍開發效率 ，當前這些頁面模板和儀表盤功能能覆蓋大部分運維平臺的展示需求，已經應用到了資源管理、部署、監控、故障處理等多個運維場景，落地的運維管理系統達20余個。此外針對少部分不能覆蓋的情況，我們也提供了基礎UI組件庫以及運維業務組件庫，可以直接使用這些組件來開發需要的頁面。 NoahV框架不僅僅是頁面模板 除了上述頁面模板和儀表盤之外，NoahV框架還提供了一系列研發輔助工具和其他實用的功能模塊，覆蓋了從開發、構建、到線上運行的各個階段。如圖8所示為NoahV運維框架架構圖： 圖8 NoahV運維前端研發框架 通過將常見運維平臺中的網站導航功能和常見的頁面布局形式加入到框架中，實現提供JSON配置就能生成通用的網站導航和布局。 此外我們也結合豐富的運維前端研發經驗沉淀出項目開發的最佳實踐，包括項目初始目錄結構、頁面模板復用、開發調試、前后端協作、前端路由管理、編譯構建、線上運行統計分析等，同時也將上述部分功能和實踐集成到了 腳手架 中，通過輸入簡單的命令就能很簡單高效的完成項目初始化、頁面模板復用、項目開發調試。這些工具和功能通過建立規范的前端工程化體系能在頁面模板和儀表盤的基礎上再次提升運維前端項目的研發效率。 項目案例-NoahEE 圖9 NoahEE部署系統 圖10 NoahEE部署系統 圖11 NoahEE監控系統 圖12 NoahEE儀表盤 總 結 目前NoahV框架在百度內部和云上運維產品已經有了較為廣泛的應用，同時也已經開源到了 GitHub ，大家有興趣可以點擊 閱讀原文（https://github.com/baidu/NoahV） 訪問我們的GitHub主頁查看使用文檔來試用，使用過程中有任何問題都可以通過GitHub Issue或者直接留言反饋給我們。 原文鏈接地址： https://developer.baidu.com/topic/show/290302

本文作者：AIOps智能運維 作者簡介 運小貝 百度高級研發工程師 負責百度內網質量監測平臺（ NetRadar ）的業務端設計及開發工作。在系統和網絡監控、時序指標異常檢測、智能客服機器人等方向有廣泛實踐經驗。 干貨概覽 百度內網連接著數十萬臺服務器，承載著全公司業務的網絡通信，其通信質量的重要性不言而喻。而百度內網的質量監測平臺 NetRadar （網絡雷達），通過對整個內網“服務器端到端”傳輸質量進行監測，實現了快速、準確地發現、通告、定位內網問題，為百度業務的正常通信提供了有力保障。 《百度網絡監控實戰： NetRadar 橫空出世》系列文章將分上、下兩篇介紹 NetRadar 平臺，本文主要介紹內網質量監測的意義、相關需求以及百度原有的內網監測技術，而下篇將從核心功能、設計框架、異常檢測策略以及可視化視圖等方面對 NetRadar 平臺進行系統介紹。 百度內網介紹 百度擁有 數十萬臺 服務器，分布于全國各地的 幾十個 數據中心（又稱IDC、機房）。這些 海量的 服務器通過網絡分層級互聯，構成了統一的“資源池”，對外提供可靠、強大的存儲、計算和通信服務。 在軟件架構上，百度的大型服務一般都是模塊化設計，一次服務需要上下游大量模塊共同協作完成。為了提高并發服務能力和容災能力，這些模塊會分布式地部署在不同機房的不同服務器上。為保證服務的正常運行，內網必須保證各模塊具有良好的 “端到端” 網絡通信能力，一旦出現網絡故障并影響了模塊間的通信，往往會對服務造成影響，甚至導致服務整體不可用。 為了提供高可靠、高性能的端到端通信能力，網絡結構在設計上預留了大量冗余，既有設備的冗余，也有線路的冗余。這樣一來，兩臺服務器間的通信可以同時存在許多條不同的路徑，能夠在一定程度上抵御網絡故障。盡管如此，實際環境中端到端的通信問題依然常見，其原因主要包括： 路由收斂延遲、ToR 交換機單點故障、網絡擁塞 等等。另一方面，即便單個設備、網線、服務器發生故障的概率很低，乘上巨大的數量，故障必然是“常態”現象。 在這種“與故障為伴”的環境下，既然無法避免故障，就需要能夠及時、準確地監測內網質量，這對于保證服務正常運行來說是至關重要的。 需求調研 在運維實踐中，工程師對內網質量監測系統都有什么樣的需求呢？我們對各業務線的運維工程師，以及來自網絡組的同學進行了調研。為了更好地說明用戶需求，圖1給出了一個典型的運維場景： 當運維工程師發現服務關鍵指標異常后，如果懷疑是內網故障導致的，則需要通過回答如下一些問題進行排查： 1）“機房A到機房B的網絡有問題嗎?” 2）“服務器a到服務器b網絡有問題嗎?” 如果經過檢查確認內網沒有問題，就要繼續排查其他可能的原因，諸如上線、操作、程序 bug 等原因，以幫助進行有效的止損和恢復決策。而如果確定是內網故障導致服務受損，那么網絡工程師為了診斷和修復網絡故障，會排查一系列的通信問題來幫助縮小故障范圍，比如：“哪些服務器通信有問題?”，“哪條鏈路有問題?”等。為了回答這些問題，最直接有效地方式就是“進行服務器端到端檢測”，比如： 1) 排查 “機房A到機房B網絡有問題嗎?” 可以測試: 機房A大部分機器到機房B大部分機器間的網絡質量 2) 排查 “機房A內部網絡有問題嗎?” 可以測試: 機房A大部分機器互相訪問的網絡質量 3) 排查 “服務器a到服務器b網絡有問題嗎?” 只需測試: 服務器a訪問服務器b的網絡質量 4) 排查 “哪些服務器通信有問題?” 需要挨個ping或ssh疑似有問題的服務器 5) 排查 “在哪條鏈路上出的問題?” 需要執行traceroute命令查看路由細節 但是，人工執行上述測試任務費時又費力。如圖2所示，為了進行一次端到端的網絡質量檢測，首先要確定“源-目的”服務器，然后獲得服務器的登錄權限，之后才能登錄到機器上執行各種測試操作，最終分析數據得到測量結果。顯然，這種人工測量的方式可擴展性很差，無法應對大規模測量的需求。因此，需要一個平臺能夠 實時地、自動地 執行測量任務，給出分析結果。 那么，這個平臺需要滿足什么要求呢? 通過對業務線運維工程師和網絡工程師進行調研，整理的需求如下： 1）“端到端”的持續監測 由于百度業務線的程序或模塊均部署在服務器上，其網絡通信也都是從服務器發起和接收，所以服務器“端到端”的網絡質量更能反應內網狀況對業務通信的實際影響。所以從業務角度出發，平臺應當能夠對端到端網絡質量進行持續監測。 2）全覆蓋的監測 實際中，運維工程師通常知道業務部署在哪些機房，但不清楚具體哪些機器間有網絡通信，所以會關注 “這些機房網絡是否正?！边@種全局性的問題。此外，網絡工程師的責任是保證整個內網質量可靠，需要系統地監測整個內網性能，盡可能地發現和修復網絡故障，減少隱患。 3）按需下發監測任務 實際工作中常常需要根據現場情況執行特定的監測任務，這導致需要進行額外的、有針對性的測量。所以，監測平臺還需支持按需監測。 4）檢測結果主動報警 由于網絡工程師直接對內網質量負責，因此希望監測平臺在測量”端到端”通信性能后，對相關數據進行分析，判斷網絡是否正常，并在檢測到網絡異常后及時發送報警，以保證各業務線服務正常。 5）針對產品業務的定制化展示 由于一個產品業務通常只部署在部分機房，依賴部分網絡，所以運維工程師往往不關注非其負責的。因此，監測系統需要支持定制化展示，使運維工程師能迅速獲取其需要關注的網絡狀態信息。 那么，百度現有的內網監測技術能否滿足以上需求呢？ 現有監測技術 其實，百度內部已經應用了一些內網質量監測技術，這些技術利用不同的測量手段獲取內網質量數據，并加以分析，進而判斷網絡是否正常。表1給出了三種現有監測技術的相關信息。 編號 監控原理 不足 技術1 利用交換機的 Syslog 監測交換機級別故障　 交換機級別故障無法準確反映業務所感知的網絡性能 Syslog無法記錄所有交換機故障 無法檢測非交換機故障類網絡異常 技術2 部署專用的服務器 探針 來連接各IDC核心交換機，服務器通過互相發包對IDC間網絡性能進行主動探測 IDC內部網絡通信監控缺失 探測到的IDC間網絡性能和業務感受到的網絡性能有所差別 資源開銷大，不能直接擴展 技術3 在所有線上服務器部署探針，并在各IDC分別設置一個 靶標服務器 ，讓所有線上服務器測量到各靶標服務器的網絡狀態 單個靶標服務器存在單點故障問題，不能很好代表機房的網絡情況 機房內部的拓撲覆蓋不全 不支持按需探測功能 上述幾種技術在內網質量監測和運維中發揮了一定作用，但在使用過程中也發現了一些不足，不能很好滿足上述需求。因此，基于以上技術的實戰經驗，我們開發了新平臺 NetRadar （網絡雷達）。與以上監測技術相比， NetRadar 具有以下優點： 覆蓋廣 ： 探測agent在全網linux服務器完成部署，覆蓋了百度全部內網機房； 多層級 ： 7*24小時持續監測整個內網的網絡質量，包括機房間、機房內集群間、集群內ToR交換機間的網絡質量； 指標全 ： 評價網絡質量的方式多樣，區分QOS隊列、協議、統計值，共計27種網絡質量監控指標，每個探測周期會產生近百萬的監控指標； 檢測準 ： 通過自適應異常檢測算法對監控指標進行檢測，并進一步生成機房、區域級別的網絡事件； 除此之外， NetRadar 還支持按需探測，并提供全內網“端到端”探測接口以及故障事件接口，以幫助工程師快速診斷網絡問題。 總結 相信通過本文的介紹，您已經對百度內網質量監測有了一些了解。接下來，我們將推出本系列文章的下篇：《百度網絡監控實戰： NetRadar 橫空出世（下）》，系統性地介紹 NetRadar 平臺，請持續關注AIOps智能運維！ 若您有其他疑問或者想進一步了解 NetRadar 平臺，歡迎留言反饋！ 智能運維時代，AIOps智能運維與您同行！ 原文鏈接地址： https://developer.baidu.com/topic/show/290301

本文作者：AIOps智能運維 作者簡介 運小皮 百度資深運維工程師 負責百度智能運維平臺的設計和實施。曾負責網頁搜索、移動搜索產品運維和服務高可用、持續部署等技術方向。 干貨概覽 在本系列的上一篇文章《百度自動化運維的演進（一）：聊聊百度自動化運維》中，百度運維部元老級高工運小皮介紹了他眼中的自動化運維以及百度的自動化運維標準。在本篇文章中運小皮將詳細介紹百度三代運維平臺，百度運維平臺從web化走向開放，最終達到智能的過程。 百度自動化運維標準中能力等級與能力描述對應關系如下： L0--人工（無自動化） L1--工具輔助的自動化 L2：部分自動化 L3：有條件的自動化 L4：高度自動化 L5：完全自動化 2008年以前 無運維平臺 這段期間，是分散的團隊、小組各自為政的時期。開源、自研方案不一，抽象層次不一，自動化層次也不一，可以認為大多數在 L1，部分還依然完全靠人肉（L0），少量已經踏進了 L2。 2008-2011年 第一代運維平臺，Web化 2008 立項開發的第一代運維管理平臺（嗯，這就是很多友商經常提起的 Noah 平臺），標志著百度自動化運維全面邁向 L2。這期間我們的主要工作是研發一個統一的運維平臺來代替人工執行一系列運維工作，包括資源的管理（增刪改）、服務運行狀態的采集、服務變更操作等等。 服務樹：資源、機器管理 由運維人員管理的資源有哪些？歸根到底是三類： 軟件、硬件 和 人 ；具體講主要就是 服務、機器 和 權限 。 2008年，我們第一次以服務為中心來進行組織和管理資源，也即“ 服務樹 ”： 首先，通過“公司/部門/產品線”這類客觀存在的管理范圍，自頂向下地定義樹形結構，并且允許通過自定義子樹節點的方式來擴展管理多個服務； 其次，機器掛載到服務樹的葉子節點上，這樣就可以通過服務及其從屬關系來管理大量的機器； 最后，將人員歸屬到一系列角色權限中，并以服務樹來定義其作用域。 在統一到服務樹這個模型之前，雖然已經有諸多解決方案和工具了，無論形式上到底是命令行還是一些開源平臺，但究其本質上都是通過數組結構來管理若干個機器列表。 樹形結構 在表達歸屬、層級、繼承等關系上的優勢，大大方便了其他運維系統組件的設計和實現。 監控：標準化采集 基于服務樹提供的具有層次和繼承關系的機器管理方案， 監控系統 就方便多了：只要專注于服務狀態的 采集 、 呈現 和 報警策略 即可。 第一代監控系統包含 機器監控 和 服務監控 兩大類。機器監控全覆蓋地采集機器的基本信息，包括各類硬件資源的使用情況（cpu、內存、磁盤 io、網絡帶寬等）。服務監控以 探針 （probe）的方式檢測服務的健康狀態。 探針 支持不同的協議和方式（HTTP、Socket），并且定義了最簡單的自定義數據采集協議（基于 Bash 命令行）。 隨著產品服務的迭代，對服務的運行狀態需要更精細的掌控，第二代監控系統應運而生。 監控功能不斷拓展，增加了 進程級 的資源數據采集、基于 日志匹配 的業務指標統計監控、 報警的匯聚與合并 。與此同時，我們也在實踐過程中提煉同類服務間的共同點，提出了第一版的監控規范，賦予數據特定的運維語義（ 存活性 、 資 源消耗 、 業務功能 等等）。 上線系統：自動化部署 Noah 上線（又稱 Noah web 上線、 ad-web 上線）系統是第一代的自動化部署系統，其核心設計目標是，實現一個通用的平臺來替代運維工程師在上線時的手工操作；所以其基本設計思想是 翻譯 上線步驟（備份、下載、替換、重啟等文字描述）為一系列標準的操作命令（wget、cp、mv、restart 等）。 2011-2014年 第二代運維平臺，開放 隨著業務規模的擴張，集群規模也在指數型增長，統一的、Web 化的運維平臺也遭遇了瓶頸： 眾口難調：和業務特點相關的需求越來越離散（有的重效率，有的看重流程的完備性，有的對易用性要求高）再加上需求方越來越多，功能交付排隊積壓嚴重。 性能差：極端情況下，需要提交一個 K 量級機器的操作，平臺響應長達數分鐘，甚至還有比較高的錯誤率。 于是，這段時間，我們增強了運維系統的架構能力，使其可以更方便定制和集成，為全面進化到 L3 級自動化做好了準備，且在變更領域開始向 L3 邁進。 BNS：一種更簡單、高效的服務發現和管理方案 服務樹 的路徑，和文件的絕對路徑一樣，理論上可以作為服務的一個全局、權威的名字，但因為其路徑中耦合了組織和管理上的信息，導致這部分的變化帶來的協同修改成本非常高，于是 BNS（Baidu Naming Service）應運而生。 BNS 參考 DNS 的解決方案，類似域名。服務名包含如下兩大部分 DNS 的解決方案，類似域名。服務名包含如下兩大部分： 名字空間只包含兩類和服務管理緊密相關的信息，即服務的物理部署（機房）和業務歸屬（產品線） 在名字空間下只需要保持名字唯一即可 這個名字可以穩定、一致地被用于各個系統之間交換服務實例列表（類似 IP 列表）。 除此之外，它也可以掛載到服務樹上，繼續滿足組織、行政、權限等管理需求，同時這也保持了和服務樹原有模型的向前兼容。 進一步，隨著 實例標簽 （Tag）的支持，我們可以以多維度視圖的方式來管理服務，終于打破了樹形結構的摯肘。 監控3.0 Argus：高性能、靈活定制的監控解決方案 第三代監控系統 ，基于先前在監控數據應用場景的經驗，抽象出來 多維度時序數據 的模型，設計和實現了相應的存儲架構（時序數據庫 TSDB）、 計算架構 （多維度流式聚合計算），打開了運維數據分析的新篇章。 與此同時，為了方便集成，監控采集方式更加靈活（采集接口、數據庫直推等），監控配置規則也徹底 DSL 化 ，使監控的設計可以和開發編碼階段的工作流相結合。 大量的數據，帶來了大量的輔助分析工具和數據可視化需求，運維平臺和業務運維同學緊密配合，合作研發定制化的監控平臺實踐逐漸成熟。 一鍵上線Archer：持續部署的瑞士軍刀 由于 Noah web 上線只維護當次上線涉及什么文件、什么命令，是典型的“增量”模式，只能看到局部的 diff，不利于服務生命周期內更多場景下的自動化工作開展，諸如：服務遷移、故障處理、測試調研實驗等同源環境搭建等。 所以在 2011 年我們推出了它的繼任者， Archer 上線，其基本設計原則，來源于當時業界的“ 持續集成/交付 ”和“ DevOps ”思潮：將決定服務運行邏輯的所有代碼、配置、數據、運維接口等信息進行同源（倉庫）管理并全量發布，基于此簡化部署系統的內部設計實現復雜度、提高了二次開發的靈活度，促進了整個構建、測試、上線流水線的自動化。 2014年-當前 第三代運維平臺，智能 2014 年是百度智能運維元年，自此之后，異常檢測、多維度分析、關聯推導等算法策略逐漸應用，感知、決策、執行的工程框架逐漸定型。我們迎來了 L3 自動化的大規模實施，并開始邁向 L4。 總結 從2008年以前至今，百度運維平臺經歷了web化、開放、智能三次重大變革，期間百度運維部研發了服務樹、監控系統、Noah web上線、BNS、監控3.0 Argus、Archer等系統，助力百度運維逐步走向智能化。 接下來，我們將詳細介紹百度運維平臺中的各個系統，請持續關注AIOps智能運維！ 若您有其他疑問或者想進一步了解百度自動化運維，歡迎留言反饋！ 原文鏈接地址： https://developer.baidu.com/topic/show/290300

本文作者：HelloDeveloper 大型網站的 HTTPS 實踐（一）-- HTTPS 協議和原理 前言 百度已經于近日上線了全站 HTTPS 的安全搜索，默認會將 HTTP 請求跳轉成 HTTPS。本文重點介紹 HTTPS 協議 ,并簡單介紹部署全站 HTTPS 的意義。 HTTPS 協議概述 HTTPS 可以認為是 HTTP + TLS。HTTP 協議大家耳熟能詳了，目前大部分 WEB 應用和網站都是使用 HTTP 協議傳輸的。 TLS 是傳輸層加密協議，它的前身是 SSL 協議，最早由 netscape 公司于 1995 年發布，1999 年經過 IETF 討論和規范后，改名為 TLS。如果沒有特別說明，SSL 和 TLS 說的都是同一個協議。 HTTP 和 TLS 在協議層的位置以及 TLS 協議的組成如下圖： TLS 協議主要有五部分：應用數據層協議，握手協議，報警協議，加密消息確認協議，心跳協議。 TLS 協議本身又是由 record 協議傳輸的，record 協議的格式如上圖最右所示。 目前常用的 HTTP 協議是 HTTP1.1，常用的 TLS 協議版本有如下幾個：TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻擊已經被證明不安全，但統計發現依然有不到 1% 的瀏覽器使用 SSL3.0。TLS1.0 也存在部分安全漏洞，比如 RC4 和 BEAST 攻擊。TLS1.2 和 TLS1.1 暫時沒有已知的安全漏洞，比較安全，同時有大量擴展提升速度和性能，推薦大家使用。 需要關注一點的就是 TLS1.3 將會是 TLS 協議一個非常重大的改革。不管是安全性還是用戶訪問速度都會有質的提升。不過目前沒有明確的發布時間。 HTTPS 功能介紹 百度使用 HTTPS 協議主要是為了保護用戶隱私，防止流量劫持。HTTP 本身是明文傳輸的，沒有經過任何安全處理。例如用戶在百度搜索了一個關鍵字，比如 “蘋果手機”，中間者完全能夠查看到這個信息，并且有可能打電話過來騷擾用戶。也有一些用戶投訴使用百度時，發現首頁或者結果頁面浮了一個很長很大的廣告，這也肯定是中間者往頁面插的廣告內容。如果劫持技術比較低劣的話，用戶甚至無法訪問百度。 這里提到的中間者主要指一些網絡節點，是用戶數據在瀏覽器和百度服務器中間傳輸必須要經過的節點。比如 WIFI 熱點，路由器，防火墻，反向代理，緩存服務器等。 在 HTTP 協議下，中間者可以隨意嗅探用戶搜索內容，竊取隱私甚至篡改網頁。不過 HTTPS 是這些劫持行為的克星，能夠完全有效地防御?？傮w來說，HTTPS 協議提供了三個強大的功能來對抗上述的劫持行為： 內容加密。瀏覽器到百度服務器的內容都是以加密形式傳輸，中間者無法直接查看原始內容。 身份認證。保證用戶訪問的是百度服務，即使被 DNS 劫持到了第三方站點，也會提醒用戶沒有訪問百度服務，有可能被劫持 數據完整性。防止內容被第三方冒充或者篡改。 那 HTTPS 是如何做到上述三點的呢？下面從原理角度介紹一下。 HTTPS 原理介紹 內容加密 加密算法一般分為兩種，對稱加密和非對稱加密。所謂對稱加密（也叫密鑰加密）就是指加密和解密使用的是相同的密鑰。而非對稱加密（也叫公鑰加密）就是指加密和解密使用了不同的密鑰。 非對稱密鑰交換 在非對稱密鑰交換算法出現以前，對稱加密一個很大的問題就是不知道如何安全生成和保管密鑰。非對稱密鑰交換過程主要就是為了解決這個問題，使得對稱密鑰的生成和使用更加安全。 密鑰交換算法本身非常復雜，密鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等操作。 常見的密鑰交換算法有 RSA，ECDHE，DH，DHE 等算法。它們的特性如下： RSA：算法實現簡單，誕生于 1977 年，歷史悠久，經過了長時間的破解測試，安全性高。缺點就是需要比較大的素數（目前常用的是 2048 位）來保證安全強度，很消耗 CPU 運算資源。RSA 是目前唯一一個既能用于密鑰交換又能用于證書簽名的算法。 DH：diffie-hellman 密鑰交換算法，誕生時間比較早（1977 年），但是 1999 年才公開。缺點是比較消耗 CPU 性能。 ECDHE：使用橢圓曲線（ECC）的 DH 算法，優點是能用較小的素數（256 位）實現 RSA 相同的安全等級。缺點是算法實現復雜，用于密鑰交換的歷史不長，沒有經過長時間的安全攻擊測試。 ECDH：不支持 PFS，安全性低，同時無法實現 false start。 DHE：不支持 ECC。非常消耗性能。 百度只支持 RSA 和 ECDH_RSA 密鑰交換算法。原因是： ECDHE 支持 ECC 加速，計算速度更快。支持 PFS，更加安全。支持 false start，用戶訪問速度更快。 目前還有至少 20% 以上的客戶端不支持 ECDHE，我們推薦使用 RSA 而不是 DH 或者 DHE，因為 DH 系列算法非常消耗 CPU（相當于要做兩次 RSA 計算）。 需要注意通常所說的 ECDHE 密鑰交換默認都是指 ECDHE_RSA，使用 ECDHE 生成 DH 算法所需的公私鑰，然后使用 RSA 算法進行簽名最后再計算得出對稱密鑰。 非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點： CPU 計算資源消耗非常大。一次完全 TLS 握手，密鑰交換時的非對稱解密計算量占整個握手過程的 90% 以上。而對稱加密的計算量只相當于非對稱加密的 0.1%，如果應用層數據也使用非對稱加解密，性能開銷太大，無法承受。 非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是 2048 位，意味著待加密內容不能超過 256 個字節。 所以公鑰加密目前只能用來作密鑰交換或者內容簽名，不適合用來做應用層傳輸內容的加解密。 非對稱密鑰交換算法是整個 HTTPS 得以安全的基石，充分理解非對稱密鑰交換算法是理解 HTTPS 協議和功能的關鍵。 下面分別通俗地介紹一下 RSA 和 ECDHE 在密鑰交換過程中的應用。 RSA 在密鑰交換過程中的應用 RSA 算法的原理是乘法不可逆或者大數因子很難分解。RSA 的推導實現涉及到了歐拉函數和費馬定理及模反元素的概念，有興趣的讀者可以自行百度。 RSA 算法是統治世界的最重要算法之一，而且從目前來看，RSA 也是 HTTPS 體系中最重要的算法，沒有之一。 下面用一個簡單的示例介紹一下 RSA 的神奇妙用。 假設一個網站需要使用 HTTPS 協議，那么它首先就得申請數字證書，申請證書之前需要生成一對公鑰和私鑰，為了方便說明問題，假設 server 的密鑰長度只有 8 位，事實上現在的服務器證書至少是 2048 位長。 隨機挑選兩個質數 p, q，使得 p q 接近 2 的 8 次方 = 256， 假設 p = 13, q = 19。n = p q = 13*19 = 247。 挑選一個數 e，滿足 1< e < (p-1) (q-1) 并且 e 與 (p-1) (q-1) 互質，假設 e = 53。 計算 e 關于 n 的模反元素 , ed≡1 (mod φ(n))， d = 實際應用中，(n,e) 組成了公鑰對，（n,d）組成了私鑰對。公鑰一般都注冊到了證書里，任何人都能直接查看，比如百度證書的公鑰對如下圖，其中最末 6 個數字（010001）換算成 10 進制就是 65537，也就是公鑰對中的 e, 取值比較小的原因有兩個： 減小 client 端的計算強度，特別是現在移動終端的計算能力比較弱，較小的公鑰使得 CPU 計算會更快。 加大 server 端的破解難度。e 比較小，d 必然會非常大。所以 d 的取值空間也會非常大。 ECDHE 算法在密鑰交換中的應用 ECDHE 算法實現要復雜很多，依賴的數學原理主要是 ECC 橢圓曲線和離散對數。詳細概念不做說明，示例介紹一下。 對稱內容加密 非對稱密鑰交換過程結束之后就得出了本次會話需要使用的對稱密鑰。對稱加密又分為兩種模式：流式加密和分組加密。流式加密現在常用的就是 RC4，不過 RC4 已經不再安全，微軟也建議網站盡量不要使用 RC4 流式加密。 一種新的替代 RC4 的流式加密算法叫 ChaCha20，它是 google 推出的速度更快，更安全的加密算法。目前已經被 android 和 chrome 采用，也編譯進了 google 的開源 openssl 分支---boring ssl，并且 nginx 1.7.4 也支持編譯 boringssl。 分組加密以前常用的模式是 AES-CBC，但是 CBC 已經被證明容易遭受 BEAST 和 LUCKY13 攻擊。目前建議使用的分組加密模式是 AES-GCM，不過它的缺點是計算量大，性能和電量消耗都比較高，不適用于移動電話和平板電腦。 數據完整性 這部分內容比較好理解，跟平時的 md5 簽名類似，只不過安全要求要高很多。openssl 現在使用的完整性校驗算法有兩種：MD5 或者 SHA。由于 MD5 在實際應用中存在沖突的可能性比較大，所以盡量別采用 MD5 來驗證內容一致性。SHA 也不能使用 SHA0 和 SHA1，中國山東大學的王小云教授在 2005 年就宣布破解了 SHA-1 完整版算法。微軟和 google 都已經宣布 16 年及 17 年之后不再支持 sha1 簽名證書。 身份認證 身份認證主要涉及到 PKI 和數字證書。數字證書有兩個作用： 身份授權。確保瀏覽器訪問的網站是經過 CA 驗證的可信任的網站。 分發公鑰。每個數字證書都包含了注冊者生成的公鑰。在 SSL 握手時會通過 certificate 消息傳輸給客戶端。 這里簡單介紹一下數字證書是如何驗證網站身份的，PKI 體系的具體知識不做詳細介紹。 證書申請者首先會生成一對密鑰，包含公鑰和密鑰，然后把公鑰及域名還有 CU 等資料制作成 CSR 格式的請求發送給 RA，RA 驗證完這些內容之后（RA 會請獨立的第三方機構和律師團隊確認申請者的身份）再將 CSR 發送給 CA，CA 然后制作 X.509 格式的證書。 申請者拿到 CA 的證書并部署在網站服務器端，那瀏覽器發起握手接收到證書后，如何確認這個證書就是 CA 簽發的呢？怎樣避免第三方偽造這個證書？ 答案就是數字簽名（digital signature）。數字簽名可以認為是一個證書的防偽標簽，目前使用最廣泛的 SHA-RSA 數字簽名的制作和驗證過程如下： 數字簽名的簽發。首先是使用哈希函數對證書數據哈希，生成消息摘要，然后使用 CA 自己的私鑰對證書內容和消息摘要進行加密。 數字簽名的校驗。使用 CA 的公鑰解密簽名，然后使用相同的簽名函數對證書內容進行簽名并和服務端的數字簽名里的簽名內容進行比較，如果相同就認為校驗成功。 這里有幾點需要說明： 數字簽名簽發和校驗使用的密鑰對是 CA 自己的公私密鑰，跟證書申請者提交的公鑰沒有關系。 數字簽名的簽發過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。 現在大的 CA 都會有證書鏈，證書鏈的好處一是安全，保持根 CA 的私鑰離線使用。第二個好處是方便部署和撤銷，即如何證書出現問題，只需要撤銷相應級別的證書，根證書依然安全。 根 CA 證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗證。而證書鏈上的證書簽名都是使用上一級證書的密鑰對完成簽名和驗證的。 怎樣獲取根 CA 和多級 CA 的密鑰對？它們是否可信？當然可信，因為這些廠商跟瀏覽器和操作系統都有合作，它們的公鑰都默認裝到了瀏覽器或者操作系統環境里。比如 firefox 就自己維護了一個可信任的 CA 列表，而 chrome 和 IE 使用的是操作系統的 CA 列表。 HTTPS 使用成本 HTTPS 目前唯一的問題就是它還沒有得到大規模應用，受到的關注和研究都比較少。至于使用成本和額外開銷，完全不用太過擔心。 一般來講，使用 HTTPS 前大家可能會非常關注如下問題： 證書費用以及更新維護。大家覺得申請證書很麻煩，證書也很貴，可是證書其實一點都不貴，便宜的一年幾十塊錢，最多也就幾百。而且現在也有了免費的證書機構，比如著名的 mozilla 發起的免費證書項目： let’s encrypt 就支持免費證書安裝和自動更新。這個項目將于今年中旬投入正式使用。 數字證書的費用其實也不高，對于中小網站可以使用便宜甚至免費的數字證書服務（可能存在安全隱患），像著名的 verisign 公司的證書一般也就幾千到幾萬塊一年不等。當然如果公司對證書的需求比較大，定制性要求高，可以建立自己的 CA 站點，比如 google，能夠隨意簽發 google 相關證書。 HTTPS 降低用戶訪問速度。HTTPS 對速度會有一定程度的降低，但是只要經過合理優化和部署，HTTPS 對速度的影響完全可以接受。在很多場景下，HTTPS 速度完全不遜于 HTTP，如果使用 SPDY，HTTPS 的速度甚至還要比 HTTP 快。 大家現在使用百度 HTTPS 安全搜索，有感覺到慢嗎？ HTTPS 消耗 CPU 資源，需要增加大量機器。前面介紹過非對稱密鑰交換，這是消耗 CPU 計算資源的大戶，此外，對稱加解密，也需要 CPU 的計算。 同樣地，只要合理優化，HTTPS 的機器成本也不會明顯增加。對于中小網站，完全不需要增加機器也能滿足性能需求。 后記 國外的大型互聯網公司很多已經啟用了全站 HTTPS，這也是未來互聯網的趨勢。國內的大型互聯網并沒有全站部署 HTTPS，只是在一些涉及賬戶或者交易的子頁面 / 子請求上啟用了 HTTPS。百度搜索首次全站部署 HTTPS，對國內互聯網的全站 HTTPS 進程必將有著巨大的推動作用。 目前互聯網上關于 HTTPS 的中文資料比較少，本文就著重介紹了 HTTPS 協議涉及到的重要知識點和平時不太容易理解的盲區，希望能對大家理解 HTTPS 協議有幫助。百度 HTTPS 性能優化涉及到大量內容，從前端頁面、后端架構、協議特性、加密算法、流量調度、架構和運維、安全等方面都做了大量工作。本系列的文章將一一進行介紹。 原文鏈接地址： https://developer.baidu.com/topic/show/290299

作者 | 阿里云售后技術專家?聲東 導讀 ：當我們嘗試去理解 K8s 集群工作原理的時候，控制器（Controller）肯定是一個難點。這是因為控制器有很多，具體實現大相徑庭；且控制器的實現用到了一些較為晦澀的機制，不易理解。但是，我們又不能繞過控制器，因為它是集群的“大腦”。今天這篇文章，作者通過分析一個簡易冰箱的設計過程，來幫助讀者深入理解集群控制器的產生，功能以及實現方法。 K8s 集群核心組件大圖 下圖是 K8s 集群的核心組件，包括數據庫 etcd，調度器 Scheduler，集群入口 API Server，控制器 Controller，服務代理 kube-proxy 以及直接管理具體業務容器的 kubelet。 這些組件邏輯上可以被分為三個部分： 核心組件 etc 數據庫； 對 etcd 進行直接操作的入口組件 API Server； 其他組件, 這里的“其他組件”之所以可以被劃分為一類，是因為它們都可以被看做是集群的控制器。 今天我們要講的就是集群控制器原理。 控制器原理 雖然控制器是 K8s 集群中比較復雜的組件，但控制器本身對我們來說并不陌生的。我們每天使用的洗衣機、冰箱、空調等，都是依靠控制器才能正常工作。在控制器原理這一節，我們通過思考一個簡易冰箱的設計過程，來理解 K8s 集群控制器的原理。 簡易的冰箱 這個冰箱包括五個組件：箱體、制冷系統、照明系統、溫控器以及門。 冰箱只有兩個功能： 當有人打開冰箱門的時候，冰箱內的燈會自動開啟； 當有人按下溫控器的時候，制冷系統會根據溫度設置，調節冰箱內溫度。 統一入口 對于上邊的冰箱，我們可以簡單抽象成兩個部分：統一的操作入口和冰箱的所有組件。 在這里，用戶只有通過入口，才能操作冰箱。這個入口提供給用戶兩個接口：開關門和調節溫控器。用戶執行這兩個接口的時候，入口會分別調整冰箱門和溫控器的狀態。 但是這里有一個問題，就是用戶通過這兩個接口，既不能讓冰箱內部的燈打開，也不能調節冰箱的溫度。 控制器 控制器就是為了解決上邊的問題產生的?？刂破骶褪怯脩舻牟僮?，和冰箱各個組件的正確狀態之間的一座橋梁： 當用戶打開門的時候，控制器觀察到了門的變化，它替用戶打開冰箱內的燈； 當用戶按下溫控器的時候，控制器觀察到了用戶設置的溫度，它替用戶管理制冷系統，調節冰箱內溫度。 控制器管理器 冰箱有照明系統和制冷系統，顯然相比一個控制器管理著兩個組件，我們替每個組件分別實現一個控制器是更為合理的選擇。同時我們實現一個控制器管理器來統一維護所有這些控制器，來保證這些控制器在正常工作。 SharedInformer 上邊的控制器和控制器管理器，看起來已經相當不錯了。但是當冰箱功能增加，勢必有很多新的控制器加進來。這些控制器都需要通過冰箱入口，時刻監控自己關心的組件的狀態變化。比如照明系統控制器就需要時刻監控冰箱門的狀態。當大量控制器不斷的和入口通信的時候，就會增加入口的壓力。 這個時候，我們把監控冰箱組件狀態變化這件事情，交給一個新的模塊 SharedInformer 來實現。 SharedInformer 作為控制器的代理，替控制器監控冰箱組件的狀態變化，并根據控制器的喜好，把不同組件狀態的變化，通知給對應的控制器。通過優化，這樣的 SharedInformer 可以極大的緩解冰箱入口的壓力。 ListWatcher SharedInformer 方便了控制器對冰箱組件的監控，而這個機制最核心的功能，當然是主動獲取組件狀態和被動接收組件狀態變化的通知。這兩個功能加起來，就是 ListWatcher。 假設 SharedInformer 和冰箱入口通過 http 協議通信的話，那么 http 分塊編碼（chunked transfer encoding）就是實現 ListWatcher 的一個好的選擇?？刂破魍ㄟ^ ListWatcher 給冰箱入口發送一個查詢然后等待，當冰箱組件有變化的時候，入口通過分塊的 http 響應通知控制器?？刂破骺吹?chunked 響應，會認為響應數據還沒有發送完成，所以會持續等待。 舉例說明 以上我們從一個簡易冰箱的進化過程中，了解了控制器產生的意義，扮演的角色，以及實現的方式?，F在我們回到K8s 集群。K8s 集群實現了大量的控制器，而且在可以預見的未來，新的功能的控制器會不斷出現，而一些舊的控制器也會被逐漸淘汰。 目前來說，我們比較常用的控制器，如 Pod 控制器、Deployment 控制器、Service 控制器、Replicaset 控制器等。這些控制器一部分是由 kube controller manager 這個管理器實現和管理，而像 route 控制器和 service 控制器，則由 cloud controller manager 實現。 之所以會出現 cloud controller manager，是因為在不同的云環境中，一部分控制器的實現，會因為云廠商、云環境的不同，出現很大的差別。這類控制器被劃分出來，由云廠商各自基于 cloud controller manager 分別實現。 這里我們以阿里云 K8s 集群 cloud controller manager 實現的 route? 控制器和 service 控制器為例，簡單說明 K8s 控制器的工作原理。 服務控制器 首先，用戶請求 API Server 創建一個 LoadBalancer 類型的服務，API Server 收到請求并把這個服務的詳細信息寫入 etcd 數據庫。而這個變化，被服務控制器觀察到了。服務控制器理解 LoadBalancer 類型的服務，除了包括存放在 etcd 內部的服務記錄之外，還需要一個 SLB 作為服務入口，以及若干 endpoints 作為服務后端。所以服務控制器分別請求 SLB 的云 openapi 和 API Server，來創建云上 SLB 資源，和集群內 endpoints 資源。 路由控制器 在集群網絡一章中，我們提到過，當一個節點加入一個 K8s 集群的時候，集群需要在 VPC 路由表里增加一條路由，來搭建這個新加入節點到 Pod 網絡的主干道。而這件事情，就是路由控制器來做的。路由控制器完成這件事情的流程，與上邊服務控制器的處理流程非常類似，這里不再贅述。 結束語 基本上來說，K8s 集群的控制器，其實扮演著集群大腦的角色。有了控制器，K8s 集群才有機會擺脫機械和被動，變成一個自動、智能、有大用的系統。

Kubernetes 1.18.0已經正式發布，對于高可用集群也可以直接升級?？焖偕墸ê瑖鴥如R像快速下載鏈接）包括升級kubeadm/kubectl/kubelet版本、拉取鏡像、升級Kubernetes集群三個主要步驟。參考《 Ubuntu上軟件鎖定版本不更新 》安裝特定DockerCE版本。 kubeadm upgrade apply v1.18.0 1、升級kubeadm/kubectl/kubelet版本 sudo apt install kubeadm=1.18.0-00 kubectl=1.18.0-00 kubelet=1.18.0-00 設置中國區的軟件源，參考： kubernetes for china 查看該版本的容器鏡像版本： kubeadm config images list 輸出如下： ~ # kubeadm config images list k8s.gcr.io/kube-apiserver:v1.18.0 k8s.gcr.io/kube-controller-manager:v1.18.0 k8s.gcr.io/kube-scheduler:v1.18.0 k8s.gcr.io/kube-proxy:v1.18.0 k8s.gcr.io/pause:3.2 k8s.gcr.io/etcd:3.4.3-0 k8s.gcr.io/coredns:1.6.7 2、拉取容器鏡像 原始的kubernetes鏡像文件在gcr上，不能直接下載。我給鏡像到了阿里云的杭州機房的容器倉庫里，拉取還是比較快的。 echo "" echo "==========================================================" echo "Pull Kubernetes v1.18.0 Images from aliyuncs.com ......" echo "==========================================================" echo "" MY_REGISTRY=registry.cn-hangzhou.aliyuncs.com/openthings ## 拉取鏡像 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-apiserver:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-controller-manager:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-scheduler:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-kube-proxy:v1.18.0 docker pull ${MY_REGISTRY} /k8s-gcr-io-etcd:3.4.3-0 docker pull ${MY_REGISTRY} /k8s-gcr-io-pause:3.2 docker pull ${MY_REGISTRY} /k8s-gcr-io-coredns:1.6.7 ## 添加Tag docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-apiserver:v1.18.0 k8s.gcr.io/kube-apiserver:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-scheduler:v1.18.0 k8s.gcr.io/kube-scheduler:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-controller-manager:v1.18.0 k8s.gcr.io/kube-controller-manager:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-kube-proxy:v1.18.0 k8s.gcr.io/kube-proxy:v1.18.0 docker tag ${MY_REGISTRY} /k8s-gcr-io-etcd:3.4.3-0 k8s.gcr.io/etcd:3.4.3-0 docker tag ${MY_REGISTRY} /k8s-gcr-io-pause:3.2 k8s.gcr.io/pause:3.2 docker tag ${MY_REGISTRY} /k8s-gcr-io-coredns:1.6.7 k8s.gcr.io/coredns:1.6.7 echo "" echo "==========================================================" echo "Pull Kubernetes v1.18.0 Images FINISHED." echo "into registry.cn-hangzhou.aliyuncs.com/openthings, " echo " by openthings@https://my.oschina.net/u/2306127." echo "==========================================================" echo "" 保存為shell腳本，然后執行。 或者，下載腳本： https://github.com/openthings/kubernetes-tools/blob/master/kubeadm/2-images/ 3、升級Kubernetes集群 全新安裝： #指定IP地址，1.18.0版本： sudo kubeadm init --kubernetes-version=v1. 18 . 0 --apiserver-advertise-address= 10.1.1.199 --pod-network-cidr= 10.244.0.0 / 16 使用kubeadm部署高可用Kubernetes 1.17.0 先查看一下需要升級的各個組件的版本。 使用 kubeadm upgrade plan ，輸出的版本升級信息如下： Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply' : COMPONENT CURRENT AVAILABLE Kubelet 1 x v1 .17 .2 v1 .18 .0 8 x v1 .17 .2 v1 .18 .0 Upgrade to the latest version in the v1 .18 series: COMPONENT CURRENT AVAILABLE API Server v1 .17 .2 v1 .18 .0 Controller Manager v1 .17 .2 v1 .18 .0 Scheduler v1 .17 .2 v1 .18 .0 Kube Proxy v1 .17 .2 v1 .18 .0 CoreDNS 1.6 .5 1.6 .7 Etcd 3.4 .3 3.4 .3 -0 You can now apply the upgrade by executing the following command: kubeadm upgrade apply v1 .18 .0 確保上面的容器鏡像已經下載（如果沒有提前下載，可能被網絡阻隔導致掛起），然后執行升級： kubeadm upgrade apply v1 .18 .0 看到下面信息，就OK了。 [upgrade/successful] SUCCESS ! Your cluster was upgraded to " v1 .18 .0 ". Enjoy ! 然后，配置當前用戶環境： mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config 就可以使用 kubectl version 來查看狀態和 kubectl cluster-info 查看服務地址。 4、工作節點的升級 每個工作節點需要拉取上面對應版本的鏡像，以及安裝kubelet的對應版本。 檢查版本： ~$ kubectl version 查看Pod信息： kubectl get pod --all-namespaces 完成。 ??注意：1.17后版本，如果使用kubeadm安裝為高可用模式，所有master節點都可以被升為最新版本（需要提前把k8s的容器鏡像放到節點上去）。 更多參考： Kubernetes 1.17.4快速升級 Kubernetes 1.17.2快速升級 Kubernetes 1.17.1快速升級 Kubernetes 1.17.0 已發布 使用kubeadm部署高可用Kubernetes 1.17.0 Kubernetes 1.17.0管理界面Dashboard 2 設置Kubernetes的Master節點運行應用pod Kubernetes pod中systemctl狀態探針失敗問題 運用Jupyter Notebook進行系統管理 將Jupyter/JupyterHub/JupyterLab運行為系統服務 快速設置JupyterHub for K8s 在JupyterHub for K8s使用GlusterFS存儲

本文作者：o****0 英偉達稱稍后會放出一個使用 AI 模型 GameGAN 復刻的《吃豆人》游戲，以致敬誕生40周年的街機版《吃豆人》。 根據英偉達發布的研究報告，GameGAN 目標是用神經網絡取代游戲引擎。 它不同于以往用 AI 做游戲的例子。之前的谷歌 DeepMind 和 Open AI 還是在現有游戲框架中，被用來“玩游戲”，相當于是智能生成一個游戲對手。比如 OpenAI 被用來在 Dota2 5v5中對戰人類，OpenAI 2018年通過學習人類演示，在蒙特祖瑪的復仇游戲中刷出了74500分的高分。 GameGAN 則被用來“創作”游戲，是對現有游戲代碼的取代。它在訓練過程中攝入大量游戲劇本和鍵盤動作，通過觀察場景和玩家的操作動作，預測下一幀游戲畫面，而不訪問底層游戲邏輯或引擎。 “當玩家按下左鍵的時候，這個 AI 會猜測畫面的變化，并且生成一個“看起來是角色在往左走”的圖像。 中間發生的事情，全部都在 AI 的黑盒中。 沒人知道 AI 是怎么理解玩家操作的，得到的只有最終的輸出結果?！? 除了生成下一幀游戲畫面，GameGAN 還學習環境的內在動力學，“我們有興趣訓練一個游戲模擬器，它可以模擬環境的確定性和隨機性”。 GameGAN包括動力引擎；記憶模塊；渲染引擎；對抗性損失、循環損失訓練和培訓計劃。 首先GameGAN要學習環境會如何跟隨用戶操作變化而改變，這涉及一些基本的規則，比如不能穿過墻壁。同時還要通過訪問歷史，產生一致性模擬。場景中的長期一致性實現通過記憶模塊實現，GameGAN使用內存模塊，記住生成的靜態元素，如背景，并在需要的時候適當檢索。神經渲染引擎負責渲染模擬圖像。此外，對抗訓練用來完成圖像和視頻的合成任務，GameGAN用對抗性訓練學習環境動力學，并產生真實的時間相關模擬。 這次復刻《吃豆人》，主要訓練的細節包括吃豆人的速度和移動能力；鬼魂的運作方式；吃豆人吃下大力丸后的變化；鬼魂與吃豆人相遇的場景。據了解，GameGAN基于PyTorch開發，模型研發已經進行了8個月，關于復刻《吃豆人》只用了4天。 游戲開發商萬代南宮夢為此次訓練提供了總計幾百萬幀、50000集的《吃豆人》劇本。該公司的 Koichiro Tsutsumi 表示：“在看到這個結果時，我們都感到震驚，大家都無法相信可以在沒有游戲引擎的情況下再現了南夢宮的經典游戲《吃豆人》。這項研究將幫助游戲開發人員加快新關卡、角色甚至游戲的開發。一想到這一點，我們就感到十分興奮?！? 不過，復刻游戲只是開始，英偉達的目標是擴展模型來捕捉更復雜的現實世界環境。英偉達多倫多研究實驗室主任 Sanja Fidler 表示：“我們最終將訓練出一個 AI，其只需通過觀看視頻和觀察目標在環境中所采取的行動，就能模仿駕駛規則或物理定律?！?而 GameGAN 只是第一步。 Nvidia GameGAN Research： https://cdn.arstechnica.net/wp-content/uploads/2020/05/Nvidia_GameGAN_Research.pdf 原文鏈接地址： https://developer.baidu.com/topic/show/291047

導讀 ：云原生操作系統進化，詳解阿里云 ACK Pro、ASM、ACR EE、ACK @Edge 等四款企業級容器新品。 KubeCon 2020 中國站，阿里云容器服務負責人易立會在《云原生，數字經濟技術創新基石》的演講中，分享阿里云原生如何助力數字技術抗‘疫’，闡述阿里云對云原生操作系統的思考，同時詳解阿里云 ACK Pro、ASM、ACR EE、ACK @Edge 四款企業級容器新品。 容器服務 ACK Pro，為企業級大規模生產環境提供增強的可靠性安全性，以及與可賠付標準 SLA，現已開啟公測。同時還有三款產品商業化：服務網格 ASM，統一精準管控容器化微服務應用流量；容器鏡像服務企業版 ACR EE，公共云首個獨享實例形態的容器鏡像倉庫產品，是支撐阿里巴巴經濟體的雙十一同款利器，具備如下能力：多維度安全保障、全球鏡像分發加速、DevSecOps 交付提效特點，保障企業客戶云原生制品的安全托管及高效分發；邊緣容器 ACK @Edge 采用非侵入方式增強，提供邊緣自治、邊緣單元、邊緣流量管理、原生運維 API 支持等能力，以原生方式支持邊緣計算場景下的應用統一生命周期管理和統一資源調度。 疫情期間，爭分奪秒的云原生 云計算是數字時代新基建，而 2020 疫情也為數字化生活按下了快進鍵?！吧习嘤冕斸?，上學云課堂，出門健康碼，訂菜送到家”成為了日常生活一部分，這背后是一系列云計算、云原生技術支撐的業務創新。 2 小時內支撐了釘釘業務 1 萬臺云主機的擴容需求，基于阿里云服務器和容器化的應用部署方案，釘釘應用發布擴容效率大大提升，順利扛住有史以來最大的流量洪峰，為全國用戶提供線上工作的流暢體驗。 停課不停學，希沃課堂整體業務性能提升 30%、運維成本降低 50%，洋蔥學院系統資源利用率提升 60%。 健康碼基于云原生大數據平臺具備彈性、韌性和安全的特點，平穩支撐每日億次調用。 盒馬通過阿里云邊緣容器服務 ACK @Edge ，快速構建人、貨、場數字化全鏈路融合，云、邊、端一體化協同的天眼 AI 系統。結合了云原生技術體系良好的資源調度和應用管理能力，與邊緣計算就近訪問，實時處理的優勢，輕松實現全方位的**『降本提效』**，門店計算資源成本節省 50%，新店開服效率提升 70%。 云原生操作系統的誕生與進化 容器技術的發展揭開了云原生計算的序幕，在易立看來， Kubernetes 為基礎的云原生計算也已經成為新的操作系統，云原生操作系統的雛形被越來越多的行業和企業采納并因此受益：容器應用化、容器編排系統和 Istio 服務網格等技術依次解耦了應用與運行環境、資源編排調度與底層基礎設施、服務實現與服務治理等傳統架構的依賴關系。 阿里云為用戶提供了怎樣的云原生操作系統？這個云原生操作系統又有哪些突出特點呢？ 首先基礎設施層是強大的 IaaS 資源，基于第三代神龍架構的計算資源可以更彈性的擴展，以更加優化的成本提供更高的性能；云原生的分布式文件系統，為容器持久化數據而生；云原生網絡加速應用交付能力，提供應用型負載均衡與容器網絡基礎設施。 其次在容器編排層，阿里云容器服務自 2015 年上線來，伴隨數千家企業客戶，共同實踐過各行各業大量生產級場景。越來越多的客戶以云原生的方式架構其大部分甚至全量應用，隨著業務深入發展，為了滿足大中型企業對可靠性、安全性的強烈需求，阿里云推出新品可供賠付 SLA 的容器服務企業版 ACK Pro。 容器服務企業版 ACK Pro 橫空出世：全面安全、高性能，支持新一代神龍架構，SLA 可賠付 容器服務企業版 ACK Pro，是在原容器服務 ACK 托管版集群的基礎上發展而來，其繼承了原托管版集群的所有優勢，例如 Master 節點托管和高可用等。同時，相比原托管版進一步提升了集群的可靠性、安全性和調度性能，并且支持賠付標準的 SLA，高達 99.95%，單集群可支持 5000 節點。ACK Pro 非常適合生產環境下有著大規模業務、對穩定性和安全性有高要求的企業客戶。 ACK Pro 支持神龍架構，憑借軟硬一體的優化設計，可為企業應用提供卓越的性能；支持無損 Terway 容器網絡，相比路由網絡延遲下降 30%；為企業提供全面安全防護，支持阿里云安全沙箱容器，滿足企業客戶對應用的安全、隔離需求，性能相比開源提升 30%。此外，ACK Pro 提供了對異構算力和工作負載優化的高效調度，支持智能 CPU 調度優化，在保障 SLA 和密度的前提下，Web 應用 QPS 提升 30%；支持 GPU 算力共享, AI 模型預測成本節省 50% 以上。 阿里云視頻云已在全球十多個區域使用容器服務作為服務基礎，有效管理全球萬級節點的資源，其中 ACK Pro 切實保障基礎設施層大規模計算資源的運維效率和高穩定性，使視頻云團隊可以將更多時間精力聚焦在視頻領域從而為客戶提供更多價值。 近日， 阿里云容器服務并成為國內首批通過可信云容器安全先進性認證的企業級容器平臺，以 49 個滿分項目榮獲最高級別先進級認證，特別是在最小化攻擊面，二進制鏡像驗簽名，密文的 BYOK 加密等能力上國內領先，達到國際先進水平。 容器服務 ACK Pro 現已正式開啟公測，非常適用于互聯網、大數據計算、金融政府及跨海業務企業等，歡迎各位感興趣的客戶在官網上申請試用。 業內首個全托管 Istio 兼容服務網格 ASM，多種異構應用服務統一治理 在服務網格技術誕生前，應用服務治理的邏輯實現通常都是以代碼庫的方式嵌入在應用程序中，隨著應用復雜度的增長和團隊規模的擴大，代碼庫變更和維護會變地越來越復雜。服務網格通過 Sidecar 代理功能，將服務治理能力與應用程序本身解耦，將服務治理能力標準化、統一化，且更好地支持多種編程語言和技術框架的應用服務。 作為業內首個全托管 Istio 兼容的服務網格產品 ASM，已經正式商業化發布，用戶可以在多個地域部署使用。阿里云一開始從架構上就保持了與社區、業界趨勢的領先性，控制平面的組件托管在阿里云側，與數據面側的用戶集群獨立。ASM 在托管的控制面側提供了用于支撐精細化的流量管理和安全管理的組件能力。通過托管模式，解耦了 Istio 組件與所管理的 K8s 集群的生命周期管理，使得架構更加靈活，提升了系統的可伸縮性。 商米科技使用服務網格 ASM 之后，充分享受了 Service Mesh 帶來的好處，解決了 GRPC-HTTP2.0 多路復用引起的負載不均衡的問題，得以分離控制平面和數據平面，受益于 ASM 的可視化方式對控制平面進行管理，對規則配置一目了然。同時還無縫結合鏈路監控（Tracing Analysis）解決服務化體系下調用鏈排查追蹤問題。 作為多種類型計算服務統一管理的基礎設施, ASM 提供了統一的流量管理能力、統一的服務安全能力、統一的服務可觀測性能力、以及統一的數據面可擴展能力, 并提出了相應的實踐之成熟度模型。針對用戶不同的場景, 逐步采用, 分別為一鍵啟用、可觀測提升、安全加固、多種基礎設施的支持以及多集群混合管理。 全球鏡像同步加速，ACR EE 保障云原生制品的安全托管及高效分發 容器鏡像服務企業版 ACR EE 面向安全及性能需求高，業務多地域大規模部署的企業級客戶，提供了公共云首個獨享實例模式的企業版服務。 在制品托管部分，ACR EE 除了支持多架構容器鏡像，還支持多版本 Helm Chart 等符合 OCI 規范制品托管。在分發及安全治理部分，ACR EE 加強了全球多地域分發和大規模分發支持，提供網絡訪問控制、安全掃描、安全加簽、安全審計等多維度安全保障，助力企業從 DevOps 到 DevSecOps 的升級。目前已有數百家企業線上環境大規模使用，保障企業客戶云原生應用制品的安全托管及高效分發。 某國際零售巨頭是全球多地域業務形態，存在多地研發協作及多地域部署的場景。采用 ACR EE 之后，客戶只需配置實例同步規則，在業務迭代更新容器鏡像后，可實現分鐘級自動同步至全球指定地域，自動觸發 ACK 集群業務部署。完美應對跨海網絡鏈路不穩定、分發不安全的問題，極大提高業務研發迭代效率和部署穩定性，保障企業業務的全球化部署。 除了業務鏡像全球自動化部署，也有很多企業通過 ACR EE 的云原生應用交付鏈功能，通過全鏈路可追蹤、可觀測、可自主配置等實踐容器化 DevSecOps。 業界首創“云邊一體化”理念 ，邊緣容器服務 ACK @Edge 正式商業化 與此同時，阿里云深度挖掘了“邊緣計算+云原生落地實施”訴求，在去年 KubeCon 上，重磅發布了邊緣容器（ACK@Edge），時隔一年，宣布 ACK@Edge 正式商用。此外，ACK@Edge 也將其核心能力開源，并向社區貢獻完整的云原生邊緣計算項目——OpenYurt。 在過去短短一年的時間里，該款產品已經應用于音視頻直播、云游戲、工業互聯網、交通物流、城市大腦等應用場景中，并服務于盒馬、優酷、阿里視頻云和眾多互聯網、新零售企業。 YY 使用 ACK@Edge 之后，可以 API 統一管理、統一運維邊緣容器集群和中心容器集群，邊緣算力快速接入并實現邊緣節點自治，同時也可以無縫接入 Prometheus 服務實現監控數據上報，總體上運維效率和資源使用率都得到顯著改善。 ACK@Edge 適用于豐富的應用場景， 包括邊緣智能、智慧樓宇、智慧工廠、音視頻直播、在線教育、CDN。 云原生技術不但可以最大化云的彈性，幫助企業實現降本提效；而且還意味著更多創新的想象空間， 云原生將和 AI, 邊緣計算，機密計算等新技術相結合，為數字經濟構建智能、互聯、信任的創新基礎設施。 “新基石、新算力、新生態是容器產品發展策略 ”? ，易立稱， “云原生技術正成為釋放云價值的最短路徑，團隊會幫助企業更好支撐混合云、云邊一體的分布式云架構和全球化應用交付?；谠圃能浻惨惑w化技術創新，如神龍架構，含光芯片，GPU 共享調度等，阿里云將加速業務智能化升級。同時我們還會通過開放技術生態和全球合作伙伴計劃，讓更多企業分享云時代技術紅利?！?“ 阿里巴巴云原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號?！?

前言：春節期間因為疫情影響只能在家，正好用來進行網上視頻復習，并在1月28日完成CKAD的考試，1月29日拿到通過證書，加上去年底拿到的CKA證書，我已經通過了CNCF的兩大認證，即CKA和CKAD。應LF開源軟件大學的邀請，寫下這篇文章，介紹我為什么考CKA以及我的備考經驗，希望可以幫助到有同樣想法的同學。 首先為什么要學習云原生？ 2011年著名互聯網企業家和投資人Marc Andreessen在《華爾街日報》上指出“Software is eating the world”，他指出很多行業的創新領先者（例如廣告行業的谷歌，視頻行業的netflix）其實都是軟件公司。而現在這個趨勢越來越明顯，即所有的行業都在進行數字化改造，每個行業的創新領先公司都是技術公司，是能充分利用互聯網技術優勢的互聯網化的公司。而互聯網公司中，研發是重要的基礎部門?；ヂ摼W研發的兩個重要特點：1.是 Agile，即快速的迭代上線；2是scale，即能低成本進行快速彈性伸縮，流量激增的時候能快速擴容扛住，容量減少的時候也能快速縮容來降低成本。能比同行業的競爭對手進行更快的迭代和更低成本的伸縮是他們勝出的關鍵優勢之一。 而要做到agile和scale，快速迭代的研發團隊流程，彈性伸縮的基礎設施還有易擴展和演進的系統架構，這三者缺一不可。而這三者的演進趨勢：研發流程從瀑布到Agile，再到現在的DevOps；系統架構從單體到分層， 再到微服務；基礎設施從實體機到虛機，再到容器和容器編排； 都無一不深刻的體現出“唯有更好的支持Agile & Scale，才是研發演進的方向“。而工程師以后不會有開發/測試/運維之分，只會有負責上層業務開發和維護的工程師和負責下層基礎設施開發和維護的工程師之分了，而且即使是業務工程師也需要了解和完成部分底層基礎設施的一些工作，（雖然嚴格來說基層技術設施和上層業務是解耦的。）所以每個工程師要在未來的5年內保持競爭力，都需要了解云原生的一些基礎知識，了解和使用Docker和Kubernetes技術。 為什么要通過CKA + CKAD考試？ 而要學習一門技術，尤其是一門在不斷迭代而內容和范圍又非常廣泛的技術（Kubernetes版本發布很快，每年4個大版本），如果不從一開始即建立一個大的picture即完整的知識體系，而是從一些細小的地方從源碼開始啃起，很容易陷入“只見樹木不見森林”的地步，而且學習效率也會偏低。而如何建立起一個大的picture呢？先從外到內，即先會使用，然后了解其原理和機制，必要的時候才去定制。那么如何驗證我已經從使用的角度來建立起大的picture呢？感謝CNCF的組織，他們有現成的Kubernetes學習和認證體系，即通過他們的認證，那么可以比較有信心的確認已經建立起一個完整的知識體系，從而為下一步的學習和研究打下很好的基礎。而這個CNCF的認證體系就是CKA和CKAD。CKA適合系統管理員，CKAD適合應用開發者，兩個考試相同的部分是對Kubernetes的架構和術語都要求熟練了解， 不同的地方是CKA中會有setup cluster，debug 和fix cluster問題的內容，而CKAD會有Pod Design方面的內容。 而我在百度內部編寫大綱和教材，召集志愿者作為講師，并組織完成了10期Kubernetes Bootcamp即入門訓練營。每期采用線下授課方式，使用百度云Kubernetes集群作為實際環境，采用邊講邊練的方式進行大量的實操，每期5個晚上，共5門課程12個小時。已經有500+工程師參加培訓，口碑反饋特別好。而通過CKA和CKAD認證更能驗證我組織的大綱和培訓方式是有助于學員進行云原生基礎知識的學習，為之后進一步業務上云做好思想上和技能上的準備。 準備考試的心得： 首先需要了解考試的特點。CKA和CKAD都是上機考試，沒有選擇/填空/問答之類的題目，全是上機面對Kubernetes集群的操作，所以記住一定要在Kubernetes集群里多練習，minikube和katacoda提供的單機和網上集群可以多使用。另外因為CKA有Initial setup和TLS bootstrapping的內容，所以去AWS或則Azure上建虛擬機，直接搭建集群也是很有幫助的，而且有些debug的操作是需要在集群的master節點和node節點上ssh進去執行的，所以多自己搭建下是很有必要的。 其次需要了解考試大綱。CKA和CKAD都有自己的大綱，比較詳細，需要針對大綱的每一個內容進行有針對性的學習和準備。別覺得目的性太強，要建立起使用者的知識體系，這些大綱對應的內容是必須要掌握的。 最后需要熟悉Kubernetes的官網文檔，尤其是Task部分。因為考試時間比較緊張，CKA 3個小時，CKAD2個小時，普遍反應都是時間不夠。上機考試環境中是沒有時間讓你從頭來敲鍵盤輸入YAML文件內容的，更多都是找到Task對應的部分，Copy 現成的YAML文件下來，然后快速修改，最后完成指定操作。例如CKA和CKAD都有使用Secret的部分，即創建Secret，然后在Pod中通過環境變量或者Volume的方式來使用。建議比較省時的方法即在kubernetes.io/docs使用“inject+secret”查到第一個結果，即Task中的一個例子，然后把該例子中的YAML 內容Copy到考試使用的終端上，然后再根據題目要求修改下，最后執行，這樣能節省大量的時間。 另外別忘了CNCF提供了很優秀的線上視頻課程，其中面向管理員的《Kubernetes 基礎課程》（LFS258）和面向開發者的《kubernetes開發員課程》（LFS 259）是很有用的。在家封閉的這幾天，把這些視頻內容快速重溫了下，再去通過線上考試就心里有底多了。 后記： 當然呢，通過CKA和CKAD考試，對于某些同學來說增強職場競爭力，甚至作為入職某些云企業的敲門磚是很有用的，但是從我的角度來說，建立起從使用角度的整個知識體系（而這個體系是經過大企業和開源基金會認證和背書 過的），從而為下一步的更深入學習建立基礎，這才是我希望達到的目的，而毫無疑問，CKA和CKAD可以幫助我，確認我已經達到一定水準。

PBR 渲染參數非常少 主要 albedo normal metalic smooth ao heightmap Unity 渲染管線 核心函數 fragForwardInternal Unity shader的PBR渲染 核心函數 UNITY_PBS_SHADE 支持三種函數類型 disney PBS 迪士尼 minialist micro 模型 Normal 模型 PBR渲染 參數 主要光參數是 直接光 UnityLight 和 UnityIndirect 間接光 間接光 包括 diffuse 和 specular 直接光主要是 光顏色和朝向 通過ImageBasedLight可以通過 HDR環境貼圖 生成 間接光的 diffuse cubeMap 和 specular 的cubeMap 可以通過 IBL Baker 工具生成對應的環境光貼圖 Unity中的 Probe 和 Reflection Probe 有類似的效果 但是沒有HDR 的 貼圖信息豐富， 不好創建豐富 細膩的環境光效果

用游戲服務器，注意事項 游戲為我們和生活帶來了更多的趣味和精彩，很多游戲網站的站長在挑選租用游戲服務器時，主要看游戲服務器的什么方面，結合實際生活的各方面，注意游戲服務器提供商的信譽實力售后支持、服務器本身就看穩定性、帶寬價格這些事項。 1.游戲服務器的提供商信譽實力 信譽實力在各行各業中都是最重要的，是現實中的保證?？匆粋€游戲服務器服務商的信譽實力，可以從企業上傳到網站的信譽之星，服務之星等一些證書進行查詢。正規的游戲服務器運營商會形成一定的規模，如果有時間的話，為了以后各方面保障，直接去游戲服務器服務商那些考檢他們的公司，從公司的大小，員工數量，工作態度，服務器信息相關交流等這些就可以大概有個了解。 2.游戲服務器穩定性 穩定是游戲服務器的前提，影響到穩定的有游戲服務器配置情況、今后的擴展、安全性能。游戲的質量越來越高，對各方面的要求也變大的。在配置方面，操作系統、應用軟件、網卡、硬盤、內存、CPU等都選高一點，但也不要選得太離譜，以自己是什么游戲去定。游戲的更新也是很快的，為了可以適應游戲的變化，擴展性強的游戲服務器先看。至于安全性能，網絡上的病毒、木馬等種類很多，誰都不想在玩游戲時，經常被影響，所以有沒有實時監控防護措施服務這也要注意。 3.游戲服務器所用帶寬 無論是游戲服務器是用在大型單機下載，還是網絡游戲，為了不造成傳輸時，帶寬堵塞。寬帶盡量大點，美國服務器所用一般100M、1G國際帶寬可以滿足傳輸要求。 4.游戲服務器租用價格 現在市面上游戲服務器的價格，在配置的不同、服務的不同，價格也完全不同。在游戲服務器價格上的定位，一定要理性對待。先選好提供商，然后根據游戲網站需要游戲服務器怎樣的支持，進行服務器間比較，再決定。如 服務器。 5.游戲服務器售后支持 游戲服務器與其它服務器一樣，當工作久了，肯定會偶爾出現故障。因此，隨時都有服務技術支持和快速故障解決，這是游戲服務器最基本應該具備的。

客戶端–發送帶有 SYN 標志的數據包–一次握手–服務端 服務端–發送帶有 SYN/ACK 標志的數據包–二次握手–客戶端 客戶端–發送帶有帶有 ACK 標志的數據包–三次握手–服務端 為什么要三次握手？ 三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。 第一次握手：Client 什么都不能確認；Server 確認了對方發送正常 第二次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己接收正常，對方發送正常 第三次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常， 對方發送接收正常 所以三次握手就能確認雙發收發功能都正常，缺一不可。 為什么要傳回SYN 接收端傳回發送端所發送的 SYN 是為了告訴發送端，我接收到的信息確實就是你所發送的信號了。 傳了SYN為什么還要傳ACK 雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN，證明發送方到接收方的通道沒有問題，但是接收方到發送 方的通道還需要 ACK 信號來進行驗證。 斷開一個 TCP 連接則需要“四次揮手”： 客戶端-發送一個 FIN，用來關閉客戶端到服務器的數據傳送 服務器-收到這個 FIN，它發回一 個 ACK，確認序號為收到的序號加1 。和 SYN 一樣，一個 FIN 將占用一個序號 服務器-關閉與客戶端的連接，發送一個FIN給客戶端 客戶端-發回 ACK 報文確認，并將確認序號設置為收到序號加1 為什么要四次揮手 任何一方都可以在數據傳送結束后發出連接釋放的通知，待對方確認后進入半關閉狀態。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認后就完全關閉了TCP連接。 舉個例子：A 和 B 打電話，通話即將結束后，A 說“我沒啥要說的了”，B回答“我知道了”，但是 B 可能還會有要說的 話，A 不能要求 B 跟著自己的節奏結束通話，于是 B 可能又巴拉巴拉說了一通，后 B 說“我說完了”，A 回答“知道了”，這樣通話才算結束

在HTTP/1.0中默認使用短連接。 也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。 當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像 文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。 而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼： Connection:keep-alive 在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。 實現長連接需要客戶端和服務端都支持長連接。HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。

總體來說分為以下幾個過程: DNS解析 TCP連接 發送HTTP請求 服務器處理請求并返回HTTP報文 瀏覽器解析渲染頁面 連接結束

TCP更加可靠，因為TCP是面向連接的服務 TCP是字節流傳輸，UDP是數據報文段 TCP更慢，UDP更快，因為TCP要建立連接釋放連接 TCP一般是文件傳輸，遠程登錄的應用場景，UDP一般是視頻、直播等應用場景

記錄下搭建rocketmq過程中遇到的坑：（集群機子代號這里列為：mq-a，mq-b，mq-a-s, mq-b-s） rocketmq搭建的是 雙主雙從 模式。三臺機器，機器 a 、b 分別安裝 雙主 ，機器c 安裝 雙從 。 啟動三個 nameserver，雙主broker-master，雙從broker-slave 服務器 rocketmq 是4.7.0版本 1. 第一個坑 - 項目rokcetmq 版本和服務器rocketmq版本沒對上 ：rocketmq 雙主雙從 搭建完，從 github 上下載的 rocketmq管理后臺，本地跑起來，能成功連上rocketmq。然后自己寫了的一個demo，發下報錯，報錯信息如下： 后來發現是 demo項目于中 pom的 rocketmq 依賴是 4.3.0， 和服務器4.7.0 對不上，然后我項目改成了 4.7.0的版本依賴。然后就ok了 附上 provider生產者的 demo代碼 和 consumer消費者 的 demo 代碼： ========>>>> provider 生產者代碼： public class TestProvider { public static void main(String[] args) { try { //Instantiate with a producer group name. DefaultMQProducer producer = new DefaultMQProducer("p1"); // Specify name server addresses. producer.setNamesrvAddr("43.230.143.17:9876;58.82.250.253:9876;58.82.208.238:9876"); //Launch the instance. producer.start(); for (int i = 0; i < 10; i++) { //Create a message instance, specifying topic, tag and message body. Message msg = new Message( "testTopic" /* Topic */, "TagA" /* Tag */, ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */ ); //Call send message to deliver message to one of brokers. SendResult sendResult = producer.send(msg); System.out.printf("%s%n", sendResult); Thread.sleep(1000); } //Shut down once the producer instance is not longer in use. producer.shutdown(); } catch (Exception e) { e.printStackTrace(); } } } ========>>>> consumer 消費者代碼： public class TestConsumer { public static void main(String[] args) { try { // Instantiate with specified consumer group name. DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("c1"); // Specify name server addresses. consumer.setNamesrvAddr("58.82.250.253:9876;43.230.143.17:9876;58.82.208.238:9876"); // Subscribe one more more topics to consume. consumer.subscribe("testTopic", "*"); // Register callback to execute on arrival of messages fetched from brokers. consumer.registerMessageListener((MessageListenerConcurrently)(msgs, context) -> { // System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs.toString()); System.out.println(" Receive New Messages: " + Arrays.toString(msgs.toArray())); return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; }); //Launch the consumer instance. consumer.start(); System.out.printf("Consumer Started.%n"); } catch (Exception e) { e.printStackTrace(); } } }

互聯網行業數據倉庫/數據平臺的架構 互聯網行業數據倉庫、數據平臺的用途 1) 整合公司所有業務數據，建立統一的數據中心； 2) 提供各種報表，有給高層的，有給各個業務的； 3) 為網站或 APP 運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果； 4) 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平臺； 5) 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等； 6) 開發數據產品，直接或間接為公司盈利； 7) 建設開放數據平臺，開放公司數據； 上面列出的內容看上去和傳統行業數據倉庫用途差不多，并且都要求數據倉庫 / 數據平臺有很好的穩定性、可靠性； 但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非?？?，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務； 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模， 如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基于網站日志建立的網站統計分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數據建立的用戶模型）， 其它的業務一般都采用維度 + 寬表的方式來建立數據模型。 整體架構 邏輯上，一般都有數據采集層、數據存儲與分析層、數據共享層、數據應用層?？赡芙蟹ㄓ兴煌?，本質上的角色都大同小異。 我們從下往上看 數據采集 數據采集層的任務就是把數據從各種數據源中采集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。 數據源的種類比較多： 網站日志： 作為互聯網行業，網站日志占的份額最大，網站日志存儲在多臺網站日志服務器上， 一般是在每臺網站日志服務器上部署 flume agent ，實時的收集網站日志并存儲到 HDFS 上； 業務數據庫： 業務數據庫的種類也是多種多樣，有 Mysql 、 Oracle 、 SqlServer 等，這時候，我們迫切的需要一種能從各種數據庫中將數據同步到 HDFS 上的工具， Sqoop 是一種，但是 Sqoop 太過繁重，而且不管數據量大小，都需要啟動 MapReduce 來執行，而且需要 Hadoop 集群的每臺機器都能訪問業務數據庫；應對此場景，淘寶開源的 DataX ，是一個很好的解決方案有資源的話，可以基于 DataX 之上做二次開發，就能非常好的解決。 當然， Flume 通過配置與開發，也可以實時的從數據庫中同步數據到 HDFS 。 來自于 Ftp/Http 的數據源： 有可能一些合作伙伴提供的數據，需要通過 Ftp/Http 等定時獲取， DataX 也可以滿足該需求； 其他數據源： 比如一些手工錄入的數據，只需要提供一個接口或小程序，即可完成； 數據存儲于分析 毋庸置疑， HDFS 是大數據環境下數據倉庫 / 數據平臺最完美的數據存儲解決方案。 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來， Hive 還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的 ORC 文件存儲格式；非常方便的 SQL 支持，使得 Hive 在基于結構化數據上的統計分析遠遠比 MapReduce 要高效的多，一句 SQL 可以完成的需求，開發 MR 可能需要上百行代碼； 當然，使用 Hadoop 框架自然而然也提供了 MapReduce 接口，如果真的很樂意開發 Java ，或者對 SQL 不熟，那么也可以使用 MapReduce 來做分析與計算； 數據共享 這里的數據共享，其實指的是前面數據分析與計算后的結果存放的地方，其實就是關系型數據庫和 NOSQL 數據庫； 前面使用 Hive 、 MR 、 Spark 、 SparkSQL 分析和計算的結果，還是在 HDFS 上，但大多業務和應用不可能直接從 HDFS 上獲取數據，那么就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據； 和數據采集層到 HDFS 剛好相反，這里需要一個從 HDFS 將數據同步至其他目標數據源的工具，同樣， Sqoop,DataX 也可以滿足。 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。 數據應用 業務產品 業務產品所使用的數據，已經存在于數據共享層，他們直接從數據共享層訪問即可； 報表 同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放于數據共享層； 即席查詢 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求； 這種即席查詢通常是現有的報表和數據共享層的數據并不能滿足他們的需求，需要從數據存儲層直接查詢。 即席查詢一般是通過 SQL 完成，最大的難度在于響應速度上，使用 Hive 有點慢，目前解決方案是 SparkSQL, Impala ，它的響應速度較 Hive 快很多，而且能很好的與 Hive 兼容。 OLAP 目前，很多的 OLAP 工具不能很好的支持從 HDFS 上直接獲取數據，都是通過將需要的數據同步到關系型數據庫中做 OLAP ，但如果數據量巨大的話，關系型數據庫顯然不行； 這時候，需要做相應的開發，從 HDFS 或者 HBase 中獲取數據，完成 OLAP 的功能； 比如：根據用戶在界面上選擇的不定的維度和指標，通過開發接口，從 HBase 中獲取數據來展示。 其它數據接口 這種接口有通用的，有定制的。比如：一個從 Redis 中獲取用戶屬性的接口是通用的，所有的業務都可以調用這個接口來獲取用戶屬性。 實時計算 現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統數據庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架； Storm, JStorm ,Spark Streaming 等實時框架已經非常成熟了。 常見思路由 scribe 、 chukwa 、 kafka 、 flume 等開源框架在前端日志服務器上收集網站日志和廣告日志，實時的發送給 Storm, JStorm ,Spark Streaming ，由實時計算框架完成統計，將數據存儲至 Redis ，業務通過訪問 Redis 實時獲取。 任務調度與監控 在數據倉庫 / 數據平臺中，有各種各樣非常多的程序和任務，比如：數據采集任務、數據同步任務、數據分析任務等； 這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據采集任務完成后才能開始；數據同步任務需要等數據分析任務完成后才能開始； 這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫 / 數據平臺的中樞，負責調度和監控所有任務的分配與運行。 元數據管理 技術元數據與業務數據，開發元數據系統。

DragonBonesPro制作補間動畫、龍骨動畫 一、開場動畫 二、小丑盒子 三、跑步的人 四、跳跳羊 一、開場動畫 效果 ： 1.導入素材 2.將素材拖入到舞臺并調整位置 3.調整圖層位置 4.設置關鍵幀，創建補間動畫 二、小丑盒子 效果 ： 1.導入素材 2.將素材拖入到舞臺，調整層級 3.創建骨骼 4.創建補間動畫 三、跑步的人 效果 ： 1.導入.json文件 2.創建手臂和腿的骨骼，層級 3.創建頭部和身體的骨骼，層級（lowerbody- upperbody-head） 4.整體骨骼綁定效果 5.添加動作（run） 同理創建其他狀態的動作（jump，idle，alert） 四、跳跳羊 效果 ： 1.導入.json文件到舞臺 2.給跳跳羊創建骨骼，層級如下圖 3.選擇網格模式，對跳跳羊創建網格 添加邊線 添加頂點 4.制作補間動畫

開發工具：DragonBonesPro 1.開場動畫 2.小丑盒子 3.跑步的人 4.跳跳羊 一.開場動畫 1.導入素材 2.將素材拖入舞臺內，并調整位置以及圖層 3.設置關鍵幀，創建補間動畫 4.運行結果 二.小丑盒子動畫 1.導入素材 2.將素材拖入舞臺，并調整層級 3.創建骨骼，并調整場景樹 4.設置關鍵幀，創建補間動畫 5.運行結果 三.跑步的人 1.導入.json文件 2.創建手臂和腿的骨骼 3、創建頭部和身體的骨骼 4.整體骨骼綁定效果和所有場景樹 5.制作補間動畫 最低位姿態第0幀： 最高位姿態第2幀： 第二個最低位姿態第4幀： 把第0幀的所有關鍵幀復制到第8幀完成剩下半步。 6.同理創建其他動作： 7.運行結果 四.跳跳羊 1.導入json素材 2.給跳跳羊創建骨骼，場景樹和層級如下 3.選擇網格模式，對跳跳羊創建網格，添加邊線和頂點 4.添加關鍵幀，創建補間動畫 5.運行結果

用DragonBonesPro制作補間動畫、龍骨動畫 動畫補間 導入素材 整理素材位置并安排時間軸 調整關系以及創建補間動畫 小丑驚嚇盒 導入素材以及調整關系 創建骨骼以及創造補間動畫 跑步精靈 導入數據到項目 創建骨骼 手腳部以及頭和身體 建立整體從屬關系 跑步動畫補間 跳躍 跳跳山羊 導入素材 創建山羊骨骼以及網格 創建補間動畫