作者 | 李鴻斌
1 背景
起初，在網盤快速發展期，為了快速上線，採用了服務單體化 + 主幹開發模式進行研發，隨著用戶規模爆發式的增長以及產品形態的豐富，單體化的不足就體現出來了，於是架構上採用了微服務架構，開始對業務邏輯進行拆分部署。
服務拆分之後，也引入了新的問題，具體如下：
- 請求路由：服務部署從物理機向虛擬化方式遷移中，有大量的切流量操作，需要相關的上游都進行升級上線修改，效率低下；
- 故障管理：單實例異常、服務級別異常、機房故障異常、網絡異常等，嚴重缺失或者不完善，同時配套的故障定位也沒有，服務穩定性不足；
- 流量轉發：不同的服務採用了不同的框架，甚至裸框架，策略不完善，導致負載不均衡；
- 研發效率：相同的功能點，需要在不同的語言框架上實現一次，浪費人力，同時升級週期比較長，收斂效率低
2 解決方案 - UFC
2.1 UFC 發展史
為了解決這個問題，從 2015 年底開始思考解決方案，確定瞭解決問題的核心在於管控請求流量，在 2016 年開始自研網絡流量轉發中間件 - UFC(Unified Flow Control)，業務通過同機部署的 agent 進行服務通信，相關的發展史如下：
2.2 UFC 和 Service Mesh 的關係
後來在調研業界相關技術的時候，發現了 istio(業界 Service Mesh 的典型代表)，從而發現了 Service Mesh 的存在，而它的定義是在 2016.9 由 Buoyant 公司的 CEO William Morgan 提出的：
Service Mesh 是一個專門用來處理服務和服務之間通信的基礎設施。它複雜確保在一個由複雜服務構成的拓撲的現代雲應用中，請求能夠被穩定的傳遞。在實踐中，Service Mesh 通常通過一系列輕量級的代理來進行實現。這些代理和應用同機部署，而應用不需要感知到代理的存在。
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
從定義上，我們不難發現 UFC 和 Service Mesh 的設計理念是一致的，都是基於 sidecar 模式，有著控制面板和數據面板，UFC 是 Service Mesh 的一種實現。感慨的說，歷史的發展潮流是一致的，不管你在哪裡。
目前 UFC 應用於網盤過千個服務上，涉及虛擬化實例數量超過 20W，千億 PV，機器規模 10W+(網盤 + 其它產品線機器)，10 個 IDC，從已知的實例規模上看，是國內最大的 Service Mesh 的實踐落地。
2.3 基於 Service Mesh 之上的服務治理
百度網盤的實踐落地並不只侷限於 Service Mesh，首先是構建了從點延伸到線的 Service Mesh 進行服務通信管控，然後是在 UFC 這個 Service Mesh 的基礎之上，站在全局視角對服務進行治理，保障服務的穩定性，相關能力等發展如下：
- 點：關注與下游進行通信，不關注上游的情況；
- 線：加入上游的標識，基於上游做異構的通信策略；
- 面：多條線組成面，站著全局視角進行服務治理；
2.4 本文概要
本文將會先介紹 UFC(如何實現一個 Service Mesh)，然後是基於 UFC 做服務治理 (基於 Service Mesh 的實踐應用)
3 UFC 外部視角簡介
3.1 用戶使用視角
只需要做兩個事情：
- 服務註冊：需要先確保自己的服務 (上游) 和要訪問的服務 (下游) 已經註冊過了，沒註冊過，則需要服務的 owner 進行服務註冊；
- 服務通信：用戶通過單機 agent 進行服務通信訪問下游，下圖顯示了用戶從直接訪問下游變成了通過同機 agent 訪問下游
3.1.1 服務註冊
UFC 為每個註冊的服務分配一個 service_name，service_name 是這個服務的唯一標識。同時需要對這個 service_name 配置它的相關配置：比如 destination 來源、負載均衡、熔斷、超時重試等策略
3.1.2 服務通信
訪問下游的時候，只需要訪問本機固定端口，帶上下游服務的 service_name、自身標記、trace 等信息，例如下面就是一個發請求的 demo 例子：
curl “http://127.0.0.1:8888/URI”-H “`x-ufc-service-name`=to_service_name”–H “`x-ufc-self-service-name`=from_service_name”-H “`x-ufc-trace-xxxx` = xxxxx”
3.2 UFC 能力視角
介紹 UFC 基於點和線視角的相關能力，從服務聲明、請求路由、流量轉發、故障處理、故障定位、安全等維度和 istio 做了一個比較。而 istio 是大部分是基於下游這個點進行相關通信能力設計，線視角能力很少 (比如權限認證等)
總結來說，istio 是能力全面，但是具體實現上策略比較簡單，而 UFC 是更貼近實際的業務場景 (具體的可以看後面的介紹內容)
PS: 有些能力 (比如流量複製 / 權限管理)UFC 沒有，並代表百度網盤沒有這方面的能力，只是因為歷史原因，通過其它的方案解決了。但是故障注入這塊，的確是 UFC 需要考慮的，有了這塊的能力，混沌工程也更容易的落地。
4 UFC 內部視角簡介
主要是介紹架構和相關具體能力的實現設計初衷
4.1 架構設計
整個架構和 Service Mesh 一樣，都是採用了同機 Sidecar 進行了流量的轉發 + 中心化控制。
4.1.1 核心流程圖
UFC 組件
- Service-Mgr: 服務 (實例) 管理，提供服務的增刪改查 (存儲到 db + cache)。定期從 naming 服務拉取 destination 列表，寫入 cache(多個 idc cache)。此外還會和 paas 進行協作 (比如通知 paas 遷移異常的實例)；
- Agent：每臺機器部署一個，四個功能：1）通信代理：為服務提供通信代理 2）配置同步：從同機房的 meta 模塊同步配置 3) 上報：異常和統計數據 4）系統異常監控：接收中心的監控檢測，包括 agent 存活和配置同步時效性；
- Meta：提供服務配置元信息的查詢，多個 IDC 地域部署；
- Monitor：worker 模式，定期發起監控系統和業務是否存在異常，系統層面監控單機 agent 存活率 / 配置同步等，業務層面監控異常實例 / 服務等；
- Metrics：聚會後的數據，數據來源來 agent 和 monitor；
4.1.2 相關設計說明
4.1.2.1 高可用
服務單點
Agent: 單機 agent 肯定會掛斷，解決思路是基於如何避免請求受損出發點，1) 基於 backup 集群臨時訪問：業務使用 sdk 進行訪問的時候，當訪問本機 agent 失敗之後，會通過訪問遠端的 backup agent 集群進行訪問下游 2) 基於探活屏蔽 + 修復：Monitor 會檢測單機 agent 的存活性，當單機 agent 異常的時候，Monitor 會通知 meta 服務屏蔽單機上的實例，避免上游訪問該機器，同時進行 agent 修復；
Meta: 每個 IDC 獨立部署，另外 IDC 內部通過多實例 + 無狀態設計解決單點問題；
Monitor: 每個 IDC 獨立部署，另外 IDC 內部通過多實例 + 分佈式鎖互斥設計解決單點問題；
Metrics: 多實例，前面有一層 proxy，將 service 進行一致性 hash 進行服務拆分，單機統計聚合數據；
Service-Mgr: 多實例 + 無狀態設計解決單點問題；
IDC cache: 當某個 IDC 的 cache 異常之後，通過 Meta 切換讀取 backup IDC 的 cache 解決
機房鏈路故障：
會導致配置更新異常，解決方案是通過接入層將 IDC 流量切空，不在 UFC 這層考慮解決問題
業務實例異常：
除了通過 UFC 自身的故障屏蔽解決之外，還會聯動 paas 將長期處於異常的實例通過遷移恢復，實現異常處理的閉環
4.1.2.2 擴展性
paas 擴展性：很容易融入不同的 paas 平臺，只需要兼容不同的 naming 系統即可。
業務協議：支持任意業務協議，通過 bypass 旁路式解決 (後面的能力會進行相關介紹)。
4.1.2.3 監控
系統：各種系統的異常點，比如單機 agent 的存活和配置同步情況，中心配置定時器同步。
業務：服務單點異常、服務實例存活率、服務 sla 等業務指標儀表盤監控。
4.1.2.4 配置同步
單機上的配置是全量的，通過版本號進行增量同步 (全局的版本號 + 服務級別的版本號)，同時會通過 monitor 監控配置是否同步成功
4.1.2.5 具體實現
數據面板：基於 OpenResty 開發。從理論角度：nginx 轉發性能本身就好，同時在 2016 年的時候 Go 的 gc 問題還比較嚴重，從實際壓測：OpenResty 要優於 Go。
控制面板：基於 Go 開發，比較好實現併發編程。
4.1.2.6 實時 debug
對於一個實時運行的系統，如何實時獲取相關的 stat 數據，用於問題定位呢？比如想獲取當前封禁後端列表之類的。
為了滿足需求，增加了一個獲取數據的接口，獲取內存裡指定字段的數據，以 ^ 為分隔符。比如以下 demo 就獲取了一個服務的動態數據，包括了請求次數，更新時間，失敗次數等信息。
request:curl -v -H "token:token" 'http://10.10.11.11:8888/bypass?command=query&ar=request_info^pcs-upload'response：{"request_info": {"5xx_cnt": 2,"mtime": 1573456024,"request_cnt": 6,"success_cnt": 4}}4.2 功能設計
主要介紹 UFC 基於點和線的相關能力細節以及設計出發點
4.2.1 請求路由
提供相關的匹配能力，根據匹配條件進行後續相關的操作，比如設置後端的權重等進行多版本灰度測試、流量遷移等功能。
4.2.1.1 基於請求匹配
基於請求特徵做路由匹配，例如 http request header: headers[“x-http-flow-control”]，可以按隨機比例 或者 等價 進行匹配
類似於 istio 的路由規則
4.2.1.2 基於上游匹配
基於上游匹配是從線視角出發，UFC 的線視角如下：
為啥要做基於上游匹配，出發點如下：
流量等級：
不同的上游服務重要性也不一樣，產生請求的重要性也不一樣，於是基於上游的標誌設置異構的策略就很有必要。比如網盤的用戶文件列表展示服務和多端列表同步服務一樣會訪問數據庫，顯然前者比後者重要，用戶直接感知，需要區別對待。而如果是重試請求，這裡面的重要性又不一樣了，為了簡化策略配置，目前在將請求權重化，根據若干個請求因素的計算出請求權重，然後根據請求權重執行不同的策略。
具體的實踐落地：請求權重可以用於細粒度的降級策略。
機房策略：
上游訪問下游，默認是不關注上游請求的來源機房，也不關注下游 endpoint 的機房歸屬，流量在機房之間是混連的，那麼當時候，要切空機房流量異常麻煩。基於上游請求的機房的標識設置機房路由規則就很有必要了。
具體的實踐落地：可以定製機房轉發策略，比如流量在同一個物理 或者 邏輯機房內轉發，詳見下文流量轉發裡的基於上游轉發。
4.2.2 流量轉發
從協議、負載均衡、基於上游轉發、傳輸策略四個方面介紹
4.2.2.1 協議
Istio 只支持 http/tcp/grpc 協議，而業務使用的協議肯定不止這些協議，比如 redis/mysql 等，如果都支持這些協議以及後續的其它協議，那麼兼容的研發成本將非常的高，在用戶需求和研發成本之間，UFC 找到了折衷的解決方案實現了支持任意協議，具體上是以穿透式和旁路式進行落地的。
穿透式請求: 適用場景為 http 協議控制流，和 istio 的使用方式一樣
旁路式請求: 加強版的 DNS，適用場景為 http 協議數據流 or 非 http 協議，業務先從 UFC 拿到一個後端地址，然後業務自己通過這個後端地址訪問後端，最後需要回調 UFC 告知 UFC 這次通信的結果，方便 UFC 更新相關數據 (比如該後端的訪問成功率等，決策是否需要封禁之類的)。通過旁路式解決了任意協議的場景，同時對後端流量進行了管控。
4.2.2.2 負載均衡
採用了比較常見的負載均衡策略，比如輪詢、隨機、一致性 hash(根據業務定義的字段進行 hash)
4.2.2.3 基於上游轉發
主要的應用在於上下游 IDC 流量路由上，比如設置完下面的路由表之後，就實現了同 (邏輯 / 物理) 機房的流量轉發：
4.2.2.4 傳輸策略
主要是從連接策略、超時策略，重試策略介紹的
連接策略：
上游：短連接、長連接
下游：短連接、長連接
超時策略:
基本功能：設置與下游的連接 / 讀寫超時，可以被上游請求裡的指定參數覆蓋超時時間。
自動切換：兩套超時策略配置，結合故障處理自動切換。常規下 T1 超時策略 (客戶端可覆蓋)，雪崩下 T2 超時策略。當雪崩的時候自動切換到 T2 超時策略。這樣既可以照顧到常規情況下的請求長尾，又避免了雪崩等場景下下游服務拖跨上游訪問。
重試策略：
什麼場景下重試：需要分清楚重試的邊界。從功能角度看，Service Mesh 的功能是保障服務通信成功，所以 UFC 只在與後端通信失敗場景 (連接 / 寫 / 讀失敗) 下才重試，對於業務語義層面的錯誤，由業務發起重試，UFC 不介入重試邏輯。另外，從性能的角度出發，也不該把業務層面的重試下沉到 Service Mesh 這個基礎組件上來，因為涉及到對返回的 body 做反序列化，這個會影響其它的請求，增加請求耗時。
基本功能：設置與下游交互失敗的重試次數。
自動切換：兩套重試策略，結合故障處理自動切換。常規下重試，雪崩下不重試，當雪崩的時候自動切換到不重試。這樣既可以照顧到常規情況下少量的異常，又避免了雪崩等場景下加劇下游的雪崩，減少無意義的重試請求。
4.2.3 故障處理
從故障的範圍影響上分成：
單點故障：少量後端異常，比如進程因為 oom 掛掉 或者 因為機器異常導致進程異常。
服務級別故障：當多個單點故障之後，就引發了服務級別的故障，比如服務雪崩。另外業務自身異常 (比如全部返回 5xx) 不在處理範疇內。
從故障處理流程上分成：
發現故障: 怎麼定位故障的發生，包括單點 / 服務級別故障。
處理故障：怎麼處理使得單點 / 服務故障能夠恢復。
4.2.3.1 單點故障
故障處理具體發現故障和解決故障兩方面的內容，難點在於發現單點故障的準確性，是否存在漏判。
發現故障
基於請求：
單次異常：連接異常 (連接超時 / 拒絕 /Reset 等)、讀寫異常 (讀寫超時等)
判斷標準：N 次請求裡 M 次請求異常
基於業務：
業務維度：http status code、耗時等
判斷標準：單個後端和平均值 (算平均值的時候需要排除掉比較對象的數據) 做比較，看哪個後端嚴重偏離平均值，比如狀態碼區間比例之類的。這裡沒有采用單次異常判斷是因為有些場景下，通過單次請求是無法判斷為異常的，比如一個後端返回 404 的 http status code，這個是符合預期的？沒人知道，因為常規情況下業務也會返回 404，而在 LNMP 架構裡，如果單個實例磁盤問題導致 PHP 文件丟失，Nginx 找不到 PHP 文件，也會返回 404，這是一個混沌的狀態。UFC 的解決方案，就是和平均值進行比較，看是否偏離平均值。以 下圖後端狀態碼區間比例統計為例子，後端 2 4xx 的 http code 達到了 100%，而其它的後端這個比例也只有不到 5%，那麼大概率後端 2 就存在問題。
解決故障
處理：初始封禁 T 時間
封禁收斂：後端連續封禁時間翻倍，解決異常後端被反覆解封、封禁的場景
封禁閉環：長時間封禁的後端，通知 paas 進行異常實例的遷移封禁 backup 機制：達到最大封禁比例，通知人工介入處理
恢復：當封禁時間到了之後，檢測端口是否可用，可用則解封
4.2.3.2 服務故障
主要是針對雪崩過載的場景下如何儘量保障服務可用，也是從發現故障和解決故障進行介紹的，難點在於如何減少故障帶來的業務流量損失。
發現故障
基於通信成功率：下游服務 N 次請求裡成功率低於 X%
基於業務語義成功率: UFC 沒采用的原因是不能越俎代庖做自己能力之外的事情，Service Mesh 核心在於流量控制，它的能力是流量控制來避免下游過載，防止雪崩，例如業務代碼 bug 導致的成功率下降，Service Mesh 也沒有辦法。
解決故障
PS: 動態熔斷的思想是借鑑了網絡，當雪崩過載的時候，相當於發生了請求的擁塞，和網絡擁塞是一樣的特徵行為，網絡鏈路都帶寬相當於服務的容量
4.2.4 儀表盤
儀表盤基於數據源進行分析得到以下內容：
- 分佈式服務的日誌追蹤；
- 業務度量數據的收集 / 分析 / 展示。
4.2.4.1 數據源
有兩方面的數據源：
服務通信 access 日誌：通過日誌傳輸進行聚合分析。
何時由上游 A 對下游 B 進行訪問，請求通過了後端 X1/X2 進行訪問，重試了 N 次，耗時為 T1/T2 等，狀態碼為 S1/S2 等，
異常行為：業務層面比如服務熔斷等，系統層面比如封禁計數器異常等，由 agent 實時上報到中心做聚合分析
4.2.4.2 distributed traces
首先基於服務通信 access 日誌做鏈路分析，然後將鏈路信息存入 Elasticsearch 方便檢索，比如下圖就是一個鏈路檢索
4.2.4.3 metrics
從點、線、面視角上進行數據的聚合分析。
點視角：後端維度
服務後端異常監控：
單實例異常觸發封禁： 觸發封禁的後端，長時間封禁走 paas 遷移流程。
服務觸發熔斷： 觸發服務動態熔斷降級。
線視角：上下游維度
服務下游監控： 服務訪問所有下游的概貌，支持按 http 狀態碼和 idc 做過濾，同時支持環比 (昨天 / 一週前)。下面以視頻轉碼為例子，展示對若干個下游的訪問概貌。
請求數: 可以根據曲線分析是否存在異常。
請求失敗數： 根據失敗數量可以算出上游對下游的請求 sla
請求耗時: 可以比較昨天 / 上週的耗時數據，看是否存在異常
服務上游監控： 服務被所有上游訪問的概貌，可以按 http 狀態碼和 idc 粒度進行過濾，同時支持環比 (昨天 / 一週前)。下面以一個異步化服務為例子，被一堆的上游訪問，統計這些上游的訪問概貌。
請求數: 在定位服務的請求數突增，可以很容易識別出是哪個上游導致的。
請求失敗數： 如果一些上游訪問失敗數比較高，可以聯繫業務進行分析定位。
請求耗時: 可以比較昨天 / 上週的耗時數據，看是否存在異常
面視角：全局視角
核心功能鏈路 SLA 監控： 當鏈路 sla 降低的時候，可以很快定位到是哪個鏈路分支出現的異常。
耗時維度： 全部服務裡，耗時增加 top 10 業務，快速知曉業務概貌。
業務失敗率維度: 全部服務裡，失敗數最多的 top 10 業務，快速知曉業務概貌。
機器維度： 全部機器裡，請求 5xx 失敗最高的機器 top 10，快速知曉機器異常。
5 服務治理
5.1 服務治理的定義
如前文所述，服務治理是建立在 Service Mesh 基礎能力之上的，站在全局視角統籌規劃，以保障服務穩定性為出發點。
5.2 具體實踐
服務治理的意義：如下圖所示，百度網盤全局拓撲異常複雜，靠傳統的人工套路去保障服務穩定性，效率和覆蓋面都有很大的缺陷，基於流量控制的 service mesh 進行服務治理才是王道，具體從故障預防、故障定位和故障處理出發。
5.2.1 故障預防
故障預防從以下三個維度進行：
流量隔離：如何規避低優先級的請求流量影響高優先級的請求，避免喧賓奪主；
容量管理：如何保障服務容量滿足實際需求，避免容量不足導致雪崩；
無效請求: 如何減少無效的請求，避免服務陷入雪崩的危機之中
5.2.1.1 流量隔離
具體落地中又分成機房流量隔離以及在離線流量隔離:
機房流量隔離： 統一網盤所有服務邏輯 IDC 映射關係，UFC 自動識別上游所在機房，將請求轉發到下游服務相應機房，從入口到請求終端，以邏輯 IDC 機房維度進行了流量隔離。當發生機房故障的時候，入口處切流量即可解決機房故障。
在離線流量隔離： 定義網盤所有服務的等級，包括在離線標記，UFC 根據全局流量拓撲，可以發現是否存在在離線混連情況，避免低優先級的請求流量影響高優先級的請求，導致喧賓奪主。比如下圖中，Online-a 和 Offline-a 都訪問 Online-b 服務，這樣 Offline-a 有可能引發 Online-b 服務異常，而從影響 Online-a 與 Online-b 的請求，間接影響用戶請求。發現這種在離線混連的情況，需要對服務進行拆分，Online-b/Onine-c 各自拆分成 Onine 和 Offline 兩套服務，進行在離線流量的隔離。
5.2.1.2 容量管理
具體落地中又分成容量評估以及容量壓測，前置是根據鏈路拓撲做評估，後者是通過壓測實踐驗證評估的準確性:
容量評估： 通過鏈路上的 qps，分析出每個服務需要增加的 qps，進一步推算出需要擴容多少實例 (PS: 需要解決環路的問題)
容量壓測: 通過以線上流量以機房切流量逐漸加壓的方式來壓測，期間監控服務 sla，低於某個閾值之後，自動停止壓測
5.2.1.3 無效請求
無效請求產生的背景： 當 client 斷開連接之後，server 還在繼續訪問其它的後端，進行無效的請求。比如下圖中，client 以 300ms 的超時時間訪問 server，server 在訪問 A 和 B 之後，已經用掉了 300ms，這個時候 client 已經斷開了和 server 的連接，但是 server 卻繼續訪問 C 和 D，進行無效的請求。當這種無效請求在整個鏈路蔓延開，client 又在大量的重試的時候，就是雪崩降臨的時刻。
解決方案 - 基本思路： 基於鏈路的智能超時，設置整個鏈路的超時時間，當發現超時時間已經到了，就不再訪問其它的下游服務，避免無效請求。上游需要傳遞給下游執行超時時間 (採用相對時間，避免機器之間的時鐘不同步)，用於下游判斷執行時間是否已經到了。
解決方案 - 基於業務： 不需要使用 service mesh，業務自己維護當前的超時時間，業務改造的成本比較大。
解決方案 - 基於 service mesh：UFC 以唯一 ID 映射到一個請求到所有後端交互的鏈路上，UFC 自動維護剩餘的請求耗時，實現對業務近似 0 侵入 (PS: 還未用於生產環境)。
5.2.2 故障定位
定位的思路為：發現異常 –> 收集系統異常點 / 異常時間點相關變動 –> 定位原因。
除了基於 service mesh 採集系統的異常點，還需要聯動其它的系統監控項，比如服務容量。
5.2.3 故障處理
根據故障的影響面可以分成局部 / 全局雪崩故障。
5.2.3.1 局部故障
前置條件：
部署：服務部署在多個邏輯機房；
上線：服務分級發佈，單點 -> 單機房 -> 全機房。
場景：通過機房切流量快速解決機房硬件故障、小流量上線引發故障、後端異常封禁失敗等局部異常
5.2.3.2 全局雪崩故障
前置條件：
等級：需要定義服務 / 流量的等級；
統一降級標記：統一所有服務的降級標記。
場景：通過全局動態熔斷 + 異構降級 + 降級閉環策略解決服務引起的雪崩問題，儘量保障服務的可用度，具備自愈能力
6 總結與展望
在業務拆分面對眾多問題的背景之下，百度網盤從 2015 年底開始思考解決方案，確定瞭解決問題的核心在於管控請求流量，在 2016 年開始自研網絡流量轉發中間件 - UFC(Unified Flow Control)，業務通過同機部署的 agent 進行服務通信。後來通過調研借鑑業界技術的時候發現 UFC 和 Service Mesh 的設計理念是一致的，都是基於 sidecar 模式，有著控制面板和數據面板，UFC 是 Service Mesh 的一種實現。經過多年的線上實踐驗證，UFC 這個 Service Mesh 實現了動態熔斷 + 異構降級 + 降級閉環等故障處理、結合故障 / 上游進行流量轉發等創造性設計，滿足業務的實際場景需求。但是百度網盤的實踐落地並不只侷限於 Service Mesh，首先是構建了從點延伸到線的 Service Mesh 進行服務通信管控，然後是在 UFC 這個 Service Mesh 的基礎之上，站在全局視角對服務進行治理，保障服務的穩定性。
未來，UFC 將會加入故障注入等能力，同時基於該能力落地混沌工程，而這只是服務治理中預防的一部分。服務治理的目標是自愈，為了完成這個目標，還需要更加努力。
李鴻斌，百度資深研發工程師。2011 年畢業後加入百度的基礎架構部門，參與了百度分佈式雲存儲的設計與開發，支撐了百度所有業務線的對象存儲。2012 年至今，作為核心研發人員參與了網盤從 0 到 1 到 N 的基礎架構演進，先後參與或負責對象存儲 / 個人文件存儲 / runtime 基礎環境 / 資源管理 / 微服務架構，設計並實現了計算混佈於萬級別在線存儲機器的資源模型以及服務資源調度，節省下了數萬臺服務器的計算資源，產品線資源利用率公司第一，同時從 2016 年至今主導了自研的 Service Mesh- UFC（Unified Flow Control），實現了從點到線到面的服務治理保障了網盤服務的高可用，近期專注於邊緣計算方向，此外業餘時間反哺社區，php-src/hhvm/beego 等源碼貢獻者。
閱讀更多 互聯網技能圖譜 的文章
