微服務架構在最近兩年炒比較火熱，最近有個朋友在做充電樁管理軟件，該軟件是兩年前採用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語言的高校的開發效率和樸質的編程規範折服。