关于go-zero单体服务使用泛型简化注册Handler路由的问题

目录
  • 一、Golang环境安装及配置Go Module
    • mac OS安装Go#
    • linux 安装Go#
    • Windows安装Go#
    • MODULE配置
  • 二、Goctl 安装
  • 二、初始化go-zero
  • 三、查看注册Handler路由流程greet.go
  • 四、对注册Handler路由进行简化
    • 项目文件的增加
    • 引入泛型概念
    • 验证一下新增api路由在internal\logic下新增一个customlogic.go文件
    • 本文代码放在go-zero-monolithic-service-generics

一、Golang环境安装及配置Go Module

https://go-zero.dev/cn/docs/prepare/golang-install

mac OS安装Go#

  • 下载并安装Go for Mac
  • 验证安装结果
$ go version
go version go1.15.1 darwin/amd64

linux 安装Go#

  • 下载Go for Linux
  • 解压压缩包至/usr/local
$ tar -C /usr/local -xzf go1.15.8.linux-amd64.tar.gz

添加/usr/local/go/bin到环境变量

$ $HOME/.profile
$ export PATH=$PATH:/usr/local/go/bin
$ source $HOME/.profile

验证安装结果

$ go version
go version go1.15.1 linux/amd64

Windows安装Go#

下载并安装Go for Windows验证安装结果

$ go version
go version go1.15.1 windows/amd64

MODULE配置

Go Module是Golang管理依赖性的方式,像Java中的Maven,Android中的Gradle类似。

查看GO111MODULE开启情况

$ go env GO111MODULE
on

开启GO111MODULE,如果已开启(即执行go env GO111MODULE结果为on)请跳过。

$ go env -w GO111MODULE="on"

设置GOPROXY

$ go env -w GOPROXY=https://goproxy.cn

设置GOMODCACHE

查看GOMODCACHE

$ go env GOMODCACHE

如果目录不为空或者/dev/null,请跳过。

go env -w GOMODCACHE=$GOPATH/pkg/mod

二、Goctl 安装

Goctl在go-zero项目开发着有着很大的作用,其可以有效的帮助开发者大大提高开发效率,减少代码的出错率,缩短业务开发的工作量,更多的Goctl的介绍请阅读Goctl介绍

安装(mac&linux)

### Go 1.15 及之前版本
GO111MODULE=on GOPROXY=https://goproxy.cn/,direct go get -u github.com/zeromicro/go-zero/tools/goctl@latest
### Go 1.16 及以后版本
GOPROXY=https://goproxy.cn/,direct go install github.com/zeromicro/go-zero/tools/goctl@latest

安装(windows)

go install github.com/zeromicro/go-zero/tools/goctl@latest

环境变量检测(mac&linux)
go get 下载编译后的二进制文件位于 \$GOPATH/bin 目录下,要确保 $GOPATH/bin已经添加到环境变量。

sudo vim /etc/paths //添加环境变量

在最后一行添加如下内容 //$GOPATH 为你本机上的文件地址

$GOPATH/bin 

安装结果验证

$ goctl -v
goctl version 1.1.4 darwin/amd64

二、初始化go-zero

快速生成 api 服务

goctl api new greet
cd greet
go mod init
go mod tidy
go run greet.go -f etc/greet-api.yaml

默认侦听在 8888 端口
侦听端口可以在greet-api.yaml配置文件里修改,此时,可以通过 curl 请求,或者直接在浏览器中打开http://localhost:8888/from/you

$ curl -i http://localhost:8888/from/you
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Traceparent: 00-45fa9e7a7c505bad3a53a024e425ace9-eb5787234cf3e308-00
Date: Thu, 22 Oct 2020 14:03:18 GMT
Content-Length: 14
null

greet服务的目录结构

$ tree greet
greet
├── etc
│   └── greet-api.yaml
├── greet.api
├── greet.go
└── internal
    ├── config
    │   └── config.go
    ├── handler
    │   ├── greethandler.go
    │   └── routes.go
    ├── logic
    │   └── greetlogic.go
    ├── svc
    │   └── servicecontext.go
    └── types
        └── types.go

三、查看注册Handler路由流程greet.go

var configFile = flag.String("f", "etc/greet-api.yaml", "the config file")
func main() {
	flag.Parse()
	var c config.Config
	conf.MustLoad(*configFile, &c)
	server := rest.MustNewServer(c.RestConf)
	defer server.Stop()
        //上面的都是加载配置什么的
	ctx := svc.NewServiceContext(c)
	handler.RegisterHandlers(server, ctx) //此方法是注册路由和路由映射Handler,重点在这里
	fmt.Printf("Starting server at %s:%d...\n", c.Host, c.Port)
	server.Start()
}

RegisterHandlers在internal\handler\routes.go

func RegisterHandlers(server *rest.Server, serverCtx *svc.ServiceContext) {
   server.AddRoutes( //往rest.Server中添加路由
	[]rest.Route{ //路由数组
	   {
	      Method:  http.MethodGet,
	      Path:    "/from/:name", //路由
	      Handler: GreetHandler(serverCtx),//当前路由的处理Handler
	   },
	},
   )
}

GreetHandler在internal\handler\greethandler.go

func GreetHandler(ctx *svc.ServiceContext) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		var req types.Request
	if err := httpx.Parse(r, &req); err != nil { //请求的错误判断,这个可以不用管
			httpx.Error(w, err)
			return
		}

		l := logic.NewGreetLogic(r.Context(), ctx) //GreetHandler处理函数将请求转发到了GreetLogic中,调用NewGreetLogic进行结构体的初始化
		resp, err := l.Greet(req) //然后调用Greet来进行处理请求,所以我们在GreetLogic.Greet方法中可以看到一句话// todo: add your logic here and delete this line
		if err != nil {
			httpx.Error(w, err)
		} else {
			httpx.OkJson(w, resp)
		}
	}
}

四、对注册Handler路由进行简化

项目文件的增加

在路由注册时,我们如果服务越加越多,那么相对应的func xxxxHandler(ctx *svc.ServiceContext) http.HandlerFunc就要进行多次的添加,并且这个方法体内部1到5行是属于额外的重复添加
例如:我们添加一个customlogic.go
按照命名的正确和规范性,需要在internal\logic目录下添加customlogic.go文件,然后在internal\handler目录下添加customhandler.go文件,并且两个文件都添加相对应的结构体和函数等,最后在routes.go中再添加一次

{
    Method:  http.MethodGet,
    Path:    "/custom/:name",
    Handler: CustomHandler(serverCtx),
},

此时,我们的文件结构应该是这样

greet
├── etc
│   └── greet-api.yaml
├── greet.api
├── greet.go
└── internal
    ├── config
    │   └── config.go
    ├── handler
    │   ├── greethandler.go
    │   ├── customhandler.go
    │   ├── ...
    │   └── routes.go
    ├── logic
    │   ├── greetlogic.go
    │   ├── ...
    │   └── customlogic.go
    ├── svc
    │   └── servicecontext.go
    └── types
        └── types.go

当单体应用达到一定的数量级,handler和logic文件夹下将会同步增加很多的文件

引入泛型概念

自Go1.18开始,go开始使用泛型,泛型的广泛定义 :是一种把明确类型的工作推迟到创建对象或者调用方法的时候才去明确的特殊的类型。 也就是说在泛型使用过程中,操作的数据类型被指定为一个参数,而这种参数类型可以用在 类、方法和接口 中,分别被称为 泛型类 、 泛型方法 、 泛型接口 。
我们可以利用泛型,让在添加路由时就要固定死的Handler: GreetHandler(serverCtx)推迟到后面,去根据实际的Logic结构体去判断需要真正执行的logic.NewGreetLogic(r.Context(), ctx)初始化结构体和l.Greet(req)逻辑处理方法

如何去做在internal\logic下添加一个baselogic.go文件,参考Go泛型实战 | 如何在结构体中使用泛型

package logic
import (
	"greet/internal/svc"
	"greet/internal/types"
	"net/http"
)
type BaseLogic interface {
	any
	Handler(req types.Request, w http.ResponseWriter, r *http.Request, svcCtx *svc.ServiceContext) //每一个结构体中必须要继承一下Handler方法,例如customlogic.go和greetlogic.go中的Handler方法
}
type logic[T BaseLogic] struct {
	data T
}
func New[T BaseLogic]() logic[T] {
	c := logic[T]{}
	var ins T
	c.data = ins
	return c
}
func (a *logic[T]) LogicHandler(req types.Request, w http.ResponseWriter, r *http.Request, svcCtx *svc.ServiceContext) { //作为一个中转处理方法,最终执行结构体的Handler
	a.data.Handler(req, w, r, svcCtx)
}

greethandler.go文件修改成basehandler.go,注释掉之前的GreetHandler方法

package handler
import (
	"net/http"
	"greet/internal/logic"
	"greet/internal/svc"
	"greet/internal/types"
	"github.com/zeromicro/go-zero/rest/httpx"
)
// func GreetHandler(svcCtx *svc.ServiceContext) http.HandlerFunc {
// 	return BaseHandlerFunc(svcCtx)
// 	// return func(w http.ResponseWriter, r *http.Request) {
// 	// 	var req types.Request
// 	// 	if err := httpx.Parse(r, &req); err != nil {
// 	// 		httpx.Error(w, err)
// 	// 		return
// 	// 	}
// 	// 	l := logic.NewGreetLogic(r.Context(), svcCtx)
// 	// 	resp, err := l.Greet(&req)
// 	// 	if err != nil {
// 	// 		httpx.Error(w, err)
// 	// 	} else {
// 	// 		httpx.OkJson(w, resp)
// 	// 	}
// 	// }
// }
func BaseHandlerFunc[T logic.BaseLogic](svcCtx *svc.ServiceContext, t T) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		var req types.Request
		if err := httpx.Parse(r, &req); err != nil {
			httpx.Error(w, err)
			return
		}
		//通过泛型动态调用不同结构体的Handler方法
		cc := logic.New[T]()
		cc.LogicHandler(req, w, r, svcCtx)
	}
}

internal\logic\greetlogic.go中增加一个Handler方法

package logic
import (
	"context"
	"net/http"
	"greet/internal/svc"
	"greet/internal/types"
	"github.com/zeromicro/go-zero/core/logx"
	"github.com/zeromicro/go-zero/rest/httpx"
)
type GreetLogic struct {
	logx.Logger
	ctx    context.Context
	svcCtx *svc.ServiceContext
}
func NewGreetLogic(ctx context.Context, svcCtx *svc.ServiceContext) *GreetLogic {
	return &GreetLogic{
		Logger: logx.WithContext(ctx),
		ctx:    ctx,
		svcCtx: svcCtx,
	}
}
func (a GreetLogic) Handler(req types.Request, w http.ResponseWriter, r *http.Request, svcCtx *svc.ServiceContext) { //新增方法
	l := NewGreetLogic(r.Context(), svcCtx)
	resp, err := l.Greet(&req)
	if err != nil {
		httpx.Error(w, err)
	} else {
		httpx.OkJson(w, resp)
	}
}
func (l *GreetLogic) Greet(req *types.Request) (resp *types.Response, err error) {
	// todo: add your logic here and delete this line
	response := new(types.Response)
	if (*req).Name == "me" {
		response.Message = "greetLogic: listen to me, thank you."
	} else {
		response.Message = "greetLogic: listen to you, thank me."
	}
	return response, nil
}

然后修改internal\handler\routes.go下面的server.AddRoutes部分

func RegisterHandlers(server *rest.Server, serverCtx *svc.ServiceContext) {
   server.AddRoutes( //往rest.Server中添加路由
	[]rest.Route{ //路由数组
	   {
	      Method:  http.MethodGet,
	      Path:    "/from/:name", //路由
	      Handler: BaseHandlerFunc(serverCtx,logic.GreetLogic{}),
	   },
	},
   )
}

现在就大功告成了,我们启动一下

go run greet.go -f etc/greet-api.yaml

然后在浏览器中请求一下http://localhost:8888/from/you

验证一下新增api路由在internal\logic下新增一个customlogic.go文件

package logic
import (
	"context"
	"net/http"
	"greet/internal/svc"
	"greet/internal/types"
	"github.com/zeromicro/go-zero/core/logx"
	"github.com/zeromicro/go-zero/rest/httpx"
)
type CustomLogic struct {
	logx.Logger
	ctx    context.Context
	svcCtx *svc.ServiceContext
}
func NewCustomLogic(ctx context.Context, svcCtx *svc.ServiceContext) *CustomLogic {
	return &CustomLogic{
		Logger: logx.WithContext(ctx),
		ctx:    ctx,
		svcCtx: svcCtx,
	}
}
func (a CustomLogic) Handler(req types.Request, w http.ResponseWriter, r *http.Request, svcCtx *svc.ServiceContext) {
	l := NewCustomLogic(r.Context(), svcCtx)
	resp, err := l.Custom(&req)
	if err != nil {
		httpx.Error(w, err)
	} else {
		httpx.OkJson(w, resp)
	}
}
func (l *CustomLogic) Custom(req *types.Request) (resp *types.Response, err error) { //response.Message稍微修改了一下,便于区分
	// todo: add your logic here and delete this line
	response := new(types.Response)
	if (*req).Name == "me" {
		response.Message = "customLogic: listen to me, thank you."
	} else {
		response.Message = "customLogic: listen to you, thank me."
	}
	return response, nil
}

然后修改internal\handler\routes.go

func RegisterHandlers(server *rest.Server, serverCtx *svc.ServiceContext) {
   server.AddRoutes( //往rest.Server中添加路由
	[]rest.Route{ //路由数组
	   {
	      Method:  http.MethodGet,
	      Path:    "/from/:name", //路由
	      Handler: BaseHandlerFunc(serverCtx,logic.GreetLogic{}),
	   },
           {
	      Method:  http.MethodGet,
	      Path:    "/to/:name", //路由
	      Handler: BaseHandlerFunc(serverCtx,logic.CustomLogic{}),
	   },
	},
   )
}

其他地方不需要修改
我们启动一下

go run greet.go -f etc/greet-api.yaml

然后在浏览器中请求一下http://localhost:8888/from/youhttp://localhost:8888/to/youhttp://localhost:8888/too/you

现在,在添加新的logic做路由映射时,就可以直接简化掉添加xxxxhandler.go文件了,实际上是将这个Handler移动到了xxxxlogic.go中。

本文代码放在go-zero-monolithic-service-generics

到此这篇关于go-zero单体服务使用泛型简化注册Handler路由的文章就介绍到这了,更多相关go-zero单体服务内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • go zero微服务实战性能优化极致秒杀

    目录 引言 批量数据聚合 降低消息的消费延迟 怎么保证不会超卖 结束语 引言 上一篇文章中引入了消息队列对秒杀流量做削峰的处理,我们使用的是Kafka,看起来似乎工作的不错,但其实还是有很多隐患存在,如果这些隐患不优化处理掉,那么秒杀抢购活动开始后可能会出现消息堆积.消费延迟.数据不一致.甚至服务崩溃等问题,那么后果可想而知.本篇文章我们就一起来把这些隐患解决掉. 批量数据聚合 在SeckillOrder这个方法中,每来一次秒杀抢购请求都往往Kafka中发送一条消息.假如这个时候有一千万的用户同

  • go zero微服务高在请求量下如何优化

    目录 引言 本地缓存 自动识别热点数据 缓存使用技巧 结束语 引言 前两篇文章我们介绍了缓存使用的各种最佳实践,首先介绍了缓存使用的基本姿势,分别是如何利用go-zero自动生成的缓存和逻辑代码中缓存代码如何写,接着讲解了在面对缓存的穿透.击穿.雪崩等常见问题时的解决方案,最后还重点讲解了如何保证缓存的一致性. 因为缓存对于高并发服务来说实在是太重要了,所以这篇文章我们还会继续一起学习下缓存相关的知识. 本地缓存 当我们遇到极端热点数据查询的时候,这个时候就要考虑本地缓存了.热点本地缓存主要部署

  • go zero微服务实战处理每秒上万次的下单请求

    目录 引言 处理热点数据 优化 限制 隔离 流量削峰 如何保证消息只被消费一次 代码实现 结束语 引言 在前几篇的文章中,我们花了很大的篇幅介绍如何利用缓存优化系统的读性能,究其原因在于我们的产品大多是一个读多写少的场景,尤其是在产品的初期,可能多数的用户只是过来查看商品,真正下单的用户非常少. 但随着业务的发展,我们就会遇到一些高并发写请求的场景,秒杀抢购就是最典型的高并发写场景.在秒杀抢购开始后用户就会疯狂的刷新页面让自己尽早的看到商品,所以秒杀场景同时也是高并发读场景.那么应对高并发读写场

  • go zero微服务实战系服务拆分

    目录 微服务概述 服务划分 BFF层 工程结构 代码初始化 结束语 微服务概述 微服务架构是一种架构风格,它将一个大的系统构建为多个微服务的集合,这些微服务是围绕业务功能构建的,服务关注单一的业务功能,这些服务具有以下特点: 高度可维护和可测试 松散的耦合 可独立部署 围绕业务功能进行构建 由不同的小团队进行维护 微服务架构能够快速.频繁.可靠地交付大型.复杂的应用程序,通过业务拆分实现服务组件化,使用组件进行组合从而快速开发系统. 服务划分 我们首先进行微服务的划分,在实际的项目开发中,我们通

  • 关于go-zero单体服务使用泛型简化注册Handler路由的问题

    目录 一.Golang环境安装及配置Go Module mac OS安装Go# linux 安装Go# Windows安装Go# MODULE配置 二.Goctl 安装 二.初始化go-zero 三.查看注册Handler路由流程greet.go 四.对注册Handler路由进行简化 项目文件的增加 引入泛型概念 验证一下新增api路由在internal\logic下新增一个customlogic.go文件 本文代码放在go-zero-monolithic-service-generics 一.

  • Go单体服务开发最佳实践总结

    目录 单体最佳实践的由来 单体示例 单体实现 API 定义 Download 服务定义 Upload 服务定义 问题来了 定义单体服务接口 生成单体服务 实现业务逻辑 单体开发的总结 项目地址 单体最佳实践的由来 对于很多初创公司来说,业务的早期我们更应该关注于业务价值的交付,并且此时用户体量也很小,QPS 也非常低,我们应该使用更简单的技术架构来加速业务价值的交付,此时单体的优势就体现出来了. 正如我直播分享时经常提到,我们在使用单体快速交付业务价值的同时,也需要为业务的发展预留可能性,我们可

  • Go语言从单体服务到微服务设计方案详解

    目录 概述 业务场景 设计方案 Api网关 数据 Go中的Grpc使用 问题和反思 概述 微服务是一种思想,与编程语言无关,编程语言是思想下具体的一种实现方式,怎么设计架构方案和实现主要看主要面临的业务场景. 业务场景 主站核心业务使用的是yaf(php)开发的,要实现k8s + x编程语言 自主微服务实现,受到陈皓(左耳听风)的影响,我选用的编程语言是Go,Go语言有更强大的生态,有谷歌,k8s作为强大的后盾,摸着石头过河. 设计方案 Api网关 提到微服务我们就联想到Rpc,主流微服务价格设

  • 详解go-micro微服务consul配置及注册中心

    目录 一 Consul介绍 1. 注册中心Consul基本介绍 2.注册中心Consul关键功能 3.注册中心Consul两个重要协议 二 Consul安装 1.使用docker拉取镜像 三 Config配置 四 Consul代码编写 1.设置consul配置中心 2.获取consul配置中心的数据 3.consul可视化界面数据编写 4. main.go代码编写 五 最后 一 Consul介绍 Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置. Consu

  • Java从单体架构升级到微服务要注意的一些问题

    前言 由于近年来的移动端的发展和 2C模式 的红利,一些在风口的企业的业务得到爆发式增长.从架构层面来说,业务驱动技术的变革,所以微服务架构的概念得到很多企业的青睐,因为可以解决服务的大流量和高并发以及稳定性的要求. 但是任何架构设计不是一蹴而就的,不能从起步就开始使用微服务,一般都是先通过单体架构来快速实现需求和抢占市场,然后再迭代式扩展.不能一口气吃个胖子. 这几年自己有经历从单体到微服务的架构演变,也有直接参与到已经落地的微服务架构的项目中.见过好的架构设计,也见过一些孬的设计.好的架构设

  • Android Service服务详细介绍及使用总结

    Android Service服务详解 一.Service简介 Service是android 系统中的四大组件之一(Activity.Service.BroadcastReceiver. ContentProvider),它跟Activity的级别差不多,但不能页面显示只能后台运行,并且可以和其他组件进行交互.service可以在很多场合的应用中使用,比如播放多媒体的时候用户启动了其他Activity这个时候程序要在后台继续播放,比如检测SD卡上文件的变化,再或者在后台记录你地理信息位置的改变

  • 浅谈Spring Cloud下微服务权限方案

    背景 从传统的单体应用转型Spring Cloud的朋友都在问我,Spring Cloud下的微服务权限怎么管?怎么设计比较合理?从大层面讲叫服务权限,往小处拆分,分别为三块:用户认证.用户权限.服务校验. 用户认证 传统的单体应用可能习惯了session的存在,而到了Spring cloud的微服务化后,session虽然可以采取分布式会话来解决,但终究不是上上策.开始有人推行Spring Cloud Security结合很好的OAuth2,后面为了优化OAuth 2中Access Token

  • 浅谈服务发现和负载均衡的来龙去脉

    问题缘由 随着时代发展,单机程序遇到了计算力和存储的双重瓶颈,分布式架构应运而生.单体应用通过函数名(标识)便可轻松完成本地函数调用,在分布式系统中,服务(RPC/RESTful API)承担了类似的角色,但请求服务单靠服务名还不够,服务名只是服务能力(服务类型)的标识,还需要指示服务位于网络何处,而部署在云中的服务实例IP是动态分配的,扩缩容.失败和更新则让问题变得更加复杂,静态配置服务实例适应不了新变化,需要更精细化的服务治理能力,为了解决或者说简化这个问题,服务发现作为一种基础能力被抽象和

  • 微服务全景架构全面瓦解

    目录 1 微服务优势与挑战 1.1 微服务的优势 1.1.1 单一职责 1.1.2 轻量级通信 1.1.3 独立性 1.1.4 进程隔离 1.1.5 混合技术栈和混合部署方式 1.1.6 简化治理 1.1.7 安全可靠,可维护. 1.2 面临的挑战 1.2.1 分布式固有复杂性 1.2.2 服务的依赖管理和测试 1.2.3 有效的配置版本管理 1.2.4 自动化的部署流程 1.2.5 对于DevOps更高的要求 1.2.6 运维成本 2 微服务全景架构 3 微服务核心组件 3.1 服务注册与发现

  • 详解微服务架构及其演进史

    目录 1 传统单体系统介绍 1.1 单体系统的问题 1.2 单体系统的优点 1.3 单体服务到微服务的发展过程 2 关于微服务 2.1 单一职责 2.2 轻量级通信 2.3 独立性 2.4 进程隔离 2.5 混合技术栈和混合部署方式 2.6 简化治理 2.7 安全可靠,可维护. 3 微服务演进史 3.1 第一阶:简单服务通信模块 3.2 第二阶:原始通信时代 3.3 第三阶:TCP时代 3.4 第四阶:第一代微服务(Spring Cloud/RPC) 3.5 第五阶:第二代微服务 3.6 第六阶

随机推荐