孵化业务快速落地与优化
海外酒店是酒旅事業群第一個孵化的業務，從2016年9月份開始到現在已經半年多的時間。在業務后臺搭建、成長、優化過程中，經歷了很多的思考與選擇。
主要分為下面幾個階段：
初建：調研、落地，合理復用，高效自建。 優化：量化、決策，尋找瓶頸，優化性能。 展望：梳理、規劃，業務展望，未雨綢繆。
本文將分別介紹這幾個階段后臺系統相關的思考，此外還會在最后總結團隊建設方面的經驗。
海外酒店作為一個孵化項目，屬于新的業務場景，沒有完整的學習對象。從業務細節上來講，孵化業務的屬性、流程、發展方向均有自己的特點；但從宏觀上考慮，它是已有業務的拓展，各方面也存在一些相似點。從發展速度來講，新興業務發展初期，迭代速度非常快，需求變更會非常頻繁，業務壓力在一段時間內會持續出現。
綜上，在系統后臺建設初期需要詳細思考：已有后臺服務的調研與復用，謹慎合理創建新的業務后臺，優先選擇成熟框架與技術組件。
已有后臺服務的調研與復用
最終目的：合理的復用資源，避免重復造輪子。
什么樣的系統或者服務可以復用？復用與否從兩方面考慮：服務平臺能力、涉及需求量。總體的復用判斷方案如下圖所示：
基于以上原則，海外酒店在復用抉擇時候的判斷如下：
① 公司級別基礎服務或業務平臺
- 基礎服務可以復用：如異步消息中心、緩存中心、風控平臺等。
- 業務平臺可以復用：如訂單平臺、支付中心、客服平臺等。
② 部門級別已有業務平臺化系統
- 部門內已有基礎業務平臺。如POI中心、訂單交易平臺、促銷平臺等。
- 業務耦合性不高，已建業務支持能力的平臺。如UGC中心、主搜平臺等。
在部門級的業務平臺是復用+定制來完成需求的支持。因為這塊有一部分需求內容，現有的能力可能無法滿足新業務的要求，所以需要做部分定制。
合理謹慎的創建新業務后臺
思考清楚如何避免重復造輪后，接下來就是孵化業務后臺系統的搭建工作。
孵化業務后臺建設有哪些挑戰和風險？
第一：孵化業務需求迭代速度非常快，需要快速落地支持； 第二：業務需求變更非常頻繁，甚至推翻重來；
第三：系統建設速度非常快，整體架構方式有挑戰。
面對上面這些挑戰，海外酒店后臺系統建設過程中要盡量做到簡單、靈活、可擴展。
簡單：工程目錄，代碼結構都從簡單入手，避免太多復雜設計和復雜代碼耦合帶來的壓力。 靈活：根據前期的需求以及中短期的規劃，將系統根據業務劃清界限，做到盡可能的微服務化，將系統設計內聚合、外解耦。 可擴展：簡單、靈活的同時必須思考可擴展性，為業務持續發展做到未雨綢繆。
可擴展有資源的預備儲備，系統架構的無縫擴展，服務間的擴展交互。
基于上面的思考，海外酒店后臺初期自建的系統如下：
C端系統：API中心、產品中心、報價中心、訂單中心、POI緩存中心、黑名單服務。
B端系統：三方直連系統，三方數據同步系統。
每個系統間界限劃分清楚，哪些是提供給用戶C端展示，哪些是B端三方接口訪問，哪些是線下靜態數據同步等。
海外后臺初期整體架構落地形式如下圖所示：
優先選擇成熟框架與技術組件
業務前期在技術選型方面可能更加偏向于成熟框架，成熟技術組件。這需要我們從兩方面考慮：
① 新的技術框架和組件存在風險 * 技術文檔支持可能存在不足。
* 技術問題解決方案缺失，排查困難程度不可預知。
② 選擇成熟框架和組件的好處 * 項目搭建比較迅速。 * 問題排查解決有經驗的積累和參考。
* 人員backup比較方便，招聘也比較方便。
系統快速搭建的同時，需要考慮前期的必要優化，從而提高系統的健壯性、可用性等方面內容。
海外酒店在建設初期從下面幾個內容進行了初期思考： 1. 可用性 2. 系統性能
3. 擴展性
首先介紹一下可用性相關內容。
可用性
可用性是衡量系統服務的一個重要指標。在這里重點介紹海外酒店后臺系統前期考慮的幾個方面：容災降級， 限流控制，服務備份，監控覆蓋。
容災降級
降級策略根據不同的業務場景有不同的方式，例如超時降級、失敗次數統計降級、限流降級等。
目前，降級按方式不同分為：自動降級、手動降級。
海外酒店后臺目前都是采用的手動降級的策略。自動降級策略需要對監控數據有特別高的感知能力和預判能力，這塊還需要繼續建設完善。
對于海外酒店后臺來講目前有兩塊降級的要求。
業務場景一
產品售賣可降級，讀服務降級。
產品售賣可降級是一種人工開關，當發現大量的產品售賣出現異常時，我們將停止某個產品供應商的產品展示，從而避免造成更大的損失。然后從業務代碼來進行相關的開關配置，提供一個可修改的降級開關控制接口。目前海外酒店的降級方案是通過MCC（美團點評公司級的統一配置中心）的配置信息下發來實現整個工程的手動降級。在產品展示信息的接口，通過MCC的Key來進行設置開關的狀態。
MCC底層實現組件是ZooKeeper（以下簡稱“ZK”)，通過對ZK節點信息修改的監聽，來進行屬性的同步。由于自動降級目前存在很多技術上的不確定性，因此沒有考慮根據業務數據的突變，后者如果出現監控數據的異常，會自動觸發各種降級開關。
業務場景二
API層接口熔斷降級，使用Hystrix。
對于API層來說，主要是提供前端展示所需的數據內容。上層直接面向用戶需要可靠的服務以及快速的請求響應，下層依賴各種不同的服務然后進行信息的組合拼裝。
所以為了提高接口的穩定性，海外酒店API層接口接入Hystrix實現熔斷和降級策略。Hystrix原理可以簡單描述為：
限流控制
限流是利用有限的資源，保障業務系統核心流程的高可用。限流本身是通過一種有損的方式來提高可用性。
從限流的機器維度方面來說有單機限流和分布式限流兩種，限流算法目前有熟知的令牌桶算法、漏桶算法。
從應用的角度來說，限流可以針對總的并發數、連接數、請求數限流，也可以對某個共享資源來限流，以及針對某個接口請求數來進行平滑限流。
單機限流
從單機維度的限流，我們可以采用Java提供的semaphore來進行簡單的支持，或者采用Guava RateLimiter來進行單機限流。
分布式限流
而對于分布式服務的限流，就需要采用一個公共資源服務來進行流量的統一控制，目前美團點評內部提供了一個組件，基本原理利是用Tair的資源管理和主鍵失效策略來進行流量控制。
分布式流控系統實現原理可以利用Tair或者Redis的原子性加減操作，來進行資源的管理，同時利用失效時間來進行管理一段頻率內的資源消耗情況。
為了提高開發效率，海外酒店使用了公司統一限流組件，該組件利用了Tair的原子性加減功能，進行限流功能的實現。
海外酒店限流的業務場景
某些服務提供商，要求后臺訪問他們接口頻率的總和不能超過 40次/秒、75000次/小時，否則會進行相應的懲罰策略（返回假數據等）。
從這個要求來看，業務場景是針對第三方接口訪問的限制，需要的是對接口總體訪問量的控制，所以單機的限流策略無法滿足這個業務場景，必須采用分布式限流。海外酒店整個限流場景下做了報警功能，并沒有做直接禁止接口的訪問。這是基于海外酒店前期的流量大小來綜合考慮的結果。按照目前的海外酒店訪問量級來說，供應商提供的接口訪問次數，一段時間內可以滿足當前的用戶訪問量。
如果超過限制，很可能有異常流量進入，而這種流量必須經過人工排查才能確定，前期如果真的出現這種流量異常，也不會太影響用戶的交易行為，綜合考慮之后，我們針對限流場景，做了觸發報警的策略。
服務備份
對于分布式系統來講，雖然其特征決定了整個服務的不可用性大大降低，但對于核心系統我們必須考慮整個系統的容災備份能力。對于業務系統來講，容災能力分為兩種需要考慮： 1. 自身服務的容災特征，如何保證自身服務的高可用狀態。 2. 依賴服務的容災特征，即依賴的服務出現不可用狀態時候，對于業務方來說如何進行災備。
這種分布式系統容災的方法有： 1. 跨機房部署、異地多活、防止機房不可用災備。 2. 依賴方替換方案，防止依賴方服務不可用狀態。
對于海外酒店業務來說： 1. 每個服務都會在兩到三個機房進行部署，根據需要可以多申請（也要考慮公司資源）幾臺備用。 2. POI緩存中心強依賴于Redis緩存系統，因此做了一層災備，也將緩存數據同步了一份到Tair集群。
POI緩存中心災備模型如下：
既然是兩個緩存中心，那么服務的數據類型接口也都存在差異，就存儲信息來說，如果兩者都完全保持同步，會造成后期的維護成本比較高。因此作為備份容災的緩存服務，僅僅存儲必要的信息，而且是基本不會變動的數據結構。避免由于業務的修改，造成雙緩存中心數據結構的修改適配。
監控覆蓋
海外酒店初期，在監控方面進行了詳細的領域拆分，并結合公司的公共日志監控平臺來進行相關的監控報警工作。監控方面從監控內容上來分有：網絡監控、機器監控、業務監控、日志統計等。
整體的后臺監控體系，如下圖所示：
隨著業務系統的增加，以及服務的拆分，各個系統間日志的統一查看比較困難，給問題排查帶來很多都不便。比如訂單交易平臺下單異常， 需要排查自身系統的問題，如果發現依賴服務存在問題，就需要依賴服務（產品中心、直連中心、報價中心等等）分別確定排查，查看自身的監控情況，從而協助確定問題。
因此未來需要將各個業務統計，監控信息統一到一個監控大盤里面，可以一目了然的觀察各個維度的信息，從而優化問題排查效率，提高系統可用性。
系統性能
孵化業務前期，訪問量的絕對值雖然還不是太高，但我們仍然需要持續關注接口的性能與響應時間。特別是業務推廣初期，用戶的第一印象將直接影響其對業務的心理評判。
這些方面業務前期自然需要重點關注和考慮。海外酒店后臺在每個環境中都考慮了性能優化相關內容，主要涉及到并發請求，異步解耦，緩存使用。
并發請求
海外酒店POI詳情頁需要展示產品列表信息，產品列表信息是實時調用多家供應商接口來進行獲取，同時還要從POI緩存中心獲取房型的圖片鏈接，然后進行結果的聚合組裝然后返回。
如下圖所示：
通過并發請求獲取，來提高接口的響應時間，在進行并發任務操作時，需要注意線程池的配置和管理。這塊內容很多地方都有詳解，在這里就不展開介紹了。
異步解耦
除了用并發請求來優化響應時間以外，還有一種方式是異步解耦。
異步解耦可以描述為將非主業務功能進行拆分，對返回結果沒有影響的功能，進行異步化操作。
異步化的方式常見的有： 1. 啟動新的線程，異步化執行。 2. 通過異步消息，拆分服務執行。
啟動新線程進行異步解耦
海外酒店業務舉例來說，用戶進行下單操作： 1. 訂單交易平臺需要將下單信息同步到直連訂單系統。 2. 然后由直連訂單系統去第三方供應商進行下單。 3. 第三方供應商下單接口很多時候是非實時返回結果，需要定時去拉取結果，然后將結果同步給訂單交易平臺。
這三步操作如果同步執行，那么結果耗時會很久，用戶等待時間非常長。為了提高用戶體驗，在直連訂單系統存儲成功下單信息之后，就返回給用戶一個結果等待的中間狀態，避免用戶長時間等待。與此同時后臺會啟動一個新線程，進行到第三方下單的操作，這就是啟動新線程進行異步解耦的過程。如下圖所示：
通過異步消息，拆分服務解耦
用戶在獲取產品信息時候，需要將實時獲取到的產品信息進行相關的梳理計算并同步到統計中心，進行數據的采集。這塊數據梳理同步任務和用戶訪問主要目的沒有太多直接關系，因此可以采用異步消息的方式發送給數據梳理服務，然后由該服務進行相關的數據整理工作，從而實現業務的解耦，優化了接口的響應時間。如下圖所示：
緩存使用
緩存的使用分為兩種：一種本機緩存，一種是分布式緩存。都是將數據加載到緩存，以此來減輕數據庫查詢或者接口訪問的壓力，以及優化服務響應時間。
本地緩存使用
本地緩存比較合適的使用場景： 1. 數據量比較小（內存資源有限）。 2. 經常被訪問相對穩定信息（效果突出，數據變動小）。
在海外酒店直連工程中，床型映射信息屬于比較穩定的存儲數據，同時數據量級非常小，但訪問量相對比較大，因此符合使用本地緩存的場景。
本地緩存熟知的實現方式：Ehcache、Guava Cache。
在本地緩存使用方面需要注意：本地緩存涉及到多機之間數據不同步風險或者內存消耗方面的影響。因此使用時候需要詳細考慮數據的場景。
分布式緩存使用
當前服務一般都是分布式服務，因此使用比較多的也是分布式緩存來進行相關的優化。下面介紹一下海外酒店對于分布式緩存的使用。
避免數據庫訪問壓力
大量的DB訪問會造成DB的壓力，同時DB的查詢效率會隨著數據量的增加逐步變差，因此比較常規的做法，是將部分數據同步到緩存中，通過緩存作為中間層，減少DB的訪問，與此同時優化服務響應時間。
DB和緩存數據的同步一般有訪問時同步、定時預熱同步等。如下圖所示：
避免第三方服務訪問壓力
場景一
海外酒店產品信息是實時的調用第三方接口來獲取，三方接口性能和穩定性均可能存在未知風險，因此為了提升內部系統整體的性能與穩定性，同時為了避免大訪問量對三方接口造成壓力， 采用了產品信息緩存的策略，同時根據第三方的要求，進行緩存內容過期時間的合理設定。
場景二
海外酒店搜索列表頁、詳情頁、下單填寫頁均需要進行POI（酒店信息）相關信息的展示，對于POI查詢接口來說訪問量非常大，因此為了避免對POI中心造成流量的沖擊，海外酒店POI緩存中心將所有的POI信息每天定時全量的同步到緩存中，同時進行相關信息的整體聚合，提供給業務訪問，從而避免了服務接口的壓力。如下圖所示：
使用分布式緩存的時候需要注意的一點：數據一致性的問題。對于海外酒店POI緩存中心通過兩種方式來進行數據一致性的保證:
緩存使用的梳理
緩存使用時候需要注意緩存的雪崩、更改策略問題。
雪崩
雪崩的概念可以簡單描述為：緩存由于某些原因造成大量的緩存數據失效，大量的訪問請求直接打到數據庫或者服務接口，造成底層數據源的壓力。
有一種常見情況的雪崩，就是在短時間內大量的同步數據到緩存，到了過期時間，導致大量的緩存數據失效，從而形成雪崩現象。
海外酒店在大量同步POI數據到緩存的時候，采用了少線程、緩慢同步的策略。這塊雖然增加了整個緩存的同步總時間，但也讓數據的同步進行了有效的分散，從而避免了雪崩現象的產生。
還有一種方式，就是讓每個緩存內容的過期時間設置進行不同的賦值，不要統一設定過期時間，使用一個區間內（比如一個小時）隨機的選擇失效時間，從而可以避免雪崩的危險。
穿透
什么是緩存穿透？一般使用緩存查詢的時候，如果在緩存中查詢不到結果，就會去DB或者服務中再次查詢。但如果大量的訪問是因為查詢了緩存和數據庫中均不存在的數據，從而造成每次查詢都要去DB或者服務訪問驗證一次，就會對后端DB或者服務造成壓力。如下圖所示：
海外酒店業務場景
海外酒店的搜索列表頁，會進行酒店最低價的查詢，海外酒店的最低價需要準實時（每天兩次）從第三方來同步產品最低價信息，然后存儲到數據庫提供給搜索服務使用。
搜索列表頁是所有服務頁面中流量最大，訪問最多的頁面，因此需要將訪問的最低價數據同步到緩存，然后提供服務。
在現實業務中，很多酒店在某些時期沒有產品售賣，也就不存在最低價屬性，因此在大量訪問的時候，就會造成一定的緩存穿透情況。為了避免這種情況，采取如下策略。
前期
將所有的沒有數據的訪問，也存儲到緩存當中，防止緩存訪問的穿透；同時存儲這些無值默認數據的key，也要保持和數據庫或者服務數據的一致性。
問題：隨著數據量的增加，可能造成緩存空間的嚴重浪費。
后期
后續再次使用Bloom Filter來進行簡單的優化。Bloom Filter算法采用的是部分錯誤代價、換取空間優化的特點。具體的原理在這里不做過多的介紹。
擴展性
對于新的業務系統來講，擴展性的考慮主要有前期的容量評估和服務粒度的拆分。
前期的容量評估
作為新項目，必須進行項目前期的容量評估，從而決定前期項目需要申請的資源，以及未來一段時間需要擴充的資源。容量評估的內容一般包括：訪問量評估、數據量評估、帶寬/CPU/內存相關的評估。
訪問量評估主要考慮三方面內容： 1. 初期業務訪問量的PV有多少，正常的每天訪問密集時間段； 2. 是否會有促銷相關的運營活動，能帶來多少流量的增長； 3. 存儲數據的量級范圍，包含兩個方面：第一是數據庫存儲數據的量級，第二個是緩存存儲的量級。
拿海外酒店舉例：
服務粒度的拆分
服務的拆分應該遵循單服務高內聚，多服務低耦合。服務的劃分應該將經常一起發生變化，業務模型處理相同的模塊放在一起，從而實現內聚性； 服務間可以獨立部署，負責業務或者功能可以通過接口清晰調用，服務間部署，發布均可以獨立進行，從而實現服務間松耦合。
海外酒店后臺服務可以從上文中看出： > POI緩存中心：負責POI相關靜態數據的緩存管理； > 產品中心：負責同步三方產品數據 同時進行部分緩存操作； > 訂單中心：負責訂單相關的服務，進行交易相關的服務； > 報價中心：價格相關展示計算進行服務拆分，統一價格計算，避免同一價格，多出計算邏輯問題。
服務科學的拆分方便系統間處理業務界限清晰，同時管理起來統一方便。
上面總結了項目發展初期一般遇到的問題和思考以及部分解決方案。后續隨著業務的發展，還會遇到中期的問題與挑戰。根據不同的發展階段，需要做出不同的規劃與策略，未雨綢繆，讓系統在業務不斷發展的過程中，迭代優化，提早準備，避免系統能力支持出現瓶頸。
海外酒店后臺后續的系統建設與優化思路，總體來說可以參考下面的模型：
X軸可以理解為數據庫的主從復制，機器的擴充，緩存的擴充。側重節點能力的無差別復制。
Y軸可以理解為將部分目前業務邏輯耦合比較復雜的系統，根據業務特點進行垂直拆分，讓系統服務負責業務更加精簡明確。
Z軸可以理解為根據用戶不同特點或者特殊需求方面進行系統擴展；例如，為了提高在海外的用戶訪問效率，進行海外服務節點的部署搭建。
總體來說保證業務需求快速迭代的同時，優化系統架構，保證系統的各方面指標。
在文章的最后簡單梳理一下孵化業務團隊建設相關的內容。
團隊如何建設？
一般孵化業務面臨的問題：項目成員新，組內技術積累弱，業務了解程度淺。
面對這種問題如何解決？
快速招聘、大量進人？這樣存在團隊管理方面的風險，會造成業務開發過程中溝通、理解方面的偏差不同問題擴大，甚至產生團隊的不穩定因素，造成團隊整體效率偏低；因此越是孵化項目，越是初創團隊，就更需要循序漸進進行人員的擴充，在團隊成長的過程中形成自己的文化和節奏，后期進入的員工能快速的從身邊老員工身上體會與學習到這些文化和節奏。從而形成統一的團隊相處模式。在一個穩定的團隊擴建速度下逐步凝聚，提高效率，提升整體戰斗力。
規范如何樹立？
技術團隊建設成長的過程中，技術規范的建設起到很重要的作用，規范建設越迅速、越完整，那么業務開發過程中的風險也就更少。 海外酒店在團隊建設過程中不斷加強技術規范的建設，在半年的時間里分別進行了八個技術規范的落地。
這些技術方案的持續建設，大大降低了初創團隊的工程風險，同時也讓新加入的同學，快速的了解團隊開發習慣，迅速進入到生產角色。后續海外酒店后臺還需要進行：單元測試規范、監控報警規范等一系列的建設任務。
上面根據孵化業務現實的技術思考，從初建、優化、展望、團隊四個方面進行相關的介紹。 整體來看基本上都是根據業務不同發展需求，做出合理的技術選型與設計。 后續隨著業務的成長，系統建設與技術架構都會有不同程度的迭代思考與修整。 從各個方面去思考系統對于業務支持的合理性與前瞻性，盡量做到合理演進、靈活擴展、科學設計等各方面的要求。
宗起，后臺技術專家，2015年加入美團點評，目前負責海外酒店后臺研發團隊。之前曾在阿里巴巴、騰訊、中國移動研究院從事后臺研發工作。 關飛，高級技術專家。之前在阿里、創新工場孵化項目從事研發工程師職位，現在負責酒店后臺ehome組，負責酒店核心通路、孵化業務的系統建設、維護工作。
總結
以上是生活随笔為你收集整理的孵化业务快速落地与优化的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里P8架构师谈：主流RPC框架详解，以
- 下一篇： 消息中间件系列(三)：主流的消息队列中间