心知天氣數據API 產品的高並發實踐

心知天氣數據API 產品的高並發實踐

心知天氣作為國內領先的商業氣象服務提供商，天氣數據API 產品從公司創立以來就一直扮演着很重要的角色。2009 年API 產品初次上線，歷經十年，我們不斷用心迭代，已經為數百家企業客戶提供了超過540億次穩定可靠的數據服務。在心知天氣官網首頁一直跳動的調用量數字就實時展示了整個天氣API 產品的服務狀態。目前，心知天氣數據API 的QPS 在高峰時期已經達到數千的量級，如何承載這樣海量的並發請求，使客戶能穩定及時的獲取到所需數據自然也是心知技術團隊一路以來不斷探索的主題。

 

心知天氣API 服務實時訪問量

 

訪問量特點

天氣數據的基本屬性和客戶本身的業務需求決定了客戶來如何調用心知天氣的數據接口。對於部分使用天氣數據進行數據展示的2C 業務的客戶而言，訪問量潮汐跟人的行為規律有着明顯的相關性，這大致表現為白天比晚上並發量更高；而對於部分使用天氣數據做數據分析和研究或者其他需要批量請求天氣數據的客戶而言，他們大多會選擇在整點時刻來批量請求不同的數據，所以整點時刻往往會有突發的高峰訪問量。

 

API 數據服務訪問量特點

 

在疊加了不同客戶需求的總體API 服務的訪問量，可以看出以下幾個特點：

• 以「天」為單位周期性明顯
• 每天零點時刻並發量會激增
• 整點和半點時刻存在高並發小周期

只有了解了我們客戶的需求特點，才能設計出更合適的技術架構來應對隨之而來的挑戰。

石器時代

在創業初期，「雲計算」的理念開始興起，創始團隊在斟酌優劣之后，選擇將整個系統構建於雲服務提供商阿里雲之上，如此一來心知天氣團隊也不必自己再手工搭建和管理需要的硬件資源，這對於創業公司而言是一個不錯的選擇。和大多數早期創業公司一樣，囿於資源和技術積累，最早我們也是將API 服務實例直接部署在阿里雲ECS 之上，對外通過負載均衡SLB 提供統一的API 入口。

隨着心知天氣數據服務體驗的不斷完善，客戶數量也不斷增多，API 服務所需要承載的流量也持續上漲。由於我們已經構建了上述這樣的基礎架構體系，在並發量最高的時期，我們需要手工維護高達40 台左右的ECS。而每個ECS 上有自己獨立但不完全一致的運行環境，不管是應對訪問量突變還是部署新的版本，都無法做到比較快速的響應和執行。

在這個階段，我們產品的API 數據和邏輯都還比較簡單，所有關於用戶信息處理、位置服務和數據處理的邏輯都揉雜在一個單體服務中，最終部署時也是一個一個獨立的單體式架構通過SLB 共同對外提供服務。

青銅時代

隨着心知天氣數據種類的不斷增多，數據處理和API 服務的邏輯也變得各不相同，比如城市級數據和公里級網格數據就有着完全不一樣的處理和取數邏輯。在這種情況下，基於程序的可維護性考慮，我們很快決定根據數據處理邏輯的不同將數據服務拆分為幾個不同的微服務，各自對外提供不同的天氣數據API。而為了復用取數之前的權限校驗、訪問量和各種日志統計的邏輯，我們開始引入網關系統。

API 網關最重要的是性能和穩定性要足夠好，所有的API 請求都需要經過網關。在通過網關的校驗之后，數據服務負責獲取需要的天氣數據，其結果再通過網關返回給外部用戶。如此一來，不同的幾個數據服務退化成無狀態的純數據服務，即每個數據服務節點不再考慮任何與用戶相關的邏輯，只是簡單的根據請求條件將所有處理好的數據從存儲系統中取出后返回，網關作為唯一的請求入口來統一處理所有的權限校驗和訪問量、日志的各種統計。

基於開源的網關系統Kong，我們使用Lua 進行了大量的二次定制開發，從而形成了心知天氣自己的一套網關體系。這套系統不僅滿足網關基本的路由邏輯，還能更好的處理和我們自身業務深度耦合的用戶權限校驗、訪問量統計以及以用戶為核心的日志記錄。Kong 天生也是支持集群的，所以在理論上我們可以無限橫向擴展網關的處理能力。

在這樣的架構之下，心知天氣的API服務很好的遵循了「單一職責」的原則，使得我們的代碼維護和版本更新都能以更快速且代價更小的方式進行。但另一方面，我們還是需要手工維護大量的ECS 集群，甚至由於天氣數據服務的多樣化，手工維護多個不同種類服務的集群將面對更繁重的挑戰。不過，由於我們將服務進行了更好的拆分和分層，變成了一個個更小的微服務，使得我們能把它們進行更好的分布式部署，進而可以橫向擴展來提高整個服務集群處理並發請求的能力。這一階段既是我們成功像微服務架構的轉變階段，也可以看作是我們邁向更現代的后端架構的過渡階段。

黃金時代

Cloud-Native 的概念是2015 年被首次提出的，隨后就獲得了技術社區的大量關注。順着之前架構演進的思路，我們很快開始用Cloud-Native 的理念來武裝整個后端系統架構。在去年，心知天氣正式開始用 Docker 和 Kubernetes 來改造和管理所有對外的線上服務，這些架構設計同時也與阿里雲提供的雲服務深度結合。

從網關到數據服務，目前我們都已經完成了容器化的改造，並且所有服務都使用Kubernetes 來編排和管理，這意味着我們真正統一了各個服務的運行時環境，從而可以快速復制出新的服務節點。借助Kubernetes，心知天氣現在可以做到容器級別的自動伸縮，在並發量高的時候服務節點能夠自動橫向擴展以提高整個集群的並發處理能力，進而可以給用戶提供更加優質穩定的天氣數據API 服務。

不僅如此，基於Cloud-Native 的理念，我們還統一了各個服務的 CI（持續集成） 流程，優化了 DevOps 的體驗，做到所有服務的標准化和歸一化—— 從此以往，萬物皆容器。這對於今后產品的持續高效迭代和改進，也是意義重大的。

 

心知天氣數據API 產品的高可用之路

 

總結

心知天氣數據API 產品歷經十年，其后端架構也逐漸從傳統的企業應用的開發模式轉變為現代的Cloud-Native 應用的開發模式，不僅極大的解放了團隊的產品開發效率，而且能對外提供更加優質穩定的數據服務。心知天氣從創立之初就帶着鮮明的互聯網風格，我們崇尚極客文化，技術團隊也將繼續帶着勇於探索和敢於挑戰的極客精神，用更好的技術與更優質的產品，為我們的客戶提供更具價值的服務。