本篇文章內容來自2016年TOP100summit美團●大衆點評高級技術專家,酒店後臺研發組eHome團隊負責人許關飛的案例分享。
編輯:Cynthia算法
許關飛:美團●大衆點評高級技術專家,酒店後臺研發組eHome團隊負責人。新美大高級技術專家。 2012年加入美團,主導了新美大酒店業務從通用團購模式到專業酒店預訂的技術轉型;負責過美團酒店預訂業務系統,平臺系統,目前帶領酒店孵化業務技術團隊。緩存
導讀: 新美大以團購做爲切入點,爲了更好的鏈接用戶與商戶,從2012年開始在酒店、外賣、電影等垂直領域深耕細做。到2016年,美團酒店交易額單日破億,間夜量行業第一。
在酒店業務的轉型和高速發展過程當中,不一樣的階段對系統結構也提出來不一樣的要求,本次分享會經過對幾個階段的系統總體狀況的分析、演化,和你們一塊兒整理業務的不一樣階段給系統帶來的挑戰和機遇,但願能夠爲處於文中某個階段的同窗提供一些思路上的參考。網絡
1、案例背景架構
● 美團酒店從2012年開始,以團購爲基礎,着手酒店業務的精細化發展;
● 2012年~2016年期間,探索並完成了團購業務到預訂業務的升級,預訂業務佔比90%以上;
● 期間酒店業務快速發展,2016年消費額單日破1.5億,單日入住間夜量突破80W,行業第一;
● 在業務轉型升級、快速發展的整個過程當中,不一樣的階段對系統架構的設計帶來了不一樣的挑戰。框架
2、案例解讀運維
咱們將從開始酒店精耕細做到現階段,把酒店系統的整個發展過程分爲4個大階段:決策、落地、支撐、優化。異步
● 決策階段是指咱們須要去思考、肯定之後酒店系統應該如何去發展、纔可以更好的去支撐、推進業務的發展。
● 落地階段是指在作好決定以後,須要將決定的內容逐步落地、實現。
● 支撐階段是指在系統須要可以很好的支撐業務迅猛的發展。
● 優化階段是指在系統的支撐、發展過程,咱們須要經過不斷的優化業務、系統,以更好的推進業務發展。微服務
決策階段工具
首先咱們進入決策階段。性能
在當時的階段中,伴隨着團購業務的發展,已經造成一套完整的團購系統體系,包含全套的供給、數據、售賣流程,包含toB、toE、toC的全套功能,並搭配着相關的基礎設施,如DB、Cache、RPC等,而這一套系統同時支撐着餐飲、電影、酒店、旅遊等20多個大品類。
酒店業務的精細化發展須要咱們在供給、產品、促銷、交易等環節進行進一步的擴充、升級。
擺在面前的是一系列很是常見的問題:老系統支撐難、新系統成本高、業務可行性不確認。
● 老系統支撐難:原有團購系統是全品類系統架構,通用性強,修改、訂製較難,系統歷史「包袱」較重;
● 新系統成本高:若是新建一套系統鏈路長,涉及面廣,改動量大,週期長;
● 業務可行性不確認:不管採起何種方式來看,成本都不會低,而此時咱們對於這個業務方向是不是真正知足用戶需求還存在必定的不確認性。
這是很是常見的場景,也是很是難作的決定。對於很難決定的事情,咱們須要收集更多的信息:
首先,低成本驗證業務可行性。
採起和現有流程較爲鬆耦合的方式實現簡易版業務,以保證能夠確認用戶對此類需求的使用狀況,同時儘可能保持低成本。經驗證,業務方向OK。
第二,典型需求驗證「支撐難」。
經過典型的「價格計劃」需求,驗證團購系統進行定製化開發的成本。通過實際驗證,一個典型的需求持續2個月左右,影響方很是多,而之後相似需求還會有不少。因此,成本基本不可接受。
第三,MVP需求驗證「成本高」。
經過酒店集團接入打造酒店系統MVP版本,以第三方爲供給來源,PC版作出口,實現最簡版邏輯,以確認新建系統範圍、成本。通過實際驗證,週期在2個月左右,成本不小,但基本可控。
通過三方面的驗證得出結論:業務方向OK、複用成本太高,新建成本基本可控。依此得出方案:構建酒店系統(造個輪子)。
落地階段
方向肯定後,咱們進入落地階段。
落地過程當中主要關注三個方面:
● 哪些輪子須要本身造(自建 or 複用):全鏈路中涉及很是多的系統,所有重建成本高,且有部分是能夠重用的,如何取捨。
● 輪子造多大(分 與 合):服務化粒度問題,業務初期需求變更頻繁,小服務協調成本高,大服務穩定性、隔離性差。
● 車不停,怎麼把輪子搞上去(保證業務發展):整個服務構建須要週期,期間會對業務形成較大影響,如何下降影響,保證業務發展。
應對:「自建」 or 「複用」→掐頭去尾,保核心競爭力
構建酒店系統並不意味着全部的輪子都要重造一遍,過程當中遵循幾個原則:
● 掐頭:基礎設施如緩存、RPC框架等複用,保證基礎設施穩定性;基礎服務如用戶、支付、風控等複用,保證之後不一樣業務之間的協做。
● 去尾:對外的統一出口如主搜、推薦、訂單等複用,保證對下游用戶體驗的統一性、簡單性。
● 保核心競爭力:中間業務邏輯部分,關注和業務核心競爭力最核心相關部分。非核心部分「隨緣」,多業務核心部分「要結果」,只酒店核心部分「本身搞」。
應對:「分」與「合」→對內分,對外合
對於分與合的問題,服務化是趨勢,但咱們要儘可能下降業務前期頻繁的變更和大需求扎堆的狀況對系統帶來的影響,採起對內分、對外合的方式:
● 對內分:對內保留業務邏輯擴展性,如產品內部服務會根據後續業務發展方向拆分銷售規則、價格、庫存等服務,保證可擴展性。
● 對外合:對外保證服務邏輯完整性:如產品服務對外提供的接口,能夠完成對產品的完整操做和信息獲取,以免服務擴散太細,帶來的高協做成本。
應對:保證業務發展→分階段落地,區分優先級,保證每階段收益
系統的整個構建涉及面較廣,若是一次性完成周期較長,同時也不利於快速驗證和優化,因此將整個項目進行分步,分步的要求有兩個:
● 優先解決業務痛點;
● 必須有階段性產出。
首先,識別項目的核心目標:高效的供給→良好的用戶體驗。
而後,確認核心目標的優先級:
● 用戶體驗依賴於高效供給產生的豐富、高質量產品,而且供給系統建設完成以後須要必定的積累週期;
● 因此:優先解決供給問題,而後完善用戶體驗。
最後,明確每一個階段的業務收益:
● 供給階段:效率提高
● 用戶體驗階段:退款率
步驟一:解決效率問題
經過對於供給系統、產品系統的建設,使供給效率達到300%的提高,同時在這個過程當中,完成了酒店系統的前半部分建設:供給到產品。
步驟二:解決體驗問題
經過對於預付系統的建設,進行業務升級,用戶退款率下降60%,同時在這個過程當中,完成了酒店系統的後部分建設:售賣到交易。
步驟三:系統融合
將團購系統中的酒店業務和酒店系統進行融合,保證各個業務形態共享效率、體驗的紅利,同時統一酒店的全部系統。
通過以上的幾步,完成了酒店系統的初步建設。
下圖中,灰色部分爲去尾的基礎組件部分,桃紅色部分是去尾的基礎服務部分,綠色部分是未掐頭的統一出口部分,而其他的大片深青色部分,則是酒店業務核心相關的系統部分。
支撐階段:支撐業務需求、業務量的快速增加
酒店系統建設完成後,就須要承擔起原有團購業務量,再加上用戶爆發的需求,系統須要進一步的改進以更好的支撐業務。
支撐階段咱們主要從如下幾個方面來看:
● 質量:輪子總壞,壞一次修半天;一天N個故障,一直在處理線上問題。
● 穩定性:調整各內部的小輪子,整個車都跪了;一個小需求上線,致使整個系統癱瘓。
● 性能:車過重,輪子hold不住了;業務量愈來愈大,系統相應愈來愈慢,逐漸hold不住了。
● 服務化:小輪子變大輪子;本來的一個小服務,隨着業務的發展,愈來愈大,不少人都不敢動了。
應對:質量
一談到質量,能夠很快想到須要從需求、設計、開發、上線、維護等各個環節嚴格把關,才能保證最終的質量。
一個通用的理論是:在越前置的環節發現問題,形成的影響越小,恢復成本越低。
但伴隨着這個理論的同時,還有另外一個維度的問題:在越前置的環節想要發現問題,須要投入的成本一般也越高。當天天都在忙於救火時,若是咱們直接硬抓單測覆蓋率,精力方面不太容許,因此咱們在對於這些質量控制措施的優先級有適當的調整(固然各方面的事情都須要同時作)。
抓線上監控、問題處理:保證問題快速發現、快速解決
● 監控層面:完善基礎監控、服務監控、業務監控,查缺補漏,保證全流程監控,以快速發現問題。
● 排查層面:經過系統調用trace和業務trace維度,保證能夠根據問題狀況,迅速定位緣由。
● 處理層面:內部問題經過處理工具、數據修復工具快速處理,外部問題經過降級、限流等措施快速響應。
當把線上的監控、排查、處理方面作的差很少的時候,咱們終於能夠從救火中抽出一些精力來,繼續向前走。
抓上線流程:保證問題影響範圍儘可能小
● 內網環境:內網線上環境,內部驗證。
● 灰度環境:灰度部分用戶環境,小流量用戶驗證。
● 全量環境:全量用戶環境,上線。
抓主流程自動化測試:保證問題的嚴重程度儘可能低
● 經過MockServer進行外部服務mock,保證測試環境穩定性;
● 對業務功能進行分級;
● 按業務功能優先級覆蓋自動化測試,保關鍵流程不失。
抓設計、開發、自測:保證問題儘早避免、儘早發現
● 設計階段:提供標準的設計範例,保證設計產出的質量;經過設計Review的方式,保證設計結果;
● 開發階段:經過最佳實踐的參照,避免重複的學習和填坑成本;經過靜態掃描規則的定製,排除常見的問題;經過需求代碼Review和代碼按期走讀,對代碼精益求精;
● 自測階段:提供單元測試規範,設定覆蓋度目標,持續集成長期檢查。
應對:穩定性
系統穩定性方面能夠有不少個維度進行考慮,這裏咱們核心討論隔離問題。
分層:變與不變分離
對服務進行分層:數據層、服務層、應用層、API層,穩定性依次下降,將變化的邏輯儘可能控制在上層區域,避免底層修改。
瘦身:核心流程與分支流程分離
主線邏輯梳理,剝離無用邏輯、非主線邏輯,保證核心流程的穩定清晰。
隔離:內部與外部分離
交互部分進行檢測,發現問題後Fail Fast,避免由於一個點的問題拖壞整個系統。
應對:性能
搞性能最重要的事情:數據。任何的優化請用數聽說話,否則都是瞎搞。
經常使用的優化性能的幾個思路(基礎組件、網絡等層面優化不在這裏討論):簡化、異步、並行、就近。
● 簡化:是否是有那麼複雜
● 異步:是否是有那麼着急
● 並行:是否是必須等着別人
● 就近:擴機房慢了,能不能本地機房;網絡訪問慢了,能不能用本地數據等。
應對:服務化
隨着業務的發展,本來的小服務愈來愈大,須要考慮服務化問題。通常服務拆分有如下幾個思考維度:
● 業務層面:獨立性、完整性、原子性等
● 服務層面:輕重、快慢、讀寫等
● 組織層面:組織劃分決定系統架構
另外,對於能夠多業務公用的部分,能夠按平臺方式構建,如客服系統、結算系統等。
通過一段時間的折騰,系統變成了如圖所示的狀況:
● 最下面一層的基礎設施、基礎業務服務,支撐着公司各個事業羣的業務;
● 倒數第二層的平臺層,提供酒旅場景下的平臺業務服務,支撐着酒店、門票、交通等業務形態;
● 中間的產品、交易層面,做爲業務的服務層,保持基本穩定;
● 第二層的搜索、交易等做爲應用層,更貼近業務,更輕量的發生變化,保持靈活性。
而在這個階段中,咱們系統跑的愈來愈順暢,優化效果如圖所示。
優化階段:技術優化,推進業務進一步發展
隨着業務、系統的進一步發展,系統進入優化階段,在這個階段提出了另外一個話題:如何經過技術優化進一步推進業務發展。
核心原則兩個:
● 抓住痛點:保持思考,搞清楚想要的究竟是什麼;
● 數聽說話:和性能部分同樣,沒有數據就是瞎搞。
抓住痛點
原有的營銷流程是:運營同窗人工收集N方的數據,而後根據本身的經驗設定營銷策略,投放,而後再去收集數據驗證結果。
這個時候咱們可能會聽到運營同窗反饋:「唉,天天太累了,想休兩天假,還沒人能替我」。
從正常需求路線來看,咱們須要優化給運營同窗獲取數據的工具,優化運營同窗設定策略的系統的用戶體驗。
但咱們還應該往深層次想:
● 爲何很累:在整個環節中,運營是核心環節,須要從多方獲取信息、整合、制定決策、投放,角色較重。
● 爲何沒人能替:在策略設定的過程當中,過於依賴運營的能力,經驗對結果產生巨大的影響,並且同時經驗是不易傳授、不易積累的。
針對這個狀況,咱們對於營銷系統進行了進一步的優化:
● 經驗積累:將運營的規則設定做爲經驗輸入到分析引擎,作到有積累。
● 角色輕化:數據整合、分析的主要工做由機器替代,運營更多起到審覈、觀察的角色。
數聽說話
直連的一個典型場景是:從酒店集團或第三方獲取庫存、價格信息,而後經過MT售賣。而在這個過程當中,數據的實時性對於業務的影響很是大。
須要考慮的內容包括:
● 問題觸發點:支付轉化率較低
● 縮小範圍:分析各個環節數據,確認房態部分影響
● 明確指標:房態準確率
具體步驟:
第一:分析用戶的訂單預訂時間,確認將來N天數據的覆蓋度,針對距離當前時間的天數設定不一樣的同步策略,準確率上升10%;
第二:分析實際數據不實時引發問題的狀況,肯定經過發生驗證、交易等觸發,進行數據的同步處理,準確率上升5%;
第三:分析用戶的行爲數據,預測出熱點數據,提升同步頻率,準確率上升8%。
小結
11月9-12日,北京國家會議中心,第六屆TOP100全球軟件案例研究峯會,美團外賣算法架構師郝井華將分享《美團配送智能調度系統演進》;美團點評酒旅質量團隊工具鏈負責人王鵬將分享《微服務架構下的自動化測試和持續集成工具鏈實踐》。
TOP100全球軟件案例研究峯會已舉辦六屆,甄選全球軟件研發優秀案例,每一年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場,現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。大會開幕式單天體驗票申請入口