Dubbo-go Server 端开启服务过程是怎样的

Dubbo-go Server 端开启服务过程是怎样的，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。下面将介绍 dubbo-go 框架的基本使用方法，以及从 export 调用链的角度进行 server 端源码导读。当拿到一款框架之后，一种不错的源码阅读方式大致如下：从运行最基础的 helloworld demo 源码开始 —> 再查看配置文件—>开启各种依赖服务（比如zk、consul）—>开启服务端—>再到通过 client 调用服务端—>打印完整请求日志和回包。调用成功之后，再根据框架的设计模型，从配置文件解析开始，自顶向下递阅读整个框架的调用栈。对于 C/S 模式的 rpc 请求来说，整个调用栈被拆成了 client 和 server 两部分，所以可以分别从 server 端的配置文件解析阅读到 server 端的监听启动，从 client 端的配置文件解析阅读到一次 invoker Call 调用。这样一次完整请求就明晰了起来。将仓库 clone 到本地$gitclonehttps://github.com/dubbogo/dubbo-samples.git进入 dubbo 目录$cddubbo-samples/golang/helloworld/dubbo进入目录后可看到四个文件夹，分别支持 go 和 java 的 client 以及 server，我们尝试运行一个 go 的 server。进入 app子文件夹内，可以看到里面保存了 go 文件。$cdgo-server/appsample 文件结构可以在 go-server 里面看到三个文件夹：app、assembly、profiles。其中 app 文件夹下保存 go 源码，assembly 文件夹下保存可选的针对特定环境的 build 脚本，profiles 下保存配置文件。对于 d开发云主机域名ubbo-go 框架，配置文件非常重要，没有文件将导致服务无法启动。设置指向配置文件的环境变量由于 dubbo-go 框架依赖配置文件启动，让框架定位到配置文件的方式就是通过环境变量来找。对于 server 端需要两个必须配置的环境变量：CONF_PROVIDER_FILE_PATH、APP_LOG_CONF_FILE，分别应该指向服务端配置文件、日志配置文件。在 sample 里面，我们可以使用 dev 环境，即 profiles/dev/log.yml 和 profiles/dev/server.yml 两个文件。在 app/ 下，通过命令行中指定好这两个文件：$exportCONF_PROVIDER_FILE_PATH=”../profiles/dev/server.yml”$exportAPP_LOG_CONF_FILE=”../profiles/dev/log.yml”设置 go 代理并运行服务$gorun.如果提示 timeout，则需要设置 goproxy 代理。$exportGOPROXY=”http://goproxy.io”再运行 go run 即可开启服务。安装 zookeeper，并运行 zkServer, 默认为 2181 端口。进入 go-client 的源码目录$cdgo-client/app同理，在 /app 下配置环境变量$exportCONF_CONSUMER_FILE_PATH=”../profiles/dev/client.yml”$exportAPP_LOG_CONF_FILE=”../profiles/dev/log.yml”配置 go 代理：$exportGOPROXY=”http://goproxy.io”运行程序$gorun.即可在日志中找到打印出的请求结果：responseresult:&{A001AlexStocks182020-10-2814:52:49.131+0800CST}同样，在运行的 server 中，也可以在日志中找到打印出的请求：req:[]interface{}{“A001″}rsp:main.User{Id:”A001″,Name:”AlexStocks”,Age:18,Time:time.Time{…}恭喜！一次基于 dubbo-go 的 rpc 调用成功。当日志开始部分出现 profiderInit 和 ConsumerInit 均失败的日志，检查环境变量中配置路径是否正确，配置文件是否正确。当日志中出现 register 失败的情况，一般为向注册中心注册失败，检查注册中心是否开启，检查配置文件中关于 register 的端口是否正确。sample 的默认开启端口为 20000，确保启动前无占用。dubbo-go 框架的 example 提供的目录如下：app/ 文件夹下存放源码，可以自己编写环境变量配置脚本 buliddev.shassembly/ 文件夹下存放不同平台的构建脚本profiles/ 文件夹下存放不同环境的配置文件target/ 文件夹下存放可执行文件源码放置在 app/ 文件夹下，主要包含 server.go 和 user.go 两个文件，顾名思义，server.go 用于使用框架开启服务以及注册传输协议；user.go 则定义了 rpc-service 结构体，以及传输协议的结构。user.go可以看到，user.go 中存在 init 函数，是服务端代码中最先被执行的部分。User 为用户自定义的传输结构体，UserProvider 为用户自定义的 rpc_service；包含一个 rpc函数，GetUser。当然，用户可以自定义其他的rpc 功能函数。在 init 函数中，调用 config 的 SetProviderService 函数，将当前 rpc_service 注册在框架 config 上。可以查看 dubbo 官方文档提供的设计图：service 层下面就是 config 层，用户服务会逐层向下注册，最终实现服务端的暴露。rpc-service 注册完毕之后，调用 hessian 接口注册传输结构体 User。至此，init 函数执行完毕。server.go之后执行 main 函数。main 函数中只进行了两个操作，首先使用 hessian 注册组件将 User 结构体注册（与之前略有重复），从而可以在接下来使用 getty 打解包。之后调用 config.Load 函数，该函数位于框架 config/config_loader.go 内，这个函数是整个框架服务的启动点，下面会详细讲这个函数内重要的配置处理过程。执行完 Load() 函数之后，配置文件会读入框架，之后根据配置文件的内容，将注册的 service 实现到配置结构里，再调用 Export 暴露给特定的 registry，进而开启特定的 service 进行对应端口的 tcp 监听，成功启动并且暴露服务。最终开启信号监听 initSignal() 优雅地结束一个服务的启动过程。客户端包含 client.go 和 user.go 两个文件，其中 user.go 与服务端完全一致，不再赘述。client.gomain 函数和服务端也类似，首先将传输结构注册到 hessian 上，再调用 config.Load() 函数。在下文会介绍，客户端和服务端会根据配置类型执行 config.Load() 中特定的函数 loadConsumerConfig() 和 loadProviderConfig()，从而达到“开启服务”、“调用服务”的目的。加载完配置之后，还是通过实现服务、增加函数 proxy、申请 registry 和 reloadInvoker 指向服务端 ip 等操作，重写了客户端实例 userProvider 的对应函数，这时再通过调用 GetUser 函数，可以直接通过 invoker，调用到已经开启的服务端，实现 rpc 过程。下面会从 server 端和 client 端两个角度，详细讲解服务启动、registry 注册和调用过程。var providerConfigStr = xxxxx// 配置文件内容，可以参考log 和 client。在这里你可以定义配置文件的获取方式，比如配置中心，本地文件读取。log 地址：https://github.com/dubbogo/dubbo-samples/blob/master/golang/helloworld/dubbo/go-client/profiles/release/log.yml client 地址：https://github.com/dubbogo/dubbo-samples/blob/master/golang/helloworld/dubbo/go-client/profiles/release/client.yml在 config.Load() 之前设置配置，例如：var consumerConfigStr= xxxxx// 配置文件内容，可以参考log 和 clien。在这里你可以定义配置文件的获取方式，比如配置中心，本地文件读取。在 config.Load() 之前设置配置，例如：服务暴露过程涉及到多次原始 rpcService 的封装、暴露，网上其他文章的图感觉太过笼统，在此，简要地绘制了一个用户定义服务的数据流图：在加载配置之前，框架提供了很多已定义好的协议、工厂等组件，都会在对应模块 init 函数内注册到 extension 模块上，以供接下来配置文件中进行选用。其中重要的有：默认函数代理工厂：common/proxy/proxy_factory/default.go它的作用是将原始 rpc-service 进行封装，形成 proxy_invoker，更易于实现远程 call 调用，详情可见其 invoke 函数。注册中心注册协议： registry/protocol/protocol.go它负责将 invoker 暴露给对应注册中心，比如 zk 注册中心。zookeeper 注册协议：registry/zookeeper/zookeeper.go它合并了 base_resiger，负责在服务暴露过程中，将服务注册在 zookeeper 注册器上，从而为调用者提供调用方法。dubbo 传输协议：protocol/dubbo/dubbo.go它负责监听对应端口，将具体的服务暴露，并启动对应的事件 handler，将远程调用的 event 事件传递到 invoker 内部，调用本地 invoker 并获得执行结果返回。filter 包装调用链协议：protocol/protocolwrapper/protocol_filter_wrapper.go它负责在服务暴露过程中，将代理 invoker 打包，通过配置好的 filter 形成调用链，并交付给 dubbo 协议进行暴露。上述提前注册好的框架已实现的组件，在整个服务暴露调用链中都会用到，会根据配置取其所需。服务端需要的重要配置有三个字段：services、protocols、registries。profiles/dev/server.yml:其中 service 指定了要暴露的 rpc-service 名（”UserProvider）、暴露的协议名（”dubbo”）、注册的协议名(“demoZk”)、暴露的服务所处的 interface、负载均衡策略、集群失败策略及调用的方法等等。其中，中间服务的协议名需要和 registries 下的 mapkey 对应，暴露的协议名需要和 protocols 下的 mapkey 对应。可以看到上述例子中，使用了 dubbo 作为暴露协议，使用了 zookeeper 作为中间注册协议，并且给定了端口。如果 zk 需要设置用户名和密码，也可以在配置中写好。config/config_loader.go::Load()在上述 example 的 main 函数中，有 config.Load() 函数的直接调用，该函数执行细节如下：在本文中，我们重点关心 loadConsumerConfig() 和 loadProviderConfig() 两个函数。对于 provider 端，可以看到 loadProviderConfig() 函数代码如下：前半部分是配置的读入和检查，进入 for 循环后，是单个 service 的暴露起始点。前面提到，在配置文件中已经写好了要暴露的 service 的种种信息，比如服务名、interface 名、method 名等等。在图中 for 循环内，会将所有 service 的服务依次实现。for 循环的第一行，根据 key 调用 GetProviderService 函数，拿到注册的 rpcService 实例，这里对应上述提到的 init 函数中，用户手动注册的自己实现的 rpc-service 实例：这个对象也就成为了 for 循环中的 rpcService 变量，将这个对象注册通过 Implement 函数写到 sys（ServiceConfig 类型）上，设置好 sys 的 key 和协议组，最终调用了 sys 的 Export 方法。此处对应流程图的部分：至此，框架配置结构体已经拿到了所有 service 有关的配置，以及用户定义好的 rpc-service 实例，它触发了 Export 方法，旨在将自己的实例暴露出去。这是 Export 调用链的起始点。config/service_config.go::Export()接下来进入 ServiceConfig.Export() 函数.这个函数进行了一些细碎的操作，比如为不同的协议分配随机端口，如果指定了多个中心注册协议，则会将服务通过多个中心注册协议的 registryProtocol 暴露出去，我们只关心对于一个注册协议是如何操作的。还有一些操作比如生成调用 url 和注册 url，用于为暴露做准备。registryUrl 是用来向中心注册组件发起注册请求的，对于 zookeeper 的话，会传入其 ip 和端口号，以及附加的用户名密码等信息。这个 regUrl 目前只存有注册（zk）相关信息，后续会补写入 ServiceIvk，即服务调用相关信息，里面包含了方法名，参数等…这个 Register 函数将服务实例注册了两次，一次是以 Interface 为 key 写入接口服务组内，一次是以 interface 和 proto 为 key 写入特定的一个唯一的服务。后续会从 common.Map 里面取出来这个实例。这一步的 GetProxyFactory(“default”) 方法获取默认代理工厂，通过传入上述构造的 regUrl，将 url 封装入代理 invoker。可以进入 common/proxy/proxy_factory/default.go::ProxyInvoker.Invoke() 函数里，看到对于 common.Map 取用为 svc 的部分，以及关于 svc 对应 Method 的实际调用 Call 的函数如下：到这里，上面 GetInvoker(*regUrl) 返回的 invoker 即为 proxy_invoker，它封装好了用户定义的 rpc_service，并将具体的调用逻辑封装入了 Invoke 函数内。为什么使用 Proxy_invoker 来调用？通过这个 proxy_invoke 调用用户的功能函数，调用方式将更加抽象化，可以在代码中看到，通过 ins 和 outs 来定义入参和出参，将整个调用逻辑抽象化为 invocation 结构体，而将具体的函数名的选择、参数向下传递和 reflect 反射过程封装在 invoke 函数内，这样的设计更有利于之后远程调用。个人认为这是 dubbo Invoke 调用链的设计思想。至此，实现了图中对应的部分：上面，我们执行到了 exporter = c.cacheProtocol.Export(invoker)。这里的 cacheProtocol 为一层缓存设计，对应到原始的 demo 上，这里是默认实现好的 registryProtocol。registry/protocol/protocol.go::Export()这个函数内构造了多个 EventListener，非常有 java 的设计感。我们只关心服务暴露的过程，先忽略这些监听器。一层缓存操作，如果 cache 没有需要从 common 里面重新拿 zkRegistry。上述拿到了具体的 zkRegistry 实例，该实例的定义在：registry/zookeeper/registry.go。该结构体组合了 registry.BaseRegistry 结构，base 结构定义了注册器基础的功能函数，比如 Registry、Subscribe 等，但在这些默认定义的函数内部，还是会调用 facade 层（zkRegistry 层）的具体实现函数，这一设计模型能在保证已有功能函数不需要重复定义的同时，引入外层函数的实现，类似于结构体继承却又复用了代码。这一设计模式值得学习。我们查看上述 registry/protocol/protocol.go:: Export() 函数，直接调用了:将已有 RegistryUrl 注册到了 zkRegistry 上。这一步调用了 baseRegistry 的 Register 函数，进而调用 zkRegister 的 DoRegister 函数，进而调用：在这个函数里，将对应 root 创造一个新的节点。并且写入具体 node 信息，node 为 url 经过 encode 的结果，包含了服务端的调用方式。这部分的代码较为复杂，具体可以看 baseRegistry 的processURL() 函数：http://t.tb.cn/6Xje4bijnsIDNaSmyPc4Ot。至此，将服务端调用 url 注册到了 zookeeper 上，而客户端如果想获取到这个 url，只需要传入特定的 dubboPath，向 zk 请求即可。目前 client 是可以获取到访问方式了，但服务端的特定服务还没有启动，还没有开启特定协议端口的监听，这也是 registry/protocol/protocol.go:: Export() 函数接下来要做的事情。新建一个 WrappedInvoker，用于之后链式调用。拿到提前实现并注册好的 ProtocolFilterWrapper，调用 Export 方法，进一步暴露。protocol/protocolwrapped/protocol_filter_wrapper.go:Export()protocol/protocolwrapped/protocol_filter_wrapper.go:buildInvokerChain可见，根据配置的内容，通过链式调用的构造，将 proxy_invoker 层层包裹在调用链的最底部，最终返回一个调用链 invoker。对应图中部分：至此，我们已经拿到 filter 调用链，期待将这个 chain 暴露到特定端口，用于相应请求事件。protocol/protocolwrapped/protocol_filter_wrapper.go:Export()回到上述 Export 函数的最后一行，调用了 dubboProtocol 的 Export 方法，将上述 chain 真正暴露。该 Export 方法的具体实现在：protocol/dubbo/dubbo_protocol.go: Export()。这一函数做了两个事情：构造触发器、启动服务。将传入的 Invoker 调用 chain 进一步封装，封装成一个 exporter，再将这个 export 放入 map 保存。注意！这里把exporter 放入了 SetExporterMap中，在下面服务启动的时候，会以注册事件监听器的形式将这个 exporter 取出！调用 dubboProtocol 的 openServer 方法，开启一个针对特定端口的监听。如上图所示，一个 Session 被传入，开启对应端口的事件监听。至此构造出了 exporter，完成图中部分：上述只是启动了服务，但还没有看到触发事件的细节，点进上面的 s.newSession 可以看到，dubbo 协议为一个 getty 的 session 默认使用了如下配置：其中很重要的一个配置是 EventListener，传入的是 dubboServer 的默认 rpcHandler。protocol/dubbo/listener.go:OnMessage()rpcHandler 有一个实现好的 OnMessage 函数，根据 getty 的 API，当 client 调用该端口时，会触发 OnMessage。这一函数实现了在 getty session 接收到 rpc 调用后的一系列处理：传入包的解析根据请求包构造请求 url拿到对应请求 key，找到要被调用的 exporter拿到对应的 Invoker构造 invocation调用返回整个被调过程一气呵成。实现了从 getty.Session 的调用事件，到经过层层封装的 invoker 的调用。至此，一次 rpc 调用得以正确返回。关于 Invoker 的层层封装能把一次调用抽象成一次 invoke；能把一个协议抽象成针对 invoke 的封装；能把针对一次 invoke 所做出的特定改变封装到 invoke 函数内部，可以降低模块之间的耦合性。层层封装逻辑更加清晰。关于 URL 的抽象关于 dubbo 的统一化请求对象 URL 的极度抽象是之前没有见过的… 个人认为这样封装能保证请求参数列表的简化和一致。但在开发的过程中，滥用极度抽象的接口可能造成… debug 的困难？以及不知道哪些字段是当前已经封装好的，哪些字段是无用的。关于协议的理解之前理解的协议还是太过具体化了，而关于 dubbo-go 对于 dubboProtocol 的协议，我认为是基于 getty 的进一步封装，它定义了客户端和服务端，对于 getty 的 session 应该有哪些特定的操作，从而保证主调和被调的协议一致性，而这种保证也是一种协议的体现，是由 dubbo 协议来规范的。看完上述内容，你们掌握Dubbo-go Server 端开启服务过程是怎样的的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注开发云行业资讯频道，感谢各位的阅读！

相关推荐: 如何构建基于WAF的s3cmd安全体系

这篇文章主要讲解了“如何构建基于WAF的s3cmd安全体系”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“如何构建基于WAF的s3cmd安全体系”吧！有线上项目需要对RGW的bucket的访问进行白名单控制，只允…