1年前寫的一篇舊文，文中的分析，以及探討的問題和觀點，至今仍有意義。
從2016年起，筆者在騰訊公司負責QQ後臺的海量服務分散式元件的架構設計和研發工作，例如微服務開發框架SPP、名字路由CMLB、名字服務、配置中心、NoSQL儲存等，在分散式架構、高效能架構、海量服務、過載保護、柔性可用、負載均衡、容災、水平擴充套件等方面做了大量的工作，以公共元件的形式，支撐了來自QQ後臺和其他BG海量服務的海量流量。後來在2018年底，筆者負責監控大資料平臺的研發工作，目標是解決現有監控後臺成本高昂的痛點，和支撐內部和外部的海量監控資料的需求，打造千億級監控大資料平臺。
筆者發現當前在監控技術領域缺乏優秀的監控系統，尤其是在海量監控資料場景，很多團隊常用的一種做法是堆機器和堆開源軟體，比如採用大量高配置的機器，單機百CPU核數、TB記憶體、數十TB的SSD儲存，堆了一堆開源軟體，例如Elasticsearch、Druid、Storm、Kafka、Hbase、Flink、OpenTSDB、Atlas、MangoDB等。
但從實際效果看，效果並不好，眾多開源軟體的組合只是以非常高昂的成本，在增加了系統的運營成本和資料的處理延遲的情況下解決了接入計算，但在海量標籤和時間序列線情況下，查詢的痛點突出，常出現的一種情況是查詢超時、資料拉不出來的問題。 筆者認為，海量或千億級，是整體的量，是個籠統的概念，可通過分而治之解決，通過分叢集的方法來解決，海量監控資料的真正挑戰在於以下幾點：
- 能否做到實時，實時是種質變的能力，將一個離線監控平臺，提升為一個實時決策系統。難點在於能否設計實現足夠高效能的架構，能否實現水平擴充套件等。
- 分叢集后，單個業務的流量大小、標籤集多少是關鍵。流量大，相對容易解決，主要涉及到系統效能和水平擴充套件等。標籤集多，海量標籤，海量時間序列線，如何做查詢優化，是挑戰，如筆者遇到一些業務上報的監控資料，幾十維度的標籤，並將QQ號和URL作為標籤值，非常海量的時間序列線。
- 針對監控資料多寫少讀、成本敏感的特點，如何設計高效的儲存引擎？充分發揮硬體效能，並在高效壓縮儲存的同時保障查詢效率。
為了更好的打造有競爭力的監控系統，我們將技術理念定位為“技術降成本，堅決反對開源軟體堆砌”。
之所以定下這個理念是有原因的，技術降成本，是因為我們認為雲端計算是一種非常有突破性的技術形態，它將技術服務化，決定它能否成功的關鍵在於能否在基礎技術上突破，打造出相比開源軟體更有成本優勢的雲原生軟體。
堅決反對開源軟體堆砌，是因為現在開源軟體非常繁榮，基於開源軟體，我們很容易搭建一個基礎系統，將功能跑起來，但絕大部分開源軟體側重的是功能，不是針對海量監控資料場景而設計的，或多或少都有各種痛點或限制，再堆砌更多的開源能力，即使弱化了痛點，但成本也是非常高昂的，這時，我們需要藉助強大的技術和工程能力，直面問題，在架構和原始碼層面，解決它，而不是引入和堆砌更多的開源軟體。
基於工程效率的考慮，我們選擇了基於開源軟體進行二次開發，使用開源軟體的部分程式碼，按照我們的想法進行架構設計和功能開發，提升開發效率。在調研了眾多的開源軟體後，最終選擇了以InfluxDB原始碼為基礎進行二次開發。
選擇InfluxDB原始碼，主要是因為我們對InfluxDB原始碼背後的技術和工程實力是認可的，InfluxDB研發團隊是能真正的解決場景的痛點的，也是在認真的打造一款優秀的監控產品，而不是僅僅營銷，比如基於讀寫效能和可用性的考慮，InfluxDB研發團隊3次重構儲存引擎。
在筆者著手以InfluxDB原始碼為基礎開發叢集等功能時，在業界中仍沒有團隊實現真正可用的InfluxDB叢集能力。
一些團隊只是通過Proxy實現了負載均衡，無法突破單機接入計算和儲存的限制，缺乏一致效能力，並增加了查詢和儀表盤的資料顯示不一致性。
有些團隊在學習研究了多年的InfluxDB後，最終考慮到基於時序分片的複雜度，直接放棄基於InfluxDB開發叢集能力，而選擇基於Rocksdb、Zookeeper等開源軟體，自己搭建一套。在這裡，我想說的是，一個缺乏大系統工程化能力的團隊，又如何能用已經證明不合適的開源軟體，再“堆砌”出比InfluxDB效能和成本優秀的軟體呢？
再如，某雲廠商，推出了InfluxDB叢集版，選擇Raft協議實現DATA節點的一致性，但效能低，叢集的接入效能不如單機。
筆者在三個月內快速的開發出CP和AP架構分離、基於時序分片、水平擴充套件等基本叢集能力，根據業務的特點和場景痛點，我們在索引引擎、冷熱分離、查詢實現、第三方協議、高可用性、運營性、連續查詢、備份還原等方面也做了大量的工作。
最終的效果，也是符合預期的，例如從替換現有監控系統的後臺的實施對比看，我們用了不到10%的機器成本，就支撐了原來Flink、Druid等在支撐的海量監控資料，降低了90%+的成本，成本優勢突出，最重要的是，解決了查詢超時、資料拉不出來的問題。
InfluxDB是DB-Engines上時序資料庫排名第一的時序資料庫，是一款非常優秀的軟體，直接推動了監控技術進入實時、納秒級的新時代，除了類SQL查詢語言、RESTful API等現代特性，讀寫效能高、儲存壓縮率高，生態豐富、強大。
為了更好的推動監控技術的發展，和幫助更多的讀者掌握構建實時監控系統的方法、分散式時序型資料庫的架構設計和開發技巧，筆者規劃了2本書和1個開源軟體：
- 第一本書，也就是本書，側重InfluxDB的原理和實戰，幫助讀者吃透InfluxDB的功能原理和掌握實戰技巧；
- 第二本書，在籌劃中，側重InfluxDB的設計實現剖析、分散式技術、InfluxDB叢集能力開發實戰等，關於第二本書的更多資訊和進展，敬請關注機械工業出版社的微信訂閱號“華章電子書”上的鮮讀；
- 開源軟體，就是FreeTSDB（https://github.com/freetsdb/freetsdb），FreeTSDB的v0.x版本定位為InfluxDB企業版的開源替代，完全對標InfluxDB企業版。
最後，筆者衷心希望《InfluxDB原理與實戰》和FreeTSDB能幫助讀者更快地掌握InfluxDB的核心特性、功能原理和實戰技巧，打造更有競爭力的監控產品，賦能業務。
歡迎交流討論:
微信公眾號：influxdb-dev
FreeTSDB技術交流群（QQ）：663274123