國內現在有大量的公司都在使用 Elasticsearch，包括攜程、滴滴、今日頭條、餓了麼、360安全、小米、vivo等諸多知名公司。
除了搜尋之外，結合Kibana、Logstash、Beats，Elastic Stack還被廣泛運用在大資料*實時分析領域，包括日誌分析、指標監控、資訊保安等多個領域。它可以幫助你探索海量結構化、非結構化資料，按需建立視覺化報表，對監控資料設定報警閾值，甚至透過使用機器學習技術，自動識別異常狀況。
一、京東到家訂單中心 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查詢的流量都來源於*幾天的訂單，且訂單中心資料庫資料已有一套歸檔機制，將指定天數之前已經關閉的訂單轉移到歷史訂單庫。
架構的快速迭代源於業務的快速發展，正是由於*幾年到家業務的高速發展，訂單中心的架構也不斷最佳化升級。而架構方案沒有最好的，只有最合適的。相信再過幾年，訂單中心的架構又將是另一個面貌，但吞吐量更大，效能更好，穩定性更強，將是訂單中心繫統永遠的追求。
獲取更多Elasticsearch設計細節、入門例項、原理剖析和演示專案原始碼，可訪問Elasticsearch 7.x 技術專欄。技術專欄從實戰出發，透過理論講解-環境搭建-專案案例實戰，讓初學者快速掌握Elastic技術棧。
二、攜程Elasticsearch應用案例
1. 攜程酒店訂單Elasticsearch實戰
選擇對分片後的資料庫建立實時索引，把查詢收口到一個獨立的 Web Service，在保證效能的前提下，提升業務應用查詢時的便捷性。
最終我們選擇了 Elasticsearch，看中的是它的輕量級、易用和對分散式更好的支援，整個安裝包也只有幾十兆。
2. 攜程機票ElasticSearch叢集運維馴服記
這個是比較通用的資料的流程，一般會透過Kafka分離產生資料的應用程式和後面的*臺，透過ETL落到不同的地方，按照優先順序和冷熱程度採取不同的儲存方式。一般來說，冷資料存放到HDFS，如果溫資料、或者熱資料會採用Database以及Cache。
一旦資料落地，我們會做兩方面的應用，第一個方面的應用是傳統BI，比如會產生各種各樣的報表，報表的受眾是更高的決策層和管理層，他們看了之後，會有相應的業務調整和更高層面的規劃或轉變。這個使用路徑比較傳統的，在資料倉儲時代就已經存在了。現在有一種新興的場景就是利用大資料進行快速決策，資料不是餵給人的，資料分析結果由程式來消費，其實是再次的反饋到資料來源頭即應用程式中，讓他們基於快速分析後的結果，調整已有策略，這樣就形成了一個資料使用的迴圈。
這樣我們從它的輸入到輸出會形成一種閉環，而且這個閉環全部是機器參與的，這也是為什麼去研究這種大規模的，或者快速決策的原因所在。如果資料最終還會給人本身來看的話，就沒有必要更新那麼快，因為一秒鐘重新整理一次或者10秒鐘重新整理一次對人是沒有意義的，因為我們腦子不可能一直轉那麼快，基於資料一直的做調整也是不現實的，但是對機器來講，就完全沒有問題。
3. 攜程：大規模 Elasticsearch 叢集管理心得
目前，我們最大的日誌單叢集有120個data node，執行於70臺物理伺服器上。資料規模如下:
-
單日索引資料條數600億，新增索引檔案25TB (含一個複製片則為50TB)
-
業務高峰期峰值索引速率維持在百萬條/秒
-
歷史資料保留時長根據業務需求制定，從10天 - 90天不等
-
叢集共3441個索引、17000個分片、資料總量約9300億, 磁碟總消耗1PB
三、去哪兒：訂單中心基於elasticsearch 的解決方案
15年去哪兒網酒店日均訂單量達到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。
四、Elasticsearch 在58集團資訊保安部的應用
全面介紹 Elastic Stack 在58集團資訊保安部的落地，升級，最佳化以及應用。
包括如下幾個方面：接入背景，儲存選型，效能挑戰，master node以及data node最佳化，安全實踐，高吞吐量以及低延遲搜尋最佳化；kibana 的落地，本地化使其更方便產品、運營使用。
五、滴滴Elasticsearch多叢集架構實踐
滴滴 2016 年初開始構建 Elasticsearch *臺，如今已經發展到超過 3500+ Elasticsearch 例項，超過 5PB 的資料儲存，峰值寫入 tps 超過了 2000w/s 的超大規模。
Elasticsearch 在滴滴有著非常豐富的使用場景，例如線上核心的叫車地圖搜尋，客服、運營的多維度查詢，滴滴日誌服務等*千個*臺使用者。
先看看滴滴 Elasticsearch 單叢集的架構：
滴滴在單叢集架構的時候，寫入和查詢就已經透過 Sink 服務和 Gateway 服務管控起來。
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 回溯資料進行故障恢復。
2. Gateway 服務
所有業務的查詢都是經過 Gateway 服務，Gateway 服務實現了 Elasticsearch 的 http restful 和 tcp 協議，業務方可以透過 Elasticsearch 各語言版本的 sdk 直接訪問 Gateway 服務，Gateway 服務還實現了 SQL 介面，業務方可以直接使用 SQL 訪問 Elasticsearch *臺。
Gateway 服務最初提供了應用許可權的管控，訪問記錄，限流、降級等基本能力，後面隨著*臺演進，Gateway 服務還提供了索引儲存分離、DSL 級別的限流、多叢集災備等能力。
六、Elasticsearch實用化訂單搜尋方案
搜尋引擎中，主要考慮到Elasticsearch支援結構化資料查詢以及支援實時頻繁更新特性，傳統訂單查詢報表的痛點，以及Elasticsearch能夠幫助解決的問題。
訂單搜尋系統架構
整個業務線使用服務化方式，Elasticsearch叢集和資料庫分庫，作為資料來源被訂單服務系統封裝為對外統一介面；各前、後臺應用和報表中心，使用服務化的方式獲取訂單資料。
七、眾安保險Elasticsearch應用
下圖是眾安保險Elasticsearch應用在保單業務場景中的系統架構圖，其中Elasticsearch叢集有3個master節點、5個Client節點和25個Data節點。
-
保單資料更新秒級時效性；
-
1萬併發請求下服務穩定；
-
同城多活的服務容災能力；
-
Build Index 之前的流式資料預處理；
