從 Pulsar Client 的原理到它的監控面板
背景前段時間業務團隊偶爾會碰到一些 Pulsar 使用的問題，比如消息阻塞不消費了、生產者消息發送緩慢等各種問題。雖然我們有個監控頁面可以根據 topic 維度查看他的發送狀態，
圖片
技術治理結果的好壞往往體現在系統穩定性、研發效率、IT成本這三個方面，過去3年時間里，我和我的團隊一直在做這三方面的事情，從現在的結果看：
接下來我會介紹我們的實踐路徑，以及遇到的關鍵挑戰和應對措施，希望本次分享可以給正在從事這項領域事情的朋友帶來一些參考價值。
圖片
從20年開始到現在，我們的業務訂單規模從大約50w/天發展到現在遠遠超過100w/天，技術團隊規模也從300+人增長到現如今的1000+人，在這3～4年時間里，技術治理在不同時間階段也采取了不同的處理方式：
接下來，我會從基礎架構演進、穩定性保障和IT成本治理這三個方面分享下團隊過去幾年里的實踐總結，尤其是關鍵技術方案選型、取舍的背后思考邏輯，和一些建議。
圖片
基礎架構的演進需要遵循最優滿足業務核心訴求原則，隨著互聯網行業技術的發展沉淀，現在技術架構的實現與落地的門檻越來越低，架構師比較容易設計和交付出先進的技術架構方案和方案落地規劃，但先進的技術架構不一定是業務核心訴求的最優解。我們演進基礎架構主要遵循兩個思考點，作為背后的驅動力：
「領先業務“半步”，不過度演進」是我們對演進節奏的把控，從2019年以“多個大單體服務架構”演進到2023年的“多泳道架構”，每一次的架構升級都是做增量設計，對現有運行時環境、中間件進行改造，幾乎不會對業務研發產生影響，也不需要業務研發投入大量時間配合改造。同時，每一次架構升級都很好的解決了當期的核心痛點：
圖片
依據實踐經歷，有三個方面是我們格外注意的：
因為基礎技術架構本質是由一組技術規則構成，規則從流量調度、請求路由、服務調用、數據讀寫等多方面進行了約束，且不能被打破，它天生就造成對業務技術架構的侵入，影響了靈活性，所以好的基礎架構盡可能減少對上層應用的侵入是非常重要的；此外，選擇團隊和業務研發同學他們最熟悉的技術通常是最優的選擇，不要過于追求先進技術。
我們早期的系統是由多個內部PHP服務（服務臃腫，單個core服務包含幾百個接口很常見）組成，內部服務之間主要通過域名+HTTP方式相互通訊，服務間通訊沒有標準的數據協議規范、缺乏基本的服務治理能力。隨著業務規模增長和系統整體復雜度上升，我們決定向微服務架構演進，就遇到了要么一刀切大規模改造、要么緩慢治理的選擇問題：
最終，我們選擇了semi-SOA的方案（一種類似于半服務化思路、內部我們稱呼為泛服務調用），通過semi-SOA讓新老PHP服務、以及新老Java服務之間可以方面的互通互聯，同時整體系統又具備服務化治理能力，最重要的是所有業務研發團隊不需要立即參入大規模改造，這種“過渡型技術方案”給研發團隊預留了充足的按需改造時間，有條件的業務研發團隊可以先行改造，去PHP化，新的Java服務與現存PHP服務之間又可以很好的兼容。
圖片
我們大約每間隔1年時間都會進行一輪基礎架構的演進迭代，一方面是為長期大方向做一些儲備，另一方面是僅解決短期即將遇見的需求問題，2023年進入多泳道架構（一種跨AZ的高可用架構），驅動我們做這件事情主要有兩個方面：
并未將基礎架構直接演進到同城雙活，主要是考慮成本，一方面IT資源成本，另一方面是研發改造成本；另外就是單AZ機房環境下系統穩定性還有很多提升的空間，我們認為這樣的“保險”程度目前是最合宜的。
圖片
做好技術保障，防范系統穩定性風險的發生是技術治理過程中一個重要目標，過去4年時間里，我們的穩定性保障經歷了三個階段，每個階段都制定了差異化的核心建設，通過階段性的迭代達到目前的體系化，系統故障數量從階段一時期的不理想狀態慢慢穩定下來，到目前達到了健康狀態。
早期階段，我們更重視基本能力的建設，也就是守住關鍵戰場的基本盤能穩定性下來，早期的監控告警平臺、限流降級工具、生產環境變更規范都是需要重視的戰場。
當整體穩定下來后，所有工程師在日常系統變更、服務上線都有了穩定性意識，大家都在按照統一的規范進行操作，遇到問題都會按照規范進行應急處理了。接下來階段二我們會更關注效率和精細化的提升，我們成立了全職NOC團隊專門對系統進行盯盤和檢測、第一時間啟動應急，也補齊了像容量壓測等工具平臺的建設，進行深度的業務服務鏈路風險的治理。這個階段，應急處理效率、故障止損時效都有了具體的提升。
最終，我們的焦點是如何保障長期不出故障，盡可能防范黑天鵝和灰犀牛事件的發生。這個時期，除了工具能力、規范體系的不斷完善外，會更加重視穩定性保障項目的日常運營，一些簡單的事情會重復反復的去做，堅持高質量的去做（譬如：每天都會對當日發生的隱患事件進行復盤，渴望發生共性問題，從而反哺回進一步優化工具和體系）
圖片
回顧我們整個穩定性保障的經歷，無論是早期的搭建工具能力、完善規范，還是中后期建制度和保障體系，都不是一帆風順，也經常遇到因服務雪崩導致故障止血不及時、忘記設置告警導致不能早起發現問題、共性的隱患在服務鏈路上未治理徹底或重新滋生導致故障等等，我們總結有三個關鍵地方需要格外做好：
1）保持極大的耐心，持續的高質量做好日常“重復性”的事情，譬如鏈路服務的梳理和治理我們會間隔半年時間就會重復做一次，除了維護業務鏈路架構和理性外，也解決過去半年新引入的問題；在日常發生的穩定性隱患事件（非故障或冒煙）后，也會在當日就閉環復盤，找出隱患發生的根因，舉一反三；
2）穩定性保障最大的挑戰之一就是效率，長期始終如一的投入很多研發時間到穩定性上是很難的，所以凡事能提升研發在穩定性保障上的效率非常重要。模板告警是我們過去設計的一種智能告警的工具功能，它非常有用，我們將服務運行時狀態中通用的地方（譬如：服務某種類型的異常數量同環比波動超過30%）都支持了模板告警，無需研發主動配置告警，即節省了研發大量時間，也避免了研發漏配或錯配；
3）如何長期獲得一個好結果（不發生故障）是我們追求的終極目標，除了在技術上、人員素質上要持續提升外，我們認為有2個理念非常重要：
穩定性日常運營
圖片
最后想和大家聊一下「穩定性日常運營」在我們的實踐中起到的巨大作用。
穩定性規范和應急能力隨著規模增長、系統復雜度上升后是需要重新迭代的，迭代的方向和內容是依靠日常運營中不斷的收集和統計，譬如NOC團隊會收集每一天發生的所有隱患事件并給事件打上各種標簽，每個月都會分析它們，會嘗試發現是否有異常的標簽類型，并反饋給工具團隊或者SOP規范定義團隊進行優化。
日常運營也有多種運營級別，當系統、團隊、日常趨勢狀態都比較平穩的時候，運營級別是最低檔的，最低檔運營級別對投入的要求最小，當趨勢狀態糟糕時會調升運營級別，這是一種靈活的方式來平衡穩定性保障與研發投入的做法，當然日常運營的方式方法非常多，這里不做詳細展開了。
總結下，日常運營可以幫助我們持續發現更多的瑕疵和漏洞，并反哺回規范機制與工具能力，運營內容涉及到規范、演練、技術治理、文化考試等多方面，它有效的防范了大家長期做一件事情的過程中容易導致的疏忽、犯錯風險。
圖片
最近幾年，大家都在做降本增效，IT資源成本是大頭。我們過去2年把IT單均數值優化下降了50%以上，主要有兩個原因：首先最重要是早期業務快速發展時期，我們對IT資源使用效率關注是不夠的，所以在調整使用方式、做一些基本的技術優化后就有了明顯的提升；另外就是建立起資源使用規范（包括不限于：資源分攤、預算管理、成本可視化、成本異常檢測等等），杜絕不合理資源使用的產生。
其實，IT成本治理的關鍵點是IT資源是否做到了很高程度的科學使用，資源效率是不是達到了健康水平，唯省錢目的是不對的，這可能會對業務發展帶來損害，如果取得了IT成本治理結果而導致穩定性風險或者研發效率大大降低，那這樣是不劃算的，大家根據自己公司業務發展情況平衡看待吧。
圖片
我們在IT成本治理過程中，也發現了很多有意思的地方經驗技巧，比方說你可以聯合公司采購團隊去和供應商重新談判，嘗試爭取更優惠的商務折扣，往往會立竿見影。
上圖，是我們進行IT成本治理優化的方法矩陣，矩陣中的“降低價格/價”就非常管用，我們對不同業務模塊的資源采取合理的RI(1/3年)、Savingplan、Spot/Ondemand等購買方式可以極大降低資源購買成本；其余優化方法措施不進行詳細介紹了，大家可以自行查閱。
陳永庭，貨拉拉 技術總監。貨拉拉技術中心核心基礎設施部(CI)負責人，帶領CI團隊負責公司整體基礎架構的演進，填補、維護基礎技術能力（中間件、框架、工具）保障技術團隊的研發效率，負責全局穩定性和技術保障、資源交付和IT成本治理優化等主要工作。曾就職餓了么、騰訊、WebEx/Cisco，主要專注于中間件和基礎服務的研發、異地多活架構的設計與實施落地。（聯系郵箱：sam1.chen@huolala.cn）
本文鏈接：http://www.www897cc.com/showinfo-26-62361-0.htmlIT降本50%還賊穩！百萬訂單規模系統的技術治理實踐
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 快速在你的Vue/React應用中實現SSR(服務端渲染)
下一篇： 三分鐘帶你搞懂 Future 玩法
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號