陆陆续续使用Go来进行日常业务服务开发有段时间了,慢慢有了一些心得,也在往这些方面进行靠拢。

清晰的文件目录

我们在进行服务开发过程中,往往不是一个人在那战斗,而是一个团队。应该说,对于稍具规模的公司在这个方面都是相当看重的。因为清晰的目录结构、文件命名等体现一个团队的素养,一定程度上降低项目维护成本。比如在A同事接手B同事项目时能够做到尽量快的接手。
下面是我们现有服务的一个目录结构

展开查看
.
├── config
│   └── dev.conf
├── constants
│   ├── errors
│   └── types
├── global
│   ├── config.go
│   └── config_watcher.go
├── main.go
├── modules
│   └── doc.go
├── routes
│   └── root.go
└── vendor
    └── ...

wx20190602-160013
当前主要的目录结构就是以上的几个:

  • config:顾名思义,就是存放的本地想相关配置文件,我们配置文件主要以json为主
  • constants:存放的是一些全局宏定义,比如定义的通用错误放errors,通用全局控制放types
  • global:初始化配置文件的地方,从本地or远端配置服务拉取出来的配置均在此处进行初始化
  • modules:一些模块化定义的地方,比如服务内部的一些公共函数等
  • routers:HTTP接口路由,因为主要针对的业务服务,所有有该文件夹
  • vendor:这个是外部依赖包管理文件夹,常用的还有godep等。这个里面更多的会是依赖github上面的优秀开源库

优化

使用上面的一些服务文件目录应该就差不多了,然后在部署服务的时候运维只需要针对这个服务就行编译运行就OK了。可是今天讨论的重点在那个vendor文件夹上面,不是说使用哪个包管理工具的问题,而是这些第三方包的版本(version)问题,场景是这样的:
同事A引用了github上面的库a,同事B后续也在维护同一个项目,因为这个库a都是直接从github上面实时更新拉取下来的,所有同事A和B在拉取这个库a的时候会出现拉取到不同版本的问题,而正因为版本的不同,就可能会出现不同的线上问题。

此时的解决方案就是把所有的第三方依赖包全部拉下来,然后存放在公司的代码仓库里面,同事A、B要使用库a的时候都从公司自有仓库里面拉取,统一维护管理。这里也有两种简单的做法:一种是在自己的代码库里面直接新建一个项目,然后把这些库都放进去,方便快捷;另一种方法就是现在bilibili采用的,
依然使用包管理工具来控制,比如放进vendor里面,由专人维护,比如有某一个包需要进行版本变更,直接使用govendor update操作就OK,全公司业务线项目都公用这个vendor文件夹里面的包.

后续

后续我们也会有包管理,不过可能更绝,公司办公环境准备断网了!后续代码都只能在内网环境开发,所以初步方案是在公司自有DNS服务上面进行域名拦截,开发时依然可以向访问github一样拉取其中的库,不过这个github的域名指向的是我们自有的服务器,哈哈😿

© 2019·蜀ICP备18036663号-1 · 本页总阅读量 · 本站总访问量 · 本站总访客数