【云駐共創】微服務流量治理的總結與探索——字節跳動的流量治理體系

【云駐共創】微服務流量治理的總結與探索

——字節跳動的流量治理體系

一、引言

在一個公司在成長的過程中，會面臨業務增長、團隊成長，進而導致溝通成本的上升。對于小型服務，開發人員較少，我們可以很好的對業務進行溝通，達到更好的產品效果。但是當開發人員增多，不同team之間的溝通可能不那么順暢時，就需要我們對架構進行拆解。接下來本文將從字節跳動的微服務流量治理體系來總結一下流量治理的方法。

二、分布式架構拆分

分布式架構主要分為單體架構、SOA架構和微服務架構。下面簡單介紹一下三者的區別以及優缺點。

（1）單體架構

單體架構比較適合小項目，優點是：開發簡單直接，集中式管理，基本不會重復開發，功能都在本地，沒有分布式的管理開銷和調用開銷。

它的缺點也非常明顯，特別是對于互聯網公司來說。

開發效率低：所有的開發在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷。

代碼維護難：代碼功能耦合在一起，新人不知道何從下手。

部署不靈活：構建時間長，任何小修改必須重新構建整個項目，這個過程往往很長。

穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉。

（2）

SOA架構

SOA架構是面向服務架構，是B/S模型、XMl/Web Service的技術延伸。現在，不少企業采用dubbo開發應用系統。Dubbo是簡單有效的SOA架構，值得采用。

優點是：把模塊拆分，使用接口通信，降低模塊之間的耦合度，把項目拆分成若干個子項目，不同的團隊負責不同的子項目，增加功能時只需要在增加一個子項目，調用其它系統的接口就可以。

缺點是：系統之間交互需要使用遠程通信，接口開發增加工作量。

（3）微服務架構

微服務是系統架構上的一種設計風格，主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間通過基于HTTP/HTTPS協議的RESTful API進行通信協作，也可以通過RPC協議進行通信協作。被拆分成的每一個小型服務都圍繞著系統中一些耦合度較高的業務功能進行構建，并且每個服務都維護著自身的數據存儲，業務開發，自動化測試案例以及獨立部署機制。由于有了輕量級的通信協作基礎，所以這些微服務可以使用不同的語言來編寫。

相比較于單體應用架構和SOA架構，微服務架構的主要特點是組件化、松耦合、自治、去中心化。包括體現每個微服務粒度要小，而每個服務是針對一個單一職責的業務能力的封裝，專注做好一件事情。獨立部署運行和擴展。每個服務能夠獨立被部署并運行在一個進程內。這種運行和部署方式能夠賦予系統靈活的代碼組織方式和發布節奏，使得快速交付和應對變化成為可能。

在使用微服務的過程中，有很多難點，包括機房調度、過載處理、服務健康檢查等等，需要我們去解決。所以需要我們使用流量治理來解決上述問題。

微服務難點

三、流量治理體系

在字節跳動，將流量治理體系分為四個方向，包括路由（Route）、安全（Secure）、控制（Control）和觀測（Observe）這四個方向，接下來，對每個部分進行詳細的介紹。

（1）路由

路由是指流量從一個服務實體出發，通過服務發現和規則調度，智能控制流量走向，最終達到目標服務實體的過程。

路由的幾個能力，包括動態負載均衡、測試導流能力、泳道調度、區域集群調度、服務發現和負載均衡。其中服務發現和負載循環是路由的基本能力。動態負載均衡、測試導流能力是路由中的更高階的能力，可以實現對流量的更好控制。

在服務發現方面，字節跳動有四個產品，可以實現不同程度的功能和能力。分別是Consul、Etcd、ZooKeeper和Eureka。

對于微服務體系中，我們需要一些負載均衡的策略。包括幾種主要的算法，比如加權輪轉調度、最小請求數、一致性哈希、隨機調度、高度一致性哈希等等。

在泳道調度方面，主要應用于用戶測試的方面。可以對服務在不同泳道之間進行調度，增加流量的控制和訪問能力。

區域、集群調度能力一般都是對于大公司的體量較大的服務而言，多個機房之間可以進行轉換和調度，其中一個機房下游服務出現問題時可以進行及時調整。

測試導流可以實現Mock服務、流量復制和重放、線下流量導入至開發機和藍綠發布等等功能。

動態負載均衡可以實現對節點權重隨著系統狀態的變換而動態變化。其作用就是降低延遲和錯誤率，同時剔除故障實例和豐富監控大盤。

（2）安全

安全就是通過服務實體的身份認證、授權、流量的加密通信來完成對流量傳輸內容的安全保護。

身份認證就是對于服務請求時對其進行身份進行認證，其可以為微服務之間的RPC調用提供基本的保證，拒絕沒有權限的請求方。但是身份是可以隨意指定的，不具備真實有效性。為了確保授權效果，往往需要通過鑒定確保請求方身份的有效性。

授權就是對某些操作的權限進行賦予。對于有安全性要求的服務來說，授權和校驗是必不可少的。完善的授權系統應該包括：細粒度劃分，去覆蓋微服務調用之間的各種授權需求；通配模式，減少配置負擔；界面清晰，對于授權與否清晰明了；預線上模式，對未來即將拒絕的請求發起報警，便于服務運維者按需授權并觀察效果。

加密是指公司服務間的RPC請求為了保證通信安全，防止內容被截獲，需要開啟mutualTLS雙向認證機制。其作用就是提供可靠的身份認證、防止內容的泄露和篡改，同時防止流量重放攻擊。

（3）控制

控制是通過多種治理途徑，維護服務實體的正常運行和流量的最優處理，為流量源提供最優的可用性。在無法提供服務穩定性時，對服務進行一些降級來維持基本功能。包括控制、故障注入、熔斷、丟棄流量、流量限制等，接下來對每個部分進行詳細的介紹。

最簡單控制就是超時控制，就是當微服務體系中一個緩解出現問題，不應該一直等下去，超過一定的時間就應該放棄調用這個服務，來保證服務的正常運行。比如頭條中信息有獲取和排序，如果排序服務出現問題，超過一定時間就應該放棄，這樣用戶得到的可能不是優先排序的新聞，但是至少保證了用戶可以看到新聞。

控制還包括故障注入，故障注入簡單來說就是人為加入故障來檢測服務是否可以穩定運行。在復雜的分布式系統中，包含了大量的交互和依賴點，隨時都可能出現各種異常和故障。處理不好就會導致系統性能低下，業務停滯或者是其他各種無法預期的異常行為。只靠人力是無法阻止這些故障的發生，所以我們應該致力于在這些異常行為被觸發之前，盡可能的識別出會導致這些異常的、系統中脆弱的、易出故障的環節。進行有針對性的加固和防范。從而避免故障發生時帶來的嚴重后果。

熔斷是指當服務方可能因為處于過載狀態，造成錯誤率上升。這時候如果還是維持原有的請求發送頻率，很有可能造成雪崩。因此當出現這種情況時，我們可以調整請求的發送頻率，將下游服務從雪崩臨界點拯救回來，繼續服務。具體來說就是當錯誤率達到閾值時，觸發熔斷機制，丟棄對下游的請求，以防止被下游拖掛；然后熔斷器會逐步嘗試恢復一些請求，并決定熔斷器是保持生效的狀態，還是逐步解除。

丟棄流量是指在服務發出實際需求大于穩定閾值時，丟棄部分流量作為維穩手段，通過犧牲一些能力的方式來保持一定的可用性，防止超出閾值后的雪崩。常見的方式有兩種。分別是同等優先級和不同優先級下的。這一點很像河流上下游的水閘控制站。每一個站點都會根據上下游信息來進行實時調控，當下游水位過高時，上游進行一定的截留控制，來減小下游壓力，保證整條河流的壓力在允許范圍之內。

最后是流量限制。是一種防止服務被打掛而進行的限流設置，一般對穩定性較高的服務器都會進行壓力測試，來找到本服務單實例的最大請求數，然后再進行設置。

除此之外，我們還可以增加一些動態的控制，動態判斷服務需要的時間，在達到閾值時進行對服務降級處理。

（4）觀測

觀測是對流量狀態進行記錄和追蹤，盡可能實時地展示出流量運轉狀態，以便我們可以及時發現問題。主要分為三個方向，分布式追蹤、日志收集和指標設定，這三個方向互有重疊也各有不同。

分布式追蹤會把服務的詳細信息進行記錄，使用采樣和染色，為后臺開發的同學提供鏈路數據采集和展示、分析和統計，可以幫助大家快速分析和診斷分布式應用架構下的性能瓶頸，提高微服務時代下的開發診斷效率。

日志收集就是記錄一些logs，包括幾種方式，流式日志、錯誤日志聚合、日志流檢索和調用鏈檢索。流式日志就是對日志進行中央存儲，日后可以對每個時間進行查看。錯誤日志聚合就是對所有日志中的錯誤信息進行整合，然后讓開發人員只分析錯誤出現的地方。日志流檢索和調用鏈檢索就是日志和調用情況進行快速檢索，已達到快速找到錯誤的能力。

指標是指建立一套指標系統，提供存儲時序數據和對時序數據進行聚合查詢的功能。包括一些報警閾值的設定等等。

四、總結

本文主要介紹了字節跳動中對微服務流量治理的幾個方向和具體方法。其中包括四個大方向，分別是路由、安全、控制和觀測。通過這四大方向對上下游服務進行實時調控和調整，已達到穩定整個微服務架構的效果。

本文整理自華為云社區內容共創活動第二期之【線下分享】字節跳動微服務流量治理體系簡介。

查看活動詳情：https://bbs.huaweicloud.com/forum/thread-111494-1-1.html

微服務

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。