![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/efdf9db76b61432889c97228d9efaf45.png)

作者 | 劉曉敏 於雨

## 一、簡介

Java 的世界裡，大家廣泛使用的一個高效能網路通訊框架 netty，很多 RPC 框架都是基於 netty 來實現的。在 golang 的世界裡，[getty](https://github.com/AlexStocks/getty) 也是一個類似 netty 的高效能網路通訊庫。getty 最初由 dubbogo 專案負責人於雨開發，作為底層通訊庫在 [dubbo-go](https://github.com/apache/dubbo-go) 中使用。隨著 dubbo-go 捐獻給 apache 基金會，在社群小夥伴的共同努力下，getty 也最終進入到 apache 這個大家庭，並改名 [dubbo-getty](https://github.com/apache/dubbo-getty) 。

18 年的時候，我在公司裡實踐微服務，當時遇到最大的問題就是分散式事務問題。同年，阿里在社群開源他們的分散式事務解決方案，我也很快關注到這個專案，起初還叫 fescar，後來更名 seata。由於我對開源技術很感興趣，加了很多社群群，當時也很關注 dubbo-go 這個專案，在裡面默默潛水。隨著對 seata 的瞭解，逐漸萌生了做一個 go 版本的分散式事務框架的想法。

要做一個 golang 版的分散式事務框架，首要的一個問題就是如何實現 RPC 通訊。dubbo-go 就是很好的一個例子擺在眼前，遂開始研究 dubbo-go 的底層 getty。

## 二、如何基於 getty 實現 RPC 通訊

getty 框架的整體模型圖如下：

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

下面結合相關程式碼，詳述 seata-golang 的 RPC 通訊過程。

### 1. 建立連線

實現 RPC 通訊，首先要建立網路連線吧，我們從 [client.go](https://github.com/apache/dubbo-getty/blob/master/client.go) 開始看起。

```go
func (c *client) connect() {
	var (
		err error
		ss  Session
	)

for {
        // 建立一個 session 連線
		ss = c.dial()
		if ss == nil {
			// client has been closed
			break
		}
		err = c.newSession(ss)
		if err == nil {
            // 收發報文
			ss.(*session).run()
			// 此處省略部分程式碼
      
			break
		}
		// don't distinguish between tcp connection and websocket connection. Because
		// gorilla/websocket/conn.go:(Conn)Close also invoke net.Conn.Close()
		ss.Conn().Close()
	}
}
```

`connect()` 方法透過 `dial()` 方法得到了一個 session 連線，進入 dial() 方法：

```
func (c *client) dial() Session {
	switch c.endPointType {
	case TCP_CLIENT:
		return c.dialTCP()
	case UDP_CLIENT:
		return c.dialUDP()
	case WS_CLIENT:
		return c.dialWS()
	case WSS_CLIENT:
		return c.dialWSS()
	}

return nil
}
```

我們關注的是 TCP 連線，所以繼續進入 `c.dialTCP()` 方法：

```go
func (c *client) dialTCP() Session {
	var (
		err  error
		conn net.Conn
	)

for {
		if c.IsClosed() {
			return nil
		}
		if c.sslEnabled {
			if sslConfig, err := c.tlsConfigBuilder.BuildTlsConfig(); err == nil && sslConfig != nil {
				d := &net.Dialer{Timeout: connectTimeout}
				// 建立加密連線
				conn, err = tls.DialWithDialer(d, "tcp", c.addr, sslConfig)
			}
		} else {
            // 建立 tcp 連線
			conn, err = net.DialTimeout("tcp", c.addr, connectTimeout)
		}
		if err == nil && gxnet.IsSameAddr(conn.RemoteAddr(), conn.LocalAddr()) {
			conn.Close()
			err = errSelfConnect
		}
		if err == nil {
            // 返回一個 TCPSession
			return newTCPSession(conn, c)
		}

log.Infof("net.DialTimeout(addr:%s, timeout:%v) = error:%+v", c.addr, connectTimeout, perrors.WithStack(err))
		這裡起了兩個 goroutine，`handleLoop` 和 `handlePackage`，看字面意思符合我們的猜想，進入 `handleLoop()` 方法：<br>

```go
func (s *session) handleLoop() {
    // 省略部分程式碼
  
	for {
		// A select blocks until one of its cases is ready to run.
		// It choose one at random if multiple are ready. Otherwise it choose default branch if none is ready.
		select {
		// 省略部分程式碼
      
		case outPkg, ok =  transactionRole
	// TM will register before RM, if a session is not the TM registered,
	// it will be the RM registered
	session_transactionroles = sync.Map{}

// session -> applicationId
	identified_sessions = sync.Map{}

// applicationId -> ip -> port -> session
	client_sessions = sync.Map{}

// applicationId -> resourceIds
	client_resources = sync.Map{}
)
```

這樣，Transaction Manager 和 Resource Manager 分別透過 `coordinator.OnRegTmMessage(rpcMessage, session)` 和 `coordinator.OnRegRmMessage(rpcMessage, session)` 註冊到 Transaction Coordinator 時，會在上述 client_sessions map 中快取 applicationId、ip、port 與 session 的關係，在 client_resources map 中快取 applicationId 與 resourceIds（一個應用可能存在多個 Resource Manager） 的關係。在需要時，我們就可以透過上述對映關係構造一個 RpcContext。這部分的實現和 java 版 seata 有很大的不同，感興趣的可以深入瞭解一下。具體程式碼見 [`getty_session_manager.go`。](https://github.com/opentrx/seata-golang/blob/dev/tc/server/getty_session_manager.go)

至此，我們就分析完了 [seata-golang](https://github.com/opentrx/seata-golang) 整個 RPC 通訊模型的機制。

## 三、seata-golang 的未來

[seata-golang](https://github.com/opentrx/seata-golang)  從今年 4 月份開始開發，到 8 月份基本實現和 java 版 [seata 1.2](https://github.com/seata/seata) 協議的互通，對 mysql 資料庫實現了 AT 模式（自動協調分散式事務的提交回滾），實現了 TCC 模式，TC 端使用 mysql 儲存資料，使 TC 變成一個無狀態應用支援高可用部署。下圖展示了 AT 模式的原理：

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

後續，還有許多工作可以做，比如：對註冊中心的支援、對配置中心的支援、和 java 版 seata 1.4 的協議互通、其他資料庫的支援、raft transaction coordinator 的實現等，希望對分散式事務問題感興趣的開發者可以加入進來一起來打造一個完善的 golang 的分散式事務框架。如果你有任何疑問，歡迎加入交流群【釘釘群號 33069364】。

另外，歡迎對 dubbogo 感興趣的朋友到 dubbogo 社群釘釘群（釘釘群號 31363295）溝通 dubbogo 技術問題。

#### 參考資料

- seata 官方：[https://seata.io](https://seata.io)
- java 版 seata：[https://github.com/seata/seata](https://github.com/seata/seata)
- seata-golang 專案地址：[https://github.com/opentrx/seata-golang](https://github.com/transaction-wg/seata-golang)
- seata-golang go 夜讀 b站分享：[https://www.bilibili.com/video/BV1oz411e72T](https://www.bilibili.com/video/BV1oz411e72T)

### **作者簡介**

劉曉敏 (GitHubID dk-lockdown)，目前就職於 h3c 成都分公司，擅長使用 Java/Go 語言，在雲原生和微服務相關技術方向均有涉獵，目前專攻分散式事務。

於雨(github @AlexStocks)，dubbo-go 專案和社群負責人，一個有十多年服務端基礎架構研發一線工作經驗的程式設計師，陸續參與改進過 Muduo/Pika/Dubbo/Sentinel-go 等知名專案，目前在螞蟻金服可信原生部從事容器編排和 service mesh 工作。

分散式事務框架 seata-golang 通訊模型詳解

相關文章