在上個月，攜程網剛過完自己的 21 週歲生日。

在年初，聽到了很多關於攜程業務量銳減的新聞，當然這是無法避免的過程。當時我就在想，這樣大體量的公司，如何在“業務量很輕鬆”的情況下，繼續激發人員進行技術開發，保持鬥志？如何繼續修煉技術內功呢？

恰巧在準備 12 月 20 日QCon 全球 軟件開發大會（上海站）的時候，有幸邀請到攜程商旅事業部 CTO 宋濤老師來擔任高可用架構專題出品人，我也藉機問了一些關心的問題。

宋濤加入攜程前，曾在微軟，亞馬遜總部長期擔任技術管理工作，在操作系統內核和雲計算等領域有着豐富的經驗。擔任過 AWS 雲存儲服務技術主管，對系統可靠性，高併發和數據一致性有深入研究。2017 年加入攜程集團，先後擔任機票事業部技術總監，商旅事業部 CTO 等職務。領導研發了攜程新一代機票搜索引擎，顯著提升了高併發查詢下的系統性能和可靠性。架構設計、人才培養、技術改造

宋濤目前在商旅事業部主要負責攜程商旅的技術發展戰略和方向，以及具體的落地方案和計劃。同時負責關鍵項目的架構設計，技術選型以及運維模式。另外，爲技術團隊的管理工作提供指導，OKR 制定和人才培養。目前商旅需要解決的關鍵問題包括：提升系統發佈質量，提高研發產品流轉效率，以及加快對客戶需求的反應速度。

在擔任商旅 CTO 之前，宋濤曾擔任攜程集團機票業務技術總監。很多人都會問技術總監升 CTO 後的工作模式有哪些變化，在認知上需要做哪些轉換。

宋濤說，工作的主要轉變是從一個以執行落地爲主的角色，轉變爲一個以方向及目標設定爲主的角色。另外，CTO 是技術團隊的帶頭人，同時又是技術團隊的代言人。需要能使用非技術性語言和業務團隊以及客戶交流，有效溝通傳遞業務和技術雙方的觀點。

宋濤在微軟 Windows 團隊和亞馬遜 AWS 雲計算團隊工作多年，受兩個公司的工程師文化影響比較大。

這兩個團隊對系統可靠性有着極高的要求，實現方式則各有不同。Windows 團隊通過對代碼和測試的質量提升，來減少問題出現的可能性；AWS 雲計算通過對 DevOps 和敏捷開發的重視，強調質量問題的快速發現和恢復。

在國外多年的工作歷練，某種程度上也幫助了宋濤在處理內部團隊交流和技術選型等方面所遇到的問題。所以，目前對商旅技術團隊的技術水平和運維能力有一個比較客觀的評價，並根據業務需要和當前的現狀，制定合理的目標。基礎架構升級

攜程機票 / 酒旅的業務模型是多元化的，這些特性對基礎架構產生的挑戰可想而知。

攜程機票系統是要實現在高併發情況下的高可用。同時，由於機票搜索需要進行動態的航路分析，航段組合和稅費計算，對實時計算的性能要求很高。宋濤說，爲了補充產品豐富性，機票事業部引入了國際上一些機票分銷系統（GDS）和廉價航司直聯繫統。這些外部數據源的處理要求攜程的系統在高 I/O 的情況下保持較高的性能。

爲了應對這些挑戰，在基礎架構上，攜程針對業務特點進行了持續的技術改造，打造了世界領先的機票引擎。

宋濤在此前的“日均 20 億流量：攜程機票查詢系統的架構升級”演講中詳細闡述了基礎架構的構成：三個獨立的數據中心：可以互相做災備，已實現其中一個數據中心完全宕機情況下，攜程業務不受影響技術棧：攜程 DataCenter 技術棧是採用 SpringCloud+K8s+ 雲服務（海外）模式基於開源 DevOps 構建了整套 DevOps 工具和框架多種存儲方案：攜程內部有可用度比較高的存儲方案，包括 MySQL，Redis，MangoDB……網絡可靠性：攜程非常注重網絡的可靠性，做了很多 DR 的開發，做了很多 SRE 實踐，廣泛推動了熔斷，限流等等，以保證用戶高質量的服務

此外，在基礎架構方面，攜程推動了多數據中心的部署，實現了常規的數據備份和災難恢復演練。在系統架構方面，機票系統對緩存和任務 pooling 進行多次演進，並建立了基於 React Programming 的異步非阻塞的主流程改進。

這裏可以介紹幾個比較典型的架構演進方面的知識點，例如緩存架構的演進，一級緩存使用了 Redis，當時主要考慮讀寫性能好，快速，水平擴展性能強，能夠提高存儲量以及帶寬。

可在當前設計中有兩個侷限性：首先爲了簡單，使用了固定的 TTL，這是爲了保證返回結果的相對新鮮。第二，爲了命中率和新鮮度，研發團隊還在不斷地改善。

其次是緩存架構上，二級緩存最早採用了 MongoDB，其讀寫性能較好，同時支持二級緩存。但也有一些侷限性，多引入一種存儲方式會增加維護成本。其次，MongoDB 的 License 模式使得費用非常高。

針對 MongoDB，研發團隊做了提升，把它切成 Redis，這個改進方案的結果，是成本降低了 90%，讀寫性能提升了 30%。業務需求和體系結構升級換代之間的平衡點

技術要給業務賦能，這是技術團隊的重要價值。宋濤說，針對架構升級可以着重把握兩個點，一是要有前瞻性，一般而言，一個架構能滿足“3 年 5 倍”的業務增長速度，就已經有足夠的前瞻了。

其次，是要能用量化指標發現架構的瓶頸，並用適度的創新來解決瓶頸問題。宋濤在國外工作期間，常聽到的一句話就是“No measurements，no improvements”。要創建多維度的監控指標，用數據來發現系統和架構的瓶頸。在瓶頸確認之後，確實需要下一定的決心，投入資源進行重構。對於其中的關鍵組件，要事先想清楚替代組件的灰度替換計劃。對於複雜度高的核心繫統，在架構升級時，可以先把一部分功能獨立出來，重構之後再以微服務的形式灰度接入原有大的系統，採用小步慢跑的方式逐步實現重構。

另外，有一個思維陷阱要儘量規避，當一個新的 owner 接手系統時，往往由於對原有的系統不太瞭解產生一種不安全感，會有重構的衝動，潛意識裏是希望通過重構來掌握系統細節。這種衝動和真實的技術需求要區分開。

在基礎架構演進的過程中，多數人都會碰到棘手的技術問題，宋濤提到一個緩存演進經歷過一個 Redis 到 MangoDB 又迴歸 Redis 的歷程，其中有一個功能豐富度和系統運維能力的權衡。對於大流量高併發的系統，採用成熟技術並提升團隊運維和災難恢復能力是技術團隊需要優先考慮的問題。

在談到基礎架構的發展是否要先於業務的時候，宋濤說，有 Spring Cloud 的各種開源系統和國內外頭部互聯網的實踐做基礎，基礎架構的前瞻性研究難度已經大幅下降。挑戰比較大的是如何做權衡（tradeoff）。而根據各個公司和業務的情況不同，大家要權衡的因素會差別很大。

對於像攜程這種有 20 年曆史的科技公司，對歷史架構的兼容是一個很大的挑戰，某些場景下甚至是很大的負擔。在對技術趨勢充分了解的情況下，重點技術選型向業界流行標準靠攏會是一個相對穩妥的方案。時刻帶領團隊修煉技術內功

疫情期間，攜程商旅團隊密切跟蹤疫情的進展並積極向客戶提供急需的各項功能服務，其中包括廣泛使用的疫情通告和員工健康管理功能。另外，爲了紓解受疫情影響客戶的財務問題，商旅技術團隊對結算系統進行了多次敏捷發佈，把國家公佈的針對企業的各項財務稅收優惠政策，第一時間落地。同時，根據疫情期間業務量下降的情況，攜程商旅及時調整資源，推動多項技術改造項目，極大的提升了商旅系統的易用性和數據一致性。

伴隨着疫情的緩解，攜程商旅的努力得到了回報，多項業務指標不僅超過去年同期水平，還連創新高，通過質量和服務的提升，進一步鞏固了攜程商旅在市場上的領先地位。

關注我並轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書，點擊文末「瞭解更多」，即可移步InfoQ官網，獲取最新資訊～

相關文章