jupyter运行时in[*]是什么原因_gochassis运行时做了什么？

什么是 chassis?

Chassis&＃xff0c;是一种微服务模式。在这种模式中&＃xff0c;用户并不需要自己去处理构建微服务过程中外部配置、日志、健康检查、分布式追踪等&＃xff0c;而是将他们交给专门的框架来处理。用户可以更聚焦业务逻辑本身&＃xff0c;简单、快速的开发微服务。

阅读此文&＃xff0c;你可以得到什么&＃xff1f;

1.chassis 运行时做了什么2.chassis 运行时的隐藏操作。3.chassis 设计思路的一些理解

Go-Chassis 是什么&＃xff1f;

Go-Chassis 是一个go语言的微服务开发框架&＃xff0c;采用插件化设计&＃xff0c;原生提供了可插拔的注册发现&＃xff0c;加密解密&＃xff0c;调用链追踪等组件。协议也是插件化的&＃xff0c;支持http和grpc&＃xff0c;也支持开发者定制私有协议&＃xff0c; 开发者只需要专注于实现云原生应用即可。

云原生应用&＃xff0c;基于云服务开发或者针对云服务开发部署的应用。

上图是go-chassis 的架构图&＃xff0c;可以看出配置管理(Archaius)、服务注册(Registry)、Metrics、日志(Logger)都是独立的组件&＃xff0c;分布式追踪、负载均衡、限流等都是以中间件(Handler Chain)的方式实现的。一个请求进来后会先通过server 转换成chassis invoker&＃xff0c;然后经过Handler Chain&＃xff0c;最后由Transport 转换成对应协议的response返回。

此篇文章主要关注go-chassis 启动过程时做了什么&＃xff0c;以及做这些事情的用途。

一个例子

首先从 hello world 开始&＃xff0c; 目录结构如下&＃xff1a;

. ├── conf # 配置目录&＃xff0c;必须 │ ├── chassis.yaml # │ ├── microservice.yaml # 微服务相关配置&＃xff0c;比如server name&＃xff0c;注册中心地址 └── rest └── main.go

chassis.yaml 内容为&＃xff1a;

--- cse: protocols: rest: listenAddress: "127.0.0.1:5001" transport: timeout: rest: 1 handler: chain: Provider: default: tracing-provider

microservice.yaml 内容为&＃xff1a;

cse: service: registry: address: http://127.0.0.1:30100 service_description: name: test-rest-server

main.go

package mainimport ( rf "github.com/go-chassis/go-chassis/v2/server/restful" "log" "net/http" "github.com/go-chassis/go-chassis/v2" )//RestFulHello is a struct used for implementation of restfull hello programtype RestFulHello struct {}//Sayhi is a method used to reply user with hello world textfunc (r *RestFulHello) Sayhi(b *rf.Context) { b.Write([]byte( "hello world")) return}//URLPatterns helps to respond for corresponding API callsfunc (r *RestFulHello) URLPatterns() []rf.Route { return []rf.Route{ {Method: http.MethodGet, Path: "/sayhi", ResourceFunc: r.Sayhi, Returns: []*rf.Returns{{Code: 200}}}, }}func main() { chassis.RegisterSchema("rest", &RestFulHello{}) if err :&＃61; chassis.Init(); err !&＃61; nil { log.Fatal("Init failed." &＃43; err.Error()) return } chassis.Run()}

先来看一下这段代码具体做了什么。

•11~27 声明了 一个 RestFulHello struct&＃xff0c;这个struct 有两个方法 Sayhi 和 URLPatterns&＃xff0c;其中URLPatterns 返回一个 Route 列表。这段代码声明了一个http handler 和 对应的路由&＃xff0c;那具体为什么这么写等下再做说明。

type Schema struct { serverName string schema interface{} opts []server.RegisterOption}

•

30行 chassis.RegisterSchema("rest", &RestFulHello{}) 将前面声明的 RestFulHello 注册到 "rest" 服务。

这里内部只是简单的使用传入的参数创建一个 chassis.Schema 然后append到 chassis.schemas 中。

•

31行 chassis运行前的初始化工作。

•

35行 运行chassis 服务。

执行 go run rest/main.go 运行代码&＃xff0c;会发现启动失败&＃xff0c;日志输出内容为&＃xff1a;

INFO: Install client plugin, protocol: rest INFO: Install Provider Plugin, name: default INFO: Installed Server Plugin, protocol:rest ERROR: add file source error [[/var/folders/rr/rzqnl9h10y577rch1nsx_jww0000gp/T/go-build725280265/b001/exe/conf/chassis.yaml] file not exist]. file:go-chassis&＃64;v1.8.3/chassis_init.go:106,msg:failed to initialize conf: [/var/folders/rr/rzqnl9h10y577rch1nsx_jww0000gp/T/go-build725280265/b001/exe/conf/chassis.yaml] file not exist init chassis fail: [/var/folders/rr/rzqnl9h10y577rch1nsx_jww0000gp/T/go-build725280265/b001/exe/conf/chassis.yaml] file not exist Init failed.[/var/folders/rr/rzqnl9h10y577rch1nsx_jww0000gp/T/go-build725280265/b001/exe/conf/chassis.yaml] file not exist

通过日志可以看到两个问题&＃xff1a;

1.为什么添加了配置还会提示配置找不到&＃xff1f;2.为什么配置没有加载成功插件却可以安装成功&＃xff1f;

chassis init

下图是chassis init 的执行流程&＃xff1a;

公号内输入 【chassis_init】 获取原图

配置初始化

首先看一下chassis 初始化的过程中配置是如何加载的。

查看 config.Init() 代码可以看到 配置目录是通过 fileutil.RouterConfigPath() 来获取的&＃xff0c;目录初始化方法为&＃xff1a;

func initDir() { if h :&＃61; os.Getenv(ChassisHome); h !&＃61; "" { homeDir &＃61; h } else { wd, err :&＃61; GetWorkDir() if err !&＃61; nil { panic(err) } homeDir &＃61; wd } // set conf dir, CHASSIS_CONF_DIR has highest priority if confDir :&＃61; os.Getenv(ChassisConfDir); confDir !&＃61; "" { configDir &＃61; confDir } else { // CHASSIS_HOME has second most high priority configDir &＃61; filepath.Join(homeDir, "conf") } }

如果使用 ChassisHome 环境变量指定应用目录&＃xff0c;chassis 运行时&＃xff0c;会从该目录下的 ChassisHome/conf/ 目录中读取配置

也可以使用 ChassisConfDir 直接指定配置目录&＃xff0c;ChassisConfDir 优先级高于 ChassisHome/conf

chassis 使用 archaius 来管理配置&＃xff0c;archaius 初始化时&＃xff0c;会从文件、环境变量、命令行、内存中初始化配置。

// InitArchaius initialize the archaius func InitArchaius() error { var err error requiredFiles :&＃61; []string{ fileutil.GlobalConfigPath(), fileutil.MicroServiceConfigPath(), } optionalFiles :&＃61; []string{ fileutil.CircuitBreakerConfigPath(), fileutil.LoadBalancingConfigPath(), fileutil.RateLimitingFile(), fileutil.TLSConfigPath(), fileutil.MonitoringConfigPath(), fileutil.AuthConfigPath(), fileutil.TracingPath(), fileutil.LogConfigPath(), fileutil.RouterConfigPath(), } err &＃61; archaius.Init( // 初始化配置 archaius.WithCommandLineSource(), archaius.WithMemorySource(), archaius.WithENVSource(), archaius.WithRequiredFiles(requiredFiles), archaius.WithOptionalFiles(optionalFiles)) return err

从代码可以看出&＃xff0c;global config 和 microservice config 是必须要有的&＃xff0c;

global config 对应 conf_path/chassis.yaml

microservice config 对应 conf_path/microservice.yaml

接下来读出配置后&＃xff0c;给初始化runtime 的值&＃xff1a;

runtime 中的数据可以认为是运行时的全局变量

... // runtime 中的数据可以认为是运行时的全局变量 runtime.ServiceName &＃61; MicroserviceDefinition.ServiceDescription.Name runtime.Version &＃61; MicroserviceDefinition.ServiceDescription.Version runtime.Environment &＃61; MicroserviceDefinition.ServiceDescription.Environment runtime.MD &＃61; MicroserviceDefinition.ServiceDescription.Properties if MicroserviceDefinition.AppID !&＃61; "" { //microservice.yaml has first priority runtime.App &＃61; MicroserviceDefinition.AppID } else if GlobalDefinition.AppID !&＃61; "" { //chassis.yaml has second priority runtime.App &＃61; GlobalDefinition.AppID } if runtime.App &＃61;&＃61; "" { runtime.App &＃61; common.DefaultApp } runtime.HostName &＃61; MicroserviceDefinition.ServiceDescription.Hostname ...

archaius 也支持从配置中心读取配置&＃xff0c;通过这种方式&＃xff0c;chassis 也提供了运行时配置热加载的功能。

对于第二个问题&＃xff0c;为什么插件会先于配置安装&＃xff1f;

插件初始化

从图中可以看出init 做了预先初始化了很多的插件&＃xff0c;比如 client、provider、server、log、router rule、register、load balance、service discover、treporter等&＃xff0c;并且chassis init 方法中并没有做显式的初始化调用。通过查看代码会发现&＃xff0c;这个步骤是使用各自的init 方法自动执行的&＃xff0c;类似这样&＃xff1a;

// restful serverfunc init() { server.InstallPlugin(Name, newRestfulServer)}// route rule pluginfunc init() { router.InstallRouterService("cse", newRouter)}// init initialize the plugin of service center registryfunc init() { registry.InstallRegistrator(ServiceCenter, NewRegistrator) registry.InstallServiceDiscovery(ServiceCenter, NewServiceDiscovery) registry.InstallContractDiscovery(ServiceCenter, newContractDiscovery)}// init install plugin of new file registryfunc init() { registry.InstallRegistrator(Name, newFileRegistry) registry.InstallServiceDiscovery(Name, newDiscovery)}

之所以隐式加载是因为 chassis 是插件式设计&＃xff0c;使用 init 方式加载插件&＃xff0c;可以做到对插件的即插即用&＃xff0c;需要使用的插件只需要在代码中添加包的import 即可&＃xff0c;比如加载grpc 插件&＃xff0c;只需要在main.go 中添加

import _ "github.com/go-chassis/go-chassis-extension/protocol/grpc/server"

从这一系列插件安装方式也能看出&＃xff0c;对于chassis 来说&＃xff0c;注册中心&＃xff0c;协议&＃xff0c;负载均衡等都是插件&＃xff0c;这也就意味着这些插件都是可替换的&＃xff0c;方便二次开发。

以上两个问题现在都解决了&＃xff0c;现在执行以下命令运行服务&＃xff1a;

CHASSIS_CONF_DIR&＃61;&＃96;pwd&＃96;/conf go run rest/main.go

初始化handler chain

Handler是微服务在运行过程中在框架层面里的一个最小处理单元。go chassis通过handler和handler的组装实现组件化的运行模型架构。其基本的使用方式就是实现接口、注册逻辑&＃xff1a;

Handler 定义非常简单&＃xff0c;实现了Handler 接口就可以认为创建了一个Handler。

// Handler interface for handlerstype Handler interface { // handle invocation transportation,and tr response Handle(*Chain, *invocation.Invocation, invocation.ResponseCallBack) Name() string}

使用RegisterHandler 函数将添加到HandlerFuncMap 中即可在CreateHandler 调用时使用。

// RegisterHandler Let developer custom handlerfunc RegisterHandler(name string, f func() Handler) error { if stringutil.StringInSlice(name, buildIn) { return errViolateBuildIn } _, ok :&＃61; HandlerFuncMap[name] if ok { return ErrDuplicatedHandler } HandlerFuncMap[name] &＃61; f return nil}

对于chassis 来说&＃xff0c;协议转换&＃xff0c;权限验证&＃xff0c;全链路追踪等都可以认为是一个handler(中间件)&＃xff0c;这里会从配置中读取声明的handler&＃xff0c;并且初始化。请求调用时&＃xff0c;会按照配置文件中的定义的顺序进入handler进行处理。

在服务初始化的过程中&＃xff0c;go-chassis 会根据配置文件中的定义加载需要的handler&＃xff0c;handler 分为provider、consumer和 default 三种&＃xff0c;配置内容示例如下&＃xff1a;

handler: chain: Provider: default: tracing-provider rest: jwt

如果配置了非default 的type&＃xff0c;服务启动的时候只会执行此特定的handler&＃xff0c;比如上述配置&＃xff0c;handler 只会执行 jwt&＃xff0c;而忽略tracing-provider

这是因为chassis 使用map存储 handler chain&＃xff0c;map 的key 为 chainType&＃43;chainName&＃xff0c; default 也是一种chainType&＃xff0c;如果name(即chain type)有值则使用对应的 chain&＃xff0c;否则使用default。

type Chain struct { ServiceType string Name string Handlers []Handler}// GetChain is to get chainfunc GetChain(serviceType string, name string) (*Chain, error) { if name &＃61;&＃61; "" { name &＃61; common.DefaultChainName } origin, ok :&＃61; ChainMap[serviceType&＃43;name] if !ok { return nil, fmt.Errorf("get chain [%s] failed", serviceType&＃43;name) } return origin, nil}// chainMap :&＃61; chaninMap[strint]*Chain{ "Provider&＃43;rest": &Chain{ ServiceType: "Provider", Name: "rest", Handlers: []Handler{jwt},}, "Provider&＃43;default": &Chain{ ServiceType: "Provider", Name: "default", Handlers: []Handler{tracing-provider}},,}

初始化 server

初始化的前提是服务已经加载&＃xff0c;加载的步骤在init 之前就已经通过 init 方法载入了。

//Init initializesfunc Init() error { var err error for k, v :&＃61; range config.GlobalDefinition.Cse.Protocols { if err &＃61; initialServer(config.GlobalDefinition.Cse.Handler.Chain.Provider, v, k); err !&＃61; nil { log.Println(err) return err } } return nil}

这里初始化的是配置文件中 protocols 指定的服务。

//获取服务的方法func GetServerFunc(protocol string) (NewFunc, error) { f, ok :&＃61; serverPlugins[protocol] if !ok { return nil, fmt.Errorf("unknown protocol server [%s]", protocol) } return f, nil}

这里会从 *var* serverPlugins &＃61; make(*map*[string]NewFunc) 读取server&＃xff0c;所以在初始化时需要先安装server 对应的插件

chassis 会 默认安装rest 插件&＃xff0c;对于grpc 需要首先指定

// p 对应 protocal 中的配置if p.Listen &＃61;&＃61; "" { if p.Advertise !&＃61; "" { p.Listen &＃61; p.Advertise } else { p.Listen &＃61; iputil.DefaultEndpoint4Protocol(name) } }

服务的Listen Advertise 优先级最高&＃xff0c;如果 Advertise 和 Listen 都没有配置&＃xff0c;使用默认配置。

初始化 server options&＃xff0c;其中chainName 如果Provider 配置了对应 protocol name 的值&＃xff0c;则使用protocol name。

chainName :&＃61; common.DefaultChainName if _, ok :&＃61; providerMap[name]; ok { chainName &＃61; name }o :&＃61; Options{ Address: p.Listen, // 配置中监听的端口 ProtocolServerName: name, // protocal provider 中的名字&＃xff0c;比如 rest grpc ChainName: chainName, // protocal provider 中的名字&＃xff0c;比如 rest grpc TLSConfig: tlsConfig, BodyLimit: config.GlobalDefinition.Cse.Transport.MaxBodyBytes["rest"], }

其它

几个初始化外&＃xff0c;init 还包括 register、configcenter、router、contorl、tracing、metric、reporter、熔断器、事件监听等就不再细说了。

为止&＃xff0c;chassis 所需要的初始化步骤已经结束&＃xff0c;接下来就是 服务运行的步骤。

chassis run

首先看一下 chassis.Run() 启动的整体流程

公号内输入 【chassis_run】 获取原图

chassis 运行主要分为三个动作&＃xff1a;

1.根据schema 找到服务&＃xff0c;将对应的handle func 使用 handler chain 封装2.启动服务&＃xff0c;将服务注册到服务中心3.监听退出信号

这里使用rest 服务作为例子看一下 chassis 启动服务的时候做了哪些操作。

服务注册

首先回顾一下hello world 代码&＃xff1a;

//RestFulHello is a struct used for implementation of restfull hello programtype RestFulHello struct {}//Sayhi is a method used to reply user with hello world textfunc (r *RestFulHello) Sayhi(b *rf.Context) { b.Write([]byte( "hello world")) return}//URLPatterns helps to respond for corresponding API callsfunc (r *RestFulHello) URLPatterns() []rf.Route { return []rf.Route{ {Method: http.MethodGet, Path: "/sayhi", ResourceFunc: r.Sayhi, Returns: []*rf.Returns{{Code: 200}}}, }}chassis.RegisterSchema("rest", &RestFulHello{}) // 第一个参数即是服务名&＃xff0c;第二个参数是 Router

RestFulHello &＃xff0c;其中有一个 URLPatterns() []Route 方法&＃xff0c;实现了 Router 接口。

Router 定义

//Router is to define how route the requesttype Router interface { //URLPatterns returns route URLPatterns() []Route}

// HTTPRequest2Invocation convert http request to uniform invocation data formatfunc HTTPRequest2Invocation(req *restful.Request, schema, operation string, resp *restful.Response) (*invocation.Invocation, error) { inv :&＃61; &invocation.Invocation{ MicroServiceName: runtime.ServiceName, SourceMicroService: common.GetXCSEContext(common.HeaderSourceName, req.Request), Args: req, Reply: resp, Protocol: common.ProtocolRest, SchemaID: schema, OperationID: operation, URLPathFormat: req.Request.URL.Path, Metadata: map[string]interface{}{ common.RestMethod: req.Request.Method, }, } //set headers to Ctx, then user do not need to consider about protocol in handlers m :&＃61; make(map[string]string) inv.Ctx &＃61; context.WithValue(context.Background(), common.ContextHeaderKey{}, m) for k :&＃61; range req.Request.Header { m[k] &＃61; req.Request.Header.Get(k) } return inv, nil}

启动的服务注册流程中包含了将schemas 中所有Router 取出遍历&＃xff0c;调用 WrapHandlerChain() 函数&＃xff0c;这个函数主要做了以下工作&＃xff1a;

1.取出 Route 中 ResourceFunc (即real handler func)2.将 HttpRequest 转换成 chassis Invocation&＃xff0c;3.将Invocation 再添加回 request 中添加到 handler chain 中4.返回一个闭包函数。

最后会把使用 WrapHandlerChain 封装后的handler 注册到go-restful 框架中。

响应请求时&＃xff0c;调用关系类似以下操作:

func handle(){ func handle1(){ func handle2(){ func handle3(){ real_handle_func() }() }() }()}

为什么需要转换成统一的invocation&＃xff1f;

不同协议请求进入到对应的Server&＃xff0c;Server将具体的协议请求转换为Invocation统一抽象模型&＃xff0c;并传入Handler chain&＃xff0c;由于handler根据统一模型Invocation进行处理&＃xff0c;不必每个协议开发出来都自己开发一套治理。处理链可通过配置更新&＃xff0c;再进入Transport handler&＃xff0c;使用目标微服务的协议客户端传输到目标。

这种方式实际上真正提供业务处理的还是各个server 插件&＃xff0c;chassis 只是中间商&＃xff0c;可以对request 和 response 做它想要的处理&＃xff0c;比如限流&＃xff0c;熔断&＃xff0c;路由更新等。

1.接收到协议请求后&＃xff0c;由各协议Server转为统一的Invocation模型2.Invocation进入处理链处理3.处理结束后&＃xff0c;进入具体的业务处理逻辑

信号监听

当服务需要关闭或重启时&＃xff0c;应当处理完当前的请求或者设置为超时&＃xff0c;而不是粗暴的断开链接&＃xff0c;chassis 这里使用了信号监听的方式来处理关闭信号。

func waitingSignal() { //Graceful shutdown c :&＃61; make(chan os.Signal) // 创建一个os.Signal channel // 注册要接收的信号 signal.Notify(c, syscall.SIGINT, syscall.SIGHUP, syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGILL, syscall.SIGTRAP, syscall.SIGABRT) select { case s :&＃61; openlogging.Info("got os signal " &＃43; s.String()) case err :&＃61; openlogging.Info("got server error " &＃43; err.Error()) } // 判断服务是否有注册 if !config.GetRegistratorDisable() { registry.HBService.Stop()// 停掉心跳服务 openlogging.Info("unregister servers ...") // 从server center 中退出 if err :&＃61; server.UnRegistrySelfInstances(); err !&＃61; nil { openlogging.GetLogger().Warnf("servers failed to unregister: %s", err) } } for name, s :&＃61; range server.GetServers() { // 遍历服务&＃xff0c;调用服务的 stop 方法 openlogging.Info("stopping server " &＃43; name &＃43; "...") err :&＃61; s.Stop() if err !&＃61; nil { openlogging.GetLogger().Warnf("servers failed to stop: %s", err) } openlogging.Info(name &＃43; " server stop success") } openlogging.Info("go chassis server gracefully shutdown")}

这里使用go信号通知机制通过往一个channel中发送os.Signal实现的。创建一个os.Signal channel&＃xff0c;然后使用signal.Notify注册要接收的信号&＃xff0c;chassis 关注以下信号&＃xff1a;

接收到信号后&＃xff0c;首先判断是否注册到服务中心&＃xff0c;如果注册&＃xff0c;停掉心跳发送&＃xff0c;退出注册&＃xff0c;然后调用 server.Shutdown() 来优雅退出。

go http Server 从1.8 之后支持优雅退出。

具体实现可以参考此文章&＃xff1a;http://xiaorui.cc/archives/5803

总结

这篇文章介绍了 chassis 服务启动的过程&＃xff0c;主要介绍了init 中 配置 、插件、handler chain 、server 的初始化流程&＃xff0c;然后分析了服务启动时做了哪些操作以及对服务退出的处理。

参考链接

1.使用ServiceComb Go-chassis构建微服务^[1]2.Pattern: Microservice chassis^[2]3.Linux Signal及Golang中的信号处理^[3]4.源码分析golang http shutdown优雅退出的原理^[4]5.Go语言微服务开发框架实践-go chassis^[5]

References

[1] 使用ServiceComb Go-chassis构建微服务: https://www.infoq.cn/article/ServiceComb-Go-chassis-micro-service[2] Pattern: Microservice chassis: http://microservices.io/patterns/microservice-chassis.html[3] Linux Signal及Golang中的信号处理: https://colobu.com/2015/10/09/Linux-Signals/[4] 源码分析golang http shutdown优雅退出的原理: http://xiaorui.cc/archives/5803[5] Go语言微服务开发框架实践-go chassis: https://juejin.im/post/6844903682362834952

最后&＃xff0c;感谢女朋友支持和包容&＃xff0c;比❤️

也可以在公号输入以下关键字获取历史文章&＃xff1a;公号&小程序 | 设计模式 | 并发&协程