本文旨在介绍GoFrame
框架对微服务-单仓管理(mono-repo
)模式的支持,指导开发者如何在微服务-单仓管理(mono-repo
)模式下进行代码开发和分工协作。
一、前置阅读
在开始本章节之前,建议先了解一下单体仓库(monolith
)、微服务-多仓管理(multi-repo
)、微服务-单仓管理(mono-repo
)的基本概念以及各自的优缺点:单体仓库与多仓库都有哪些优势劣势,微服务选择哪种方案比较好?
代码仓库的管理约束并不属于框架职责的一部分,GoFrame
框架的脚手架本身也支持两种仓库项目初始化的命令 - 单仓库(mono-repo
)、多仓库(monolith/multi-repo
),以满足不同团队的需求。具体选择哪种代码仓库管理模式由开发团队根据自身需求、场景、习惯来自行选择。
二、大仓管理
1、仓库职责范围的划分
通过前置阅读的文章大家也知道,这个世界上没有银弹,大仓有优点也有缺点,其中最明显的缺点就是权限的管控以及仓库的膨胀。为了更好地管理代码仓库,避免这两点缺陷带来更高的成本,我们建议尽可能减小大仓中的微服务规模。至于仓库中需要维护哪些微服务,需要根据服务之间的协作频率来决定。
1)当团队内部的协作频率高于团队间协作频率时
- 典型的场景是针对非微服务化架构的产品,可以将服务管理的权限职责按照各个业务团队进行划分。这样团队内部可以将分散的若干服务通过统一的代码仓库维护起来,充分利用大仓管理的优势,提高团队内部的开发和维护效率。
- 另外一种场景是业务的微服务数量本身不多(例如
50
个以内),这个时候也可以合并成一个大仓进行管理。需要注意,大仓管理的服务数量并不是由组织架构中的人员数量来决定的。
2)当多个团队之间的多个服务协作频率非常高时
当业务的微服务数量比较多,并且各个服务之间的交互协作比较频繁,那么可以考虑将这些服务合并到大仓中进行管理,可以极大提高协作效率。这种情况大部分出现在微服务在同一产品线、跨团队但不跨中心或部门的情况下。但由于涉及跨多个团队的协作,这对人员的组织架构管理有一定要求,需要由一定权限的管理者来推动。能做到这一点的企业,往往上层管理水平较高。
2、大仓下的微服务间如何协作
1)代码可见性的管理
服务与服务之间能够暴露的仅仅是接口,也就是API
。各个服务内部的逻辑应当对外不可见。在Golang
里面有很好的internal
特性,正好可以满足可见性管理的要求。如下图大仓代码示例,在app
目录下管理了若干的服务,每一个服务暴露了自身的api
目录,供其他服务直接引用(提高服务间协作效率),但内部的业务逻辑包含在了internal
目录下,对其他服务不可见(也就无法引用)。
2)服务间接口的调用
协议文件单独维护到各自服务目录下,如果涉及到协议文件编译,那么编译的文件也存放到自身的服务目录下。调用端不需要单独再对目标服务的协议文件重新编译管理。以HTTP API
的接口定义为例,调用端可以直接引用目标端服务的API
接口定义:
针对于微服务间的RPC
接口调用也是同样的道理:
3)兼容性的严格要求
通过以上介绍可以发现,通过大仓的代码管理,使得大仓中所有服务的版本保持一致,每当依赖的服务API
更新时,调用端服务(使用的SDK
)也将自动得到更新。这就要求所有服务的接口设计,必须严格保证兼容性,否则接口间调用将会出现问题:轻者调用端服务编译失败需要调整代码,重者编译成功但运行时报错影响业务。此外,公共引用的大仓基础组件也会受到兼容性的影响。
保证兼容性代码设计的几个要点:
- 不随意删减接口参数,修改参数名称、参数类型、参数校验逻辑。
- 当接口必须要进行非兼容更新时,应当使用接口版本号来管理(如
v1, v2, v3...
)。 - 公共组件尽量使用稳定成熟的外部组件,如果是必要的自定义组件,需要保证对外暴露方法的兼容性。一些很基础的功能,比如说
json.Marshal&Unmarshal
,有的人封装了一些库/函数,但是后面的人可能都不知道这个库,也不太信任这个函数,就会又重新写一个...久而久之这些库/函数却又无人维护。
3、大仓下的微服务容器化支持
1)镜像仓库的统一管理
分散的镜像仓库将会降低服务容器化的管理维护效率。为便于统一服务容器化管理,我们建议大仓下的服务使用统一的镜像仓库。镜像仓库的地址统一维护到各个服务下的工具配置文件中:
2)统一编译、提交指令
框架提供了常用的指令来实现程序的编译、镜像的编译、镜像的提交。
编译程序,生成二进制文件。
更多介绍请参考文档:交叉编译-build
编译程序并编译镜像,生成Docker
镜像。
通过make image TAG=xxx
可以指定编译生成的镜像标签名称。
更多介绍请参考文档:镜像编译-docker
编译程序、编译镜像并推送镜像到已配置好的镜像仓库。
通过make image.push TAG=xxx
可以指定编译生成的镜像标签名称。
3)统一部署、调试指令
框架提供了常用的指令来实现Kubernetes
集群的容器化部署,以及一体化编译部署的开发指令。
部署当前服务到本地kubeconfig
已连接的kubernetes
集群中,其中的TAG
用于指定deploy
目录下的overlays
目录。管理部署yaml
文件使用的是行业内常用的kustomize
工具,具体介绍文档请参考:https://kubernetes.io/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/
make image.push deploy TAG=xxx
该命令是开发调试指令,用于一条指令 编译二进制文件、编译并推送Docker
镜像、部署Kubernetes
应用并重启应用。
4、大仓下的框架其他指令
框架针对于项目工程管理提供了丰富的工具指令支持,这些指令往往需要再特定的服务目录下执行,例如./app/服务名称
1)make cli
用于升级本地的框架CLI
到最新稳定版本。
2)make up
用于升级本地的框架到最新社区稳定版本。
更多介绍请参考文档:框架升级-up
3)make dao
用于生成DAO/Entity/DO
代码文件。
更多介绍请参考文档:数据规范-gen dao
4)make service
用于解析logic
目录并自动生成内调用接口。该指令在Goland IDE
下往往使用自动化的Watcher
文件变动来自动生成,具体请参考官方文档。
更多介绍请参考文档:接口维护-gen service
5)make enums
用于解析指定代码目录(默认为api
目录)并自动生成enums
加载代码。
更多介绍请参考文档:枚举维护-gen enums
6)更多指令
更多的指令支持请参考框架官网工具介绍章节:开发工具