區別
服務都是分為了兩個模型，也就是乙個拉，乙個推。來作為模型。
簡單來說，直連平台，就是將多個平台連線起來。並沒有什麼特殊的。乙個個專案堆下來總能解決的。
但是從架構上，會逐漸臃腫，直到難以接受的程度，因為接入的直連雖然現在表現很好，但是隨著需求的演進，專案堆下來的方案，是肯定不能接受的。所以要建立平台。實現通用方案。
業務上簡單說就是
要自動化，盡量快速接入，方便擴充套件，可靠性足夠
建構簡單的步驟
我們之前首先做了資料庫分庫分表。來將國內大的酒店集團全部建立為單獨的表。小的酒店就會合併，減少分表。
推模型中，我們做了臨時庫，將臨時庫同步到正式庫。
這是乙個簡單的資料庫架構。其實裡面做了很多優化，因為有很多指標。
我一直在考慮使用kafka/qmq等訊息佇列來解決併發推送的問題。但是因為我們分庫採用的是按hotelid進行分庫，然後如果採用訊息佇列的話，會造成資料無法一批批處理，造成資料庫查詢利用率過低。
但是當時乙個是架構是已經架構了，可以用，其實現在也可以用，但是指標不好看。
這裡也是其實在當時太慫，剛進公司覺得自己水平不夠，不敢堅持自己想法。
現在我將短期**快取，然後很多一些冷資料都直接快取化。
然後做資料壓縮，結構優化。來保持資料庫 以及處理效能時間等指標保持平穩。
這就是商旅之前直連平台的簡單介紹。
現在優化的乙個沉入**層面，之前很多專案**，抽成了common jar包。以後逐漸抽成服務。
其實這裡jar包和微服務化，和領導有過討論。
jar包優勢
1.jar包不存在效能問題，服務可能存在
jar包劣勢
1.jar包存在管理困難，版本更新困難問題『』
雖然我不認為劣勢是可以接受的。但是最終團隊都認可了jar包方案。不過也是當時自己剛進公司，沒有堅持導致的。現在如果我堅持我認為是可以通過的。這也是學習的一部分。
下次再畫技術架構圖。
攜程基於Flink的實時特徵平台
1.1 選擇實時計算平台 依據專案的效能指標要求 latency，throughput等 在已有的實時計算平台 storm spark flink進行選擇 1.2主要的開發運維過程 現在的架構是標準lamda架構，離線部分由spark sql datax組成。現在使用的是kv儲存系統aerospik...
攜程App的網路效能優化實踐
native模組是攜程的核心業務模組 酒店 機票 火車票 攻略等 native模組的網路服務主要通過tcp連線實現，而非常見的restful http api那種http連線，只有少數輕量級服務使用http介面作為補充。tcp連線網路服務模組使用了長連線 短連線機制，即有乙個長連線池保持一定數目長連...
攜程App的網路效能優化實踐
摘要 native模組是攜程的核心業務模組 酒店 機票 火車票 攻略等 native模組的網路服務主要通過tcp連線實現，而非常見的restful http api那種http連線，只有少數輕量級服務使用http介面作為補充。tcp連線網路服務模組使用了長連線 短連線機制，即有乙個長連線池保持一定數...