go-micro开发RPC服务以及运行原理介绍

go-micro是一个知名的golang微服务框架,最新版本是v4,这篇文章将介绍go-micro v4开发RPC服务的方法及其运作原理。

基本概念

go-micro有几个重要的概念,后边开发RPC服务和介绍其运行原理的时候会用到,这里先熟悉下:

  • Service:代表一个go-micro应用程序,Service中包括:Server、Client、Broker、Transport、Registry、Config、Store、Cache等程序运行所需的各个模块。
  • Server:代表一个go-micro服务器,主要函数包括:Start、Stop、Handle、Subscribe。默认创建的Server是 rpcServer。
  • Broker:用于处理异步消息,主要的函数包括:Connect、Publish、Subscribe。默认的Broker是httpBroker。
  • Router:用于消息处理的路由,内部包括两种路由方式:RPC服务映射serviceMap和消息订阅器subscribers。
  • Codec:用于消息的编解码,主要函数包括:Marshal、Unmarshal默认的Codec是json.Marshaler,是基于jsonpb的。RPC服务是根据请求头中的Content-Type自动创建的。
  • Registry:用于服务发现,主要函数包括:Register、Deregister、GetService、ListServices、Watch。默认的Registry是mdns。
  • Selector: 用于从同一个服务的多个实例之中选择一个,支持缓存,有随机和轮询两种策略。
  • Transport:用于同步通信,主要函数包括:Dial、Listen。它的底层基于Socket的send、recv语义,有多种实现,包括http、grpc、quic等。默认的Transport是httpTransport。

开发RPC服务

RPC全称是Remote Procedure Call,翻译过来是就是:远程过程调用,中心思想是:像调用本地函数一样调用远程函数。常见的Dubbo、Spring Cloud都可以称为RPC框架,还有最近很流行的gRPC。

使用go-micro创建一个RPC服务很简单,共分三步走:

1、编写proto协议文件

这个服务提供的功能很简单,名字为Hello,提供一个方法名字为Say,需要传入一个字符串Name,然后返回一个字符串Message。这个文件我命名为 hello.proto,放到了项目中的 proto 文件夹中。

syntax = "proto3";

option go_package="/proto";

package Business;

service Hello {
  rpc Say (SayRequest) returns (SayResponse);
}

message SayResponse {
  string Message = 1;
}

message SayRequest {
  string Name = 1;
}

2、生成go-micro服务端代理

需要首先安装protoc和两个代码生成插件。

protoc下载地址:https://github.com/protocolbuffers/protobuf/releases,保存到GO PATH/bin目录中。同时建议将 GOPATH/bin 添加到环境变量 PATH 中,方便直接执行相关命令。

两个插件直接通过命令即可安装:

go install google.golang.org/protobuf/cmd/protoc-gen-go
go install go-micro.dev/v4/cmd/protoc-gen-micro@v4

然后在项目的目录下执行命令:

protoc --go_out=. --go_opt=paths=source_relative --micro_out=. --micro_opt=paths=source_relative proto/hello.proto

然后会在proto文件夹中生成两个文件:hello.pb.go 和 hello.pb.micro.go 。

下个步骤中就要使用它们来创建RPC服务。

3、编写go-micro服务

这里先把代码贴出来,然后再做一个简要说明:

package main

import (
	"context"
	"fmt"
	"log"
	"rpchello/proto"

	"go-micro.dev/v4"
	"go-micro.dev/v4/server"
)

type Hello struct{}

func (s *Hello) Say(ctx context.Context, req *proto.SayRequest, rsp *proto.SayResponse) error {
	fmt.Println("request:", req.Name)
	rsp.Message = "Hello " + req.Name
	return nil
}

func main() {
	rpcServer := server.NewServer(
		server.Name("rpchello.service"),
		server.Address("0.0.0.0:8001"),
	)

	proto.RegisterHelloHandler(rpcServer, &Hello{})

	service := micro.NewService(
		micro.Server(rpcServer),
	)

	if err := service.Run(); err != nil {
		log.Fatal(err)
	}
}

上边我们创建了一个 Hello 类型,然后给它绑定了一个名为Say的函数。这个是和proto协议对应的,其实是实现了生成代码 hello.pb.micro.go 中的HelloHandler接口:

type HelloHandler interface {
	Say(context.Context, *SayRequest, *SayResponse) error
}

然后main函数中是我们的重头戏:先创建一个Server,默认情况下就是rpc Server,设置它的名字、监听地址等参数;然后创建一个Service,并绑定刚刚创建的Server;然后使用生成的服务端代理函数将我们编写的Hello服务注册到Server中;最后开启运行Service。

当然只有一个服务端没有什么意义,还得有客户端来访问它。这里也给一个例子:

package main

import (
	"bufio"
	"context"
	"fmt"
	"os"
	"rpchello/proto"

	"go-micro.dev/v4"
	"go-micro.dev/v4/client"
)

func main() {

	service := micro.NewService(
		micro.Client(client.NewClient()),
	)

	service.Init()
	client := proto.NewHelloService("rpchello.service", service.Client())

	rsp, err := client.Say(context.TODO(), &proto.SayRequest{Name: "BOSSMA"})
	if err != nil {
		fmt.Println(err)
	}

	fmt.Println(rsp)

	fmt.Println("Press Enter key to exit the program...")
	in := bufio.NewReader(os.Stdin)
	_, _, _ = in.ReadLine()
}

这里调用服务的时候没有指定服务的地址和端口,因为内部走了服务发现,服务端会自动注册服务,客户端会根据服务名称查找到对应的地址和端口。默认的服务发现机制使用的是mdns。

RPC服务的运行原理

这里从服务端的角度进行介绍,先来看一张图:

请大家参考代码从上往下看。

NewServer 时创建一个rpcServer,这个rpcServer还会创建一个httpTransport用于程序间网络通信,并绑定到当前rpcServer。

RegisterXXXHandler 时使用我们编写的Handler创建一个内部的service实例,然后注册这个service实例到rpcServer内部的router中,客户端请求时会用到它。这里其实可以注册任意一个带方法的类型,并不一定要定义proto协议,定义它只是为了协作更方便。

Service.Run 时会调用rpcServer的Start方法,这个方法内部会调用其绑定的httpTransport的Listen方法,然后在其创建的Listener上接收客户端连接,接收方法Accept传入了当前rpcServer的连接处理方法:rpcServer.ServeConn,有连接到来时会调用它。

当客户端请求来临时,客户端连接被交给rpcServer的ServeConn方法,然后又调用到HandleEvent方法。

然后进入rpcServer内部的router的函数ServeRequest中,通过分析请求消息,找到请求的服务名字和方法名字,在router中找到前面注册过的service,通过servcie.call,再进入function.call,最终通过反射调用到我们编写的Handler的业务方法。

有的同学可能会想,反射不是性能很低吗?!反射性能低主要是查找方法和字段的时候,调用方法的性能并不低,而查找方法和字段等的操作已经在RegisterXXXHandler的步骤中做了,并且缓存到了router中,所以性能并不受影响。

到此这篇关于go-micro开发RPC服务的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • go-micro使用Consul做服务发现的方法和原理解析

    目录 安装Consul 安装Consul插件 服务端使用Consul 服务注册 注册过程 健康检查 客户端使用Consul 调用服务 发现过程 效果展示 go-micro v4默认使用mdns做服务发现.不过也支持采用其它的服务发现中间件,因为多年来一直使用Consul做服务发现,为了方便和其它服务集成,所以还是选择了Consul.这篇文章将介绍go-micro使用Consul做服务发现的方法.关于Consul的使用方式请参考我的另一篇文章:搭建Consul服务发现与服务网格 . 安装Consu

  • go micro集成链路跟踪的方法和中间件原理解析

    目录 链路跟踪实战 安装zipkin 程序结构 安装依赖包 编写服务端 编写客户端 Wrap原理分析 服务端Wrap HandlerWrapper Wrap Handler 客户端Wrap XXXWrapper Wrap Client 客户端Wrap和服务端Wrap的区别 Http服务的链路跟踪 前几天有个同学想了解下如何在go-micro中做链路跟踪,这几天正好看到wrapper这块,wrapper这个东西在某些框架中也称为中间件,里边有个opentracing的插件,正好用来做链路追踪.op

  • go-micro集成RabbitMQ实战和原理详解

    目录 Broker的核心功能 发布 订阅 go-micro集成RabbitMQ实战 启动一个RabbitMQ 编写收发函数 编写主体代码 go-micro集成RabbitMQ的处理流程 填的几个坑 不能接收其它框架发布的消息 RabbitMQ重启后订阅者和发布者无限阻塞 在go-micro中异步消息的收发是通过Broker这个组件来完成的,底层实现有RabbitMQ.Kafka.Redis等等很多种方式,这篇文章主要介绍go-micro使用RabbitMQ收发数据的方法和原理. Broker的核

  • 关于go-micro与其它gRPC框架之间的通信问题及解决方法

    目录 客户端改造 服务端改造 运行效果 在之前的文章中分别介绍了使用gRPC官方插件和go-micro插件开发gRPC应用程序的方式,都能正常走通.不过当两者混合使用的时候,互相访问就成了问题.比如使用go-micro插件生成的gRPC客户端访问基于gRPC官方插件创建的服务端时就会出现如下错误: {"id":"go.micro.client","code":501,"status":"Not Implemented

  • go-micro开发RPC服务以及运行原理介绍

    go-micro是一个知名的golang微服务框架,最新版本是v4,这篇文章将介绍go-micro v4开发RPC服务的方法及其运作原理. 基本概念 go-micro有几个重要的概念,后边开发RPC服务和介绍其运行原理的时候会用到,这里先熟悉下: Service:代表一个go-micro应用程序,Service中包括:Server.Client.Broker.Transport.Registry.Config.Store.Cache等程序运行所需的各个模块. Server:代表一个go-micr

  • java开发分布式服务框架Dubbo原理机制详解

    目录 前言 Dubbo框架有以下部件 Consumer Provider Registry Monitor Container 架构 高可用性 框架设计 服务暴露过程 服务消费过程 前言 在介绍Dubbo之前先了解一下基本概念: Dubbo是一个RPC框架,RPC,即Remote Procedure Call(远程过程调用),相对的就是本地过程调用,在分布式架构之前的单体应用架构和垂直应用架构运用的都是本地过程调用.它允许程序调用另外一个地址空间(通常是网络共享的另外一台机器)的过程或函数,并且

  • springcloud如何使用dubbo开发rpc服务及调用

    这篇文章主要介绍了springcloud如何使用dubbo开发rpc服务及调用,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 spring cloud中基于springboot开发的微服务,是基于http的rest接口,也可以开发基于dubbo的rpc接口. 一,创建goodsService模块 1, 在创建的goodsService模块中再创建goodsServiceApi和goodsServiceServer模块 2,在oodsServic

  • Golang开发gRPC服务入门介绍

    目录 1.安装protoc 2.安装protoc的Golang gRPC插件 3.编写proto文件 4.生成gRPC代理代码 5.编写gRPC服务端程序 6.编写gRPC客户端程序 7.运行程序 gRPC是Google发起的一个开源RPC框架,使用HTTP/2传输协议,使用Protocol Buffers编码协议,相比RESTful框架的程序性能提高不少,而且当前流行的编程语言基本都已经支持. Golang开发gRPC应用程序的套路也已经很清晰,这篇文章就来做一个简单的介绍,算是入门. 1.安

  • C#开发Windows服务实例之实现禁止QQ运行

    本实例主要实现下面三个基本功能 1.C#开发windows服务 2.禁止QQ等程序运行 3.为windows服务创建自动安装程序 下面针对这三个基本功能进行实现 一.C#开发windows服务 Windows服务在VS以前的版本中叫NT服务,在VS.NET启用了新的名称.用C#创建windows服务不是一件困难的事,下页针对服务创建.启动.停止做详细介绍 1.首先在vs中添加一winform程序KillService 2.在解决方案添加新项中添加Windows服务 3.打开服务页面,切换至代码页

  • 简单了解SpringCloud运行原理

    这篇文章主要介绍了简单了解SpringCloud运行原理,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 SpringCloud是基于SpringBoot这一高度自动化的应用开发框架,将各类业界比较知名的.得到过实践反馈的开元服务治理相关的技术框架进行优化整合的框架,是一种开发方式的优化和组合,,是一组框架的统称,基于SpringBoot的starter定制,实现开箱即用的目标,通过简单的声明式注解,就能实现服务的调用.负载均衡.限流.熔断等机制

  • React服务端渲染原理解析与实践

    关于服务端渲染也就是我们说的SSR大多数人都听过这个概念,很多同学或许在公司中已经做过服务端渲染的项目了,主流的单页面应用比如说Vue或者React开发的项目采用的一般都是客户端渲染的模式也就是我们说的CSR. 但是这种模式会带来明显的两个问题,第一个就是TTFP时间比较长,TTFP指的就是首屏展示时间,同时不具备SEO排名的条件,搜索引擎上排名不是很好.所以我们可以借助一些工具来进行改良我们的项目,将单页面应用编程服务器端渲染项目,这样就可以解决掉这些问题了. 目前主流的服务器端渲染框架也就是

  • Java中ExecutorService和ThreadPoolExecutor运行原理

    目录 为什么要使用线程池 线程池的创建 线程的提交方法 具体实现 总结1 ThreadPoolExecutor运行原理 总结2 为什么要使用线程池 服务器应用程序中经常出现的情况是:单个任务处理的时间很短而请求的数目却是巨大的. 构建服务器应用程序的一个过于简单的模型应该是:每当一个请求到达就创建一个新线程,然后在新线程中为请求服务.实际上,对于原型开发这种方法工作得很好,但如果试图部署以这种方式运行的服务器应用程序,那么这种方法的严重不足就很明显. 每个请求对应一个线程(thread-per-

  • java开发Dubbo注解Adaptive实现原理

    目录 前言 什么是@Adaptive 实现原理 getAdaptiveExtension getAdaptiveExtensionClass generate 前言 前面我们已经分析Dubbo SPI相关的源码,看过的小伙伴相信已经知晓整个加载过程,我们也留下两个问题,今天我们先来处理下其中关于注解Adaptive的原理. 什么是@Adaptive 对应于Adaptive机制,Dubbo提供了一个注解@Adaptive,该注解可以用于接口的某个子类上,也可以用于接口方法上. 如果用在接口的子类上

  • C++ 学习之旅 Windows程序内部运行原理

    学习C++与.net不同的是,一定要搞清楚Windows程序内部运行原理,因为他所涉及大多数是操作系统的调用,而.net毕竟是在.netFrameWork上唱戏. 那Windows应用程序,操作系统,计算机硬件之间的相互关系究竟什么了,下面的图就给予很好的解释. 向下箭头①是 应用程序运行判断处理的结果,输出到输出的设备. 向上箭头②是输入设备,输入到操作系统中. 向下箭头③代表API,我们要解释以下API是什么.API是应用程序接口, 表示应用程序可以通知操作系统执行某个具体的动作,如操作系统

随机推荐