项目背景，之前在上家东家接触到golang，自学到项目上线，也是摸着石头过河，中间也遇到了一些小bug（生产环境出现内存泄露问题，导致业务占用内存，居高不下，实际是因为项目的service层部分应用没有应用到redis或数据库，但是也进行了实例化，最后没有释放资源导致，排查方法也是比较笨，就是一些流程在本地跑，看哪些环节导致内存居高不下，最后追查到的结果），随之后来业务的golang需求增加，公司一些业务也使用golang抽离了出来，成为服务化的内容（历史业务使用的php，包括多服务调用优化为golang的协程实现调用，mq的生产消费者服务、其中有rocketMQ、Beanstalk、RabbitMQ），包括后续的一些中台业务也使用golang写（其实中间公司有一段时间要求全员转go，但是由于诸多因素，就剩下了我一个人去处理go的业务了，到最后我也离职了，直到目前前东家的业务有问题，还会偶尔联系到我帮忙解决一下，不过业务趋于稳定，已经没有什么太多的问题了）。

以上是了解到我接触golang，以及golang业务的基础业务范畴，但是其中出现了一个比较严重的问题：部署方案及配置多项目重复问题，由于当时整体技术偏于写业务能力，个人没有太多探索相关技术解决方案，当时只是意识配置重复性导致业务迁移地址、配置的复杂性引发的工作量、及时性、错误性等问题，当时并没有特别好的解决方案（前东家团队对技术比较支持新颖，特别适合技术增长），直到前段时间了解到携程的apollo、阿里的nacos，受到了很多的启发（其中也是前团队主管调到某米后给了一些点播，统一配置他们的部署方案）。

直奔本次的业务主体，实现语言还是使用了go（目前就职单位对go是不会在触碰到了， 也算是给自己一个实战的一个小机会，虽然不能够应用到生产环境了），其中开发过程受到了一些阻碍（websocket长连接分组、整体业务架构局限等），最后通过网上了解了一些方案，并且也实际代码也采用了一些网上搜索到的结果，下面展示一下业务最重心的截图，订阅与推送：

其中才用到了几个重要的技术点：

golang的rpcx、gin框架（原本使用echo，但是针对多端口监听转换成了gin框架，两个框架都可以实现，只不过觉得更加优雅一些）、github.com/gorilla/websocket、github.com/gomodule/redigo/redis等

简单代码结构截个图：

业务流程：

实现了一个分布式的配置中心
对接zookeeper实现注册中心（后续优化成自己内部）
支持订阅，实时推送，全量通知，系统通知，指定客户端通知
目前支持api方式调用，后续增加sdk包（个人语言站有限，后续sdk只能支持 js、php、go、java），同期增加web-ui界面
日志支持多种方式（文档、数据库等）

给他起了个名字 - sun.

期待他会变得更完美吧。

本文转自 https://blog.csdn.net/u012394573/article/details/105484438/，如有侵权，请联系删除。