攜程商旅酒店直連平臺的實踐（一）

現在才發現，離我上一篇博文竟然接近1年沒有發過東西了。驚呆了我。我要每週都寫了，就算不寫技術也要寫其他東西，不然真的是思考的多，沒有留下記錄都是空白。
在攜程商旅主要做酒店直連這一塊。商旅酒店其實架構都很老，並且實踐的技術很多不是很新。但是抗住了之前的壓力，但是開始做直連之後就顯得比較不行了。
之前商旅的酒店類型區分爲如下

• 1.OTA酒店
• 2.單體酒店
• 3.非直連套系酒店
• 4.直連套系酒店

區別

• 1.就是依靠OTA，做分銷，
• 2.合同酒店然後維護，未來還是靠直連。
• 3.非直連套系酒店
• 4.直連套系酒店，靠直連
  
  這裏面一些因爲商旅的業務特點，我就不展開了，有機會再寫。我們直接看直連，如下圖
  

服務都是分爲了兩個模型，也就是一個拉，一個推。來作爲模型。
簡單來說，直連平臺，就是將多個平臺連接起來。並沒有什麼特殊的。一個個項目堆下來總能解決的。
但是從架構上，會逐漸臃腫，直到難以接受的程度，因爲接入的直連雖然現在表現很好，但是隨着需求的演進，項目堆下來的方案，是肯定不能接受的。所以要建立平臺。實現通用方案。
業務上簡單說就是
要自動化，儘量快速接入，方便擴展，可靠性足夠
建構簡單的步驟

1. 我們之前首先做了數據庫分庫分表。來將國內大的酒店集團全部建立爲單獨的表。小的酒店就會合並，減少分表。
2. 推模型中，我們做了臨時庫，將臨時庫同步到正式庫。
   這是一個簡單的數據庫架構。其實裏面做了很多優化，因爲有很多指標。
   我一直在考慮使用KAFKA/QMQ等消息隊列來解決併發推送的問題。但是因爲我們分庫採用的是按hotelID進行分庫，然後如果採用消息隊列的話，會造成數據無法一批批處理，造成數據庫查詢利用率過低。

但是當時一個是架構是已經架構了，可以用，其實現在也可以用，但是指標不好看。
這裏也是其實在當時太慫，剛進公司覺得自己水平不夠，不敢堅持自己想法。
現在我將短期價格緩存，然後很多一些冷數據都直接緩存化。
然後做數據壓縮，結構優化。來保持數據庫 以及處理性能時間等指標保持平穩。
這就是商旅之前直連平臺的簡單介紹。
現在優化的一個沉入代碼層面，之前很多項目代碼，抽成了common jar包。以後逐漸抽成服務。
其實這裏jar包和微服務化，和領導有過討論。
jar包優勢
1.jar包不存在性能問題，服務可能存在
jar包劣勢
1.jar包存在管理困難，版本更新困難問題‘’
雖然我不認爲劣勢是可以接受的。但是最終團隊都認可了jar包方案。不過也是當時自己剛進公司，沒有堅持導致的。現在如果我堅持我認爲是可以通過的。這也是學習的一部分。
下次再畫技術架構圖。