干货|Elastic 在顶级互联网公司的应用案例浅析
讀完需要
11
分鐘速讀僅需 4 分鐘
頂級互聯網公司都離不開的神器
國內現在有大量的公司都在使用 Elasticsearch，包括攜程、滴滴、今日頭條、餓了么、360 安全、小米、vivo 等諸多知名公司。
除了搜索之外，結合 Kibana、Logstash、Beats，Elastic Stack 還被廣泛運用在大數據近實時分析領域，包括日志分析、指標監控、信息安全等多個領域。它可以幫助你探索海量結構化、非結構化數據，按需創建可視化報表，對監控數據設置報警閾值，甚至通過使用機器學習技術，自動識別異常狀況。
1
? ?
京東到家訂單中心 Elasticsearch 演進歷程
京東到家訂單中心系統業務中，無論是外部商家的訂單生產，或是內部上下游系統的依賴，訂單查詢的調用量都非常大，造成了訂單數據讀多寫少的情況。京東到家的訂單數據存儲在 MySQL 中，但顯然只通過 DB 來支撐大量的查詢是不可取的，同時對于一些復雜的查詢，Mysql 支持得不夠友好，所以訂單中心系統使用了 Elasticsearch 來承載訂單查詢的主要壓力。
Elasticsearch 做為一款功能強大的分布式搜索引擎，支持近實時的存儲、搜索數據，在京東到家訂單系統中發揮著巨大作用，目前訂單中心 ES 集群存儲數據量達到 10 億個文檔，日均查詢量達到 5 億。隨著京東到家近幾年業務的快速發展，訂單中心 ES 架設方案也不斷演進，發展至今 ES 集群架設是一套實時互備方案，很好的保障了 ES 集群讀寫的穩定性。
如上圖，訂單中心 ES 集群架設示意圖。整個架設方式通過 VIP 來負載均衡外部請求，第一層 gateway 節點實質為 ES 中 client node，相當于一個智能負載均衡器，充當著分發請求的角色。第二層為 data node，負責存儲數據以及執行數據的相關操作。整個集群有一套主分片，二套副分片（一主二副），從網關節點轉發過來的請求，會在打到數據節點之前通過輪詢的方式進行均衡。集群增加一套副本并擴容機器的方式，增加了集群吞吐量，從而提升了整個集群查詢性能。
當然分片數量和分片副本數量并不是越多越好，在此階段中，對選擇適當的分片數量做了近一步探索。分片數可以理解為 Mysql 中的分庫分表，而當前訂單中心 ES 查詢主要分為兩類：單 ID 查詢以及分頁查詢。分片數越大，集群橫向擴容規模也更大，根據分片路由的單 ID 查詢吞吐量也能大大提升，但對于聚合的分頁查詢性能則將降低。分片數越小，集群橫向擴容規模更小，單 ID 的查詢性能也將下降，但對于分頁查詢，性能將會得到提升。所以如何均衡分片數量和現有查詢業務，我們做了很多次調整壓測，最終選擇了集群性能較好的分片數。
由于大部分 ES 查詢的流量都來源于近幾天的訂單，且訂單中心數據庫數據已有一套歸檔機制，將指定天數之前已經關閉的訂單轉移到歷史訂單庫。
架構的快速迭代源于業務的快速發展，正是由于近幾年到家業務的高速發展，訂單中心的架構也不斷優化升級。而架構方案沒有最好的，只有最合適的。相信再過幾年，訂單中心的架構又將是另一個面貌，但吞吐量更大，性能更好，穩定性更強，將是訂單中心系統永遠的追求。
2
? ?
攜程 Elasticsearch 應用案例
隨著訂單量的日益增長，單個數據庫的讀寫能力開始捉襟見肘。這種情況下，對數據庫進行分片變得順理成章。
分片之后的寫，只要根據分片的維度進行取模即可。可是多維度的查詢應該如何處理呢？
一片一片的查詢，然后在內存里面聚合是一種方式，可是缺點顯而易見。
對于那些無數據返回分片的查詢，不僅對應用服務器是一種額外的性能消耗，對寶貴的數據庫資源也是一種不必要的負擔。
2.1
? ?
攜程酒店訂單 Elasticsearch 實戰
選擇對分片后的數據庫建立實時索引，把查詢收口到一個獨立的 Web Service，在保證性能的前提下，提升業務應用查詢時的便捷性。最終我們選擇了 Elasticsearch，看中的是它的輕量級、易用和對分布式更好的支持，整個安裝包也只有幾十兆。http://developer.51cto.com/art/201807/579354.htm
2.2
? ?
攜程機票 ElasticSearch 集群運維馴服記
這個是比較通用的數據的流程，一般會通過 Kafka 分離產生數據的應用程序和后面的平臺，通過 ETL 落到不同的地方，按照優先級和冷熱程度采取不同的存儲方式。
一般來說，冷數據存放到 HDFS，如果溫數據、或者熱數據會采用 Database 以及 Cache。
一旦數據落地，我們會做兩方面的應用，第一個方面的應用是傳統 BI，比如會產生各種各樣的報表，報表的受眾是更高的決策層和管理層，他們看了之后，會有相應的業務調整和更高層面的規劃或轉變。這個使用路徑比較傳統的，在數據倉庫時代就已經存在了。
現在有一種新興的場景就是利用大數據進行快速決策，數據不是喂給人的，數據分析結果由程序來消費，其實是再次的反饋到數據源頭即應用程序中，讓他們基于快速分析后的結果，調整已有策略，這樣就形成了一個數據使用的循環。這樣我們從它的輸入到輸出會形成一種閉環，而且這個閉環全部是機器參與的，這也是為什么去研究這種大規模的，或者快速決策的原因所在。如果數據最終還會給人本身來看的話，就沒有必要更新那么快，因為一秒鐘刷新一次或者 10 秒鐘刷新一次對人是沒有意義的，因為我們腦子不可能一直轉那么快，基于數據一直的做調整也是不現實的，但是對機器來講，就完全沒有問題。
2.3
? ?
攜程：大規模 Elasticsearch 集群管理心得
目前，我們最大的日志單集群有 120 個 data node，運行于 70 臺物理服務器上。數據規模如下:
單日索引數據條數 600 億，新增索引文件 25TB (含一個復制片則為 50TB)業務高峰期峰值索引速率維持在百萬條/秒歷史數據保留時長根據業務需求制定，從 10 天 - 90 天不等集群共 3441 個索引、17000 個分片、數據總量約 9300 億, 磁盤總消耗 1PB
https://www.jianshu.com/p/6470754b8248
3
? ?
去哪兒：訂單中心基于 Elasticsearch 的解決方案
2015 年去哪兒網酒店日均訂單量達到 30w+，隨著多平臺訂單的聚合日均訂單能達到 100w 左右。原來采用的熱表分庫方式，即將最近 6 個月的訂單的放置在一張表中，將歷史訂單放在在 history 表中。history 表存儲全量的數據，當用戶查詢的下單時間跨度超過 6 個月即查詢歷史訂單表，此分表方式熱表的數據量為 4000w 左右，當時能解決的問題。但是顯然不能滿足攜程藝龍訂單接入的需求。如果繼續按照熱表方式，數據量將超過 1 億條。全量數據表保存 2 年的可能就超過 4 億的數據量。所以尋找有效途徑解決此問題迫在眉睫。由于對這預計 4 億的數據量還需按照預定日期、入住日期、離店日期、訂單號、聯系人姓名、電話、酒店名稱、訂單狀態……等多個條件查詢。所以簡單按照某一個維度進行分表操作沒有意義。Elasticsearch 分布式搜索儲存集群的引入，就是為了解決訂單數據的存儲與搜索的問題。對訂單模型進行抽象和分類，將常用搜索字段和基礎屬性字段剝離。DB 做分庫分表，存儲訂單詳情；Elasticsearch 存儲搜素字段。訂單復雜查詢直接走 Elasticsearch，基于 OrderNo 的簡單查詢走 DB，如下圖所示。系統伸縮性：Elasticsearch 中索引設置了 8 個分片，目前 ES 單個索引的文檔達到 1.4 億，合計達到 2 億條數據占磁盤大小 64G，集群機器磁盤容量 240G。https://elasticsearch.cn/article/6197 ( https://elasticsearch.cn/article/6197 )
4
? ?
58 集團信息安全部 Elasticsearch 應用
全面介紹 Elastic Stack 在 58 集團信息安全部的落地，升級，優化以及應用。包括如下幾個方面：接入背景，存儲選型，性能挑戰，master node 以及 data node 優化，安全實踐，高吞吐量以及低延遲搜索優化；kibana 的落地，本地化使其更方便產品、運營使用。
5
? ?
滴滴 Elasticsearch 多集群架構實踐
滴滴 2016 年初開始構建 Elasticsearch 平臺，如今已經發展到超過 3500+ Elasticsearch 實例，超過 5PB 的數據存儲，峰值寫入 tps 超過了 2000w/s 的超大規模。Elasticsearch 在滴滴有著非常豐富的使用場景，例如線上核心的打車地圖搜索，客服、運營的多維度查詢，滴滴日志服務等近千個平臺用戶。
先看看滴滴 Elasticsearch 單集群的架構：滴滴在單集群架構的時候，寫入和查詢就已經通過 Sink 服務和 Gateway 服務管控起來。
5.1
? ?
Sink 服務
滴滴幾乎所有寫入 Elasticsearch 的數據都是經由 kafka 消費入到 Elasticsearch。kafka 的數據包括業務 log 數據、mysql binlog 數據和業務自主上報的數據，Sink 服務將這些數據實時消費入到 Elasticsearch。最初設計 Sink 服務是想對寫入 Elasticsearch 集群進行管控，保護 Elasticsearch 集群，防止海量的數據寫入拖垮 Elasticsearch，之后我們也一直沿用了 Sink 服務，并將該服務從 Elasticsearch 平臺分離出去，成立滴滴 Sink 數據投遞平臺，可以從 kafka 或者 MQ 實時同步數據到 Elasticsearch、HDFS、Ceph 等多個存儲服務。有了多集群架構后，Elasticsearch 平臺可以消費一份 MQ 數據寫入多個 Elasticsearch 集群，做到集群級別的容災，還能通過 MQ 回溯數據進行故障恢復。
5.2
? ?
Gateway 服務
所有業務的查詢都是經過 Gateway 服務，Gateway 服務實現了 Elasticsearch 的 http restful 和 tcp 協議，業務方可以通過 Elasticsearch 各語言版本的 sdk 直接訪問 Gateway 服務，Gateway 服務還實現了 SQL 接口，業務方可以直接使用 SQL 訪問 Elasticsearch 平臺。Gateway 服務最初提供了應用權限的管控，訪問記錄，限流、降級等基本能力，后面隨著平臺演進，Gateway 服務還提供了索引存儲分離、DSL 級別的限流、多集群災備等能力。
https://mp.weixin.qq.com/s/K44-L0rclaIM40hma55pPQ
6
? ?
Elasticsearch 實用化訂單搜索方案
搜索引擎中，主要考慮到 Elasticsearch 支持結構化數據查詢以及支持實時頻繁更新特性，傳統訂單查詢報表的痛點，以及 Elasticsearch 能夠幫助解決的問題。
6.1
? ?
訂單搜索系統架構
整個業務線使用服務化方式，Elasticsearch 集群和數據庫分庫，作為數據源被訂單服務系統封裝為對外統一接口；各前、后臺應用和報表中心，使用服務化的方式獲取訂單數據。
6.2
? ?
數據更新設計
ES 數據更新有批量更新和實時更新兩種：
1、手動更新為初始化數據，或者修復數據時使用
2、實時更新通過監控數據庫訂單表的 binlog，進行實時同步
7
? ?
Elasticsearch在線分享直播
﹀
﹀
﹀
劉征，Elastic 中國技術布道師
《DevOps Handbook》《The Site Reliability Workbook》譯者；精通DevOps/SRE/ITSM等理論體系和相關實踐等落地實現。致力于通過社區推廣開源Elastic Stack技術堆棧的應用，包括運維大數據分析平臺、云原生服務治理、APM全鏈路監控和AIOps等使用場景。
使用 Elastic Stack 監測 COVID-19 疫情爆發網絡研討會2020年4月8日15:00 線上分享
用實際應用場景探索 Kibana 的多種用法 ，構建自己的個性化儀表板，從公共數據源跟蹤全球各地的COVID-19疫情狀況。在本演示中，您將了解如何輕松地在Elasticsearch中索引任何類型的數據索引，使用采集節點對其進行數據轉換，然后使用Kibana 的可視化、儀表板和地圖對疫情現狀進行分析。
亮點：
Elastic在CNCF云原生交互場景中的位置
在Kubernetes上運行?Elastic?Stack
演示：如何使用 ECK 部署、防護和升級 Elasticsearch
Beats?中使用?autodiscover?監測動態工作負載的入門知識
在Kubernetes上掌握可觀測經驗
報名方式：識別圖片二維碼或閱讀原文報名
想要加入中生代直播群的小伙伴，請添加群助手大白的微信
申請備注（姓名+公司+技術方向）
總結
以上是生活随笔為你收集整理的干货|Elastic 在顶级互联网公司的应用案例浅析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Netstars CTO 陈斌：技术管理
- 下一篇： nyoj990蚂蚁感冒