项目描述： 负责省级微服务管控平台的试点工作，分离解耦出系统部分边缘能力到微服务管控平台，收缩省级系 统的能力，统一由移动集团来管理管控，集团借助微服务的能力收集省级网管的能力，最终通过类似服 务编排的能力接入下级省管的能力平台，达到统一管控提升整个服务质量。 项目职责： 1. 微服务管控平台前期技术研究和基础设施搭建； 2. 核心组件及部分解耦能力的开发和维护； 3. 能力上云，与集团对接协调测试。 项目实现细节、难点： 1. 基于kubernetes v1.14版本搭建容器平台的基础设施； 2. 分离解耦系统边缘能力，使用springboot进行微服务化改造； 3. 使用zuul作为整个微服务管控平台的接入网关，实现统一鉴权、api管理等功能； 4. 采用zk作为配置管理，分离出所有改造的微服务配置外置集中配置到zk中进行统一管理； 5. 基于jwt搭建统一的认证服务器，处理整个平台的门户的认证功能；

项目职责： 1. 系统核心模块设计开发维护； 2. 系统日常业务需求设计开发及需求拆解分配； 3. 跟踪并指导普通开发人员完成日常需求的开发及上线工作； 4. 系统日常维护、故障处理以及疑难杂症的解决。 项目实现细节、难点： 1. 每天接入的告警量在每天1000万左右，去重万400万告警需要入库,每个告警是200多个字段，一条 完整的告警报文是5k大小； 2. 告警需要在页面实时呈现，这些告警需要经过一系列的过滤规则，因为是省级平台系统，需要支持 同时几百人同时实时处理告警，并且需要保证消息不能乱序； 3. 每个告警进入系统在后续的流程中都会产生4,5倍的消息量(确认消息、预处理消息、派单消息、工 单同步消息、清除恢复消息等)，并且消息都需要保持消息的时序性； 4. 每个月的历史告警在1亿2000万，通过MR计算以及es的分析需要支持每天几百个统计任务和每天 几万次的实时搜索任务； 5. 支撑整个系统的各种核心非核心的模块差不多200多个，使用自己定制的监控模块监控这些系统模 块，核心模块不仅需要短信监控更需要ivr 实时呼叫，保证系统7*24小时稳定与运行。

在职时主导参与的项目 项目职责： 1. 总体负责移动三省的故障系统的云化改造、设计和上线工作； 2. 参与故障中心云化版本的总体规范编写； 3. 总体牵头负责故障中心微服务化的改造、架构设计及核心组件模块的编写维护工作； 4. 负责故障系统前端团队的日常管理工作，需求分析设计及拆解分配。 项目实现细节、难点： 1. 基于 Zookeeper 和主导自研扩展 ZKUI 开源组件构建系统配置集中管理能力； 2. 系统采用前后端分离的概念，基于 node+angular/vue+bootstrap+webpack 构建前端UI能力； 3. 基于开源的 SpringCloud Gateway 主导自研扩展可界面配置化的门户网关组件（包括路由、灰度 发布、鉴权、 api 垂直权限管理、 iphash 等功能特性）； 4. 使用 Kafka 解耦系统内各异构模块，降低系统内部耦合度，构建集群化的模块部署，并主导封装 的统一消息处理辅助库； 5. 使用 Redis 缓存热点数据缓解数据库压力，并基于 Redis 封装分布式锁等场景； 6. 搭建统一的海量告警(日均 1000w ,每条 10k )、性能数据( 2000+ 指标)的快速搜索和统计分析库， 并基于系统高可用需要封装 ES 高可用 api ； 7. 系统所有模块均做了云化改造，基于 rancher+k8s+docker+harbor 构建故障中心应用容器化平台 (管理 200 ~ 500+ vm 节点)； 8. 基于 ES+filebeat+Kibana +分布式存储实现容器化应用的统一日志搜集和管理平台(日均 250G 日 志)； 9. 使用 saltstack 搭建批量配置和部署平台( vm 配置调整、应用软件配置安装、自动化运维工作)； 10. 自研agent类库构建系统IT监控指标采集和分析展示，提供系统预警和优化决策； 11. 难点1：系统业务量大，每天告警量差不多在300w-1000w左右，每天接入的性能指标数量量在几 百G左右，业务复杂系统稳定性要求高，需要7*24小时不间断运行，系统模块多消息流复杂，消息 实时处理时延要求高； 12. 难点2：系统改动巨大，近乎从头到尾做了全新的改造，原系统所有C++模块全部改造适配成java 版本，系统间模块调用全由同步的corba（RPC）方式调用切换成异步（kafka）方式，并将单体 式系统按照业务解耦拆分成了各个独立的微服务能力，并对前后端做彻底分离，前端也有老的技术 栈（struts+jsp）改造成了h5+angulajs/vue+webpack的纯前端模式。 13. 难点3：系统运维体系的改变，原先采用的都是基于shell脚本和监控短信的方式对系统做维护，系 统升级也基本都是纯手工传代码的方式。改造后从监控体系做了完全改造自研了一套完整监控体系 （从应用、中间件、主机），运维人员只需在维护页面配置配置即可快速完成系统的监控规则； 14. 难点4：团队组织的巨变，原系统开发模式功能一般都由一个人完成，先系统按照业务、前后端进 行拆分解耦后前端、能力层、处理层都需要专职的人员进行开发维护，分工更加精细开发效率自然 也就更加高效。