在ezbuy业务里，GO服务被大规模的用在我们后端服务上，那么我们是如何运维GO服务的呢？我们分以下3个类别说起：
- uat测试环境
- 线上生产环境
- GO服务运维
uat环境持续集成（gitlab+jenkins+docker＋Dockerfile模版）
针对新的项目在uat上线，我们会通过CMDB工单系统，让开发提交工单填写项目名称，工单系统首先会通过gitlab api查看这个项目是否在gitlab有，如果没有，拒绝在uat上线，如果有则调用jenkins的api，通过jenkins模版在所有的uat环境生成uat项目。
针对已有的uat项目，通过gitlab的webhook功能，开发在提交分支的时候自动触发gitlab webhook功能，从而jenkins会自动执行编译步骤，编译成功后会解析每个项目下的conf.ctmpl配置文件，通过这个配置文件我们可以发现服务所需要暴露出来的端口，然后通过 Dockerfile模版文件生成Docker镜像，最后通过docker api下发到docker宿主机子上。
针对GO服务的配置文件，我们统一通过consul key 来实现，这样可以保持uat和线上一致
线上环境持续部署（gitlab + jenkins + svn + CMDB api/CMDB）
开发在合并master分支的时候，会自动触发webhook,实现jenkins编译go，编译通过后上传到svn，然后可以根据项目的选择调用CMDB api直接发送到线上，也可以不掉用CMDB api，通过登录到CMDB运维平台，手动发布到线上，如果线上发布失败，系统会自动回滚到上一个稳定的版本，发布后会调用钉钉和企业微信at到发布本人，全程发布运维不干预，发布权限下发到每个开发手中。
所有的GO权限都下发到每个开发手中，开发可以通过cmdb平台实时看到自己的服务运行状态，重启/停止服务，版本回滚，GO cronjob下发，cronjob列表查询，脚本运行
GO线上运维
GO服务上线：
- 开发同学通过cmdb平台提交工单，系统自动上线
GO自动发现注册：
- 通过consul template + nginx + consul实现api的自动注册
- 通过consul template + nghttpx + consul实现gRPC调用
GO服务日志：
- 通过sentry和log让开发在跳板机查看日志
GO服务监控：
- 监控GO服务使用内存等情况，超过阀值自动重启服务并发送钉钉通知
- 监控GO服务异常，自动尝试重启，并发送钉钉通知
-
通过statsd监控所需要的服务，展示在grafana界面，超过阀值通过钉钉和企业微信报警通知到指定的开发和运维，阀值的添加开发同学可以在CMDB报警平台自行添加
grafana.png
关于GO服务的运维我们暂时介绍到这，下一篇介绍下GO服务在运维的架构，尽请期待。
