[[239181]]

　　2015 年底，阿里宣布啟動阿里巴巴集團中臺戰略。戰略定義為：構建符合 DT 時代的更具創新性、靈活性的“大中臺、小前臺”組織機制和業務機制。其中，前臺作為一線業務，更敏捷更快速適應市場，中臺將集合整個集團的數字運營能力、產品技術能力，對各業務前臺形成強力支撐，而集團在中臺布局中一個非常重要的一環便是搜索中臺化，但因搜索技術本身的復雜度和業務規模的挑戰，讓搜索中臺在技術上、產品上都遇到了***的挑戰。

　　面對挑戰，阿里選擇走上中臺開發運維一體化實踐之路。這條路究竟要怎么走？下面跟隨阿里搜索事業部高級技術專家柳明，一起來了解。

　　背景

　　阿里搜索中臺的初心是支持前臺業務更敏捷更快速適應市場的變化，愿景是讓天下沒有難用的搜索，基于初心和愿景我們從 0 到 1 建設搜索中臺 3 年，三年期間在 DevOps、AIOps、offline 平臺化上都有了不少業內前沿的沉淀，而我作為一名阿里搜索老兵，有幸見證了整個阿里搜索中臺的技術發展，所以在這里通過一些我個人有限的經驗跟大家去分享一個后端服務該如何解決規模化、成本、效率、質量問題，朝著平臺化產品前進的經驗。

　　搜索中臺技術發展

　　下圖即是搜索中臺從技術角度發展趨勢的一個判斷，也是經過 3 年多落地實踐的一個過程。

　　可以從圖上看到***個階段應該是我加入阿里的時候，無論是搜索事業部還是開源搜索技術都是靠人來負責系統和業務運維。當時人力資源是隨著業務規模成正比增長的，這期間消耗了大量的人力資源在做著低效而重復工作，這是人工管控的階段。

　　之后隨著經驗沉淀，PE 逐漸發現一些常見重復的運維工作可以通過自動化腳本實現，在一定程度上減少了人力成本，提高了運維效率，也初步有了專家經驗和領域知識沉淀的影子，這是自動化腳本運維階段，這也是絕大部分開源技術體系所處的階段。但是這樣的運維方式天然地分割了開發和運維兩種角色。

　　因為大家的使命不同，讓兩種角色天然的站在了對立面上，開發希望快速迭代，運維希望盡可能保障線上穩定而減少迭代次數，因為大家都知道絕大部分線上故障都其實是因為配置變更和軟件升級導致的，天然的分割造成了相互之間存在著對對方的不信任，所以也就有了雙方***的妥協：固定每周周二和周四的發布窗口進行發布，但這是犧牲了業務運營效率為前提的。

　　其實這里存在了一個系統能力和業務方迭代需求上的一個很大 gap，為了解決上述矛盾基于運維開發一體化的 devOps 概念的全新管控系統建設應運而生，也就有了***階段的開發運維一體化的建設，通過這些 ops 也較好地解決一些發布迭代問題。

　　但是我們的業務場景天然是一個技術體系的管控，所以我們認為 devops 不應該還停留在單個系統開發運維一體化的方法論認知上，所以希望我們的 devops 的定義是單個系統 ops 之上的“ops”，所以本質上我們和集團其他所謂的 devOps 平臺有著非常大本質上的區別。

　　集團比較有代表性 devops 平臺就是天基平臺，它主要解決的是服務源代碼到部署再到升級的一個全過程的管理，面向的用戶本質上還是運維人員。所以在這個基礎上，天基利用 IAC（Infrastructure As Code，基礎設施即代碼）的維度 +Git 管理部署配置去打造產品其實已經足夠，這是一種典型 devops 的平臺設計思路，但是僅僅如此的設計其實對于我們來講也許并不夠，因為對于我們來說我們的用戶是最終用戶，他并不具備線上系統運維專業知識，只看到配置或者 code，他一定會暈菜。

　　所以從根本上來講我們需要將對 DevOps 理解上繼續往前走一步，朝著面向平臺產品化的角度上前進一步：一是對用戶屏蔽配置或者 code 或者領域知識復雜度，二是將系統協同變成一種端對端體驗的管控，因為只有做到了簡化復雜度和全鏈路端對端體驗的管控才能真正讓復雜搜索業務迭代效率得到本質上的提升，為了達成上述 2 個目標我們經過多年努力逐步落地了 sophon、bahamut、Maat 等系統，也取得了很好的業務迭代效率提升。

　　但只做到 DevOPS 對于阿里這樣體量的平臺就***了嗎？顯然不是，全鏈路的 DevOps 只是有效解決了研發、PE、用戶配合效率和用戶使用體驗的問題，但是對于平臺方來講隨著業務規模的急劇膨脹，以及搜索服務類型的復雜多樣及多變，業務跟平臺的矛盾其實又發生了本質性的轉移：如何給在海量規模下為每個業務提供更好的穩定性保障和合理的資源利用率、以及更高的迭代效率等就成為了我們平臺新目標。

　　目前我們基于在 AIOPS 數據化運營的 3 年實踐中落地了 Hawkeye -在線服務優化平臺、Torch-容量治理平臺、Heracles-日常壓測服務化平臺、CostMan-成本服務等系統。這些服務系統幫助平臺在容量管理，日常巡檢、一鍵診斷優化上取得了一定的階段性成果，也讓我們對未來統一集團搜索運維管控，業務數量即使超過 10000+ 規模效應下平臺也能應對自如，樹立了堅定的信心。

　　雖然經過 3 年的數據化運營的實踐，但我們離真正的 AIOps 還有較遠距離，因為之前我們的性能瓶頸分析、問題診斷、故障自愈、復雜運維決策主要還是停留在專家經驗沉淀上，說白了還是把人的經驗沉淀到系統來解決線上運維的問題，而 AIOPS 期待的是用數據和算法能力幫我們自動地發現規律問題并解決問題，從這點上看 AIOps 在我們的平臺依然還有非常多的潛力可挖，所以我們希望未來在效率提升、質量保障、成本優化上能真正借助 AI 的能力幫平臺更好地適應未來的發展。 

　　搜索中臺開發運維一體化實踐-Sophon

　　開發運維一體化-DevOPS

　　在我們介紹開發運維一體化-sophon 的系統前，我們先看看一個稍微復雜搜索場景的業務接入時需要涉及到的系統以及他們是如何協調工作的。

　　從上圖其實大家看到整個系統模塊大致分為 3 大模塊，OPS、Online、Offline。其中如圖所示 Ops 層很明顯分成了在線有狀態服務 ops、在線無狀態服務 ops 和離線 ops。

　　就是說每個服務都是單獨 OPS 進行單獨管控，但實際上如上圖所示一個復雜業務就是一個多服務體系協同的結果，所以在我的記憶里當 tisplus 沒上線前，我們接入復雜業務之前***件事情就是召集在線有狀態服務團隊、在線無狀態服務團隊、離線 DUMP 團隊、業務方、PE 開個會互通下有無，然后安排怎么合作推進這個項目上線，上線后的線上變更和問題處理也是支持群里相互吼：“我已經做完這一步了，你可以做下一步了”，“你稍等下再操作，我還要重新發下”。所以可以想象這樣的業務接入合作效率得有多低，相信大家從我剛才的描述中也能知道為啥我們之前支持 10 來個業務已經是極限的原因了吧。

　　有了這些痛點需求，那再回過頭來說說我們我們在實踐過程中認為復雜搜索系統的 devops 建設必須有：

1. 提供端對端體驗的全鏈路 OPS 才是我們認為符合我們場景的 devops 標準定義。

2. 復雜的運維管控鏈路中基于我們常識認知的過程式運維方式需要升級到基于目標驅動式的運維管控。

3. 較好的運維抽象及產品抽象，更好的賦能用戶。

4. 提高業務迭代效率必須是保障業務穩定性為基礎。

　　有了這些需求痛點，也就有了我們在這個領域的技術平臺布局-Sophon，接下來我們將分章節詳細介紹下該系統。

　　搜索中臺 devops 實踐-Sophon

　　目標驅動式運維

　　什么叫基于目標驅動式的運維？其實乍一聽，會覺得太過于抽象，其實如果聽完我的解釋，你會覺得非常簡單，我們舉個實際搜索的運維場景來說明也許更容易明白為什么我們要提倡基于目標的運維管控。

　　比如我們的搜索系統現在的索引版本是A版本，然后要求系統執行切換索引B版本，但正在 rollingB 版本的時候，我后悔了我要 rolling C 版本。這其實在早些年的時候，線上這種狀況是非常讓人崩潰的，如果這事讓 PE 去做的話 ， 只能殺掉切換流程，檢查系統每個節點到哪一步了，清理中間狀態，重新發起運維流程，可以想象過程式的運維管控方式在復雜運維體系下是多么低效的事情。

　　但如果是基于目標驅動的調度，我們只需要重新給系統設定新的 rolling C 版本，那么系統將會獲得***目標和當前執行漸進的目標進行對比，發現目標狀態存在變化，系統會馬上終止掉當前執行路徑和自動清理系統存在的不一致狀態，開始下放***目標狀態關鍵路徑執行通知，各個節點接受到***命令后開始逐步向新的目標漸進，所以只看最終狀態的漸進式最終一致性運維方式自然而然屏蔽了運維中間狀態的復雜性，讓復雜運維管控變得更加簡單更靈活，這也是為什么我們平臺自上而下所有的運維方式都升級成了基于目標驅動的原因。

　　運維概念簡化

　　我們平臺一直提到從托管到賦能，言下之意是希望讓最終用戶承擔起自己應當要承擔的責任才能享受更強大的搜索能力。但談到要賦能，那也不能將搜索系統復雜的領域知識和運維概念直接暴露給最終用戶，否則這肯定不叫賦能用戶，而是叫做折騰用戶了。所以如何將系統的運維概念簡化，將復雜和潛在領域知識留給系統內部就是 sophon 需要解決的核心問題之一。

　　上圖下方是從 PE 視角看到的各個數據中心的基礎設施和各種在線服務，如果沒有一層管控抽象，讓最終用戶和 PE 看到的是一樣的復雜度，我相信用戶一定會暈菜。

　　所以 sophon 做的一個事情就是將運維管控對象抽象成一組數據關系模型，也就是運維管控模型，如上圖右側所示，但是這一層運維抽象依然足夠復雜，用戶不應該也不需要去了解這層運維抽象，我們應該給用戶看到的是觸達業務場景的業務抽象，所以 sophon 在***層運維抽象之上又抽象了業務抽象，如左上角的三層概念：業務邏輯（插件、配置）、服務（部署關系）、數據（數據源&離線數據處理）。這層的定義用戶是幾乎無成本就能接受的，所以通過 sophon 做到的抽象運維概念和簡化業務概念的能力也讓我們平臺從托管到賦能用戶成為了可能。 

　　穩定性保障

　　sophon 保障服務穩定性主要體現在 2 個方面：

• 當平臺支持越來越多的頭部核心業務，我們需要對業務的搜索服務進行 SLA 保障，同時也能適應各個業務根據自己的穩定性要求進行靈活的在離線服務的部署，同時還需要具備自動容災切換能力。目前 sophon 服務穩定性方面能夠支持搜索在線服務單元化、在離線服務單元化、離線數據冷備部署以及查詢鏈路和數據回流鏈路自動容災切切換的能力，如下圖所示：

• 我們前面提到迭代效率提升有一點就是讓原先基于時間窗口的線上發布迭代變成了可以 24 小時隨時隨地可以發布，但我們說的隨時隨地并不是代表我們只是提供了發布按鈕功能，而不去考慮快速發布過程可能帶來的潛在危險，所以高效且安全的發布迭代才是我們追求的目標，這個背后非常重要的基礎就是我們設計和標準化了一套發布迭代規范。

  例如一次正常的業務迭代，需要經過日常、預發 2 套環境進行驗證，同時在預發發布線上的發布流程中我們加入了多重校驗機制來進行發布的穩定性，比如插件、算法策略升級時，我們會要求 clone 壓測對比，如果性能差距太大，發布流程會被回退，同時基于單機房切流灰度發布和冒煙驗證等能力可以在發布流程里被定義，所以有了 sophon 提供的強大的多重校驗機制和快速容災切換的能力，讓業務快速迭代中再也沒有了后顧之憂，可以將業務運營迭代效率提升到***，如下圖所示：

　　專家經驗沉淀

　　搜索技術體系雖然功能強大，但強大的背后也有很多專業潛規則，所以如果平臺把復雜的運維管控和業務迭代需要遵循的專業知識暴露給普通用戶，用戶肯定歇菜，所以我們在 devops 這層一定要將引擎服務領域知識下沉讓平臺去屏蔽這些復雜性。

　　舉個真實的搜索場景來說，如果業務方有一個字段的修改，但真實情況下一個字段的修改其實是可能涉及到在線和離線的配置聯動修改，換句話說你不能說讓用戶在修改配置的時候讓他判斷我這次修改是只會影響到在線服務、還是影響到離線服務，還是在離線服務都會影響到，此外配置推送需要先離線服務生效還是在線服務先生效，還是說配置必須做全量后一起生效等等，這些都是引擎服務的專家知識。

　　目前我們依靠 sophon devOPS 這層將這些領域知識都在背后默默消費掉了，用戶完全不需要關注這些潛在知識，運維平臺內部會分解復雜運維操作，然后會根據我們定義好的專家運維 DAG 圖來有條不紊分階段的進行運維執行，如下圖所示：

　　通過我們不斷將運維專家經驗沉淀到系統（運維 DAG 執行流程圖），用戶對平臺的使用成本會不斷變小，同時迭代效率也會越來越高。當然如果運維操作變得越來越復雜（比如我們暴露給用戶的業務視角需要涵蓋越來越多的服務），運維 DAG 執行鏈從簡單就會發展到可能存在多種執行分支，那么如何在運維執行中尋找到***執行鏈路就會成為一個有趣的話題（如上圖右邊所示），目前我們稱之為最短路徑選擇，這是智能化運維一個有趣的嘗試，這也是未來我們持續努力的方向。

從系統到全鏈路

　　前面其實也介紹了我們的所有業務場景都是一個技術體系協同的結果，而這個過程中最重要也***挑戰的點便是如何將在線和離線高效協同提供給用戶端對端的體驗。

　　從上圖可以看到最終用戶使用離線數據永遠看到的是可視化數據關系定義和簡單的 dump->Build->switchindex 任務執行列表。但是實際上是我們把所有的復雜度屏蔽掉，系統背后卻是有一個復雜的狀態機在管控在離線的協同，這張圖不打算展開講，整個在離線協同，狀態機不是關鍵，關鍵是我們如何將每個在線搜索業務對離線數據處理的個性化需求轉換成一種抽象，***通過平臺方式來支撐的。

　　在展開介紹離線平臺技術前，稍微跟大家介紹下一個搜索業務對離線處理的普世需求，而這些需求也是沒有離線平臺之前支持復雜業務在離線跨團隊合作中被重復討論過多次的話題。那就是到引擎的業務數據并不是一個簡單的數據庫表，它可能來源于多個同構或者異構數據源，同時每個搜索業務都有全量和增量的需求，所以如何將這些根據業務不同而不同數據源關系處理變成一種高層抽象并且屏蔽內部處理環節和統一增量和全量處理流程就變得非常重要，否則來一個業務我們都要為其實現全量和增量數據處理代碼簡直是不可忍的事情。

　　現在來回顧之前我們離線支持效率低的原因還是我們之前對引擎 schema 定義的數據源都是被弱化成一對對的資源進行抽象和管理，也就導致我們沒有把本應該的基礎的抽象給提煉出來，其實仔細想下來我們目前接入的所有數據資源都是 Dynamic Table，所以如果我們以表的抽象去定義這些資源，那一些通用的類似創建表、刪除表、修改表、增刪改查表數據，定義表之間關系等 API 都應該可以被收斂掉而不會存在重復開發問題，所以有了這樣一個思考，也就有了我們打造離線組件平臺-bahamut 的整體設計思路。

　　平臺支持用戶在平臺畫布上定義好各自數據源信息和表之間關系定義后（我們可以支持異構表之間的 join，例如 odps 和 mysql），我們會將這個前端的 Graph 提交給 Bahamut 進行翻譯，bahamut 將這個前端的 Graph 解析、優化、拆分、翻譯成成若干個 blink 可執行的 graph，比如增量的 syncBlink 、全量的 BulkLoad MR 任務，和 Blink Join 任務等。

　　這里最重要的兩個關鍵的 graph 節點是 merge 和 left join。merge 是將所有的1：1 和1：N關系表的處理通過行轉列到一個 HBASE 中間表，而N：1 的關系處理以下圖的例子來說，我們目前只支持主表N這邊（商品表）驅動，也就是說N這方的通過 blink sync 更新后利用 blink Join 合并 1 這方（即用戶表）成完整的行記錄發送到 SwiftSink（增量）&HDFSSink（全量）最終回流到到 BuildService 構建索引，如下圖所示：

　　通過在線離線管控協同和 BaHamut 組件平臺的打造，可以讓用戶通過可視化的手段就能享受到強大的離線復雜數據關系處理和計算能力，極大地提升了業務支持效率，同時也讓我們平臺成為***個可以整合離線提供在離線端對端體驗的里程碑式的產品。另外我們還在做一件事情將離線能力變成在線服務通用能力，相信不遠的將來離線組件平臺不會是 HA3 搜索場景的離線組件平臺，而是整個搜索在線服務的離線組件平臺。

---

　　本文是阿里搜索中臺技術系列 Devops 實踐的分享，接下來還會陸續推出搜索離線組件平臺、搜索 AIOps 實踐的多篇分享，敬請期待。

　　搜索中臺從 0 到 1 建設已經走過了 3 年，但它離我們心目中讓天下沒有難用的搜索的遠大愿景還離得非常遠，在這個前行的道路上一定會充滿挑戰，無論是業務視角的 SaaS 化能力、搜索算法產品化、云端 DevOps&AIOps，還是業務建站等都將遇到***的難題。