阿里集團搜索和推薦關於效率&穩定性的思考和實踐

02-18

摘要：效率和穩定性是我們從工程層面來衡量系統對業務支持能力的兩個關鍵指標。從流程管控上來看，業務效率的提升一定程度上會影響到穩定性，而對穩定性要求過高又會帶來對業務效率的影響。從業務的角度來看，成熟的業務會更偏向於穩定性，而新業務更偏向於效率。效率和穩定性兼顧，也就變成了一個巨大的挑戰。

作者：李偉-劍豪

原文

背景

效率和穩定性是我們從工程層面來衡量系統對業務支持能力的兩個關鍵指標。從流程管控上來看，業務效率的提升一定程度上會影響到穩定性，而對穩定性要求過高又會帶來對業務效率的影響。從業務的角度來看，成熟的業務會更偏向於穩定性，而新業務更偏向於效率。效率和穩定性兼顧，也就變成了一個巨大的挑戰。

我們理解的效率

通常我們提到「效率」更多的是關注開發效率或迭代效率，我們這裡稱之為「業務效率」。大家通常容易忽視「資源效率」，在阿里集團搜索和推薦現有業務規模下，忽視資源效率的將付出很大的成本。

效率 = 業務效率 + 資源效率

影響業務效率的因素主要有：

開發複雜度
業務迭代流程
業務維護成本
穩定性要求

開發複雜度取決於其生態能為業務的開發提供什麼支持，包括語言層面和業務領域所在的第三方生態、集團層面的二方生態、以及業務所在平台。迭代流程一方面可以保證業務功能的正確性，同時也可以提升線上系統的穩定性，但是複雜的流程會很大程度上影響到業務的效率。如何降低業務開發複雜度，為業務開發提供更強大的生態支持？如何簡化迭代流程且不影響穩定性？如何降低業務的維護成本，提升其穩定性？

影響資源效率的因素主要有：

穩定性要求：通常出於穩定性考慮會適當的降低資源利用率的要求，比如為了應對流量高峰我們需要提前準備容量，為了容災我們需要有一定的容量buffer。
資源的管理和分配方式：傳統靠人來管理和分配物理機效率低下，所以才有了容器技術以及現在docker的大規模應用，但是沒有調度系統的支持docker與傳統vm相比並沒有明顯的優勢，並不能有效解決整體資源利用率低的問題。
長尾業務：傳統人治的方式無法顧及長尾業務，長尾業務由於其業務規模限制必然存在資源浪費。
資源採購交付時間：通常採購交付時間從業務的角度來看是不可控的，為了應對業務未來的資源需求，我們通常需要提前1年提預算、提前半年左右時間提交採購。而這裡時間的把控完全依賴於個人經驗。

提升資源效率最直接的手段當然是讓所有業務提升資源利用率。而運動式的做這項工作成本巨大收益也不一定能達到預期，還會極大的影響到業務效率和穩定性。如何用更低的成本、在不影響業務效率和穩定性的前提下，持續的讓資源利用率保持在合理的範圍內，是否敢於延遲採購交付時間？這是我們的挑戰。

我們理解的穩定性

通常我們對穩定性最直觀的認識就是不core、沒有內存泄露，這也是我們通常穩定性測試的範圍。往往大家比較容易忽視穩定性另外一個重要的因素 ——— Robustness（魯棒性）。我們認為穩定性是在任何情況下都不會出現服務異常中斷或資源泄露，同時在非正常輸入和非正常壓力情況下服務在可接受延遲範圍內正確響應率不低於一定比例。

導致系統不穩定的因素主要有以下幾類：

變更：比如代碼或配置的修改上線。
用戶行為變化：比如大規模推廣導致用戶流量增加。
數據的變化：比如用戶行為變化後導致的行為點擊或PV數據增長、比如商家通過後台系統修改商品數據。
自然因素：比如硬體故障、自然災害。

針對這些因素，通常我們的應對策略有：

變更管控，即封網。封網可以在特定時間範圍內減少由於變更導致的穩定性問題，但是變更通常都是有業務訴求的，在封網結束後變更仍然會執行，只是把風險從一個時間點轉移到了另外的時間。封網也無法避免用戶行為和數據的變化以及自然因素的問題。
擴容。通過增加資源方式提升系統容量以應對用戶行為變化產生的大流量或或數據量的增長，可以有scale-out（增加replica數量）和scale-up（增加單replica資源）兩種方式。擴容不但需要付出資源的成本，而且傳統運維方式擴容響應時間慢。
性能優化。提升單位資源的服務能力，即單replica的容量。但是這通常需要我們投入大量的人力成本，也需要對系統有足夠深入的理解。
限流。通常限流的實現是配置單機或集群整體的最大服務QPS，這裡配置該配多少？隨著業務迭代性能變化如何同步？是否應該從入口限流？
多機房容災。多機房能有效應對自然因素導致的穩定性問題，但是多機房也會增加我們的管理成本，同時要多機房互相災備需要每個機房留有足夠的容量buffer。

由上可以看出現有各種方案能一定程度上解決問題，都存在一定的局限性或缺陷，如何發揮其優點同時彌補缺陷並降低成本，以更有效的提升穩定性，這是我們需要考慮的。

如何提升業務效率

業務效率主要是業務的開發迭代效率和維護成本。我們通過平台化來提升效率，主要有TPP、Tisplus、OpenSearch三大業務平台，支持了阿里集團大部分的搜索和推薦業務。

TPP：淘寶推薦平台，支持了阿里集團內大部分的推薦業務。
Tisplus：阿里集團搜索中台 https://yq.aliyun.com/articles/402309，支持了集團內大部分的搜索類業務。
OpenSearch：阿里雲開放搜索 https://www.aliyun.com/product/opensearch，為阿里雲上的業務提供搜索服務。

通過這些平台業務方可以非常快速的搭建自己的搜索或推薦業務，業務方只需要有一些基本的搜索常識熟悉自己的業務即可，不需要了解分散式問題，不需要有運維經驗，甚至也不用關心穩定性問題。這裡我們重點結合Tisplus和搜索業務來介紹。

對於沒有搜索經驗的團隊，如何搭建搜索系統支持其搜索業務需求。通常其需要考慮很多方面：Query的分析和處理、離線數據的處理、搭建搜索引擎、相關性、A/B Test，複雜一點的還需要考慮個性化、Online Learning。再進一步，隨著業務發展系統規模膨脹，如何對系統進行優化、引擎的行（replica）和列（shard）數量如何配置最優、哪些欄位應該有索引、哪些應該建立聯合索引、是否應該用cache、哪些pattern對性能影響較大可以優化、如何做容災、如何提升系統的穩定性？解決這些問題需要具備豐富的搜索引擎、演算法和分散式系統經驗。

我們結合Tisplus和我們在淘寶主搜索積累的經驗，把業務需要關注的部分剝離出來提供可視化的開發和流程支持，不需要關注的由平台來負責，需要平台和業務共同關注的則由平台提供工具輔助支持。

業務開發和流程可視化

從開發層面，對離線數據處理和引擎進行封裝，提供可視化的開發，對於複雜的業務邏輯，也可以通過簡單腳本的方式來描述，所見即所得。

對於離線數據處理，用戶通過我們基於Blink的組件平台進行可視化的開發，描述數據之間的關係，提交後就會自動生成相應的Blink job。對於引擎，通過可視化配置數據源、schema、插件，提交後就會自動搭建引擎服務，並提交任務到Build Service build索引。對於業務邏輯，則通過業務層SP（Search Planner）提供的嵌入式腳本（Lua）機制來開發，同樣可以在web console里進行開發、調試。

同時從開發流程上進行完善，提供測試、冒煙、壓測等平台支持。

演算法產品化

對於一些常用的演算法，技術上可能涉及到多個分散式系統角色的協調以及離線的數據分析處理，而業務上來看不同的業務有很大的共性。將這些演算法特性沉澱為Tisplus平台的產品功能，業務方只需要通過簡單的配置即可以使用。

以個性化演算法為例，不同的業務會有不同的item數據和用戶群體，用戶行為也會各有差異。基礎的用戶行為有展現、點擊，而電商類的還會有收藏、加購、購買等行為。接入Tisplus的業務會統一收集所有的行為日誌。業務方可通過基於Blink的組件平台和機器學習平台Porsche提取特徵訓練模型，自動同步到Rank Service。也可以產出i2i（item-to-item）和u2i（user-to-item）等數據，自動同步到iGraph（圖檢索引擎）。在線查詢時SP會先調用iGraph獲取i2i和u2i信息，再調用Ha3進行檢索，然後再調用Rank Service進行排序，給出最終的搜索結果。

運維自動化和智能化

我們強調devops，並不是直接把ops的工作交給業務方，人治的方式並不能解決運維問題。我們希望業務是由業務方負責，但是其只需要關注業務相關的運維操作，比如業務的發布、系統容量規劃。其它的比如機器故障、監控、報警等問題，則應該完全由平台來負責。業務方關注的業務的發布和系統容量規劃，平台也應該盡量降低其門檻。發布過程中如何保證系統的可用性？如何避免發布業務功能異常導致故障？容量該如何評估，單replica性能怎麼樣？什麼時候該擴容什麼時候該縮容？

基於集團的Sigma調度系統，結合搜索的業務，我們打造了搜索的業務調度平台Hippo。所有搜索的系統都由Hippo從Sigma申請資源進行調度。同時我們每個系統都有其對應的二層調度（即ApplicationManager）和管控系統。二層調度主要的職責是從一層調度（即ResourceManager）申請資源、部署業務、業務拓撲結構管理、rolling、節點遷移、自動更換異常節點、節點數據同步name service，並提供各種操作的API。管控系統主要是提供可視化的用戶操作入口、管理流程、管理多個機房/集群。對於無數據的服務，其二層調度是Carbon/Fiber，管控系統是Drogo。對於有數據的服務，其二層調度是Suez Admin，管控系統是Suez Ops。我們通過調度系統和管控系統，實現大部分的運維功能自動化。調度系統通過rolling機制加上最小可用度保證在任何情況（發布、重啟）下服務的可用性。

通過智能的彈性伸縮，來動態適應業務流量的變化。對於特定的運營活動可能產生的突發流量，業務方可以提前錄入其活動起止時間，調度系統也會作為將其作為演算法決策的輸入。同時我們通過對整個數據反饋、調度和決策鏈路進行優化，對於無數據的服務其調度響應時間可以做到秒級，讓系統有足夠的能力應對異常情況。接下來我們在穩定性里還會再提到智能彈性伸縮。

通過離線分析數據和日誌，對引擎的部署和配置給出優化建議，比如行列如何分布最優、哪些欄位應該增加索引。這裡的優化建議還會從平台的角度結合全局資源情況來定，比如從平台角度考慮到調度系統資源分配可能存在資源碎片，我們希望部分業務能適當拆分，用更多的行和列、每一個instance佔用更少的內存和CPU。雖然從業務本身的角度來看並不是最優，但是從平台的角度會有非常大的好處。我們跟iDST演算法團隊合作，給出智能的全局優化建議。

通過kmonitor（監控平台）和烽火台，業務新接入後自動創建相應的監控和報警並將報警轉換為事件，同時kmonitor還會對業務的metrics進行檢測發現異常點並轉換為事件。再通過kmon watch指定事件的處理方式，可以是報警，也可以是其它的定製化處理手段。

通過壓測平台，我們定期跟蹤業務帶來的性能變化，同時在業務做容量規劃的時候給出參考建議。TPP上千個場景在雙11預熱期甚至雙11當天都會有頻繁的變更，我們通過daily run每天跟蹤場景的性能並在每次變更後自動run，保證每一個場景演算法變更後系統的穩定和容量。壓測平台還支撐了搜索和推薦大規模的全鏈路壓測，由於個性化和cache對系統整體性能影響較大，所以搜索和推薦的壓測需要極大的query量，壓測平台結合我們的調度系統，充分利用碎片資源實現極低的資源消耗。

如何提升資源效率

我們從兩方面來看資源的效率，一是「資源利用率」，二是「資源的維護成本」。

資源利用率 = (可用的機器數 * 調度系統分配率 * 應用水位) / 總機器數

所以我們從4個方面來提升資源效率：

有效的管理機器提升可用機器數，降低閑置機器數及閑置時間
提升調度系統分配效率
提升應用水位
降低資源維護成本

資源的有效管理

這裡我們提到「可用的機器數」，那不可用的機器是哪些呢？當然我們並不是指這些機器沒用，而是指在我們資源緊缺比如大促過程中不能有效發揮出作用的機器。比如老舊機型由於機型性能差無法跟其它機型混用、比如我們的線下測試環境、預發環境、A/B Test環境、大量長尾應用只需要極少cpu就佔用1台物理機的情況。

我們將所有機器統一加入Sigma和Hippo統一管理，低配機型可以由長尾使用，甚至後續在調度系統支持下可以低配與高配機型混用。各種非生產環境可以快速拆除恢復，每次全鏈路壓測前拆掉，壓測結束後恢復。所有的長尾應用統一遷移到Drogo，不再有獨佔物理機的應用。通過Drogo提供的彈性伸縮和自動更換異常節點、自動的監控報警又能降低長尾業務的管理和運維成本。

同時我們通過應用的一鍵部署和一鍵建站，加快應用的部署效率，新的機器交付後可以快速投產。這樣提交採購的時間也就可以盡量延遲，降低我們採購機器閑置的成本。目前我們可以一鍵部署基礎設施，在一些新機房的建站中得到了應用，後續再擴展到業務的一鍵部署。

資源的分配效率

搜索的所有在線資源都由Hippo統一管理分配，各個應用申請的資源規格不一，自然也就有了資源碎片問題。如何有效降低碎片提升資源分配率？我們做了兩方面的嘗試，也取得了較好的結果。

碎片整理。通過搬遷任務，將合適的幾個應用compact到一台物理機讓物理機的資源分配率最大化。同時還需要考慮同一業務的分布盡量按物理機打散，甚至部分系統由於埠資源問題只能在一台物理機上部署一個instance。碎片整理要求我們所有的任務（離線/batch/streaming/service）都需要具備可動態遷移（起新下老）的能力，Carbon為所有調度系統提供了動態遷移基礎能力的支持。
拆分足夠多的小規格（0.1 ~ 4 core）容器。一是長尾業務對於性能要求不高，其可以分配小於1core的容器，通過share CPU使用碎片資源。二是結合我們前面提到的跟iDST演算法團隊合作的智能全局優化建議，讓合適的業務拆分出足夠多的小規格容器，能夠最大化使用碎片資源。

通過這些措施，我們在壓測階段將Hippo整體的分配效率提升到了95%，在雙11期間也保持在90%以上。這些離不開我們跟iDST演算法團隊合作進行的計算資源優化，讓我們的調度系統和決策系統真正的智能化。

提升應用水位

通過西彌斯（資源運營系統），我們跟蹤線上各系統對資源的使用情況，包括其資源使用總量、水位情況。同時結合智能擴縮容，以及預算和Quota，對於水位不達標的應用，限制其擴容和預算，同時降低其Quota。對於高水位運行的應用由於由智能擴容的支撐，也無須擔心穩定性問題。從而可持續的推動應用提升水位。

由於業務本身具有流量周期性特徵，在流量低谷期資源消耗低，加上系統為了容災而預留的容量buffer，所以從全天來看整體的平均資源利用率仍然很低。我們通過在離線混部，在離線任務充分利用這些閑置的資源，從而提升整體資源的水位。

資源的自動化管理

我們機器數量到了一定規模後，硬體異常也就成了常態，降低硬體異常的處理成本很大程度上降低了我們的管理成本。

通過接下來我們將要介紹的穩定性手段，我們把硬體異常對業務的影響降到最低，然後通過西彌斯，我們實現從故障機器檢測 -> 下線 -> 維修 -> 重刻系統 -> 初始化 -> 上線，全部的自動化處理。

同樣作為基礎設施，機器的內核版本管理、操作系統配置、虛擬IP中間件環境的管理，這些也都是我們「資源」管理的一部分。我們要保障生產環境所有機器內核和系統配置的一致性、保障IP中間件環境的正確性，同時提供對於內核灰度、升級的支持。

效率提升帶來的穩定性問題

平台化的好處很明顯，極大的提升了業務效率，新業務接入成本低，業務可以低成本試錯創新。從平台的角度還可以全局優化提升資源效率節省成本。

但是平台化也帶來了更大的穩定性挑戰：

平台穩定性問題會放大，平台的問題都是大問題。
長尾業務從平台全局來看規模小不重要，而從用戶的角度來看卻可能是至關重要。長尾的穩定性也需要保證，所以我們不可能通過靠人分而治之的方式來解決問題。
平台為了用戶體驗屏蔽了大量的細節，用戶在對其細節不夠了解的情況下，可能會引入人為的穩定性風險。而我們又不能要求用戶具備很資深的分散式系統運維經驗，否則為什麼還需要用平台？
平台要兼顧資源利用率，我們通過一系列的措施（資源審計、混部）來提升資源利用率，而資源利用率的提升又一定程度上引入了穩定性的風險。

如何提升穩定性

穩定性目標

通常我們用可用性N個9來衡量系統的穩定性，針對不同的可用性目標，系統設計方案上可能會有很大的差異。當可用性目標要求不高時，簡單的通過多replica也許就能達成目標。當可用性目標要達到4個9甚至更高時，從單個服務的角度可能就變成了mission-impossible。比如一個典型的搜索業務，會涉及到至少5個子系統，需要各個子系統都達到99.998%整個業務的可用性才能達到99.99%。

我們把穩定性拆分成「服務穩定性」和「業務穩定性」，分別從兩個不同的方向來共同達成穩定性目標。我們對服務穩定性目標可能低於4個9，但是要保證業務的穩定性目標要不低於4個9。

服務穩定性

服務穩定性的核心是通過一個robust rpc framework來保證我們的服務在各種異常情況下保證其正常服務能力。一個典型的rpc framework如下圖所示：

這種簡單的rpc框架存在很多問題：

靜態權重的問題：我們機型換代周期和過保周期不一致，所以必然存在2代甚至更多不同機型同時服務的情況，不同機型服務能力差異較大。同時在我們大規模容器化和混部的情況下，不同物理機的負載不一致也會對容器的服務能力有所影響。所以靜態權重已經無法保證server的負載均衡。當我們的調度進一步成熟，未來可能會存在不同計算能力的replica，甚至動態調整部分replica的計算能力。
心跳探測機制的問題：通常心跳探測實現採用7層健康檢查（4層健康檢查局限性太大這裡我們就忽略吧），傳統7層健康檢查實現是檢查特定路徑下status文件是否存在並通過HTTP Status Code來進行區分，這已經是腳本或者人肉運維時代的機制。我們現在強調devops，甚至infrastructure as code，需要系統有自動部署的能力，status文件也就退化成了鏡像里的一個普通文件，此時7層和4層檢查的差異也就不大了。另外跟Server的7層健康檢查實現有關，當系統出現異常的情況下，心跳探測請求不一定能反應出系統的異常。就算我們對其實現進行優化，可以讓系統異常的情況下返回404，但是也解決不了心跳探測的網路鏈路跟client實際訪問server的網路鏈路不一致的問題。
單replica服務能力問題：我們通過壓測可以得出單replica的服務能力，但是如果超出其服務能力後會怎樣？超時還是拒絕服務？此時如果其服務能力反應到心跳探測上，更多流量導到其它replica，極有可能產生雪崩效應。我們也可以對Name Service優化通過保護機制避免雪崩，但是當整體流量超過整個集群的服務能力上限後，Name Service也無能為力了。
集群服務能力擴展問題：這裡server可以有多replica，也可以隨時調整replica。但是應該什麼時候調、調到多少？
熔斷問題：server端rt高導致client端資源（連接池或線程池）耗盡，client也就掛了。在多層的分散式服務系統里，問題會逐級向上傳遞，最終導致整體系統所有服務不可用。

為了解決這些問題將rpc framework擴展成robust rpc framework，我們重新設計了其架構：

這裡引入了動態負載均衡、動態timeout（熔斷）、自動降級、自動限流、自動擴縮容這一系列的概念，還將集團的EagleEye結合起來。通過動態負載均衡解決靜態權重的問題，動態timeout來確保server端的異常不會進一步向上傳遞放大，異常流量可以通過自動降級和自動限流來最大程度上降低對業務的影響，再通過快速的自動擴容來提升集群服務能力，新擴容的replica可能預熱不充分服務能力差，又可以通過動態負載均衡和自動降級來平滑過渡到正常服務能力的狀態。自動縮容又可以保證我們及時釋放資源提升資源利用率。通過EagleEye我們可以對流量打標標識爬蟲流量或壓測流量，當負載高時可以優先對爬蟲和壓測流量進行降級或限流，避免壓測影響生產的可用性。這一系列的措施相輔相成，共同保證了我們服務的穩定。

案例：

A線上服務存在bug，B服務在不知情的情況下調用A服務觸發bug導致core，影響生產的穩定性。

從穩定性的角度來看，A引入了穩定性風險，系統本身的穩定性是不達標的，應該更多的由A來承擔責任。我們對於故障的定責和action也重新進行了定義，我們希望故障的定責和action更關注的是幫助我們的系統向更好的方向演進，而不只是完善我們的流程。

案例：

A服務調用B服務，超時時間為150ms，B由於變更性能下降，延遲從50ms增長到100ms，A線程池耗盡導致故障。

這裡的誘因是B，根本原因在於A的超時時間與資源（線程池）設置不匹配。B的性能下降可能是非正常的也可能是正常的，B可能承諾了正常響應時間範圍也可能沒有承諾，這些都不關鍵。A應該保證其線程數量與依賴服務的RT相匹配，這裡並不是要求B一定要承諾其RT，A可以去動態適配，當B的RT超出A承受能力上限後，A應該通過熔斷機制確保自己服務正常，不將B的影響進一步向上傳遞。

案例：

A服務訪問B服務，A服務由於爬蟲流量大加上防爬系統C不完善，導致B服務雪崩完全不可服務。

我們有很多流程上的理由讓A或者C承擔責任。但是為什麼B會完全不可服務？B服務完全可以保證自己的最大服務能力，超出部分可以拒絕服務。所以我們認為B應該承擔更多的責任。

業務穩定性

前面我們提到對單個服務的穩定性要求可以低於4個9，但是業務的穩定性要求要高於4個9。這就要求我們從更高的維度來思考問題。

影響穩定性有兩個重要因素：一是人為因素變更；二是不可預知的非人為因素，比如機房斷電、網路鏈路故障。我們的故障絕大部分的都人為因素導致的，所以首先我們要降低變更帶來的風險。集團有封網制度保障關鍵時期系統穩定，但是封網是以犧牲業務迭代為代價的。我們要在不影響業務迭代的情況下降低變更風險。其次我們要能有效應對不可預知的非人為因素導致的故障。

我們可以對非關鍵業務進行隔離，將非關鍵業務剝離出獨立服務，該服務可以任意迭代發布。所有依賴該非關鍵服務的系統可以結合自己的自動降級和熔斷機制，保證在非關鍵服務在任何異常情況下都不影響主要業務。

同時結合非人為因素的問題，我們可以通過多機房部署，分機房發布來降低變更風險和應對機房非人為因素的故障。

這裡每個機房內部署了一個完整的業務，包括整個服務調用棧涉及到的所有系統。這裡我們把機房當成一個單點，機房內雖然有大量伺服器，但是受限於地理、機房基礎設施、網路設備等因素，其存在很多單點因素。所以我們把一個機房作為一個「單元」，兩個單元就相當於一個業務的兩個replica，其中一個replica出現故障，自然應該把流量導到另一個replica。這也是我們通常提到的「單元化」的概念，而搜索「單元化」相比交易等業務一個顯著的區別在於，我們的多個單元是完全對等的，不需要考慮數據一致性的問題。

多機房或多單元已經不是什麼新鮮的概念，但是還有一些問題沒有明確：

如何降低多機房給業務帶來的維護成本？
如何把變更的影響控制在機房內？
如何快速發現故障？
如何有效提升監控覆蓋率和報警準確率？
故障如何快速止損？
如何降低機房容災的容量buffer的成本？

前面提到我們有管控系統，基於管控系統，要解決這些問題就比較簡單了，我們不只是制定流程規範來約定，還可以將規範變成管控系統的代碼來進行強制約束。所以我們在管控系統里提供了多機房的支持，所有服務都可以低成本部署和維護多機房，同時實現了以下規範：

所有變更必須灰度和分機房發布，機房之間有一定發布間隔。
所有系統的機房發布順序保持一致，避免多個機房同時由於變更導致不可用。
自動化冒煙，冒煙失敗不能繼續發布。
所有監控自動分機房聚合，快速定位故障影響的機房。
重要監控保證在1min內發出報警。
任何情況下可通過管控系統一鍵切流，切流後可以直觀的看到整個鏈路所有系統的穩定性情況。

按我們傳統經驗來看雙機房容災我們的系統水位需要運行在35%以下，三機房容災我們系統水位需要運行在45%以下。由於超線程和其它的一些因素，我們系統的並發能力並不能隨CPU消耗線性增長。也就是說為了極小概率的故障可能性，我們付出了在日常情況下犧牲資源利用率的代價。當我們所有系統都具備了自動降級和自動限流的能力後，在故障發生時我們切流後可以通過自動降級和自動限流承接正常容量之外的流量，可能會對業務帶來短時間的極小的影響，但是卻能讓我們的系統在日常情況下都敢於高水位運行，提升資源利用率。

案例：

A服務依賴於B服務，B服務所支持的功能對業務影響不大。B服務由於變更導致整體超時，A由於B超時導致故障。

這裡B服務是非關鍵服務，A服務把對B服務的依賴變成了關鍵依賴。這是A服務設計的問題。

案例：

A服務使用iGraph，iGraph雙機房部署。其中一個機房由於iGraph變更不可用，另一個機房正常。A服務由於iGraph單機房不可用導致故障。

iGraph的可用性是允許單機房故障的，在單機房故障情況下只要通過name service把流量快速切到其它機房，就可以認為對業務無影響。而這裡A服務完全依賴於單個機房的可用性，這是我們不允許的。

總結

?我們從業務效率、資源效率、穩定性三方面來打造搜索和推薦平台。Tisplus、TPP、OpenSearch支持了大量的搜索和推薦業務，提升業務的效率。我們的調度系統、管控系統、西彌斯，提升資源效率。為了保障業務的穩定性，我們從服務穩定性和業務穩定性兩方面著手，沉澱出了我們的高可用分散式服務框架，以及跟管控系統相結合的多機房容災方案。最終目標是在不影響業務迭代效率情況下達到4個9的可用性、以及重大故障在5min內快速恢復。我們通過一系列的項目逐步完善了我們的系統，包括自動降級和自動限流、智能彈性調度、管控系統、親維、5min故障快速恢復項目、接入EagleEye等，將我們的經驗沉澱為「搜索在線服務穩定性規範」和「搜索業務接入規範」。???????

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎