百萬訂單規模系統的技術治理實踐

　　 一、背景介紹　　

　　技術治理結果的好壞往往體現在系統穩定性、研發效率、IT成本這三個方面，過去3年時間裡，我和我的團隊一直在做這三方面的事情，從現在的結果看：

　　系統穩定性從早期的故障頻發到如今故障收斂，並已經接近2年都未發生過嚴重故障；

　　IT單均（每筆訂單的IT花費）過去一年也下降了50%以上，看起來是挺有效果的。

　　接下來我會介紹我們的實踐路徑，以及遇到的關鍵挑戰和應對措施，希望本次分享可以給正在從事這項領域事情的朋友帶來一些參考價值。　　

　　從20年開始到現在，我們的業務訂單規模從大約50w/天發展到現在遠遠超過100w/天，技術團隊規模也從300+人增長到現如今的1000+人，在這3～4年時間裡，技術治理在不同時間階段也採取了不同的處理方式：

　　早期我們會更側重於對研發效率的提升，盡最大可能提升研發專案的迭代效率，支撐業務快速的發展。長期未得到妥善解決的技術債會加劇系統穩定性風險，我們就會切換治理重點，透過演進和改造基礎架構來提升系統高可用性，複雜的基礎架構勢，必會引入更多的架構規則約束，也會影響到研發效率，這個我們是可以接受的；

　　早期業務高速發展時期，更傾向於透過疊加IT資源，來加速技術迭代效率和守護技術穩定性，一般中後期我們就會遇到IT成本的壓力，所以也需要更多的關注IT資源的使用效率，技術治理中提高IT資源最佳化的權重。長期的技術治理過程中，我們很難同時滿足三個方面，以最大化支援公司業務發展考慮，在一些“平衡點”前後需要做一些側重點的切換。

　　接下來，我會從基礎架構演進、穩定性保障和IT成本治理這三個方面分享下團隊過去幾年裡的實踐總結，尤其是關鍵技術方案選型、取捨的背後思考邏輯，和一些建議。

　　 二、基礎架構的演進　　

　　基礎架構的演進需要遵循最優滿足業務核心訴求原則，隨著網際網路行業技術的發展沉澱，現在技術架構的實現與落地的門檻越來越低，架構師比較容易設計和交付出先進的技術架構方案和方案落地規劃，但先進的技術架構不一定是業務核心訴求的更優解。我們演進基礎架構主要遵循兩個思考點，作為背後的驅動力：

　　技術支撐業務快速發展，對研發效率和穩定性的訴求，即技術要快又穩

　　研發效率和穩定性對基礎架構的要求

　　「領先業務“半步”，不過度演進」是我們對演進節奏的把控，從2019年以“多個大單體服務架構”演進到2023年的“多泳道架構”，每一次的架構升級都是做增量設計，對現有執行時環境、中介軟體進行改造，幾乎不會對業務研發產生影響，也不需要業務研發投入大量時間配合改造。同時，每一次架構升級都很好的解決了當期的核心痛點：

　　2020年，基礎架構由PHP單體大服務升級到泛服務化架構，解決了業務研發對服務化治理的訴求，也無需進行大規模的老程式碼重構；

　　2021年，在微服務架構基礎上支援全鏈路灰度能力，支援全鏈路灰度高峰期釋出，一個物理環境輕易就能快速構建出多個獨立的邏輯鏈路環境，解決了研發和測試同學當期的工作效率問題；

　　2023年，在全鏈路灰度架構基礎上對流量標識、閘道器、資料儲存等進行改造，演進到多泳道架構，單個泳道對應單個物理AZ，一個請求的後端事務處理儘可能在單泳道內閉環，支援AZ機房容災容錯能力。　　

　　依據實踐經歷，有三個方面是我們格外注意的：

　　儘可能對上層服務、應用架構不侵入

　　儘可能不造成業務研發大面積的配合改造

　　團隊熟悉的技術

　　因為基礎技術架構本質是由一組技術規則構成，規則從流量排程、請求路由、服務呼叫、資料讀寫等多方面進行了約束，且不能被打破，它天生就造成對業務技術架構的侵入，影響了靈活性，所以好的基礎架構儘可能減少對上層應用的侵入是非常重要的；此外，選擇團隊和業務研發同學他們最熟悉的技術通常是最優的選擇，不要過於追求先進技術。

　　我們早期的系統是由多個內部PHP服務（服務臃腫，單個core服務包含幾百個介面很常見）組成，內部服務之間主要透過域名+HTTP方式相互通訊，服務間通訊沒有標準的資料協議規範、缺乏基本的服務治理能力。隨著業務規模增長和系統整體複雜度上升，我們決定向微服務架構演進，就遇到了要麼一刀切大規模改造、要麼緩慢治理的選擇問題：

　　一刀切：採取成熟的開源SOA框架（像SpringCloud或dubbo），直接把我們的PHP服務按照SOA規範改造成標準SOA服務。這個思路的最大問題是影響面廣，涉及到每一個團隊，改造工作量巨大，改造週期會比較長，可能會影響正常業務需求的日常交付上線，對處於高速發展期的業務來說難以接受；

　　semi-SOA：避免一刀切，研發可以根據自身情況按需擇時重構，先初步具備服務治理能力。

　　最終，我們選擇了semi-SOA的方案（一種類似於半服務化思路、內部我們稱呼為泛服務呼叫），透過semi-SOA讓新老PHP服務、以及新老Java服務之間可以方面的互通互聯，同時整體系統又具備服務化治理能力，最重要的是所有業務研發團隊不需要立即參入大規模改造，這種“過渡型技術方案”給研發團隊預留了充足的按需改造時間，有條件的業務研發團隊可以先行改造，去PHP化，新的Java服務與現存PHP服務之間又可以很好的相容。　　

　　我們大約每間隔1年時間都會進行一輪基礎架構的演進迭代，一方面是為長期大方向做一些儲備，另一方面是僅解決短期即將遇見的需求問題，2023年進入多泳道架構（一種跨AZ的高可用架構），驅動我們做這件事情主要有兩個方面：

　　業務發展訴求，即是系統穩定性要求，2022.4我們就發生過因底層硬體變更引發150臺機架當機故障，我們業務系統癱瘓且無法恢復，只能等廠商修復；

　　業務對系統故障容忍度降低了，系統不可用導致的業務損失比較大了，需要我們考慮為這種低頻事件買一份“保險”，做更多的投入。

　　並未將基礎架構直接演進到同城雙活，主要是考慮成本，一方面IT資源成本，另一方面是研發改造成本；另外就是單AZ機房環境下系統穩定性還有很多提升的空間，我們認為這樣的“保險”程度目前是最合宜的。

　　 三、技術保障的取捨　　

　　做好技術保障，防範系統穩定性風險的發生是技術治理過程中一個重要目標，過去4年時間裡，我們的穩定性保障經歷了三個階段，每個階段都制定了差異化的核心建設，透過階段性的迭代達到目前的體系化，系統故障數量從階段一時期的不理想狀態慢慢穩定下來，到目前達到了健康狀態。

　　階段一：活下來

　　早期階段，我們更重視基本能力的建設，也就是守住關鍵戰場的基本盤能穩定性下來，早期的監控告警平臺、限流降級工具、生產環境變更規範都是需要重視的戰場。

　　階段二：規範、工具建設

　　當整體穩定下來後，所有工程師在日常系統變更、服務上線都有了穩定性意識，大家都在按照統一的規範進行操作，遇到問題都會按照規範進行應急處理了。接下來階段二我們會更關注效率和精細化的提升，我們成立了全職NOC團隊專門對系統進行盯盤和檢測、第一時間啟動應急，也補齊了像容量壓測等工具平臺的建設，進行深度的業務服務鏈路風險的治理。這個階段，應急處理效率、故障止損時效都有了具體的提升。

　　階段三：體系化建設

　　最終，我們的焦點是如何保障長期不出故障，儘可能防範黑天鵝和灰犀牛事件的發生。這個時期，除了工具能力、規範體系的不斷完善外，會更加重視穩定性保障專案的日常運營，一些簡單的事情會重複反覆的去做，堅持高質量的去做（譬如：每天都會對當日發生的隱患事件進行復盤，渴望發生共性問題，從而反哺回進一步最佳化工具和體系）　　

　　回顧我們整個穩定性保障的經歷，無論是早期的搭建工具能力、完善規範，還是中後期建制度和保障體系，都不是一帆風順，也經常遇到因服務雪崩導致故障止血不及時、忘記設定告警導致不能早起發現問題、共性的隱患在服務鏈路上未治理徹底或重新滋生導致故障等等，我們總結有三個關鍵地方需要格外做好：

　　1）保持極大的耐心，持續的高質量做好日常“重複性”的事情，譬如鏈路服務的梳理和治理我們會間隔半年時間就會重複做一次，除了維護業務鏈路架構和理性外，也解決過去半年新引入的問題；在日常發生的穩定性隱患事件（非故障或冒煙）後，也會在當日就閉環覆盤，找出隱患發生的根因，舉一反三；

　　2）穩定性保障最大的挑戰之一就是效率，長期始終如一的投入很多研發時間到穩定性上是很難的，所以凡事能提升研發在穩定性保障上的效率非常重要。模板告警是我們過去設計的一種智慧告警的工具功能，它非常有用，我們將服務執行時狀態中通用的地方（譬如：服務某種型別的異常數量同環比波動超過30%）都支援了模板告警，無需研發主動配置告警，即節省了研發大量時間，也避免了研發漏配或錯配；

　　3）如何長期獲得一個好結果（不發生故障）是我們追求的終極目標，除了在技術上、人員素質上要持續提升外，我們認為有2個理念非常重要：

　　規範體系需要具備自我迭代能力，過去定義的規範不一定最適配當下，所以我們每次在事件覆盤中都渴望發現一些整改代辦項，完善當前的規範體系；

　　不僅僅要做應急預案的技術功能性演練，其他任何預期性質的SOP都儘可能開展演練，把演練變成日常的一種習慣，這樣才能儘可能保證當發生非預期事件（故障、冒煙）時你的所有預期內的工具、SOP都能正常表現

　　穩定性日常運營　　

　　最後想和大家聊一下「穩定性日常運營」在我們的實踐中起到的巨大作用。

　　穩定性規範和應急能力隨著規模增長、系統複雜度上升後是需要重新迭代的，迭代的方向和內容是依靠日常運營中不斷的收集和統計，譬如NOC團隊會收集每一天發生的所有隱患事件並給事件打上各種標籤，每個月都會分析它們，會嘗試發現是否有異常的標籤型別，並反饋給工具團隊或者SOP規範定義團隊進行最佳化。

　　日常運營也有多種運營級別，當系統、團隊、日常趨勢狀態都比較平穩的時候，運營級別是最低檔的，最低檔運營級別對投入的要求最小，當趨勢狀態糟糕時會調升運營級別，這是一種靈活的方式來平衡穩定性保障與研發投入的做法，當然日常運營的方式方法非常多，這裡不做詳細展開了。

　　總結下，日常運營可以幫助我們持續發現更多的瑕疵和漏洞，並反哺回規範機制與工具能力，運營內容涉及到規範、演練、技術治理、文化考試等多方面，它有效的防範了大家長期做一件事情的過程中容易導致的疏忽、犯錯風險。

　　 四、IT成本如何管治　　

　　最近幾年，大家都在做降本增效，IT資源成本是大頭。我們過去2年把IT單均數值最佳化下降了50%以上，主要有兩個原因：首先最重要是早期業務快速發展時期，我們對IT資源使用效率關注是不夠的，所以在調整使用方式、做一些基本的技術最佳化後就有了明顯的提升；另外就是建立起資源使用規範（包括不限於：資源分攤、預算管理、成本視覺化、成本異常檢測等等），杜絕不合理資源使用的產生。

　　其實，IT成本治理的關鍵點是IT資源是否做到了很高程度的科學使用，資源效率是不是達到了健康水平，唯省錢目的是不對的，這可能會對業務發展帶來損害，如果取得了IT成本治理結果而導致穩定性風險或者研發效率大大降低，那這樣是不划算的，大家根據自己公司業務發展情況平衡看待吧。　　

　　我們在IT成本治理過程中，也發現了很多有意思的地方經驗技巧，比方說你可以聯合公司採購團隊去和供應商重新談判，嘗試爭取更優惠的商務折扣，往往會立竿見影。

　　上圖，是我們進行IT成本治理最佳化的方法矩陣，矩陣中的“降低價格/價”就非常管用，我們對不同業務模組的資源採取合理的RI(1/3年)、Savingplan、Spot/Ondemand等購買方式可以極大降低資源購買成本；其餘最佳化方法措施不進行詳細介紹了，大家可以自行查閱。