![1.png](https://ucc.alicdn.com/pic/developer-ecology/dabb61725d3e4bc1b7308c42575faf9c.png)

作者 | 李志信

> **導讀**：有了上一篇文章[《Dubbo-go 原始碼筆記（一）Server 端開啟服務過程》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495437&idx=1&sn=54cabeeb2cf93849a2eff99488c923e5&chksm=fae6e4c2cd916dd41e436a821d9159b457e86c831b53f43985dd43eb73c905f229ac70c14f1e&scene=21#wechat_redirect)的鋪墊，可以類比客戶端啟動於服務端的啟動過程。其中最大的區別是服務端透過 zk 註冊服務，釋出自己的ivkURL並訂閱事件開啟監聽；而客戶應該是透過zk註冊元件，拿到需要呼叫的serviceURL，更新invoker並重寫使用者的RPCService，從而實現對遠端過程呼叫細節的封裝。

# 配置檔案和客戶端原始碼

## 1. client 配置檔案

helloworld 提供的 demo：profiles/client.yaml。

```
registries :
  "demoZk":
    protocol: "zookeeper"
    timeout  : "3s"
    address: "127.0.0.1:2181"
    username: ""
    password: ""
references:
  "UserProvider":
    # 可以指定多個registry，使用逗號隔開;不指定預設向所有註冊中心註冊
    registry: "demoZk"
    protocol : "dubbo"
    interface : "com.ikurento.user.UserProvider"
    cluster: "failover"
    methods :
    - name: "GetUser"
      retries: 3
```

可看到配置檔案與之前討論過的 Server 端非常類似，其 refrences 部分欄位就是對當前服務要主調的服務的配置，其中詳細說明了呼叫協議、註冊協議、介面 id、呼叫方法、叢集策略等，這些配置都會在之後與註冊元件互動、重寫 ivk、呼叫的過程中使用到。

## 2. 客戶端使用框架原始碼

user.go：

```
func init() {
  config.SetConsumerService(userProvider)
  hessian.RegisterPOJO(&User{})
}
```

main.go：

```
func main() {
  hessian.RegisterPOJO(&User{})
  config.Load()
  time.Sleep(3e9)
  println("\n\n\nstart to test dubbo")
  user := &User{}
  err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user)
  if err != nil {
      panic(err)
  }
  println("response result: %v\n", user)
  initSignal()
}
```

在官網提供的 helloworld demo 的原始碼中，可看到與服務端類似，在 user.go 內註冊了 rpc-service，以及需要 rpc 傳輸的結構體 user。

在 main 函式中，同樣呼叫了 config.Load() 函式，之後就可以透過實現好的 rpc-service：userProvider 直接呼叫對應的功能函式，即可實現 rpc 呼叫。

可以猜到，從 hessian 註冊結構、SetConsumerService，到呼叫函式 .GetUser() 期間，使用者定義的 rpc-service 也就是 userProvider 對應的函式被重寫，重寫後的 GetUser 函式已經包含實現了遠端呼叫邏輯的 invoker。

接下來，就要透過閱讀原始碼，看看 dubbo-go 是如何做到的。

# 實現遠端過程呼叫

## 1. 載入配置檔案

```
// file: config/config_loader.go :Load()

// Load Dubbo Init
func Load() {
  // init router
  initRouter()
  // init the global event dispatcher
  extension.SetAndInitGlobalDispatcher(GetBaseConfig().EventDispatcherType)
  // start the metadata report if config set
  if err := startMetadataReport(GetApplicationConfig().MetadataType, GetBaseConfig().MetadataReportConfig); err != nil {
      logger.Errorf("Provider starts metadata report error, and the error is {%#v}", err)
  return
  }
  // reference config
  loadConsumerConfig()
```

在 main 函式中呼叫了 config.Load() 函式，進而呼叫了 loadConsumerConfig，類似於之前講到的 server 端配置讀入函式。

在 loadConsumerConfig 函式中，進行了三步操作：

```
// config/config_loader.go
func loadConsumerConfig() {
    // 1 init other consumer config
    conConfigType := consumerConfig.ConfigType
    for key, value := range extension.GetDefaultConfigReader() {}
    checkApplicationName(consumerConfig.ApplicationConfig)
    configCenterRefreshConsumer()
    checkRegistries(consumerConfig.Registries, consumerConfig.Registry)
    
    // 2 refer-implement-reference
    for key, ref := range consumerConfig.References {
        if ref.Generic {
            genericService := NewGenericService(key)
            SetConsumerService(genericService)
        }
        rpcService := GetConsumerService(key)
        ref.id = key
        ref.Refer(rpcService)
        ref.Implement(rpcService)
    }
    // 3 wait for invoker is available, if wait over default 3s, then panic
    for {}
}
```

1. 檢查配置檔案並將配置寫入記憶體
2. **在 for 迴圈內部**，依次引用（refer）並且例項化（implement）每個被調 reference
3. 等待三秒鐘所有 invoker 就緒

其中重要的就是 for 迴圈裡面的引用和例項化，兩步操作，會在接下來展開討論。

至此，配置已經被寫入了框架。

## 2. 獲取遠端 Service URL，實現可供呼叫的 invoker

上述的 ref.Refer 完成的就是這部分的操作。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/5c3b5a16741b4e67802a48f8c80f5eac.png)
圖（一）

### 1）構造註冊 url

和 server 端類似，存在註冊 url 和服務 url，dubbo 習慣將服務 url 作為註冊 url 的 sub。

```
// file: config/reference_config.go: Refer()
func (c *ReferenceConfig) Refer(_ interface{}) {
  //（一）配置url引數(serviceUrl)，將會作為sub
  cfgURL := common.NewURLWithOptions(
  common.WithPath(c.id),
  common.WithProtocol(c.Protocol),
  common.WithParams(c.getUrlMap()),
  common.WithParamsValue(constant.BEAN_NAME_KEY, c.id),
  )
  ...
  // （二）註冊地址可以透過url格式給定，也可以透過配置格式給定
  // 這一步的意義就是配置->提取資訊生成URL
  if c.Url != "" {// 使用者給定url資訊，可以是點對點的地址，也可以是註冊中心的地址
  // 1. user specified URL, could be peer-to-peer address, or register center's address.
  urlStrings := gxstrings.RegSplit(c.Url, "\\s*[;]+\\s*")
  for _, urlStr := range urlStrings {
    serviceUrl, err := common.NewURL(urlStr)
    ...
  }
  } else {// 配置讀入註冊中心的資訊
  //  assemble SubURL from register center's configuration mode
  // 這是註冊url，protocol = registry,包含了zk的使用者名稱、密碼、ip等等
  c.urls = loadRegistries(c.Registry, consumerConfig.Registries, common.CONSUMER)
  ...
  // set url to regUrls
  for _, regUrl := range c.urls {
    regUrl.SubURL = cfgURL// regUrl的subURl存當前配置url
  }
  }
  //至此，無論透過什麼形式，已經拿到了全部的regURL
  // （三）獲取registryProtocol例項，呼叫其Refer方法，傳入新構建好的regURL
  if len(c.urls) == 1 {
  // 這一步訪問到registry/protocol/protocol.go registryProtocol.Refer
  // 這裡是registry
  c.invoker = extension.GetProtocol(c.urls[0].Protocol).Refer(*c.urls[0])
  } else {
  // 如果有多個註冊中心，即有多個invoker,則採取叢集策略
  invokers := make([]protocol.Invoker, 0, len(c.urls))
  ...
  }
```

這個函式中，已經處理完從 Register 配置到 RegisterURL 的轉換,即圖（一）中部分：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/db3056e1c33b4b43953eeb93335d7573.png)

接下來，已經拿到的 url 將被傳遞給 RegistryProtocol，進一步 refer。

### 2）registryProtocol 獲取到 zkRegistry 例項，進一步 Refer

```
// file: registry/protocol/protocol.go: Refer

// Refer provider service from registry center
// 拿到的是配置檔案registries的url，他能夠生成一個invoker = 指向目的addr，以供客戶端直接呼叫。
func (proto *registryProtocol) Refer(url common.URL) protocol.Invoker {
  var registryUrl = url
  // 這裡拿到的是referenceConfig，serviceUrl裡面包含了Reference的所有資訊，包含interfaceName、method等等
  var serviceUrl = registryUrl.SubURL
  if registryUrl.Protocol == constant.REGISTRY_PROTOCOL {// registryUrl.Proto = "registry"
  protocol := registryUrl.GetParam(constant.REGISTRY_KEY, "")
  registryUrl.Protocol = protocol//替換成了具體的值，比如"zookeeper"
  }
  // 介面物件
  var reg registry.Registry
  // （一）例項化介面物件，快取策略
  if regI, loaded := proto.registries.Load(registryUrl.Key()); !loaded {
  // 快取中不存在當前registry，新建一個reg
  reg = getRegistry(&registryUrl)
  // 快取起來
  proto.registries.Store(registryUrl.Key(), reg)
  } else {
  reg = regI.(registry.Registry)
  }
  // 到這裡，獲取到了reg例項 zookeeper的registry
  //（二）根據Register的例項zkRegistry和傳入的regURL新建一個directory
  // 這一步存在複雜的非同步邏輯，從註冊中心拿到了目的service的真實addr，獲取了invoker並放入directory，
  // 這一步將在下面詳細給出步驟
  // new registry directory for store service url from registry
  directory, err := extension.GetDefaultRegistryDirectory(&registryUrl, reg)
  if err != nil {
  logger.Errorf("consumer service %v  create registry directory  error, error message is %s, and will return nil invoker!",
    serviceUrl.String(), err.Error())
  return nil
  }
  // （三）DoRegister 在zk上註冊當前client service
  err = reg.Register(*serviceUrl)
  if err != nil {
  logger.Errorf("consumer service %v register registry %v error, error message is %s",
    serviceUrl.String(), registryUrl.String(), err.Error())
  }
  // （四）new cluster invoker，將directory寫入叢集，獲得具有叢集策略的invoker
  cluster := extension.GetCluster(serviceUrl.GetParam(constant.CLUSTER_KEY, constant.DEFAULT_CLUSTER))
  invoker := cluster.Join(directory)
  // invoker儲存
  proto.invokers = append(proto.invokers, invoker)
  return invoker
}
```

可詳細閱讀上述註釋，這個函式完成了從 url 到 invoker 的全部過程：

（一）首先獲得 Registry 物件，預設是之前例項化的 zkRegistry，和之前 server 獲取 Registry 的處理很類似。

（二）透過構造一個新的 directory，非同步拿到之前在 zk 上註冊的 server 端資訊，生成 invoker。

（三）在 zk 上註冊當前 service。

（四）叢集策略，獲得最終 invoker。

這一步完成了圖（一）中所有餘下的絕大多數操作，接下來就需要詳細地檢視 directory 的構造過程。

### 3）構造 directory（包含較複雜的非同步操作）

![4.png](https://ucc.alicdn.com/pic/developer-ecology/a3f48b1cbf204508af7a34c15c56008a.png)
圖（二）

上述的 `extension.GetDefaultRegistryDirectory(&registryUrl, reg)` 函式，本質上呼叫了已經註冊好的 `NewRegistryDirectory` 函式:

```
// file: registry/directory/directory.go: NewRegistryDirectory()

// NewRegistryDirectory will create a new RegistryDirectory
// 這個函式作為default註冊在extension上面
// url為註冊url，reg為zookeeper registry
func NewRegistryDirectory(url *common.URL, registry registry.Registry) (cluster.Directory, error) {
  if url.SubURL == nil {
  return nil, perrors.Errorf("url is invalid, suburl can not be nil")
  }
  dir := &RegistryDirectory{
  BaseDirectory:    directory.NewBaseDirectory(url),
  cacheInvokers:    []protocol.Invoker{},
  cacheInvokersMap: &sync.Map{},
  serviceType:      url.SubURL.Service(),
  registry:         registry,
  }
  dir.consumerConfigurationListener = newConsumerConfigurationListener(dir)
  go dir.subscribe(url.SubURL)
  return dir, nil
}
```

首先構造了一個註冊 directory，開啟協程呼叫其 subscribe 函式，傳入 serviceURL。

這個 directory 目前包含了對應的 zkRegistry，以及傳入的 URL，它的 cacheInvokers 部分是空的。

進入 dir.subscribe(url.SubURL) 這個非同步函式：

```
/ file: registry/directory/directory.go: subscribe()

// subscribe from registry
func (dir *RegistryDirectory) subscribe(url *common.URL) {
  // 增加兩個監聽，
  dir.consumerConfigurationListener.addNotifyListener(dir)
  dir.referenceConfigurationListener = newReferenceConfigurationListener(dir, url)
  // subscribe呼叫
  dir.registry.Subscribe(url, dir)
}
```

重點來了，它呼叫了 zkRegistry 的 Subscribe 方法,與此同時將自己作為 ConfigListener 傳入。

> 我認為這種傳入 listener 的設計模式非常值得學習，而且很有 java 的味道。
> 針對等待 zk 返回訂閱資訊這樣的非同步操作，需要傳入一個 Listener，這個 Listener 需要實現 Notify 方法，進而在作為引數傳入內部之後，可以被非同步地呼叫 Notify，將內部觸發的非同步事件“傳遞出來”，再進一步處理加工。
> 層層的 Listener 事件鏈，能將傳入的原始 serviceURL 透過 zkConn 傳送給 zk 服務，獲取到服務端註冊好的 url 對應的二進位制資訊。
> 而 Notify 回撥鏈，則將這串 byte[] 一步一步解析、加工；以事件的形式向外傳遞，最終落到 directory 上的時候，已經是成型的 newInvokers 了。
> 具體細節不再以原始碼形式展示，可參照上圖查閱原始碼。

至此已經拿到了 server 端註冊好的真實 invoker。

完成了圖（一）中的部分：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/895b41321c254158a83bce242a2be829.png)

### 4）構造帶有叢集策略的 clusterinvoker

經過上述操作，已經拿到了 server 端 Invokers，放入了 directory 的 cacheinvokers 陣列裡面快取。

後續的操作對應本文從 url 到 invoker 的過程的最後一步，由 directory 生成帶有特性叢集策略的 invoker。

```
// （四）new cluster invoker，將directory寫入叢集，獲得具有叢集策略的invoker
  cluster := extension.GetCluster(serviceUrl.GetParam(constant.CLUSTER_KEY, constant.DEFAULT_CLUSTER))
  invoker := cluster.Join(directory)
123
```

Join 函式的實現就是如下函式：

```
// file: cluster/cluster_impl/failover_cluster_invokers.go: newFailoverClusterInvoker()

func newFailoverClusterInvoker(directory cluster.Directory) protocol.Invoker {
  return &failoverClusterInvoker{
  baseClusterInvoker: newBaseClusterInvoker(directory),
  }
}
12345
```

dubbo-go 框架預設選擇 failover 策略，既然返回了一個 invoker，我們檢視一下 failoverClusterInvoker 的 Invoker 方法，看它是如何將叢集策略封裝到 Invoker 函式內部的：

```
// file: cluster/cluster_impl/failover_cluster_invokers.go: Invoker()

// Invoker 函式
func (invoker *failoverClusterInvoker) Invoke(ctx context.Context, invocation protocol.Invocation) protocol.Result {
  ...
  //呼叫List方法拿到directory快取的所有invokers
  invokers := invoker.directory.List(invocation)
  if err := invoker.checkInvokers(invokers, invocation); err != nil {// 檢查是否可以實現呼叫
  return &protocol.RPCResult{Err: err}
  }
  // 獲取來自使用者方向傳入的
  methodName := invocation.MethodName()
  retries := getRetries(invokers, methodName)
  loadBalance := getLoadBalance(invokers[0], invocation)
  for i := 0; i <= retries; i++ {
  // 重要！這裡是叢集策略的體現，失敗後重試！
  //Reselect before retry to avoid a change of candidate `invokers`.
  //NOTE: if `invokers` changed, then `invoked` also lose accuracy.
  if i > 0 {
    if err := invoker.checkWhetherDestroyed(); err != nil {
    return &protocol.RPCResult{Err: err}
    }
    invokers = invoker.directory.List(invocation)
    if err := invoker.checkInvokers(invokers, invocation); err != nil {
    return &protocol.RPCResult{Err: err}
    }
  }
  // 這裡是負載均衡策略的體現！選擇特定ivk進行呼叫。
  ivk := invoker.doSelect(loadBalance, invocation, invokers, invoked)
  if ivk == nil {
    continue
  }
  invoked = append(invoked, ivk)
  //DO INVOKE
  result = ivk.Invoke(ctx, invocation)
  if result.Error() != nil {
    providers = append(providers, ivk.GetUrl().Key())
    continue
  }
  return result
  }
  ...
}
```

> 看了很多 Invoke 函式的實現，所有類似的 Invoker 函式都包含兩個方向：一個是使用者方向的 invcation；一個是函式方向的底層 invokers。
> 而叢集策略的 invoke 函式本身作為接線員，把 invocation 一步步解析，根據呼叫需求和叢集策略，選擇特定的 invoker 來執行。
> proxy 函式也是這樣，一個是使用者方向的 ins[] reflect.Type, 一個是函式方向的 invoker。
> proxy 函式負責將 ins 轉換為 invocation，呼叫對應 invoker 的 invoker 函式，實現連通。
> 而出於這樣的設計，可以在一步步 Invoker 封裝的過程中，每個 Invoker 只關心自己負責操作的部分，從而使整個呼叫棧解耦。
> 妙啊！！！

至此，我們理解了 failoverClusterInvoker 的 Invoke 函式實現，也正是和這個叢集策略 Invoker 被返回，接受來自上方的呼叫。

已完成圖（一）中的：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/e04ff571ba7c45f3821e4a7b5924786b.png)

### 5）在 zookeeper 上註冊當前 client

拿到 invokers 後，可以回到這個函式了：

```
  // file: config/refrence_config.go: Refer()
  
  if len(c.urls) == 1 {
  // 這一步訪問到registry/protocol/protocol.go registryProtocol.Refer
  c.invoker = extension.GetProtocol(c.urls[0].Protocol).Refer(*c.urls[0])
  // （一）拿到了真實的invokers
  } else {
  // 如果有多個註冊中心，即有多個invoker,則採取叢集策略
  invokers := make([]protocol.Invoker, 0, len(c.urls))
  ...
  cluster := extension.GetCluster(hitClu)
  // If 'zone-aware' policy select, the invoker wrap sequence would be:
  // ZoneAwareClusterInvoker(StaticDirectory) ->
  // FailoverClusterInvoker(RegistryDirectory, routing happens here) -> Invoker
  c.invoker = cluster.Join(directory.NewStaticDirectory(invokers))
  }
  // （二）create proxy，為函式配置代理
  if c.Async {
  callback := GetCallback(c.id)
  c.pxy = extension.GetProxyFactory(consumerConfig.ProxyFactory).GetAsyncProxy(c.invoker, callback, cfgURL)
  } else {
  // 這裡c.invoker已經是目的addr了
  c.pxy = extension.GetProxyFactory(consumerConfig.ProxyFactory).GetProxy(c.invoker, cfgURL)
  }
```

我們有了可以打通的 invokers，但還不能直接呼叫，因為 invoker 的入參是 invocation，而呼叫函式使用的是具體的引數列表，需要透過一層 proxy 來規範入參和出參。

接下來新建一個預設 proxy，放置在 c.proxy 內，以供後續使用。

至此，完成了圖（一）中最後的操作：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/039803b3d5e54f34a47e207541d744d9.png)

## 3. 將呼叫邏輯以代理函式的形式寫入 rpc-service

上面完成了 config.Refer 操作，回到：

> config/config_loader.go: loadConsumerConfig()

![8.png](https://ucc.alicdn.com/pic/developer-ecology/c301abf0a0464fa7a03e5710ea5e5ed0.png)

下一個重要的函式是 Implement，它的操作較為簡單：旨在使用上面生成的 c.proxy 代理，連結使用者自己定義的 rpcService 到 clusterInvoker 的資訊傳輸。

函式較長，只選取了重要的部分:

```
// file: common/proxy/proxy.go: Implement()

// Implement
// proxy implement
// In consumer, RPCService like:
//    type XxxProvider struct {
//    Yyy func(ctx context.Context, args []interface{}, rsp *Zzz) error
//    }
// Implement 實現的過程，就是proxy根據函式名和返回值，透過呼叫invoker 構造出擁有遠端呼叫邏輯的代理函式
// 將當前rpc所有可供呼叫的函式註冊到proxy.rpc內
func (p *Proxy) Implement(v common.RPCService) {
  // makeDubboCallProxy 這是一個構造代理函式，這個函式的返回值是func(in []reflect.Value) []reflect.Value 這樣一個函式
  // 這個被返回的函式是請求實現的載體，由他來發起呼叫獲取結果
  makeDubboCallProxy := func(methodName string, outs []reflect.Type) func(in []reflect.Value) []reflect.Value {
  return func(in []reflect.Value) []reflect.Value {
    // 根據methodName和outs的型別，構造這樣一個函式，這個函式能將in 輸入的value轉換為輸出的value
    // 這個函式具體的實現如下：
    ...
    // 目前拿到了 methodName、所有入參的interface和value，出引數reply
    // （一）根據這些生成一個 rpcinvocation
    inv = invocation_impl.NewRPCInvocationWithOptions(
    invocation_impl.WithMethodName(methodName),
    invocation_impl.WithArguments(inIArr),
    invocation_impl.WithReply(reply.Interface()),
    invocation_impl.WithCallBack(p.callBack),
    invocation_impl.WithParameterValues(inVArr))
    for k, value := range p.attachments {
    inv.SetAttachments(k, value)
    }
    // add user setAttachment
    atm := invCtx.Value(constant.AttachmentKey) // 如果傳入的ctx裡面有attachment，也要寫入inv
    if m, ok := atm.(map[string]string); ok {
    for k, value := range m {
      inv.SetAttachments(k, value)
    }
    }
    // 至此構造inv完畢
    // (二）觸發Invoker 之前已經將cluster_invoker放入proxy，使用Invoke方法，透過getty遠端過程呼叫
    result := p.invoke.Invoke(invCtx, inv)
    // 如果有attachment，則加入
    if len(result.Attachments()) > 0 {
    invCtx = context.WithValue(invCtx, constant.AttachmentKey, result.Attachments())
    }
    ...
  }
  }
  numField := valueOfElem.NumField()
  for i := 0; i < numField; i++ {
  t := typeOf.Field(i)
  methodName := t.Tag.Get("dubbo")
  if methodName == "" {
    methodName = t.Name
  }
  f := valueOfElem.Field(i)
  if f.Kind() == reflect.Func && f.IsValid() && f.CanSet() { // 針對於每個函式
    outNum := t.Type.NumOut()
    // 規定函式輸出只能有1/2個
    if outNum != 1 && outNum != 2 {
    logger.Warnf("method %s of mtype %v has wrong number of in out parameters %d; needs exactly 1/2",
      t.Name, t.Type.String(), outNum)
    continue
    }
    // The latest return type of the method must be error.
    // 規定最後一個返回值一定是error
    if returnType := t.Type.Out(outNum - 1); returnType != typError {
    logger.Warnf("the latest return type %s of method %q is not error", returnType, t.Name)
    continue
    }
    // 獲取到所有的出參型別，放到陣列裡
    var funcOuts = make([]reflect.Type, outNum)
    for i := 0; i < outNum; i++ {
    funcOuts[i] = t.Type.Out(i)
    }
    // do method proxy here:
    // （三）呼叫make函式，傳入函式名和返回值，獲得能呼叫遠端的proxy，將這個proxy替換掉原來的函式位置
    f.Set(reflect.MakeFunc(f.Type(), makeDubboCallProxy(methodName, funcOuts)))
    logger.Debugf("set method [%s]", methodName)
  }
  }
  ...
}
```

正如之前所說，proxy 的作用是將使用者定義的函式引數列表，轉化為抽象的 invocation 傳入 Invoker，進行呼叫。

其中已標明有三處較為重要的地方：

1. 在代理函式中實現由引數列表生成 Invocation 的邏輯
2. 在代理函式實現呼叫 Invoker 的邏輯
3. 將代理函式替換為原始 rpc-service 對應函式

至此，也就解決了一開始的問題：

```
  // file: client.go: main()
  
  config.Load()
  user := &User{}
  err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user)
```

這裡直接呼叫使用者定義的 rpcService 的函式 GetUser，此處實際呼叫的是經過重寫入的函式代理，所以就能實現遠端呼叫了。

# 從 client 到 server 的 invoker 巢狀鏈- 小結

在閱讀 dubbo-go 原始碼的過程中，我們能夠發現一條清晰的 invoker-proxy 巢狀鏈，希望能夠透過圖的形式來展現：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/fb6c66da5aca4bd299547f6742b1dd0e.png)

如果你有任何疑問，歡迎釘釘掃碼加入釘釘交流群：釘釘群號 23331795。

### 作者簡介

**李志信** (GitHubID LaurenceLiZhixin)，中山大學軟體工程專業在校學生，擅長使用 Java/Go 語言，專注於雲原生和微服務等技術方向。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496103&idx=1&sn=68aeef14759b4d82dc58d9ff0abc8a70&chksm=fae6fa68cd91737e525c42a65be7d91698563bf61d1c2ac1055f5963e8173a49e04c863415ac&token=849729660&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

Dubbo-go 原始碼筆記（二）客戶端呼叫過程

相關文章