TOP100summit：【分享實錄-貓眼電影】業務縱橫捭闔背後的技術拆分與融合

王洋：貓眼電影商品業務線技術負責人、技術專家。主導了貓眼商品供應鏈和交易體系從0到1的建設，並在貓眼與美團拆分、與點評電影業務融合過程當中，從技術層面保障了商品業務的平穩切換，同時也是美團點評《領域驅動設計》課程的講師。在加入貓眼電影以前，曾就任於螞蟻金服，參與了阿里網商銀行從0到1的建設，以及支付寶錢包、花唄等產品的研發。

導讀：互聯網電影行業在2016年經歷了較大的變更，其中包括貓眼電影和原美團的拆分，以及貓眼電影和點評電影業務的融合。業務發生大的變化時，技術一般也會作出較大的重構，貓眼後臺技術團隊在整個拆分、融合的過程當中，對系統架構、領域模型進行了比較多的調整和思考，探索出一套成本和收益較爲平衡的技術方案。本文將分享實踐的具體過程、步驟和方法，但願給後互聯網時代，遭遇業務拆分和融合的技術團隊提供一些參考案例。

一．問題的提出

具備必定規模的互聯網公司，一般會有不少的細分領域和垂直業務，爲了提升效率，大部分公司都會採用平臺化的思路：建設一套通用的基礎平臺，全部業務線基於這套基礎平臺搭建本身的業務和技術服務。這種作法一方面能夠縮減人力成本，另外一方面也能夠提升新業務的開發效率。貓眼的商品業務一開始爲了快速發展，就採用了這種發展模式，將整個業務的交易都搭建在美團的團購體系之上，如圖1所示：

從上圖能夠看出，商品業務徹底依賴於美團的商品、訂單、支付、促銷、劵服務，耦合性很是高。因爲當時美團和貓眼是同一家公司，這種耦合性是能夠接受的。但後來貓眼獨立了，組織架構、業務規劃出現了較大的不一樣，這種耦合性就變成了商品業務後續發展的一大難題。

基於獨立發展的考慮，貓眼須要將商品業務從團購體系拆分出來，並和點評電影的商品業務融合在一塊兒，組建一套新的業務和技術體系，用來支撐後續的業務發展。

通過大量的現狀分析和調研以後，團隊肯定了這次技術升級的目標：

● 產品需求不能中斷。
● 最低的客戶感知度。
● 新舊體系能夠自由切換。
● 最低的試錯成本。
● 持續分階段交付、驗證。

電商體系從供應鏈到交易再到結算，複雜度已經很高，再加上業務切換、數據整合的時間，必然會是一場持久戰。爲了減小風險，讓商務、財務等團隊更好地配合咱們，技術團隊必須分階段產出，作線上驗證。

肯定上述的5個目標以後，接下來咱們就要思考如何圍繞這些目標設計總體的方案。

二．技術拆分方案

首先，咱們來分析一下業務場景，圖2是商品業務的簡圖：

從圖2能夠看出，整個業務能夠被拆解爲四個大的模塊，這樣咱們就粗略地肯定了團隊的分工：供應鏈、交易、消費、消費後服務。肯定好團隊的組成，接下來咱們須要對服務的重要性和優先級作一個明確的劃分。分析的維度以下：

● 基礎數據層面，如商家、用戶、合同，這些是公司長期積累下的資源，短時間內不可能重建，因此這個層面的服務，儘可能複用之前的服務。
● 核心服務層面，供應鏈的核心是上單，交易的核心是商品、訂單、支付、促銷，消費的核心是物流、商品券和與之對應的網關服務，這些都是交易的主流程，必須重建。
● 財務層面，如對接商家的結算，以及反應業務運轉狀況的帳務，在公司拆分時，一般是須要獨立覈算的，因此這個層面的服務也必須重建。
● 非功能性服務，例如客服、售後，這些服務一般優先級不高，可是沒有的話，會影響用戶的體驗，因此儘可能考慮複用之前的服務，後期再考慮重建。
通過上面的分析，咱們肯定了一期工程須要重建的服務。

2.1 拆分的前置方案

肯定了須要重建的服務以後，還不能急於開發，要提早思考若是全部的服務都已經有了，該如何作切換。須要考慮的事情有這麼幾點：

● 切換期間，商品如何售賣。

在前面咱們確立了「新舊體系可自由切換」的目標，因此在切換過程當中，須要保證商家和運營上一次單，就能夠在美團、點評、貓眼三個體系中售賣，這樣能夠提升切換的靈活性，減小切換帶來的交易損失。

● 版本問題。

前文已經提到，商品業務一開始是在團購之上搭建起來的，客戶端調用的大部分接口都是美團團購的接口。最直觀的作法是在團購接口中加上判斷，將電影品類的交易請求導流到貓眼這邊，這種作法速度快，且沒有流量損失，但之後修改接口參數、擴展業務的負擔比較重，可維護性比較差。

● 切換的方式和粒度。

爲了達成「新舊體系可自由切換」和「最低試錯成本」的目標，在切換過程當中，必然會處於一個新老並存的狀態，因此咱們不能簡單地替換接口，而要採用更靈活的切換方式和更細的切換粒度。

● 與貓眼現有業務的關係。

貓眼自己有一套選座交易，但受制於行業模型，暫時沒法支撐商品交易。考慮到將來確定是須要融合的，因此須要提早考慮兩套交易的關係。

2.1.1 上單雙推

針對售賣問題，貓眼採用了「上單雙推」的作法，如圖3：

正常狀況下，上單系統在確認商家提交的商品信息後，會將商品推送到商品中心。爲了讓商品在美團、點評、貓眼三個體系中售賣，貓眼須要作如下幾步操做：

● 歷史單遷移。

先從美團商品中心將當下能夠售賣的商品同步到貓眼，保持對齊。

● 創建關係映射。

對於商家來講，不管商品在幾個體系中售賣，都是一個商品，在統計銷量、結算時，都應該是一個商品，因此咱們須要將多個商品中心的商品關聯起來。這個作起來比較簡單，只要給貓眼的商品分配一個id，而後在商品數據中存下對方的id就能夠了。

另外，爲了區分兩個體系的商品，咱們採用分段的策略來分配商品id，好比當下的美團商品最大id是X，那麼貓眼的商品就採用2×X做爲id的起始，而在美團商品id增加到2*X以前，咱們確定完成了切換，不用再考慮id序列統一的問題了。

● 商品雙推，庫存按比例分配。

貓眼上單系統確認商品信息後，將商品推送到美團、貓眼兩個商品中心，並建立各自的庫存，根據當下的交易比例分配庫存量。因爲美團、點評兩個體系是通過融合的，因此只須要推送美團團購，點評就能夠售賣了。

2.1.2 業務入口回收

解決了售賣問題以後，接下來咱們來考慮版本和切換方式的問題。

衆所周知，移動App一旦發版就很難再改動代碼了，因此切換完成後，老的版本很難支持現有的體系。但通過分析咱們發現，貓眼涉及的幾個App，2~3個版本能夠覆蓋到90%以上的客戶端，而核心 服務自建足夠支撐3個版本以上的迭代，這樣所有切換完成的時候，能夠把老版本的流量損失降到5%之內（老版本的用戶交易意願有必定折損），這是一個能夠接受的範圍。

爲了加快切換的速度，咱們須要在覈心服務自建以前，先把交易和消費環節全部的業務入口，也就是客戶端調用的接口所有替換成貓眼本身的接口，由貓眼來對接美團的服務，如圖4所示：

在美團的服務之上，先創建一個業務流程層，給客戶端提供交易和消費環節所須要的接口，而後由業務流程層轉接美團團購的基礎服務。例以下單操做，原先是直接調用美團訂單的接口，如今由交易業務系統作轉接，一旦貓眼的訂單系統開發完成，只須要將美團訂單服務替換成貓眼訂單服務就能夠實現無縫對接了。

2.1.3 切換方法和粒度

收回業務入口之後，接下來須要考慮切換的粒度。

目前有這麼幾個粒度：商品、影院、App、入口位置（場次頁、支付頁、取票機、搜索、推薦）。綜合起來看，影院+入口位置是比較合理的粒度。

商品粒度太細，且數據是動態變化的，維護起來比較麻煩；App維度又太粗，一次性切換起來涉及的範圍太大，且沒法回滾；影院的粒度處於中間，數據變化小，流量也比較好控制，因此咱們採用了影院做爲主要的切換粒度。

另外，因爲商品業務自己的特色比較碎片化，入口衆多，還得對接美團、點評的搜索、推薦等服務，因此將入口位置做爲輔助的切換粒度。

切換以前，先給全部的展現入口分配固定的渠道號，如圖5所示。支付頁是渠道1，取票機是渠道3，客戶端在請求後臺數據時，須要帶上渠道號；而後商品業務系統將查詢邏輯抽象成處理器，例如貓眼支付頁處理器對接貓眼的商品中心，而美團的支付頁處理器對接美團的商品中心，公共流程如排序、最低價計算，能夠抽象到父類中。

當一個查詢請求到達商品業務系統後，由渠道分發控制器根據渠道號選擇對應的處理器，同時，渠道分發控制器須要詢問渠道切換服務的建議，看看是走團購體系仍是走貓眼體系。而咱們只須要在渠道切換服務內部維護一個走貓眼體系的影院+渠道列表，而後用配置推送服務動態更新，就能夠實現影院+入口位置兩個維度的自由切換了。

經過以上的辦法，後臺系統已經在商品展現層面實現了兩個體系的自由切換，但後續的交易流程還有很長，須要客戶端可以分辨後續該使用哪些接口，才能夠走到正確的交易流程。圖6是客戶端須要配合作的改動：

客戶端須要維護兩套交易接口的列表，一套走美團，一套走貓眼。後臺接口在返回商品數據時，會帶上商品是否貓眼的標記，若是爲true，則後續流程都使用貓眼的交易接口；若是爲false，則都使用美團的交易接口。等到切換完成，後臺返回的標記所有變成true，客戶端也能夠考慮刪除這段邏輯，直接使用貓眼的接口列表。

2.1.4 統一id服務

最後，考慮商品交易和已有業務的關係。

交易的核心是訂單，而貓眼內部已經存在一套選座訂單了，但這二者的模型差別很大，沒法複用，因此只能選擇自建訂單，在訂單號層面作好統一，下降將來數據融合的複雜度。

統一訂單id，就須要一個統計id服務，如圖7所示。每一個交易業務在下單前，都從統一id服務獲取訂單號，而後再下單，這樣能夠保證整個公司的訂單號分佈在同一個遞增序列下，下降促銷、結算等系統融合的複雜度。

2.2 核心服務自建

完成了前置方案的設計，接下來要分析交易須要哪些核心服務，下面是商品業務的行爲分析圖：

從上圖中能夠看出，整個交易過程能夠簡單的劃分爲三個階段：交易前（商品爲核心）、交易中（訂單爲核心）、交易後（即消費過程，商品券爲核心）。下面詳細分析每一個階段的核心模型該如何設計。

2.2.1 商品輸出模型

根據商品的做用，咱們能夠將商品信息的存在形式分紅三個階段：編輯階段、使用階段、業務聚合階段。如下是這三個階段的說明：

● 編輯階段，即還未成形的商品。

這個階段以上單流程爲核心，維護商品的寫模型，因此須要重點關注商品的增刪改操做，並作好審覈機制和操做記錄。這個階段的模型主要維護在上單系統裏邊。

● 使用階段，即經過審覈，容許售賣的商品。

這個階段維護的是商品的基礎信息，一部分信息是隻讀的，例如商品標題、價格、所屬的門店等；另一部分是可變的，例如庫存量、銷量、商品狀態等。使用階段的模型主要維護在商品中內心邊。

● 業務聚合階段，即整合其它信息之後的商品。

這個階段維護的是商品的讀模型，不能改變商品的任何信息，例如商品列表是聚合了多個商品信息，商品詳情則是聚合了商品基礎信息和促銷信息。當外部系統，例如搜索等服務須要接入商品體系的時候，都應該輸出業務聚合階段的商品。這個階段的模型主要維護在商品業務裏邊。

定義好商品的三個階段之後，就能夠根據每一個系統使用商品的方式來組織系統的關係，獲得圖9所展現的輸出模型。

2.2.2 訂單處理模型

訂單是交易過程當中最重要的模型之一，也是最容易和業務耦合太重的模塊。因此在設計訂單模型的時候，須要重點考慮如何讓訂單和業務流程分離，只關注訂單的基本信息和狀態流轉。考慮點主要有如下幾點：

● 命令模型和查詢操做須要分開，即CQRS。

例以下單和查詢訂單詳情兩個操做，前者是交易的主流程，會寫入訂單的信息，然後者不會改變訂單的任何信息，只須要查詢到訂單便可。另外，下單重視的是業務流程，核心指標是穩定性和準確性，而查詢訂單詳情重視的是數據聚合，核心指標是完整性和用戶體驗。

● 業務流程和訂單處理過程須要分離。

例以下單操做可能會分爲好幾個步驟：判斷商品是否可售、計算商品的價格、鎖庫存、寫訂單數據等。這些步驟是業務流程，訂單不該該關心。並且每一個業務的交易流程可能會不同，因此須要一個靈活性更高的辦法來處理交易流程。

考慮以上兩個問題後，咱們設計出了訂單處理模型，如圖10所示。

首先得開發一個任務處理引擎，負責處理業務流程中的單個任務，例如鎖庫存、生成商品券、推送訂單信息等等。每個任務都對應一條數據庫記錄，用來講明要使用哪一個處理器、用到的數據該從哪裏獲取，以及步驟完成以後該怎麼辦，記錄之間也會使用編號鏈接起來，用來處理優先級和依賴關係。

接單服務負責將不一樣業務的下單流程拆解成一個個子任務，並肯定好任務之間的優先級和依賴關係，進行簡單的編排，而後寫入到任務引擎的數據庫中，而任務引擎則負責撈取這些任務，分析並執行已經編排過的任務。這種方式的好處在於業務流程被拆得很細，不一樣業務之間能夠重用一些任務處理步驟，當一個新的交易業務接入的時候，只須要添加對應的子任務處理器，而後在接單系統中配置編排的規則，便可快速支持。

如圖10所示，咱們將訂單的寫模型和查模型分開，讓增刪改三個操做都走訂單核心繫統的寫模型，而用戶查詢操做則走訂單查詢系統的查模型。每次訂單信息有變化的時候，訂單核心會通知任務引擎，由任務引擎負責更新查模型。這期間會有時間上的延遲，因此訂單查詢維護的查模型只能給用戶端展現需求使用，而退款過程當中查詢訂單狀態則必須走訂單核心的寫模型，由於寫模型的狀態是實時的。

用戶成功支付訂單之後，訂單核心會收到支付成功消息，而後將不一樣類型的訂單拆分，並挨個通知任務引擎，執行支付成功後的業務流程，例如生成商品券、推送訂單信息到美團訂單列表等。

2.2.3 商品券與結算模型

商品券和物流是消費過程當中的核心模型，而結算恰好要的就是消費維度的數據，因此這二者的設計緊密相關。因爲商品券和物流比較相似，因此本文只介紹商品券的模型。
商品券的本質是一串數字，用來做爲兌換服務的憑證。它的特色：

● 一是要足夠亂，不能讓你隨便輸入一個數字就可使用；
● 二是不能重複，不然沒法分清對應的是哪一個服務。

在數據操做上，商品券須要支持生成、驗證、撤銷等操做。
通過以上分析，咱們設計出了商品券和結算的模型，如圖11：

爲了足夠亂，系統須要一個隨機數生成的模塊，同時爲了避免重複，須要爲隨機數創建一個防衝突表，每次生成完隨機數，都須要到防衝突表裏查一下是否有使用過。因爲隨機數是有限的，生成的碼越多，衝突的機率就越高，對併發度會有必定的影響。爲了優化這個問題，咱們採用了異步生成的方式：先預生成必定數量的劵碼，並添加到一個可用劵碼的隊列中，在不一樣的併發數下，只要調整隊列的容量和預生成速度就能夠支持了。

當用戶經過pos機等設備驗證券碼的時候，商品券會發消息給結算系統，結算系統會寫一條流水數據到數據庫中，並按照結算週期聚合到一塊兒造成付款計劃。結算系統也會天天掃描合同中約定的結算週期，觸發打款操做。

2.3 線上線下切換

在前文介紹的前置方案裏，咱們已經提早將切換點埋入到了客戶端中，當交易模型搭建起來時，線上實際已經有大量的客戶端支持在兩個體系切換了。但此時，咱們還不能着急將全部的商家都切換到新體系，須要考慮更多的問題：

● 舊體系已有的業務，在新體系是否都已經支持。例如促銷、優惠券，必須在業務對齊的狀況下才能切換，不然會干擾到商家的正常運營活動。
● 商家結算的模式是否支持切換。在拆分過程當中，結算、財務方面的數據是惟一不能遷移的數據，任何的變化都須要兩個公司財務之間覈算清楚才能執行。因此在切換以前，須要根據結算的模式，將商家作好分類，優先將結算方式簡單的商家切換到新體系，用於驗證線上服務的正確性和切換方案的合理性。
● 交易過程當中是否依賴第三方系統。例如貓眼在交易後的過程當中，依賴了影院的第三方券系統，致使了這部分影院必須在對接完依賴的第三系統以後，才能夠切換。
分析完上述三個因素，肯定好能夠切換的商家列表以後，就能夠開始和商務一塊兒推動線上線下的切換了。切換的過程當中，須要注意線下的切換一般比線上要緩慢，因此要預先啓動線下的切換，並讓商務團隊給商家作好培訓。

三．技術融合方案

通過技術拆分，貓眼實際擁有了一套完整的商品供應鏈和交易體系，而此時點評的商品業務也有一套本身的供應鏈和交易。爲了下降從此的維護成本，咱們必須將點評的商品業務適配到貓眼的這套供應鏈和交易體系之上。

供應鏈層面的解決方案和拆分的方案相似，這裏再也不詳述，重點說說交易層面的適配和融合辦法。設計融合技術方案的時候，須要重點考慮這麼幾個問題：

● 客戶端調用接口的遷移問題。點評客戶端以前對接的都是點評的業務服務，須要替換成貓眼的業務服務。
● 交易流程銜接以及頁面跳轉的問題。融合以後，核心的如訂單、支付、券消費確定得走貓眼的交易體系，因此整個交易的頁面和跳轉都應該使用貓眼的頁面。
● 已經有的數據整合問題。在融合以前，點評已經積累了大量的商品訂單和券數據，這部分數據須要和貓眼的數據進行整合，才能知足用戶和商家的查詢需求。

3.1 業務入口適配

針對客戶端調用接口的問題，解決思路和拆分的方案差很少，也是提早創建業務層，將客戶端使用的接口都回收到業務系統，而後再適配到貓眼的業務服務，如圖12所示。

爲了儘可能不維護兩套業務系統，貓眼在融合一期工程的時候先採用了簡單的適配，目的是將業務入口先牽引到貓眼的交易體系，而後在後續的開發中再讓點評客戶端直接對接貓眼的業務系統，逐步取代點評的適配層，等到須要適配的版本愈來愈少的時候，就能夠廢棄掉這個適配層了。

3.2 交易過程使用觸屏版

交易流程的銜接和跳轉是個比較棘手的問題，一是貓眼之前沒有在點評客戶端作過開發，爲了融合單作一套native交易頁面的代價較高；二是從此在作功能迭代的時候，要適配的端太多，會拖慢產品迭代的速度。綜合考慮了流量、體驗和團隊多方面的因素以後，貓眼決定使用觸屏版來解決這個問題。

商品交易有一個特色，即大部分的下單操做都會先通過商品詳情頁，因此只要從商品詳情頁開始，作一套觸屏版頁面，就能夠將交易流程都引導到貓眼的頁面了。

然而商品的展現一般比較碎片化，可能會有搜索、推薦、商品列表、猜你喜歡等各類入口，因此進入交易的第一步就是儘量的讓展現入口都跳轉到觸屏版的商品詳情頁，而後繼續下單、支付，再跳轉到觸屏版的結果頁。訂單成功以後，貓眼再將本身的訂單數據 推送到點評的訂單中心，同時將訂單詳情頁的跳轉設置成觸屏版。一旦用戶點擊訂單列表，就又回到了貓眼可控的範圍內，後續的退款、消費、客服就走回到貓眼的交易體系，具體的作法如圖13所示。

整個過程當中，可能會遇到一些其它的問題，例如跳轉登陸：點評客戶端登錄的是點評帳號，而貓眼的觸屏版登錄的是貓眼帳號，因此這個作法還依賴於帳號的融合。在跳轉收銀臺的時候也須要當心謹慎，須要點評收銀臺和貓眼收銀臺採用一樣的驗證方式和解析規則，不然極容易出現金額錯誤，或者沒法支付的狀況。這些也是觸屏版須要考慮的問題。

使用觸屏版的前提是：交易流程必須通過商品詳情頁，假如交易流程不通過商品詳情頁的話，就必須對多個業務入口進行適配，但跳轉到收銀臺以後的流程，仍然是能夠複用的。

3.3 數據整合思路

數據整合是技術融合中最繁瑣的部分，作法一般有三種：

● 數據層面不作整合，在代碼層面區分該走哪一個數據源。這個方法的優點在於數據可不作改動，但須要維護兩套數據源，成本較高。
● 數據層面創建映射關係，而後經過轉換層將數據轉換成業務方須要的模型。這個方法的改動成本比較可控，能夠快速實現兩個體系的互通。
● 數據層面作完全的整合，將兩方的數據遷移到一個數據源中。這個方法的優點是隻保留一套數據模型，後期可維護性高，但整合的難度大，須要重點處理差別數據。

貓眼和點評數據的整合過程當中，主要之後兩種方法爲主，如圖14所示：

查詢數據一般使用的都是id，而咱們能夠簡單的將數據id分爲兩類：一類是不能變化的，例如影院id；一類是能夠變化的，例如訂單id。

對於影院id，貓眼和點評都有本身的一套序列，並且這兩套id都依附在各自的商家體系上，不能輕易統一塊兒來，因此只能經過創建映射關係的方式來實現互通。圖14中左半部分的示例就是解決數據id不能改變的場景：

先將點評的影院id和貓眼的影院id創建映射關係，例如貓眼的影院id=1和點評的影院id=2，可能指向同一家影院（只是舉例使用，不保證必定是對應關係）。而貓眼app和點評app依然使用以前的id，只是在查詢數據的時候，會先通過數據轉換層，由數據轉換分析映射關係，拿到統一以後的影院信息。

對於訂單id，用戶一般不會手動記錄訂單id是多少，徹底依靠後臺返回，這時候就能夠將點評的訂單數據按照貓眼的格式，遷移到貓眼的數據庫中，並將id轉換成貓眼序列的id，字段若是不一樣的話，可使用擴展字段或者差別表作一層兼容。

圖14的右半部分描述 的就是這種作法：用戶在查詢訂單列表的時候，返回的是貓眼的訂單id，那麼進入到詳情的時候天然就會查詢貓眼的訂單數據，這樣就實現了數據整合。

須要注意的是：修改訂單id的時候，一般須要修改全部和訂單相關的數據，例如促銷、商品券等系統，都是以訂單id爲區分依據的，這就須要同時改動全部受牽連的數據，須要當心謹慎地去推動。

4、案例啓示和教訓

技術拆分和融合的過程在貓眼內部持續將近半年時間，期間遇到了很多困難，對系統架構和模型也進行了較多的思考，如下是從案例中得到的啓示：

● 在大公司作垂直業務時，若是要複用平臺的服務，最好在客戶端和平臺服務之間創建業務層，作一層服務轉接，這樣能夠爲服務的替換提供更好的靈活性。
● 在設計系統模型時，儘可能讓業務入口渠道化、處理過程組件化，這樣不只能夠提升系統的橫向擴展性，並且也能夠對每一個入口作更精細的把控
● 不一樣業務在快速發展時，能夠有本身的核心服務，但必須使用統一的id生成策略，保證模型的主要id屬於同一個遞增序列，這樣能夠爲之後的融合，或者平臺化減小數據整合的複雜度。
● 數據模型層面，儘可能將命令模型和查詢模型分開，一方面能夠將主流程和數據展現操做完全分開；一方面也能夠下降數據操做的複雜性。
● 系統的流量控制和切換粒度要足夠精細，這樣能夠提升應對風險的能力。

也從本案例中積累了一些教訓：

● 設計技術拆分和融合方案時，須要全面考慮非技術因素的影響，好比結算、財務，數據既不能遷移，也不能修改，此時財務的結論頗有可能會影響總體的切換方案和模式設計。
● 線下的切換要提早進行，以便儘早收集到業務一線的反饋，能夠並行的去修復問題，這樣才能保證在線上開始切換的時候，不被拖慢進度。

5、總結和感謝

技術拆分和融合是一個龐大的工程，涉及的技術點比較多，因爲篇幅有限，本文只是介紹了總體的設計方案，但願給行業中遭遇相同問題的工程師們提供一個參考案例。

最後，在此感謝全部參與本次技術拆分和融合的技術、產品、運營和商務、財務團隊全部的小夥伴，以及美團點評熱心幫助的同事們。有了你們的緊密協做，才能在有限的時間裏，完成如此複雜的技術升級。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峯會，美團外賣算法架構師郝井華將分享《美團配送智能調度系統演進》；美團點評酒旅質量團隊工具鏈負責人王鵬將分享《微服務架構下的自動化測試和持續集成工具鏈實踐》。

TOP100全球軟件案例研究峯會已舉辦六屆，甄選全球軟件研發優秀案例，每一年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。大會開幕式單天體驗票申請入口