阿里妹導讀：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建設必須有：
- 提供端對端體驗的全鏈路OPS才是我們認為符合我們場景的devops標準定義。
- 複雜的運維管控鏈路中基於我們常識認知的過程式運維方式需要升級到基於目標驅動式的運維管控。
- 較好的運維抽象及產品抽象，更好的賦能用戶。
- 提高業務迭代效率必須是保障業務穩定性為基礎。
有了這些需求痛點，也就有了我們在這個領域的技術平臺佈局-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，還是業務建站等都將遇到世界級的難題等著我們去挑戰。
無論是web開發，引擎開發還是算法同學，歡迎加入我們阿里搜索中臺團隊
平臺工程師崗位詳情：https://job.alibaba.com/zhaopin/position_detail.htm?trace=qrcode_share&positionCode=GP037395
我們一起讓天下沒有難用的搜索。
閱讀更多 阿里技術 的文章
