|Dubbo 跨语言调用神兽：dubbo-go-pixiu( 三 )

referenceConfig := dg.NewReferenceConfig(irequest.Interface context.TODO()) referenceConfig.InterfaceName = irequest.Interface referenceConfig.Cluster = constant.DEFAULT_CLUSTER var registers [
string for k := range dgCfg.Registries { registers = append(registers k)referenceConfig.Registry = strings.Join(registers \"\") if len(irequest.DubboBackendConfig.Protocol) == 0 { referenceConfig.Protocol = dubbo.DUBBOelse { referenceConfig.Protocol = irequest.DubboBackendConfig.ProtocolreferenceConfig.Version = irequest.DubboBackendConfig.Version referenceConfig.Group = irequest.Group referenceConfig.Generic = true if len(irequest.DubboBackendConfig.Retries) == 0 { referenceConfig.Retries = \"3\"else { referenceConfig.Retries = irequest.DubboBackendConfig.Retriesdc.lock.Lock() defer dc.lock.Unlock() referenceConfig.GenericLoad(key) clientService := referenceConfig.GetRPCService().(*dg.GenericService) ?实际上，在泛化调用的客户端中，实际执行泛化调用的关键步骤是 Dubbo-go 中的 generic_filter (如下代码片段) 。在调用 generic_filter 的 Invoke 时，约定 invocation 参数列表第一个为方法名，第二个为参数类型列表，第三个为参数值列表。 generic_filter 将用户请求的参数值列表转化为统一格式的 map（代码中的 struct2MapAll ），将类（ golang 中为 struct ）的正反序列化操作变成 map 的正反序列化操作。这使得无需 POJO 描述通过硬编码注入 hessain 库，从而完成 Dubbo 服务的泛化调用。
func (ef *GenericFilter) Invoke(ctx context.Context invoker protocol.Invoker invocation protocol.Invocation) protocol.Result { if invocation.MethodName() == constant.GENERIClen(invocation.Arguments()) == 3 { oldArguments := invocation.Arguments() if oldParams ok := oldArguments[2
.([
interface{); ok { newParams := make([
hessian.Object 0 len(oldParams)) for i := range oldParams { newParams = append(newParams hessian.Object(struct2MapAll(oldParams[i
)))newArguments := [
interface{{ oldArguments[0
oldArguments[1
newParamsnewInvocation := invocation2.NewRPCInvocation(invocation.MethodName() newArguments invocation.Attachments()) newInvocation.SetReply(invocation.Reply()) return invoker.Invoke(ctx newInvocation)return invoker.Invoke(ctx invocation) 总结通过上面的四个模块以及注册中心的简单介绍不难发现，当请求通过 listener 被 Pixiu 接收后，请求被传入 router 中。 router 根据接口的配置，从原请求中找到目标后端服务连同相关API配置下发到 filter 组件。 filter 组件根据原请求、 API 配置等信息顺序执行，最终请求到达 client ，通过 client 调用后端服务。
Pixiu的未来图 3: Pixiu 迭代里程碑
Pixiu 作为网关产品外，其衍生项目也会在我们的未来计划中，主要目的是提供更好的可用性。例如，由于 Golang 语言缺乏原生的注解，因此 Dubbo-go 需要通过配置文件方式生成服务的元数据写入注册中心。开课啦教育公司相关同学写了一个扫描代码的工具 _https://github.com/jack15083/dubbo-go-proxy-tool_ ，在每个 RPC 服务方法前加上对应的注释，从而在服务启动前通过扫描注释生成元数据。 Pixiu 也计划在未来的版本上通过提供 package ，允许服务通过注释借助 _https://github.com/MarcGrol/golangAnnotations _生成 API 配置并注册到 Pixiu 上。
Pixiu 目前的定位是一个七层协议网关，其最初版本是被定义成一个 Dubbo 的服务网关。作为云时代的产品， Pixiu 的发展方向必然是面向云原生的。现在的版本为0.2.1 已经实现基本的 Dubbo/Http 服务代理和部分的网关通用功能。目前正在开发中的 0.4 及其后续版本支持 gRPC 和 Spring Cloud 服务调用，后续还将提供 MQ 服务支持。另外，社区将继续优化配置方式，降低用户的使用难度，继续优化官方的 filter ，使 Pixiu 可以在官方层面实现更多的网关通用功能。