https://yq.aliyun.com/articles/465262?spm=a2c4e.11157919.spm-bestcontent.4.146c27aejU0iKh

背景

效率和穩(wěn)定性是我們從工程層面來衡量系統(tǒng)對業(yè)務(wù)支持能力的兩個關(guān)鍵指標(biāo)。從流程管控上來看，業(yè)務(wù)效率的提升一定程度上會影響到穩(wěn)定性，而對穩(wěn)定性要求過高又會帶來對業(yè)務(wù)效率的影響。從業(yè)務(wù)的角度來看，成熟的業(yè)務(wù)會更偏向于穩(wěn)定性，而新業(yè)務(wù)更偏向于效率。效率和穩(wěn)定性兼顧，也就變成了一個巨大的挑戰(zhàn)。

我們理解的效率

通常我們提到“效率”更多的是關(guān)注開發(fā)效率或迭代效率，我們這里稱之為“業(yè)務(wù)效率”。大家通常容易忽視“資源效率”，在阿里集團搜索和推薦現(xiàn)有業(yè)務(wù)規(guī)模下，忽視資源效率的將付出很大的成本。

效率 = 業(yè)務(wù)效率 + 資源效率

影響業(yè)務(wù)效率的因素主要有：

• 開發(fā)復(fù)雜度
• 業(yè)務(wù)迭代流程
• 業(yè)務(wù)維護成本
• 穩(wěn)定性要求

開發(fā)復(fù)雜度取決于其生態(tài)能為業(yè)務(wù)的開發(fā)提供什么支持，包括語言層面和業(yè)務(wù)領(lǐng)域所在的第三方生態(tài)、集團層面的二方生態(tài)、以及業(yè)務(wù)所在平臺。迭代流程一方面可以保證業(yè)務(wù)功能的正確性，同時也可以提升線上系統(tǒng)的穩(wěn)定性，但是復(fù)雜的流程會很大程度上影響到業(yè)務(wù)的效率。如何降低業(yè)務(wù)開發(fā)復(fù)雜度，為業(yè)務(wù)開發(fā)提供更強大的生態(tài)支持？如何簡化迭代流程且不影響穩(wěn)定性？如何降低業(yè)務(wù)的維護成本，提升其穩(wěn)定性？

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

• 穩(wěn)定性要求：通常出于穩(wěn)定性考慮會適當(dāng)?shù)慕档唾Y源利用率的要求，比如為了應(yīng)對流量高峰我們需要提前準(zhǔn)備容量，為了容災(zāi)我們需要有一定的容量buffer。
• 資源的管理和分配方式：傳統(tǒng)靠人來管理和分配物理機效率低下，所以才有了容器技術(shù)以及現(xiàn)在docker的大規(guī)模應(yīng)用，但是沒有調(diào)度系統(tǒng)的支持docker與傳統(tǒng)vm相比并沒有明顯的優(yōu)勢，并不能有效解決整體資源利用率低的問題。
• 長尾業(yè)務(wù)：傳統(tǒng)人治的方式無法顧及長尾業(yè)務(wù)，長尾業(yè)務(wù)由于其業(yè)務(wù)規(guī)模限制必然存在資源浪費。
• 資源采購交付時間：通常采購交付時間從業(yè)務(wù)的角度來看是不可控的，為了應(yīng)對業(yè)務(wù)未來的資源需求，我們通常需要提前1年提預(yù)算、提前半年左右時間提交采購。而這里時間的把控完全依賴于個人經(jīng)驗。

提升資源效率最直接的手段當(dāng)然是讓所有業(yè)務(wù)提升資源利用率。而運動式的做這項工作成本巨大收益也不一定能達(dá)到預(yù)期，還會極大的影響到業(yè)務(wù)效率和穩(wěn)定性。如何用更低的成本、在不影響業(yè)務(wù)效率和穩(wěn)定性的前提下，持續(xù)的讓資源利用率保持在合理的范圍內(nèi)，是否敢于延遲采購交付時間？這是我們的挑戰(zhàn)。

我們理解的穩(wěn)定性

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

導(dǎo)致系統(tǒng)不穩(wěn)定的因素主要有以下幾類：

• 變更：比如代碼或配置的修改上線。
• 用戶行為變化：比如大規(guī)模推廣導(dǎo)致用戶流量增加。
• 數(shù)據(jù)的變化：比如用戶行為變化后導(dǎo)致的行為點擊或PV數(shù)據(jù)增長、比如商家通過后臺系統(tǒng)修改商品數(shù)據(jù)。
• 自然因素：比如硬件故障、自然災(zāi)害。

針對這些因素，通常我們的應(yīng)對策略有：

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

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

如何提升業(yè)務(wù)效率

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

• TPP：淘寶推薦平臺，支持了阿里集團內(nèi)大部分的推薦業(yè)務(wù)。
• Tisplus：阿里集團搜索中臺?https://yq.aliyun.com/articles/402309，支持了集團內(nèi)大部分的搜索類業(yè)務(wù)。
• OpenSearch：阿里云開放搜索?https://www.aliyun.com/product/opensearch，為阿里云上的業(yè)務(wù)提供搜索服務(wù)。

通過這些平臺業(yè)務(wù)方可以非?？焖俚拇罱ㄗ约旱乃阉骰蛲扑]業(yè)務(wù)，業(yè)務(wù)方只需要有一些基本的搜索常識熟悉自己的業(yè)務(wù)即可，不需要了解分布式問題，不需要有運維經(jīng)驗，甚至也不用關(guān)心穩(wěn)定性問題。這里我們重點結(jié)合Tisplus和搜索業(yè)務(wù)來介紹。

對于沒有搜索經(jīng)驗的團隊，如何搭建搜索系統(tǒng)支持其搜索業(yè)務(wù)需求。通常其需要考慮很多方面：Query的分析和處理、離線數(shù)據(jù)的處理、搭建搜索引擎、相關(guān)性、A/B Test，復(fù)雜一點的還需要考慮個性化、Online Learning。再進一步，隨著業(yè)務(wù)發(fā)展系統(tǒng)規(guī)模膨脹，如何對系統(tǒng)進行優(yōu)化、引擎的行（replica）和列（shard）數(shù)量如何配置最優(yōu)、哪些字段應(yīng)該有索引、哪些應(yīng)該建立聯(lián)合索引、是否應(yīng)該用cache、哪些pattern對性能影響較大可以優(yōu)化、如何做容災(zāi)、如何提升系統(tǒng)的穩(wěn)定性？解決這些問題需要具備豐富的搜索引擎、算法和分布式系統(tǒng)經(jīng)驗。

我們結(jié)合Tisplus和我們在淘寶主搜索積累的經(jīng)驗，把業(yè)務(wù)需要關(guān)注的部分剝離出來提供可視化的開發(fā)和流程支持，不需要關(guān)注的由平臺來負(fù)責(zé)，需要平臺和業(yè)務(wù)共同關(guān)注的則由平臺提供工具輔助支持。

業(yè)務(wù)開發(fā)和流程可視化

從開發(fā)層面，對離線數(shù)據(jù)處理和引擎進行封裝，提供可視化的開發(fā)，對于復(fù)雜的業(yè)務(wù)邏輯，也可以通過簡單腳本的方式來描述，所見即所得。

對于離線數(shù)據(jù)處理，用戶通過我們基于Blink的組件平臺進行可視化的開發(fā)，描述數(shù)據(jù)之間的關(guān)系，提交后就會自動生成相應(yīng)的Blink job。對于引擎，通過可視化配置數(shù)據(jù)源、schema、插件，提交后就會自動搭建引擎服務(wù)，并提交任務(wù)到Build Service build索引。對于業(yè)務(wù)邏輯，則通過業(yè)務(wù)層SP（Search Planner）提供的嵌入式腳本（Lua）機制來開發(fā)，同樣可以在web console里進行開發(fā)、調(diào)試。


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

算法產(chǎn)品化

對于一些常用的算法，技術(shù)上可能涉及到多個分布式系統(tǒng)角色的協(xié)調(diào)以及離線的數(shù)據(jù)分析處理，而業(yè)務(wù)上來看不同的業(yè)務(wù)有很大的共性。將這些算法特性沉淀為Tisplus平臺的產(chǎn)品功能，業(yè)務(wù)方只需要通過簡單的配置即可以使用。

以個性化算法為例，不同的業(yè)務(wù)會有不同的item數(shù)據(jù)和用戶群體，用戶行為也會各有差異。基礎(chǔ)的用戶行為有展現(xiàn)、點擊，而電商類的還會有收藏、加購、購買等行為。接入Tisplus的業(yè)務(wù)會統(tǒng)一收集所有的行為日志。業(yè)務(wù)方可通過基于Blink的組件 平臺和機器學(xué)習(xí)平臺Porsche提取特征訓(xùn)練模型，自動同步到Rank Service。也可以產(chǎn)出i2i（item-to-item）和u2i（user-to-item）等數(shù)據(jù)，自動同步到iGraph（圖檢索引擎）。在線查詢時SP會先調(diào)用iGraph獲取i2i和u2i信息，再調(diào)用Ha3進行檢索，然后再調(diào)用Rank Service進行排序，給出最終的搜索結(jié)果。


運維自動化和智能化

我們強調(diào)devops，并不是直接把ops的工作交給業(yè)務(wù)方，人治的方式并不能解決運維問題。我們希望業(yè)務(wù)是由業(yè)務(wù)方負(fù)責(zé)，但是其只需要關(guān)注業(yè)務(wù)相關(guān)的運維操作，比如業(yè)務(wù)的發(fā)布、系統(tǒng)容量規(guī)劃。其它的比如機器故障、監(jiān)控、報警等問題，則應(yīng)該完全由平臺來負(fù)責(zé)。業(yè)務(wù)方關(guān)注的業(yè)務(wù)的發(fā)布和系統(tǒng)容量規(guī)劃，平臺也應(yīng)該盡量降低其門檻。發(fā)布過程中如何保證系統(tǒng)的可用性？如何避免發(fā)布業(yè)務(wù)功能異常導(dǎo)致故障？容量該如何評估，單replica性能怎么樣？什么時候該擴容什么時候該縮容？

基于集團的Sigma調(diào)度系統(tǒng)，結(jié)合搜索的業(yè)務(wù)，我們打造了搜索的業(yè)務(wù)調(diào)度平臺Hippo。所有搜索的系統(tǒng)都由Hippo從Sigma申請資源進行調(diào)度。同時我們每個系統(tǒng)都有其對應(yīng)的二層調(diào)度（即ApplicationManager）和管控系統(tǒng)。二層調(diào)度主要的職責(zé)是從一層調(diào)度（即ResourceManager）申請資源、部署業(yè)務(wù)、業(yè)務(wù)拓?fù)浣Y(jié)構(gòu)管理、rolling、節(jié)點遷移、自動更換異常節(jié)點、節(jié)點數(shù)據(jù)同步name service，并提供各種操作的API。管控系統(tǒng)主要是提供可視化的用戶操作入口、管理流程、管理多個機房/集群。對于無數(shù)據(jù)的服務(wù)，其二層調(diào)度是Carbon/Fiber，管控系統(tǒng)是Drogo。對于有數(shù)據(jù)的服務(wù)，其二層調(diào)度是Suez Admin，管控系統(tǒng)是Suez Ops。我們通過調(diào)度系統(tǒng)和管控系統(tǒng)，實現(xiàn)大部分的運維功能自動化。調(diào)度系統(tǒng)通過rolling機制加上最小可用度保證在任何情況（發(fā)布、重啟）下服務(wù)的可用性。



通過智能的彈性伸縮，來動態(tài)適應(yīng)業(yè)務(wù)流量的變化。對于特定的運營活動可能產(chǎn)生的突發(fā)流量，業(yè)務(wù)方可以提前錄入其活動起止時間，調(diào)度系統(tǒng)也會作為將其作為算法決策的輸入。同時我們通過對整個數(shù)據(jù)反饋、調(diào)度和決策鏈路進行優(yōu)化，對于無數(shù)據(jù)的服務(wù)其調(diào)度響應(yīng)時間可以做到秒級，讓系統(tǒng)有足夠的能力應(yīng)對異常情況。接下來我們在穩(wěn)定性里還會再提到智能彈性伸縮。

通過離線分析數(shù)據(jù)和日志，對引擎的部署和配置給出優(yōu)化建議，比如行列如何分布最優(yōu)、哪些字段應(yīng)該增加索引。這里的優(yōu)化建議還會從平臺的角度結(jié)合全局資源情況來定，比如從平臺角度考慮到調(diào)度系統(tǒng)資源分配可能存在資源碎片，我們希望部分業(yè)務(wù)能適當(dāng)拆分，用更多的行和列、每一個instance占用更少的內(nèi)存和CPU。雖然從業(yè)務(wù)本身的角度來看并不是最優(yōu)，但是從平臺的角度會有非常大的好處。我們跟iDST算法團隊合作，給出智能的全局優(yōu)化建議。

通過kmonitor（監(jiān)控平臺）和烽火臺，業(yè)務(wù)新接入后自動創(chuàng)建相應(yīng)的監(jiān)控和報警并將報警轉(zhuǎn)換為事件，同時kmonitor還會對業(yè)務(wù)的metrics進行檢測發(fā)現(xiàn)異常點并轉(zhuǎn)換為事件。再通過kmon watch指定事件的處理方式，可以是報警，也可以是其它的定制化處理手段。

通過壓測平臺，我們定期跟蹤業(yè)務(wù)帶來的性能變化，同時在業(yè)務(wù)做容量規(guī)劃的時候給出參考建議。TPP上千個場景在雙11預(yù)熱期甚至雙11當(dāng)天都會有頻繁的變更，我們通過daily run每天跟蹤場景的性能并在每次變更后自動run，保證每一個場景算法變更后系統(tǒng)的穩(wěn)定和容量。壓測平臺還支撐了搜索和推薦大規(guī)模的全鏈路壓測，由于個性化和cache對系統(tǒng)整體性能影響較大，所以搜索和推薦的壓測需要極大的query量，壓測平臺結(jié)合我們的調(diào)度系統(tǒng)，充分利用碎片資源實現(xiàn)極低的資源消耗。

如何提升資源效率

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

資源利用率 = (可用的機器數(shù) * 調(diào)度系統(tǒng)分配率 * 應(yīng)用水位) / 總機器數(shù)

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

• 有效的管理機器提升可用機器數(shù)，降低閑置機器數(shù)及閑置時間
• 提升調(diào)度系統(tǒng)分配效率
• 提升應(yīng)用水位
• 降低資源維護成本

資源的有效管理

這里我們提到“可用的機器數(shù)”，那不可用的機器是哪些呢？當(dāng)然我們并不是指這些機器沒用，而是指在我們資源緊缺比如大促過程中不能有效發(fā)揮出作用的機器。比如老舊機型由于機型性能差無法跟其它機型混用、比如我們的線下測試環(huán)境、預(yù)發(fā)環(huán)境、A/B Test環(huán)境、大量長尾應(yīng)用只需要極少cpu就占用1臺物理機的情況。

我們將所有機器統(tǒng)一加入Sigma和Hippo統(tǒng)一管理，低配機型可以由長尾使用，甚至后續(xù)在調(diào)度系統(tǒng)支持下可以低配與高配機型混用。各種非生產(chǎn)環(huán)境可以快速拆除恢復(fù)，每次全鏈路壓測前拆掉，壓測結(jié)束后恢復(fù)。所有的長尾應(yīng)用統(tǒng)一遷移到Drogo，不再有獨占物理機的應(yīng)用。通過Drogo提供的彈性伸縮和自動更換異常節(jié)點、自動的監(jiān)控報警又能降低長尾業(yè)務(wù)的管理和運維成本。

同時我們通過應(yīng)用的一鍵部署和一鍵建站，加快應(yīng)用的部署效率，新的機器交付后可以快速投產(chǎn)。這樣提交采購的時間也就可以盡量延遲，降低我們采購機器閑置的成本。目前我們可以一鍵部署基礎(chǔ)設(shè)施，在一些新機房的建站中得到了應(yīng)用，后續(xù)再擴展到業(yè)務(wù)的一鍵部署。

資源的分配效率

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

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

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

提升應(yīng)用水位

通過西彌斯（資源運營系統(tǒng)），我們跟蹤線上各系統(tǒng)對資源的使用情況，包括其資源使用總量、水位情況。同時結(jié)合智能擴縮容，以及預(yù)算和Quota，對于水位不達(dá)標(biāo)的應(yīng)用，限制其擴容和預(yù)算，同時降低其Quota。對于高水位運行的應(yīng)用由于由智能擴容的支撐，也無須擔(dān)心穩(wěn)定性問題。從而可持續(xù)的推動應(yīng)用提升水位。

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

資源的自動化管理

我們機器數(shù)量到了一定規(guī)模后，硬件異常也就成了常態(tài)，降低硬件異常的處理成本很大程度上降低了我們的管理成本。

通過接下來我們將要介紹的穩(wěn)定性手段，我們把硬件異常對業(yè)務(wù)的影響降到最低，然后通過西彌斯，我們實現(xiàn)從 故障機器檢測 -> 下線 -> 維修 -> 重刻系統(tǒng) -> 初始化 -> 上線，全部的自動化處理。

同樣作為基礎(chǔ)設(shè)施，機器的內(nèi)核版本管理、操作系統(tǒng)配置、虛擬IP中間件環(huán)境的管理，這些也都是我們“資源”管理的一部分。我們要保障生產(chǎn)環(huán)境所有機器內(nèi)核和系統(tǒng)配置的一致性、保障IP中間件環(huán)境的正確性，同時提供對于內(nèi)核灰度、升級的支持。

效率提升帶來的穩(wěn)定性問題

平臺化的好處很明顯，極大的提升了業(yè)務(wù)效率，新業(yè)務(wù)接入成本低，業(yè)務(wù)可以低成本試錯創(chuàng)新。從平臺的角度還可以全局優(yōu)化提升資源效率節(jié)省成本。

但是平臺化也帶來了更大的穩(wěn)定性挑戰(zhàn)：

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

如何提升穩(wěn)定性

穩(wěn)定性目標(biāo)

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

我們把穩(wěn)定性拆分成“服務(wù)穩(wěn)定性”和“業(yè)務(wù)穩(wěn)定性”，分別從兩個不同的方向來共同達(dá)成穩(wěn)定性目標(biāo)。我們對服務(wù)穩(wěn)定性目標(biāo)可能低于4個9，但是要保證業(yè)務(wù)的穩(wěn)定性目標(biāo)要不低于4個9。

服務(wù)穩(wěn)定性

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


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

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

為了解決這些問題將rpc framework擴展成robust rpc framework，我們重新設(shè)計了其架構(gòu)：



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

案例：

A線上服務(wù)存在bug，B服務(wù)在不知情的情況下調(diào)用A服務(wù)觸發(fā)bug導(dǎo)致core，影響生產(chǎn)的穩(wěn)定性。

從穩(wěn)定性的角度來看，A引入了穩(wěn)定性風(fēng)險，系統(tǒng)本身的穩(wěn)定性是不達(dá)標(biāo)的，應(yīng)該更多的由A來承擔(dān)責(zé)任。我們對于故障的定責(zé)和action也重新進行了定義，我們希望故障的定責(zé)和action更關(guān)注的是幫助我們的系統(tǒng)向更好的方向演進，而不只是完善我們的流程。

案例：

A服務(wù)調(diào)用B服務(wù)，超時時間為150ms，B由于變更性能下降，延遲從50ms增長到100ms，A線程池耗盡導(dǎo)致故障。

這里的誘因是B，根本原因在于A的超時時間與資源（線程池）設(shè)置不匹配。B的性能下降可能是非正常的也可能是正常的，B可能承諾了正常響應(yīng)時間范圍也可能沒有承諾，這些都不關(guān)鍵。A應(yīng)該保證其線程數(shù)量與依賴服務(wù)的RT相匹配，這里并不是要求B一定要承諾其RT，A可以去動態(tài)適配，當(dāng)B的RT超出A承受能力上限后，A應(yīng)該通過熔斷機制確保自己服務(wù)正常，不將B的影響進一步向上傳遞。

案例：

A服務(wù)訪問B服務(wù)，A服務(wù)由于爬蟲流量大加上防爬系統(tǒng)C不完善，導(dǎo)致B服務(wù)雪崩完全不可服務(wù)。

我們有很多流程上的理由讓A或者C承擔(dān)責(zé)任。但是為什么B會完全不可服務(wù)？B服務(wù)完全可以保證自己的最大服務(wù)能力，超出部分可以拒絕服務(wù)。所以我們認(rèn)為B應(yīng)該承擔(dān)更多的責(zé)任。

業(yè)務(wù)穩(wěn)定性

前面我們提到對單個服務(wù)的穩(wěn)定性要求可以低于4個9，但是業(yè)務(wù)的穩(wěn)定性要求要高于4個9。這就要求我們從更高的維度來思考問題。

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

我們可以對非關(guān)鍵業(yè)務(wù)進行隔離，將非關(guān)鍵業(yè)務(wù)剝離出獨立服務(wù)，該服務(wù)可以任意迭代發(fā)布。所有依賴該非關(guān)鍵服務(wù)的系統(tǒng)可以結(jié)合自己的自動降級和熔斷機制，保證在非關(guān)鍵服務(wù)在任何異常情況下都不影響主要業(yè)務(wù)。
同時結(jié)合非人為因素的問題，我們可以通過多機房部署，分機房發(fā)布來降低變更風(fēng)險和應(yīng)對機房非人為因素的故障。



這里每個機房內(nèi)部署了一個完整的業(yè)務(wù)，包括整個服務(wù)調(diào)用棧涉及到的所有系統(tǒng)。這里我們把機房當(dāng)成一個單點，機房內(nèi)雖然有大量服務(wù)器，但是受限于地理、機房基礎(chǔ)設(shè)施、網(wǎng)絡(luò)設(shè)備等因素，其存在很多單點因素。所以我們把一個機房作為一個“單元”，兩個單元就相當(dāng)于一個業(yè)務(wù)的兩個replica，其中一個replica出現(xiàn)故障，自然應(yīng)該把流量導(dǎo)到另一個replica。這也是我們通常提到的“單元化”的概念，而搜索“單元化”相比交易等業(yè)務(wù)一個顯著的區(qū)別在于，我們的多個單元是完全對等的，不需要考慮數(shù)據(jù)一致性的問題。

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

• 如何降低多機房給業(yè)務(wù)帶來的維護成本？
• 如何把變更的影響控制在機房內(nèi)？
• 如何快速發(fā)現(xiàn)故障？
• 如何有效提升監(jiān)控覆蓋率和報警準(zhǔn)確率？
• 故障如何快速止損？
• 如何降低機房容災(zāi)的容量buffer的成本？

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

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

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

案例：

A服務(wù)依賴于B服務(wù)，B服務(wù)所支持的功能對業(yè)務(wù)影響不大。B服務(wù)由于變更導(dǎo)致整體超時，A由于B超時導(dǎo)致故障。

這里B服務(wù)是非關(guān)鍵服務(wù)，A服務(wù)把對B服務(wù)的依賴變成了關(guān)鍵依賴。這是A服務(wù)設(shè)計的問題。

案例：

A服務(wù)使用iGraph，iGraph雙機房部署。其中一個機房由于iGraph變更不可用，另一個機房正常。A服務(wù)由于iGraph單機房不可用導(dǎo)致故障。

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

總結(jié)



我們從業(yè)務(wù)效率、資源效率、穩(wěn)定性三方面來打造搜索和推薦平臺。Tisplus、TPP、OpenSearch支持了大量的搜索和推薦業(yè)務(wù)，提升業(yè)務(wù)的效率。我們的調(diào)度系統(tǒng)、管控系統(tǒng)、西彌斯，提升資源效率。為了保障業(yè)務(wù)的穩(wěn)定性，我們從服務(wù)穩(wěn)定性和業(yè)務(wù)穩(wěn)定性兩方面著手，沉淀出了我們的高可用分布式服務(wù)框架，以及跟管控系統(tǒng)相結(jié)合的多機房容災(zāi)方案。最終目標(biāo)是在不影響業(yè)務(wù)迭代效率情況下達(dá)到4個9的可用性、以及重大故障在5min內(nèi)快速恢復(fù)。我們通過一系列的項目逐步完善了我們的系統(tǒng)，包括自動降級和自動限流、智能彈性調(diào)度、管控系統(tǒng)、親維、5min故障快速恢復(fù)項目、接入EagleEye等，將我們的經(jīng)驗沉淀為“搜索在線服務(wù)穩(wěn)定性規(guī)范”和“搜索業(yè)務(wù)接入規(guī)范”。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/8446782.html

總結(jié)

以上是生活随笔為你收集整理的阿里集团搜索和推荐关于效率稳定性的思考和实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。