微服务架构在最近两年炒比较火热，最近有个朋友在做充电桩管理软件，该软件是两年前采用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语言的高校的开发效率和朴质的编程规范折服。
