愛用科技CTO 江樹源
本文講述了在電商新零售行業下，電商服務商愛用科技如何借助Elasticsearch，應對在業務系統中的大規模交易訂單資料管理，以及全觀測日志運維場景下的痛點和挑戰，為其百萬電商商家使用者提供穩定高效的商家服務。
愛用交易，實作交易全流程管理
随着10年來零售經驗的積累，阿裡零售雲内彙聚了一批擁有天然的場景、業務資料流以及客戶網的電商服務商。這些電商服務商通過其全面的零售産品，幫助數百萬家品牌商家快速建構業務場景。
愛用科技是基于淘寶服務平台的最早一批應用軟體與資訊技術服務提供商之一。專注為淘寶電商商家提供包含訂單處理、商品管理、分銷供應、資料分析、營銷打折等功能的軟體産品，目前已經服務于400萬淘寶商家。
在交易管理場景，愛用科技基于“愛用交易”這款交易管理軟體，支援賣家使用者從接單、訂單管理、列印發貨、物流跟蹤、到評價管理實作全流程管理覆寫，付費版本還支援更多自動、批量操作等功能，幫助賣家使用者高效、實時管理訂單動态。
訂單管理中心是整個愛用交易管理的核心子產品，訂單管理下通常包括各個狀态的不同訂單：等待買家付款的訂單、等待您發貨的訂單、已發貨的訂單、退款中的訂單、需要您評價的訂單、已成功交易的訂單、及訂單查詢子產品。而對于不同狀态的訂單狀态，會顯示不同的訂單資訊，并在訂單詳情頁支援不同的操作。如【待付款】的訂單，會顯示訂單編号、買家ID、待付款等待時間、備忘、訂單狀态、詳情，是否關閉訂單、寶貝屬性、實收款（包括價格與運費）、旺旺是否線上等；而【待發貨】的訂單，則會顯示訂單訂單編号、成交時間、賣家備忘、寶貝名稱、寶貝屬性、詳情、寶貝價格等。
愛用交易為商家使用者，提供了非常豐富和強大的訂單查詢能力，可以支援通過訂單号、買家昵稱、關鍵詞、收件人姓名、手機号、運單号、收貨位址、交易時間以及賣家備注、買家留言等等非常全面的訂單資訊字段進行各類進階查詢、篩選和标簽過濾，同時也支援賣家進行不同次元的訂單排序，比如拍下時間或者商品的SKU排序等。
在這樣的業務場景下，交易訂單作為電商系統的"紐帶"貫穿了整個系統的關鍵流程，承載着所有購買資訊與支付資訊。在618、雙11等各種大促的高流量下，不論是各類獨立品牌商家，還是我們愛用科技這樣的電商服務商，極高并發的訂單查詢請求，給整個訂單系統的對接效率、處理能力、災備能力，系統互通效率，都帶來了極大的考驗。
與此同時，大規模業務資料帶來的是，更為複雜的日志分析與系統運維工作。如何收集分散在各層的日志、名額資料，進行集中的收集存儲、并完成後續的分析監控，快速搭建整套日志平台，以保障整體業務的平穩運作，也是我們在業務發展過程中所持續面臨的問題。
方案架構：基于Elasticsearch的訂單檢索
在接觸阿裡雲Elasticsearch整體産品與方案前，我們僅依靠傳統關系型資料庫實作業務系統的訂單檢索，随着業務的發展，檢索延遲高、效率差的問題日益明顯，主要展現在以下幾點：
海量資料帶來性能和穩定性瓶頸：電商行業遇到諸如大促的業務高峰期，會産生高達百萬、千萬級的訂單資料量，面對這樣的高流量、高并發查詢，關系型資料庫有天然的處理瓶頸，對整體系統穩定性的巨大挑戰。
複雜字段與查詢條件導緻查詢效率低：電商訂單往往包含複雜的商品資訊、優惠、使用者、位址等多元度字段資訊。在商家進行訂單查詢過程中，往往存在大量的模糊查詢場景，如不完整的賣家位址或昵稱等。DB在複雜條件下查詢能力弱，對模糊比對的處理效率低，僅僅依靠關系型資料庫，無法滿足訂單系統的檢索需求。
面對流量波動缺乏靈活伸縮能力：為順利承載活動帶來的流量，電商這個行業具有明顯的業務波動，一方面，高峰流量所需要的臨時擴容，帶來了極大的人力運維成本；另一方面，業務低峰期的閑置機器也是極大的資源成本浪費。
說到檢索能力，我們開始學習和考慮業内最主流的全文檢索引擎Elasticsearch。它在DB-Engine指數排行上是全球熱度No.7的資料庫、No.1的檢索引擎。可在PB級資料中找到比對資訊，并具備毫秒級資料時效性，能夠快速處理文本、數字、日期、IP 以及地理資料等各類資料類型。面對訂單場景，資料膨脹會導緻傳統資料庫方案逐漸暴露性能、查詢能力的瓶頸，橫向的膨脹即不斷疊代引入的新字段次元，縱向即總的存儲資料量。而Elasticsearch可作為關系型資料庫二級索引，彌補原先傳統關系型資料庫在大資料量、高并發查詢的局限性，混合應用進而實作能力和性能上的互補。
是以，基于這樣的能力和背景，我們整體系統的訂單查詢能力，正是基于MySQL+Elasticsearch組合方案實作的。我們愛用主要服務于淘寶的長尾商家，對于這些小微商家，每天的訂單量可能不超過200單，而目前這類商家客戶數量在40萬左右，是以我們主要通過建立集中存儲的存儲叢集和計算叢集，進行訂單資料的集中管理。在零售雲内，部分其他的服務商，當單個商家體量達到一定規模時，也會為單個商家建立獨立的運算叢集，也就是MySQL/PG/ADS/ES等等存儲和計算資源都是獨立的。
Part1 ：分庫分表和集中索引方案
在整個系統鍊路中，我們将業務應用服務系統将全部商家的全量訂單資料存入MySql資料庫，對訂單資料用商家ID取模的形式進行分庫分表，作為持久化存儲；同時将需要檢索的字段和基礎屬性字段存入Elasticsearch，提供可以應付次元膨脹的訂單資料，在複雜查詢、模糊比對場景下借助Elasticsearch的檢索能力，必要時反查MySql擷取訂單完整資訊。
Part2：資料全增量同步方案
關于從資料庫到Elasticsearch的資料同步，通用方案可借助雲上産品或開源方案實作MySQL向ES進行全量資料同步，當業務系統産生業務表資訊變更時，由增量資料更新的方式補充/變更ES中的資料。增量更新主要是以mysql binlog訂閱的方式，利用DTS、Canal、Logstash或DataWorks等多種工具實作。這其中會有幾個常見問題，一方面，通過MySQL到ES增量同步會有一定的延遲，當RDS主庫産生較大負載，會無法保證ES的資料寫入；而Canal在實際的測試過程中有資料延遲和資料丢失，需要每天晚上再手動做一次同步。
這種情況下，我們為保證資料的時效性，選擇了另一種方案，直接通過業務系統實作對MySQL和ES雙寫，自行保證兩條鍊路的品質。并在業務端通過補償腳本，保證兩條鍊路的資料均寫入成功才算寫入成功，否則會復原重試，以保證整體資料一緻性。
Part3：索引方式和字段定義
在訂單檢索場景下，将需要檢索的字段和基礎屬性字段存入Elasticsearch。在這個流程中的海量資料，可以通過hash映射将海量資料分割成相應的小塊資料，然後再針對各個小塊資料通過hash_map進行統計或其它操作。
如果将所有資料均分在幾十個節點中，雖然能保證寫入無法滿足實時高效的查詢要求。是以，在整個訂單資料索引中可以采用雙分片處理，首先對商家ID進行哈希處理，将商家ID聚集在某個小片的集合裡，再通過相應的routing設定。同時，再對訂單進行哈希，進而保證整體查詢的高效性。
Part4：雲上ES服務能力和優勢
相比于自建的Elasticsearch方案，最終選擇阿裡雲Elasticsearch，也是考慮雲托管服務本身，所具備的彈性平滑擴縮、以及在安全方面更加豐富的能力。
一方面，雲上ES服務可以幫助我們在較短的時間在叢集中拉起新的節點或者使用更高規格的節點，而不需要考慮供應鍊上潛在的問題，來扛住大促這種情況下的流量洪峰，并且擴容過程平滑對業務無影響。同理，當負載降低時，我們也能夠減少節點個數，隻針對非高峰時段的流量保有計算資源，觸發并完成叢集縮容，進而在滿足業務需求的同時，降低在非大促的日常經營期間的業務成本。
而為了保證服務的高可用性，盡可能降低系統的資料存儲、安全通路等可能造成的風險，阿裡雲Elasticsearch為我們直接提供了OSS備份、多可用區、CCR跨叢集實時同步等多種容災能力。
相比于開源ES服務，阿裡雲Elasticsearch還免費提供各類X-pack功能，在安全和權限管理上，具備更加全面和專業的安全特性。尤其是對于我們這種服務商，在面向多個商家提供服務時，有強資料權限的管控需求，而阿裡雲ES基于X-pack安全插件能夠支援精确到字段級别的資料權限分割能力連結，進而為我們的商家客戶提供靈活的使用者-角色-權限定制能力，在資料共享、通路隔離、防止誤操作及洩露等方面，實作了更強的權限控制。
總體而言，通過以上這些方案，我們實作了訂單查詢服務的整體架構的更新改造，不僅借助Elasticsearch作為資料庫二級索引，達到了毫秒級資料時效性的準實時查詢，帶來了近一倍的IOPS大幅提升；也降低了MySql主資料庫的查詢壓力，避免了高并發查詢下造成的寫入資料丢失風險。
與初始的架構方案相比，這套利用Elasticsearch實作的訂單檢索方案，在資源方面為我們降低了50%的成本。而基于ES的檢索能力、資料權限體系再進一步進行上層的業務封裝，為各個商家提供在用戶端、移動端的訂單管理。最終完美的實作了我們愛用科技對客戶的承諾——“在1~5s内進行所有訂單資料的檢索和打單發貨”。
方案架構：基于Elasticsearch的全觀測運維方案
除了訂單場景外，系統及日志運維也是我們愛用科技使用Elasticsearch的另一個重要場景。随着技術的發展演進，Docker微服務化的技術架構被越來越多的企業所采用，同時帶來容器中各種日志統一收集和分析的需求。各大服務商紛紛進行服務和技術更新，整體架構越來越複雜，多種伺服器、存儲、網絡裝置、安全裝置，基礎設施與架構的複雜化給我們帶來的是更加海量的資料。
另一方面，服務的分布化導緻資料的集中和追溯困難，各層業務服務之間的調用錯綜複雜，由此帶來全鍊路的監控訴求，而服務的分布化，增加了鍊路上各個環節的故障分析排查難度。對于我們愛用科技或者其他服務商而言，開發運維的結合對我們的技術同學帶來了更高的要求，随着大資料應用發展，開發與運維環節緊密結合，共享同樣的資訊來源，更需要對日志、名額、APM進行立體、統一觀察分析， 通過“全觀測”打破資料與工具之間的壁壘。
基于以上的問題，我們也需要一套更成熟的方案，不僅實作容器、業務系統日志的收集、集中存儲、搜尋分析，并可以快速搭建上線的日志分析系統。經過多方選型後，我們決定通過ELK體系搭建集中的日志分析平台。
衆所周知，在運維監控全觀測方面，Elastic Stack包含Beats、Logstash、Kibana的整套産品生态元件，具備對多種資料類型和資料來源的采集能力、同時可支援進行靈活的資料結構化處理，并最終實作可視化分析與監控。這樣一整套具備端到端能力的産品元件，都已經在阿裡雲Elasticsearch平台上實作了全托管。
借助這樣的方案，我們可以充分利用分散在系統各層的日志、名額、APM資料，在較短的時間内，快速的搭建一套完善的智能診斷與分析、智能監控報警的全觀測平台，更好的發揮整體業務流程中的各類資料價值，進行業務情況的實時追蹤。目前，已線上上環境穩定運作，也為我們在整體系統和服務的運維成本方面帶來了大幅降低。
遠不止電商新零售下的Elasticsearch與商家服務
放眼未來，包含我們愛用科技在内的廣大服務商還在不斷調研和開發基于Elasticsearch更多圖檔、音視訊檢索、以及智能客服等更多的場景應用；同時，基于Elastic Stack打造更完善的業務資料、名額分析大盤。探索在新零售以及新場景下，如何更好的為廣大商家客戶提供商家服務，實作業務的快速發展。
我們也相信，阿裡雲Elasticsearch所具備的檢索能力和方案不僅僅隻是在訂單場景下的應用；而全托管下的Elastic Stack全鍊路觀測分析能力，在所有電商之外其他的行業和領域，一定會有更多的企業和服務商，有更多更好的運用實踐方案。也歡迎大家交流分享。
謝謝大家。
更多大資料客戶實戰案例：
https://developer.aliyun.com/article/772449