C/S模式充電樁管理軟體向微服務架構演進

微服務架構在最近兩年炒比較火熱，最近有個朋友在做充電樁管理軟體，該軟體是兩年前采用C/S模式開發的 ，主要Client（UI）和 Server端兩個層次，中間采用資料庫共享方式進行通信，如下圖所示為充電樁管理軟體的用戶端界面：

這類應用是傳統的C/S模式，适合于30個場站以下的管理和應用，在目前充電樁整體規模不大的情況下，還是勉強可以支撐試用的，最近我這位朋友遇到一個新需求，要接入到第三方的管理平台（B/S模式）中，要求提供标準的REST接口。由于傳統的應用開發者（尤其是以嵌入式為主的開發工程師），對REST 等類型的網際網路接口存在一定的陌生，在向我咨詢後，我們仔細分析了該項目的需求，我給他推薦了向微服務架構演進的方法，最後他們順利的接入到第三方的管理平台中，或者內建資質。本文将主要闡述我們将傳統的充電樁管理軟體向微服務架構演進的經驗，以下分幾個層面進行拆分和演進：

1\業務閉環、顆粒度細分、RPC互動

原來的充電樁管理軟體主要劃分為兩個子產品（UI和背景伺服器），UI主要用于客戶資訊維護、充值、充電樁狀态監視等功能，背景伺服器主要負責充電樁接入、鑒權、執行任務、資料采集等功能。通過對這兩個子產品進行分析，我們将 UI和背景伺服器都進行了拆分。

UI拆分成三個子產品（本地大屏監控、本地營運用戶端 、中心監控用戶端，通過權限進行區分），本地大屏監控直接從本地服務程式中擷取資料，部署在場站，用于實時回報充電樁狀态（忙、閑狀态），便于客戶快速的定位到空閑的充電樁進行充電。本地營運用戶端主要用于本地充值、場站經營狀況管理等功能。中心監控用戶端是一個功能全集，用于監控所有的充電樁狀态、經營情況等。

背景伺服器拆分成接入管理、鑒權、計劃、事件四個子產品。接入管理負責充電樁的接入和心跳維護，采用Boost ASIO實作，支援30000+充電樁接入，心跳周期為15秒一次。鑒權：對裝置進行認證管理，剔除非法的裝置、并對裝置進行分域管理。計劃：負責根據客戶定制的計劃，定期執行任務或者采集資料。事件: 負責收集和存儲充電樁的各類事件，并上報。

拆分的各個子產品都支援按域動态擴容，在傳輸層支援主備IP備份政策，各個子產品之間采用Google Protobuf RPC進行傳遞通信。

2\業務服務下沉、本地自治、多級緩沖

為了防止因為WLAN網絡異常影響，我們做了多級防護，多級緩沖，保障資料不丢失，業務不中斷。

a,所有子產品均支援下沉部署，子產品間通過辨別和類型進行識别。

b,本地采用SQLite資料庫進行本地業務最小化自治，SQLITE保持裝置和使用者最小資訊，支援後付費同步功能，當WLAN側出現異常，本地可保障業務基本運作，不中斷，WLAN恢複後可自動同步資訊到資料中心。

c,對于關鍵資料采用确認機制和多重緩沖，例如WLAN網絡異常，在本地儲存60+天以上的業務資料緩沖LOGS, WLAN恢複後，自動同步到資料中心。

d,資料進行層層過濾，每層過濾後将最小量級資料上報給上一層，避免資料中心資料庫爆裂式增長，滿足核心基礎資料要求為準要。

3\Go語言嘗試、統一應用層接口

除了在自身架構上的調整，為了提供接口給第三方應用，按照要求，我們采用REST接口，并将服務層和應用層進行徹底隔離，統一接口，按域區分不同的應用和權限，支援多應用接入。是以我們新拆分的中心監控用戶端進行調整，也通過統一的接口子產品接入到背景服務中，不過我們對域進行保留，0x00~0x80的域認為是自己系統的裝置。其他域開放給第三方應用。在這個過程中第一次推薦采用Go語言實作，引用了BeeGo開源代碼作為基礎架構，同時支援WebSocket接口方式釋出即時狀态、告警和事件。在後續朋友的開發過程中，足以證明，Go語言天生就是做網際網路的開發語言，極高的開發速率。為了防止統一接口管理子產品存在性能瓶頸，我們采用Zookeeper + Nginx 作為叢集基礎架構，提高穩定性，便于後續輕松擴容。

經過2個月的架構調整，整套系統按期傳遞，即相容了老系統的基礎子產品，又完成了和第三方應用的業務對接，做到了業務上的平滑過渡，性能有原來的30個場站規模，演進成可以平滑擴容的架構，初步預估可以做到10萬個充電樁的接入和業務營運。經過這個項目曆練，朋友在微服務架構上有了全新的認識，也被Go語言的高校的開發效率和樸質的程式設計規範折服。