【51CTO.com原創稿件】WOT2016大數據峰會將于2016年11月25-26日在北京粵財JW萬豪酒店召開，屆時，數十位大數據領域一線專家、數據技術先行者將齊聚現場，在圍繞機器學習、實時計算、系統架構、NoSQL技術實踐等前沿技術話題展開深度交流和溝通探討的同時，分享大數據領域***實踐和最熱門的行業應用。

51CTO記者在會前采訪了小米公司研發總監歐陽辰，他是小米公司MIUI商業產品部的架構師和研發主管，是此次WOT2016大數據峰會重要演講嘉賓之一。他的演講主題是小米程序化廣告交易平臺(MAX)的架構實踐。

【受訪人簡介】

歐陽辰·小米公司研發總監

歐陽辰，目前就職小米公司MIUI商業產品部，擔任架構師和研發主管，主要負責廣告平臺系統架構，廣告交易系統研發和數據平臺。之前在微軟工作10年，帶領團隊從事互聯網廣告和搜索引擎的研發工作，包括負責微軟移動上下文廣告系統和數據算法，必應搜索引擎的Index Serve的性能提升，最早在甲骨文公司從事數據庫的研發工作。

當問及所處團隊當前的規模和業務劃分情況，歐陽老師這樣說：“小米商業產品部目前是百余人的規模，其中大部分為技術人員，整體團隊還在不斷增長，不斷有廣告行業技術專家加入我們。研發部門按業務目標劃分，可分為媒體方、系統架構、策略算法、廣告主服務和數據平臺。媒體方組負責媒體變現對接和用戶體驗，系統組負責架構演化和可靠性，策略算法組負責點擊率預估、相關性等，廣告主服務負責提升廣告主滿意度和ROI，數據平臺提供數據洞察和營銷數據平臺DMP”。

小米程序化廣告交易平臺(MAX)的架構設計思路

關于架構設計思路，歐陽老師談到架構設計本身就是一種學習和演化，踩坑踩多了，知道哪些地方不能走，也便成了思路。廣告平臺的設計思路是從幾個方面出發：

首先是對于目前業務和未來業務的深刻理解，一直堅信架構是為現在和未來的業務服務的，減少業務變化而引入的成本，在設計理念上更愿意按照業務分解系統，特別是將需求多變的業務模塊隔離出來，減少耦合。

其次，架構設計需要和團隊的組織方式是一致的，遵守康威法則，例如在平臺建設初期，各個業務小組都飛速發展，放馬狂飆，那么架構需要提供足夠的靈活性。

另外，廣告系統對于可靠性要求非常高，不僅僅涉及到用戶體驗，也涉及到業務收入，因此系統的預警，報警和錯誤排除都需要大力投入。廣告系統也有業務驅動的特點，不同的廣告業務可能需要不同的系統架構來支持，因此架構的擴展性和可演化性也是非常重要的，需要支持業務的小步快跑，敏捷式迭代。

小米程序化廣告交易平臺(MAX)的演化過程以及對應業

歐陽老師表示平臺架構的過程實際上是一個演化的過程，每一步演化都是為業務服務的。其可以分為四個階段，分別是”加、減、乘、除”。

***個階段是加法，不斷的上線新業務，整個系統不斷復雜化，結果造成各個業務之間耦合很厲害，在后期，每一次設計涉及的影響都很大。

第二個階段是減法，為了解決***階段的問題，系統的解耦成是一項最重要的工作，將各個模塊獨立出來，服務化，減少各個模塊之間的不必要的聯系。

第三個階段是“乘法”，這一階段的業務發展脈路較為穩定，各個模塊分解的比較合適，各個模塊（服務）都可以利用各種技術，高速提高服務質量，例如數據處理方面，通過流式處理，大大提高及時性；算法模塊在解耦后，也大大提高了算法上線的速度和種類；架構服務化后，系統的容量和可靠性也大大提高。

***一個階段是“除法”，整個系統變得非常大且復雜，開發人員也有近5倍的增長，部署的機器也有近10倍的增長，服務模塊數量也超過20個，這時候架構的調整涉及到一些抽象，按照業務分為服務群，對于離線的數據流也進行了大規模的優化，整合了一些分散的小模塊，使得整個系統更加簡單。

值得分享的經驗是，架構師的工作不是創建一個靜態的，美麗的架構藍圖，更多的工作是在成本、質量、收益和速度中找到長期技術投入的平衡，其目標是支持業務的快速發展。

研發過程中遇到的問題及經驗教訓

談到經驗教訓，歐陽老實說開發過程中踩坑是不可避免的，關鍵是能從踩坑中吸取教訓，不要第二次踩到同一個坑。架構設計上，其個人收獲到很重要一點就是：架構及演化一定要堅持為業務服務。這部分，他舉了兩個例子：

其一：一年前剛剛接觸這個平臺時，當時感覺平臺的層次不清楚，各業務之間的重復性很高，很多代碼不忍直視，我的***個直覺就是需要一個周全的架構，統一化的廣告檢索，可擴展的廣告檢索元語言等，基于這些想法和過去多個廣告平臺的經驗，設計了一個廣告演化的目標架構（所謂藍圖），有些模塊沿著這個思路開始了重構工作，有些模塊并沒有重構，沿著老路發展，半年以后，我們再回首當時的決定。當時重構的模塊是業務相對穩定的模塊，后期的業務并沒有從其中得到太多直接好處，雖然代碼很整齊，設計很規范，但是投入和產出比很低； 對于沒有重構的一些模塊，在各個新業務的沖擊，打磨和碰撞下，不斷的進行自然演化，反而成為最適宜業務變化的模塊，回想過來，其中的很多設計都不是當初能夠規劃出來的，因為很多新業務都未到位。

其二：關于MySQL的，在項目初期使用MySQL一直很順利，讀訪問量大了，就采用、讀寫分離；寫訪問量大了，就進行垂直拆庫（分表）；數據量繼續增長，然后進行水平拆庫、水平擴展、引入代理層；然后數據量又長大了，不得不將部分數據移植到HBase里去。整個過程中，我們在MySQL折騰了太多的時間，每一次數據庫改進都需要花不少人力，而且容易出錯，每次的工作成果只能維持很短的一段時間，總結出一個簡單道理， 如果有機會再重新做一次，我會更早的擁抱NoSQL的解決方案，避免在MySQL上很多無謂的投入 。

開發和設計“老司機”給入行新手的忠告

每個人都是從新手成長起來的，新手往往是潛力無窮的。我有幾點小建議，也是我成長過程中，在多次經歷迷惑后的一些體會。首先，要學會確定自己想去的方向，確定自己想成為架構師還是某個領域專家，一旦確定目標了就可以多向周邊的大牛學習，看看優秀的同事都是如何思考問題的。 第二，保持學習的熱情，計算機行業新技術層出不窮，需要不斷的充電，了解***的技術動態。第三，在學習過程中，要坐的住冷板凳，學會漁而非魚，對于每種新技術，每一類問題，都會有學習的曲線，往往需要經歷過一段黑暗的曲線，堅持下去就是光明。另外，在解決問題的時候，盡量了解問題的原理，把問題想透，學會刨根問底的思考。

***，也祝愿剛入門的新手能夠享受計算機技術的歡樂和痛苦，這是一條長長的路，道長且阻，行則將至，加油！

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】