最近发现 golang 社区里出了一个新兴的微服务框架。看了一下官方提供的工具真的很好用，只需要定义好 .api 文件模版代码都可以一键生成，只需要关心业务；同时 core 中的工具极大减少了开发成本。
废话不多说，来看看这个微服务框架：go-zero
起源
聊聊与go-zero结缘
最先接触go-zero是2020年10月国庆假期，说来也巧，看到有人在go-micro群中问go-zero情况，当时go-zero作者在群中就大概回答了一下，引起了我的好奇，当时公司用的go-micro1.x，因为go-micro版本真的太混乱了，2还没多少人用明白，现在又搞了个3，而且这几个大版本之间高度不兼容，简直一团糟。我抱着好奇心去github.com查看了go-zero，当时并没有因为它的star数、文档少而放弃，哈哈，抱着试玩的心态去go get它，从此发现了新大陆，并加入了go-zero群，开始了go-zero之旅。
选择它的几点原因
- 微服务：在现在这个大环境下，单体服务诟病已经越来越多了，项目大起来之后 “牵一发而动全身” 的教训比比皆是，维护越来越困难，测试测起来也是很头疼，构建速度慢等等，在这样趋势下拥抱微服务成为了大趋势，go-zero就是一个微服务框架并且能为我解决很多实际项目中遇到的痛点、难点
- 稳定性：内外同源。稳定性是我很看重的，他们公司内外同源势必保证了此框架的稳定性。
- 高并发：经历了2020年疫情期间，“晓黑板” 轻松获得支撑千万日活服务
- 工作效率：说到工作效率，必须要提的就是goctl，goctl配合go-zero所有代码基本都是可以通过这个工具生成，只需要关心自己的业务逻辑即可，包括一键生成dockerfile，k8s的yaml文件，简直不要太爽，大大提高了工作效率
- 代码质量：大概看了一些go-zero的源码，代码质量上感觉还是没得喷的，至少感觉比我自己写的好很多，哈哈，这个每个人看法不同，大家可以去亲自看一下。
- 团队：当时加了go-zero作者微信，感觉他为人很谦和，无论问一些比较基础的东西还是一些线上实战经验，也总是会耐心给我解答、意见，在使用期间我也提了一些bug，go-zero团队都能及时的解决，迭代速度真的让我惊艳。大家应该都知道，在国内做开源有多么不容易。
对比go其他微服务框架：go的微服务框架大概我玩过go-micro、go-kit、kratos、rpcx、go-zero。
- go-micro我开始就说了是版本真心有点混乱
- go-kit也不错但是资料相对来说较少
- kratos经过b站源码泄漏大家应该都知道它了，前一段时间都断更了，差点安乐死，毛神在issue中说太忙了，不过他们在出2.0版本了，还是很期待
- rpcx 玩了一下玩的不多，但是他们宣传是“好未来”也在用，go-zero就是“好未来”的呀，哈哈
- go-zero 上面我都说过了，就不再提了。
设计架构
在介绍go-zero实际使用前，先说一下整体架构，更方便理解
CI/CD
Step1：本地deveploer开发好代码之后提交到gitlab（这里分支就不详细说明了）
Step2：jenkins，使用pipline方式部署
- 从gitlab拉取代码
- docker build ，基于最新gitlab上的code构建镜像
- docker push，将构建好的镜像推送到镜像仓库（当然一般都是有自己私有镜像仓库比如harbor，用阿里云的也可以）
- kubectl apply -f xxx.yaml ：使用kubectl 部署到k8s中 （阿里云k8s容器服务那么好用，不用岂不可惜？）
kubectl部署之后，k8s就会根据你的service中的yaml定义的镜像来你的镜像仓库拉取刚才你打包的最新镜像，so～～上线成功啦！
嗯，有的同学说，阿里云k8s好用是好用，可是我不会写or不想写Dockerfile，不会写k8s的yaml or 不想写，没关系，goctl说放开它，让我来
生成 Dockerfile
$ goctl docker -go user.go
生成k8s yaml
$ goctl kube deploy -name user-api -namespace blog -image user:v1 -o user.yaml -port 2233
所以，就是这么简单
访问流程
app/web/pc 透过防火墙，首先访问到阿里云的负载均衡SLB，同时SLB可以将你的后端服务器ip隐藏起来，同时可以预防DDOS***，虽然有额度的，但是好过没有～～，然后SLB访问到前面的nginx，nginx作为代理使用，k8s中的service通过 nodeport方式暴露出来在nignx中代理到该service，同时在nginx中上报日志到kafka，然后api可以在etcd中拿到多个rpc节点，调用多个后端rpc服务，rpc负责跟db交互、或者调用其他rpc获取数据（当然api、rpc之间是通过etcd动态发现的）返回给api，api就是聚合数据，然后层层返回到客户端。
整体架构都是高可用高可用
项目设计
go的项目比较灵活不像java已经形成统一标准化了，所以对于不同项目的结构都不一样，我的做法是如下：
整个项目使用的一个大仓，项目fishtwo根目录下：
- app : 应用内部程序
- build：构建、以及脚本等
- lib：应用程序用到的内部库
app下分为3个模块：
- gateway：api服务
- services： rpc服务
- jobs：日常要处理的任务（这个可以使用 go-zero 作者的 go-queue ，测试了下很好用，哈哈，后面搞好也会写进来）
下一篇我们来看看：
- 怎么改造 gateway 服务？
- 怎么改造 rpc 服务？
- jobs 怎么定义？怎么和项目结合？
有疑问加站长微信联系（非本文作者）
