洋碼頭技術演進之路

最新 03-10

剩餘篇幅約10000字，可參閱下面的大綱分段閱讀。

系統架構

架構1.0

緩存、消息隊列、微服務

資料庫優化和分離

消息匯流排

轉型JAVA

自研開源分支

平台化運維

純人肉時代

平台化改造

海外線路優化

https及國內優化

自動化發布

基礎監控和業務監控

雙活機房和混合雲

容器化研究

數據科學

全站埋點

千人千面、個性化搜索/推薦

推薦系統實時行為反饋

AB測試系統

門神、風控反作弊

項目敏捷

敏捷的理念

持續集成

測試

全鏈路壓測

自動化測試

進化

在2013年初，洋碼頭的技術團隊只有20人，洋碼頭當時的技術表現形式類似一個傳統的PC電商網站。然而隨著APP形態的大熱，業務形態快速從傳統的PC網站向APP發展升級。在這樣的場景下，由於之前二、三年代碼堆砌下，洋碼頭的應用已經很臃腫，開發人員都在抱怨編譯慢，系統模塊也不能重用。最初級形態的系統架構就這樣自然的發生了，技術團隊開始對應用進行拆站、組件化和服務化工作，並制訂了最初的主站架構藍圖。從最複雜最核心的訂單交易業務開始，把訂單交易相關的代碼拆分出來，快速封裝成一個restful風格的服務，供各端調用；然後將活動站、商品模塊、列表、搜索等開發內容拆分，不再共享同一個應用，使得開發效率有了一定的提升。

經過上述改造，這個架構迎來了初次的業務高峰，並成功接受了第一次交易峰值的洗禮。雖然從現在來看那個峰值並不高，而且這種拆分還是相當簡單粗暴的，有很多後遺症，但是從當時的人力情況來說，這個方案快速的解決了重用業務邏輯和開發效率的問題，有效的支持了當時的業務能繼續高效發展。

2013-2014洋碼頭技術架構圖

在第一次的架構圖設計完成之後，洋碼頭開始有了專職的架構師，並完成了幾個非常關鍵的開發工作：

商品服務重構引入了redis緩存方案；

引入了分散式消息隊列RabbitMQ，基於開源框架二次開發了一套事件匯流排的架構，一定程度上解決了當時各系統之間的集成問題；

核心交易下沉為獨立的服務，基於事件機制，快速與包括商品、活動、庫存等模塊進行集成；

從單一的PC網站，轉變為同時面向PC、手機APP、手機WAP等多元化業務生態系統。

同時，線上環境的伺服器資源進行了數倍的擴張，有效的緩解了線上系統的訪問壓力瓶頸。不過業務的複雜性是遞增的，擴容只能解決單點的性能問題，沒有合理的架構，單純靠物理硬體的投入是不可能長期支持業務的爆髮式增長的。而且多個敏捷小團隊並行開發，版本合併、回歸測試等等耗時耗力的任務仍然嚴重的影響著業務功能的快速交付。服務化勢在必行。當時正值微服務大熱，技術團隊對服務拆分改造熱情高漲，陸續將下單、購物車、優惠券、庫存、限購策略、紅包等業務的服務拆分，分由不同的團隊開發和維護，從原本的版本合併完成後兩周發一次版本，變成一天幾十個服務分頭髮版上線，大大提高了並行開發效率。

2014-2015服務化架構圖

在性能上，這個時期設計的商品瀏覽、價格、庫存、活動信息等大部分都是直接讀取資料庫，內部又包含了大量的join，性能很差，經常性地把主資料庫的IO/CPU等瞬間拉高，並導致其他應用受到影響。當時的解決方案是不光從硬體上投入更好的資源，同時單獨啟用MongoDB集群對只讀業務進行分離，將相關信息使用消息匯流排的方式近實時的同步過去，這樣分拆後查詢效率得到極大的提高，並達成了初步的讀寫分離。

隨著服務化的推進，系統間的關係越來越複雜，迫切需要一個非同步處理框架來解決系統間解耦，非同步調用的問題。隨之架構團隊啟動了第一代消息匯流排服務，採用RabbitMQ作為消息中間件。定義了一套restful風格的標準的消息發送和消費介面，這樣各業務系統就像調用普通的服務介面一樣調用消息匯流排，沒有任何負擔；同時消費端也不需要關心消息中間件怎麼用，只需要提供一個webAPI介面就行，匯流排自動會分發到各訂閱站。這大大簡化了非同步系統的開發。很多業務系統（包括我們大量需要雙寫的系統）都接入了消息匯流排，使之成為整個電商系統不可或缺的一部分。

但是第一代的消息匯流排存在一些不太好解決的問題，比如客戶端發送失敗怎麼辦，RabbitMQ腦裂導致消息消費時丟失怎麼辦？吞吐量特別高的時候，比如用戶認證消息，批量發送用戶營銷消息，RabbitMQ的性能可能不夠。架構團隊很快又啟動第二代消息匯流排的重構，通過匯流排客戶端MQ組件內嵌內部資料庫的方式解決發送失敗重試的問題，針對關鍵消息引入mongoDB二級存儲，在中間件出問題的時候，可以通過DB進行補單，甚至在兩種存儲都出問題的時候，還可以通過服務端本地文件隊列維持消息匯流排的正常運行。同時針對大批量的數據分發業務，引入Kafka來解決問題。通過後台配置，可以在兩種存儲之間進行切換。

2016年起技術團隊決定技術平台轉型試點，從.NET逐步轉到java平台，線上服務越來越多，迫切需要一個服務框架來治理這些服務。那個時候springboot、 spring clound剛剛起步還未流行起來，技術團隊選擇了業界比較成熟的dubbox,可以同時支持dubbo協議和基於http的json協議，該框架自帶服務註冊和發現，同時通過客戶端組件進行服務調用的負載均衡，實現了P2P的服務調用，不再依賴中間代理伺服器。目前大部分核心服務都已經完成了基於dubbox的微服務改造，系統的性能有了明顯的提升，部分.NET業務開始試點.NET CORE。

在架構不斷演化升級的今天，洋碼頭架構團隊根據業務場景需要，已經先後開發推出了多個重磅級產品，包括根據開源系統定製的洋碼頭分支disconfY和DubboY，消息匯流排服務、高性能高可用的RPC框架、統一後台和批處理調度服務、計數服務等。在業務和應用架構方向，對系統做了多重拆分方案，將應用層和服務層分離，基礎服務獨立出來並可復用，對獨立的業務進行了垂直切分。明確了服務化方案，對各服務提供的介面進行了整理規範，細化了服務的職責。技術架構決定了可以支撐的業務高度。洋碼頭這幾年來在技術架構上的持續構建和優化逐漸展現威力，近幾年多次大促中業務系統穩定流暢的表現便是最好的註解。

在洋碼頭成立之初，受制於團隊規模，線上運維團隊大部分的工作是使用一些簡單的腳本程序進行人肉發布。發布效率低工作強度卻非常的高。且由於資源緊張和準備不充分，自動化程度不高，2014年末的首次黑五齣現了大量的不可接受事件：先是黑五預熱期出現了異常流量，由於當時設計未考慮周全存在性能瓶頸，導致一個較大壓力流量波峰過來就會系統響應過慢而無法響應；緊急修改上線後又來了新的流量直接把redis內存吃滿，當時的硬體資源也非常有限，運維團隊手忙腳亂的花了不少的時間去處理擴容；隨著黑五大促的開始，各種性能和壓力峰流隨之而來，系統到處報警，只能見招拆招頭痛醫頭。還好當時採購了一台硬體WAF應用防火牆在前端扛著，發現一個問題手工設一個防護策略，跌跌撞撞的把首個黑五扛下來了。

經過了首次黑五大促，2015年起運維團隊開始大力推動自動化和平台化改造，結合上游測試團隊，在不斷的摸索改造中總結了多項要求：

線上的任何服務節點都不允許有單點；

整個測試到上線過程必須是全自動化的；

要有完善的線上監控管理系統；

要有統一的運維管理平台；

國際訪問線路需要優化；

用戶訪問速度要持續提升；

細粒度針對業務的防禦功能要高效可靠；

運維和發布的細度和頻度會要求要高；

業務監控要更加深入和細化；

雙機房保障；

……

經過多次的迭代開發，洋碼頭運維平台集成了大量開源二次開發和自研的運維工具，令日常運維工作變得簡單便捷。開發人員可以使用Jira系統完成全自動的服務上線工作，也可以利用運維平台直觀的查看業務異常和報警數據，查看線上的實時日誌，查看線上的資料庫數據是否正確（自動脫敏），對任意環境的業務配置文件進行修改管理等等。

洋碼頭運維平台

在經歷了幾次大促後，運維團隊發現每年到了10月底，海外國際線路就開始頻繁不穩定，在很久以後才知道原因：每年這個時間點因為國內重要會議保障、通信商封網和線路優化導致的割接、國內外訪問大量上升等原因會導致中國網路出口壓力大量增加，線路的擁堵導致海內外互訪速度明顯波動。而洋碼頭的黑五大促正在這個時間段內，海外買手和貨站的高頻次訪問請求受到明顯影響。洋碼頭運維技術團隊想了很多方案來緩解這個非常棘手的問題。最終，運維團隊使用了第三方廠商的高速國際通道服務，業務在香港地區部署，將國際用戶請求從海外加速廠商Akamai回源到香港入口，如果通路中斷或緩慢會自動從常規線路回源目標節點，完美的解決了海外訪問的速度問題。

APP的用戶體驗和原本PC端用戶的體驗是不一樣的。技術應該都聽說過八秒法則，當一個用戶訪問WEB網站時如果超過八秒，70%的用戶會放棄。然而到了APP時代，別說8秒，APP請求內容超過1秒鐘才出來都可能會導致用戶感受太慢而放棄APP。洋碼頭技術團隊很早就開始重視用戶的訪問速度，先後做了多種技術優化，例如對圖片做了webp格式處理、核心介面嚴格限定返回時效、客戶端預緩存和DNS刷新等等。同時針對國內普遍存在的運營商劫持和DNS污染等情況，適時推動了全站https化，基本杜絕了在2015年以前經常會出現的APP中內容被惡意篡改的情形，同時用戶的訪問速度並沒有因為上了https變慢，反而因為各類技術優化效果好，大大提升了使用感受。當時網上有一個洋碼頭APP的小視頻，展示了在APP中快速下拉滾動，完全無延遲的流式秒現商品圖片和內容的場景，充分體現了優化後的速度現狀。

經過2015年的線上發布系統運行，洋碼頭技術團隊認為還需要進一步強化自動化工作流。因此在2016年大力推行了Jira流程和運維發布的自動化結合改造，並最終使得業務上線完全由開發測試來實現，將運維從繁瑣的日常發布工作中解決出來了。運維研發團隊還設計了一鍵擴容、線上數據查詢系統、線上日誌查詢系統和基於ES的實時業務日誌查看等系統，進一步提升了運維和開發人員的工作效率。數據顯示2016年平均每周線上發布超過500次，發布高峰時近1000次。和最初沒有自動化時人肉發布效率不可同日而語。而在2017年，運維團隊進一步加強了各自動化功能之間的閉環，改善線上發布為自動灰度發布模式、一分鐘快速全自動擴容、發現特定異常自動預處理並在完成後通知對應運維和開發人員等等。基本上常規的運維工作都只需要在界面上點點看看就能完成。

在完成了基礎監控開發工作的同時，針對應用和業務的監控分析工作也早已經開始。在2016年前後，原有的應用性能監控系統升級優化為全新的獵鷹falcon系統，該系統後端使用了Cassandra資料庫來改善系統異常時的超大並發讀寫性能問題。獵鷹系統可以快速查看針對應用和介面的訪問PV、耗時，同時提供查詢API，結合運維監控工具可以在一張報表上實時聯動查看性能和異常情況。在業務監控上通過對業務數據的分析挖掘，除了常規的GMV、註冊登錄等數據外，還開發了可以實時查看客戶端請求性能數據、設備安裝、買手商品發布和做單時效等高度業務相關的監控數據，為優化業務和提供快速分析建立了有效的基礎環境。有了這麼多的基礎監控信息，洋碼頭技術研發了全鏈路監控系統，能從用戶請求入站開始至最終請求到內容成功返回進行完整監控，任一應用或業務出現異常，都會立即在全鏈路監控大屏上即時展現出來，得以最快速的分析和解決。

碼頭全鏈路監控系統

最初的洋碼頭只有一個核心機房，單一的運營商線路。為了避免機房異常導致的風險，在2015年起洋碼頭技術團隊就開始籌備雙機房，在2016年雙機房的硬體部署都已經到位，機房之間通過裸光纖打通，保證數據傳輸基本無延遲，同時設定了運維上線邏輯，每個應用都不得有單點，保證散布在不同的機房和不同的機櫃、不同的物理伺服器之上，避免因為一個機房、一個機櫃、或者一台物理伺服器的損壞而導致這個應用完全不可使用。

不過僅僅是雙機房是不夠的，因為如果單個機房出現問題，還是會有較多的手工操作來處理切換到另一機房，因此有必要完成雙活部署。在2017年洋碼頭運維團隊通過對資料庫、緩存、應用等的分離部署，調整前端流量調度進入模式，完成了真雙活機房的部署。在此結構下，平時二個機房同時承載壓力，但特定場景下的一個機房或線路不可用會自動調度到另一機房支撐核心業務正常。

作為電商平台，洋碼頭的業務模式決定了在年度最大的黑五活動期間會出現數十倍於平時的突發訪問峰值，如果全部靠自建投入計算資源來解決大促的峰值壓力，成本上是非常不合算的。因此洋碼頭運維團隊積極和雲廠商溝通實現細節，實現了在保證應用框架結構不需要改變的情況下，突發峰值的壓力應用可以在雲上快速自動部署上線的混合雲結構。這個結構可以在黑五峰值壓力來臨時，只需要半到一個小時的提前準備，就能在雲端迅速部署完成幾百個應用並投入使用，保證線上訪問

洋碼頭的運維平台化已經非常成熟，大量基礎運維工作都可以通過平台自動化或簡單界面維護完成。但自動化程度高也使得其他新的自動化運維技術缺少落地場景。洋碼頭運維團隊經過同行調研和技術判斷，主動擁抱變化，展開容器化的研究和實操。目前洋碼頭的k8s容器平台已經完成高壓力測試，正在結合自身業務進行平台自動化開發過程中，即將全面投入產線使用。

相對於PC網站，APP的入口更短，用戶訪問流量也集中。怎麼把有限的流量更好的分配給最合適的用戶是非常重要的事。業務上也需要知道用戶到底喜歡什麼，訪問服務時到底速度如何，新的功能用戶到底是喜歡還是討厭，如果沒有一套科學的大數據分析機制，只是通過運營或管理層來拍腦袋決策是完全不可行的。在這樣的背景下，洋碼頭成立了數據科學團隊，引用了行業主流的大數據分析框架，先後自研了洋碼頭AB測試系統、全站埋點、數據收集分析系統，針對業務展現實現了實時推薦排序系統、用戶特徵和訓練系統等等。

為了提供個性化的用戶體驗，洋碼頭技術適當的收集了用戶的行為數據。這些數據來自客戶端上不同頁面不同模塊中的埋點，收集用戶的行為包括點擊、滑動、停留時間等，然後將這些數據包裝成一條條的日誌，發送給我們的日誌收集伺服器，並進行大數據分析。

全站埋點

通過收集的用戶行為數據進行分析，可以在滿足用戶查詢的商品條件基礎之上,按照用戶的興趣偏好進行重新排序，最後應用業務邏輯對重排的商品列表進行打散，得到最終的搜索結果。

與搜索不同，個性化推薦的場景中沒有用戶輸入的關鍵詞，洋碼頭數據團隊通過演算法對用戶畫像中的信息進行初步召回，經過個性化模型進行重排，最後同樣應用業務規則進行打散得到最終的推薦列表，使得用戶能快速看到自己感興趣的推薦商品內容。

通過用戶的行為更新用戶畫像，可以得到模型的特徵並用於個性化搜索與推薦。因此用戶畫像更新的實時性決定了用戶個性化的體驗。與傳統的批量Map Reduce處理不同，洋碼頭數據團隊採用流式計算（Spark Streaming）的方式計算用戶畫像。如下圖所示，通過特徵和訓練系統，令用戶的行為數據以分鐘級的速度傳到日誌收集伺服器中，同時相關的業務系統也實時的向Kafka寫入日誌數據（如交易系統，搜索引擎等），這些數據再經過Kafka進入到Spark Streaming，由Spark Streaming中的應用去更新用戶畫像數據，從而快速得到幾乎實時的行為反饋信息。

大數據特徵和訓練系統

AB測試系統是洋碼頭進行線上效果優化和觀察的有利工具，其基本原理是通過對訪問請求按用戶緯度進行切分，使得用戶按一定比例落在不同的測試組中，然後通過對用戶的行為進行日誌收集、分析，最後以報表的形式進行直觀數據展示，以達到對比不同測試組所使用策論優劣的目的。目前該系統已經應用在洋碼頭各業務中，通過後台簡單配置可以非常快速的創建AB測試的實驗組與對照組。

AB測試系統配置界面

長期以來電商一直是黑客和羊毛黨重點關注的對象，洋碼頭在最初使用了第三方的雲安全服務，的確達到了不錯的通用防護效果。但第三方雲安全服務需要在外部再流量過濾一次，再高效也會有20-40ms的延遲，這對於追求用戶訪問極速的洋碼頭技術來說是不希望看到的。在2016年黑五前，技術架構團隊重點研發了自主實現的門神系統，不光可以防範常規的SQL注入、腳本攻擊、惡意爬蟲等，還能針對業務特點對每一次進出請求的進行特徵規則掃描，快速應對突發事件。自主研發的門神系統，性能非常的高延遲卻低於1ms，實際產線測試單機能扛數萬並發，而且可以完全線性擴容。

洋碼頭自研的反作弊系統可以快速高效的識別各種類型的異常作弊數據。系統由用戶關係圖譜、用戶行為風險評估、用戶內容檢測和買手信用評估四大模塊組成。用戶關係圖譜用於識別用戶集團，包括用戶馬甲、黃牛群體、賣家小號等，用戶行為風險評估模塊用於用戶風險數值化，用戶內容檢測模塊用於識別垃圾信息和不良內容，買手信用評估用於賣家在平台中使用增值服務的權利依據，如買手的快速提現功能。

洋碼頭反作弊系統

洋碼頭技術還集成了第三方用戶風控產品，結合自己研發的反作弊系統，對羊毛黨和惡意用戶、刷單等現象做了大量技術分析和處理，可以直觀的發現和制止各種惡意行為對洋碼頭業務生態的破壞。

用戶關係圖譜，惡意用戶、買手擼羊毛路徑自動展現

結合洋碼頭現有的業務水平和業務需求，技術團隊設計的這套基於大數據分析，以圖模型、圖計算為基礎的反作弊系統，滿足了優惠券活動、訂單交易、賣家增值服務、商品信息、社區運營等多方面的業務需求。創新的用戶流程化信息採集的技術，克服了傳統行業風控信息不對稱、數據維度狹窄、人工採集成本、效率低下的缺點。

2015年初，洋碼頭技術團隊迅速擴張，很快技術人員就從20人達到了3位數。大量的優秀技術新人進入後，項目管理是當時開始突出顯現的問題。同樣，時間對於發展的創業公司是非常寶貴的，當時技術管理層參與了一些外部的敏捷培訓，發現敏捷開發是解決這個問題的關鍵，於是在管理層的大力推動下，整個公司範圍內展開了敏捷轉型運動。

在每個迭代計劃會議上，各團隊需要把業務場景先梳理出來，全體參與成員在忙於自己手頭任務前，都需要先細想一下：為什麼要做這個，解決了什麼問題，給客戶帶來了什麼價值？PO在計劃會上向團隊介紹迭代backlog的使用場景（口述、現場畫圖、UI效果圖……）。團隊成員根據自己的理解，由開發或測試輪流主導，畫出業務場景圖。業務場景圖包含了幾個關鍵元素，場景解決的問題、用戶有哪些接觸點、需要展示哪些內容、用戶在這個接觸點上可能有什麼疑問。通過問答方式，讓團隊對業務場景和用戶行為有了清晰的認識。並通過識別接觸點，自然而然的將整個業務場景可以分為幾個階段來完成。同時為了令項目組有全局概念目標，還引用了敏捷看板（scrum board）的傳統使用方式來令信息更透明化。

在整個過程中，買家APP團隊成為眾多敏捷小團隊中最有代表性的一支隊伍。開發交付和問題解決的速度明顯加快了，團隊的滿意度和大家的認可度也都變高了。在這個過程中，洋碼頭技術團隊總結了其中最有效的敏捷理念：

需求先行

迭代開發

最小可行產品

及時溝通

快速決策

當下，洋碼頭技術團隊已經將敏捷的思想深入到了每個成員的心中，不再刻意強調敏捷，但敏捷卻無處不在。

自動化是敏捷的基礎，如果沒有自動化就沒有敏捷。在2014年底之前整體基礎措施還非常的簡陋，當時的測試環境有ALPHA和BETA二套，ALPHA相當於開發測試環境，BETA則是將線上數據的鏡像不定期離線備份下來的一個測試環境，或者說和線上數據脫離的預發布環境。版本是開發人員控制的，發布則是運維員通過半自動腳本複製上去的，整個環節到處都要人工干預操作。如果只有10-20個人的技術團隊，這套系統還能運作，但快速升級為100多人的大團隊，這套方案成為了絕對的瓶頸。2014年8月入職的資深測試工程師在回顧的時候深有體會的說到，當時到洋碼頭，上班時間不知道，下班時間是明確的——凌晨2-3點以後，天天如此，沒有周末。為了保證線上運行正常，發布單元對應的開發和運維基本上都要全程跟進。經常是開發周五寫代碼通宵到凌晨，測試周六早上來測試，發現測試環境上的版本卻不可用，可能是依賴的其他版本有問題或者配置有錯，排查問題沒什麼有效手段，只能等待對應的開發再過來編譯打包，半天一天過去了，一個功能點都還沒開測。測試團隊總結了最初碰到的問題，並為這些問題逐一設定了解決方式：

發布不能成為單點，要平台化；

整個過程必須是全自動化的，沒有任何人為操作，避免出錯；

要解決多個版本或者多分支的發布需求；

一個站點只能配一個域名；

……

雖然的找到了問題點，但制訂規範、實施和推動落地是細活。最初的洋碼頭網站有大約100個應用，卻分別使用到了.NET、java、NodeJS、python，.NET里還分IISWEB應用、windows service、甚至有console運行的應用，代碼庫也有好幾套，啟動和運行方式都不統一，非常的考驗團隊的技術能力。在多次的磨合中，最終技術團隊在測試部分選擇使用Jenkins來做中間的架梁，把規範化後的代碼庫、測試環境部署等全部使用自動化腳本實現，從開發到線上總共分為SIT、UAT、STG、PROD四套環境，並持續延用至今，SIT和UAT全部通過Jenkins自動完成代碼打包編譯和測度環境部署等工作，而運維研發團隊則快速開發了發布系統1.0版本、CMDB1.0版本、CMC配置管理工具，集成到統一運維平台對全體技術人員開放。發布系統1.0版本實現了將通過UAT測試的編譯包自動部署至STG測試環境，在通過線上真實數據測試後則由運維通過平台發布到線上正式PROD環境中去。

這一系列的動作使得開發運維和測試從長期的通宵加班中解放出來，大大提升了技術團隊的工作效率。

測試團隊總結了以下幾個主要心得：

技術的統一是整個持續集成過程中的額外收穫，有了統一的標準，大大降低了運維成本，減少了技術上的不確定因素，是持續集成的必經之路；

持續集成需要跟測試環境、研發過程整合才能發揮真正的作用；

測試環境的主要使用者是測試，測試當仁不讓應該為這套環境負責；

通過負責發布測試環境，測試人員能更充分的了解被測試的系統；

持續集成沒有最牛的方案，只有最適合自己的方案，不同階段、不同特點，探索屬於自己的方案。

經過測試團隊幾年如一日的精心打造，這套持續集成方案目前已經是洋碼頭研發體系里不可或缺的組成部分，也是洋碼頭實踐敏捷開發的重要支撐，是質量與效率的基礎。兩年多時間運行下來，穩步發展和迭代優化。下圖是2017年的發布數據，平均每月發布4000～5000次，全年超過700個不同應用，發布超過50000次。

在2017年的黑五前，洋碼頭技術測試團隊協調資源，進行了首次的核心全鏈路壓測，真實的模擬用戶在高並發的情況下大量擁入和下單的情況，通過壓測結果，對應用和各通路做了細化的調整。2017年的黑五壓力比以往更高，秒峰值是2016年的5倍以上並持續了很長時間。不過，由於壓測的鏈路不完全，這次黑五仍然發現了一些瑕疵。在最初的峰值來臨時，監控發現資料庫壓力很大，分析發現未參與壓測的新優惠券服務模式性能有瓶頸，導致大量IO並影響到了下單的性能，這個問題在發現後通過事先準備的預案快速降級了，保障了後續活動的快速穩定進行。回顧來看，2017年的業務增長是同期的2-3倍。

在2018年，技術測試團隊將會把全鏈路壓測真正從核心鏈路擴展到所有的全部鏈路，這將會帶來更優質全面的壓力風險評估結果。

洋碼頭使用敏捷開發模式，開發迭代多，應用上線頻繁，如果傳統測試方式，每一次測試都拿測試結果、寫報告，時間周期過長完全無法接受。洋碼頭測試團隊根據業務場景需要，總結了幾個需求點，在這些需求的基礎上開發自動化測試平台：

?後台服務的增多，需要大量的介面回歸測試

?需要一個方便查看、分析測試結果的方案

?能夠管理、統計自動化的推廣進程

?統一的技術方案，整個團隊公用

?滿足現有測試環境等現狀的要求

根據這些需求點，測試團隊自主開發的自動化測試平台，以應用為核心，圍繞使用環境、應用性能、測試用例、測試結果等幾大方向直觀的展示自動化測試結果。在這個平台上，測試用例是整個設計的核心，需要做到完整、精確驗證介面邏輯，這也需要長期的測試和開發人員實際磨合的。整個平台可支持擴展，以同樣的方案可以接入APP、web、H5的自動化測試。

洋碼頭自動化測試平台better

洋碼頭的業務始終保持著每年數倍的增長，洋碼頭團隊對技術的各種極限挑戰永不會停歇。2018年的黑五將會需要擁有10倍以上的2017年黑五峰值承載能力，並保證這個架構是可以在未來2-3年內可以穩定可靠擴展的。為了這個目標，洋碼頭技術團隊已經列出了一系列的提升改進項目，多項優化項目已經或者將要上線，包括：

MySQL group replication的線上環境實戰及訂單等核心業務分庫改造；

容器化環境的無縫運行和自動化改造；

RPC服務框架的大量投入使用；

……

當今洋碼頭的技術能力已經有了一定規模的積累，但洋碼頭技術團隊深知這遠遠不夠。業務持續在擴張，技術必須先行並做好足夠的提前準備。來之能戰，戰之能勝是對技術團隊所有人員的基本要求。我們也期望將我們實現的各種技術和使用思想都在行業內共享，將會本公眾號不定期的發布各種技術類文章，歡迎各位洋碼頭的技術戰友以及行業技術大牛一起分享。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 洋碼頭技術 的精彩文章:

TAG:洋碼頭技術 |