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

背景

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

我們理解的效率

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過(guò)這些平臺(tái)業(yè)務(wù)方可以非常快速的搭建自己的搜索或推薦業(yè)務(wù)，業(yè)務(wù)方只需要有一些基本的搜索常識(shí)熟悉自己的業(yè)務(wù)即可，不需要了解分布式問(wèn)題，不需要有運(yùn)維經(jīng)驗(yàn)，甚至也不用關(guān)心穩(wěn)定性問(wèn)題。這里我們重點(diǎn)結(jié)合Tisplus和搜索業(yè)務(wù)來(lái)介紹。

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

我們結(jié)合Tisplus和我們?cè)谔詫氈魉阉鞣e累的經(jīng)驗(yàn)，把業(yè)務(wù)需要關(guān)注的部分剝離出來(lái)提供可視化的開(kāi)發(fā)和流程支持，不需要關(guān)注的由平臺(tái)來(lái)負(fù)責(zé)，需要平臺(tái)和業(yè)務(wù)共同關(guān)注的則由平臺(tái)提供工具輔助支持。

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

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

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


同時(shí)從開(kāi)發(fā)流程上進(jìn)行完善，提供測(cè)試、冒煙、壓測(cè)等平臺(tái)支持。

算法產(chǎn)品化

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

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


運(yùn)維自動(dòng)化和智能化

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

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



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

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

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

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

如何提升資源效率

我們從兩方面來(lái)看資源的效率，一是“資源利用率”，二是“資源的維護(hù)成本”。

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

所以我們從4個(gè)方面來(lái)提升資源效率：

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

資源的有效管理

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

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

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

資源的分配效率

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

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

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

提升應(yīng)用水位

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

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

資源的自動(dòng)化管理

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

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

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

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

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

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

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

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

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

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

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

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

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


這種簡(jiǎn)單的rpc框架存在很多問(wèn)題：

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

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



這里引入了動(dòng)態(tài)負(fù)載均衡、動(dòng)態(tài)timeout（熔斷）、自動(dòng)降級(jí)、自動(dòng)限流、自動(dòng)擴(kuò)縮容這一系列的概念，還將集團(tuán)的EagleEye結(jié)合起來(lái)。通過(guò)動(dòng)態(tài)負(fù)載均衡解決靜態(tài)權(quán)重的問(wèn)題，動(dòng)態(tài)timeout來(lái)確保server端的異常不會(huì)進(jìn)一步向上傳遞放大，異常流量可以通過(guò)自動(dòng)降級(jí)和自動(dòng)限流來(lái)最大程度上降低對(duì)業(yè)務(wù)的影響，再通過(guò)快速的自動(dòng)擴(kuò)容來(lái)提升集群服務(wù)能力，新擴(kuò)容的replica可能預(yù)熱不充分服務(wù)能力差，又可以通過(guò)動(dòng)態(tài)負(fù)載均衡和自動(dòng)降級(jí)來(lái)平滑過(guò)渡到正常服務(wù)能力的狀態(tài)。自動(dòng)縮容又可以保證我們及時(shí)釋放資源提升資源利用率。通過(guò)EagleEye我們可以對(duì)流量打標(biāo)標(biāo)識(shí)爬蟲流量或壓測(cè)流量，當(dāng)負(fù)載高時(shí)可以優(yōu)先對(duì)爬蟲和壓測(cè)流量進(jìn)行降級(jí)或限流，避免壓測(cè)影響生產(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)定性的角度來(lái)看，A引入了穩(wěn)定性風(fēng)險(xiǎn)，系統(tǒng)本身的穩(wěn)定性是不達(dá)標(biāo)的，應(yīng)該更多的由A來(lái)承擔(dān)責(zé)任。我們對(duì)于故障的定責(zé)和action也重新進(jìn)行了定義，我們希望故障的定責(zé)和action更關(guān)注的是幫助我們的系統(tǒng)向更好的方向演進(jìn)，而不只是完善我們的流程。

案例：

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

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

案例：

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

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

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

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

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

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



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

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

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

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

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

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

案例：

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

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

案例：

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

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

總結(jié)



我們從業(yè)務(wù)效率、資源效率、穩(wěn)定性三方面來(lái)打造搜索和推薦平臺(tái)。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é)合的多機(jī)房容災(zāi)方案。最終目標(biāo)是在不影響業(yè)務(wù)迭代效率情況下達(dá)到4個(gè)9的可用性、以及重大故障在5min內(nèi)快速恢復(fù)。我們通過(guò)一系列的項(xiàng)目逐步完善了我們的系統(tǒng)，包括自動(dòng)降級(jí)和自動(dòng)限流、智能彈性調(diào)度、管控系統(tǒng)、親維、5min故障快速恢復(fù)項(xiàng)目、接入EagleEye等，將我們的經(jīng)驗(yàn)沉淀為“搜索在線服務(wù)穩(wěn)定性規(guī)范”和“搜索業(yè)務(wù)接入規(guī)范”。

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

總結(jié)

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

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