詳解PHP調用Go服務的正確方式

更新時間：2021年05月26日 11:39:57 作者：枕邊書

本文主要介紹了PHP調用Go服務的正確方式 - Unix Domain Sockets，對進程間通信感興趣的同學，可以參考一下。

問題

服務耦合

我們在開發(fā)過程中可能會遇到這樣的情況：

進程依賴于某服務，所以把服務耦合在進程代碼中；
服務初始化耗時長，拖慢了進程啟動時間；
服務運行要占用大量內存，多進程時內存損耗嚴重。

文本匹配服務，它是消息處理流程中的一環(huán)，被多個消息處理進程依賴，每次初始化進程要 6秒左右時間構造 Trie 樹，而且服務讀取關鍵詞大文件、使用樹組構造 Trie 樹，會占用大量(目前設置為 256M )內存。

我已經把進程寫成了守護進程的形式，讓它們長時間執(zhí)行，雖然不用更多地考慮初始化時間了，但占用內存量巨大的問題沒有辦法。如果關鍵詞量再大一些，一臺機器上面跑十來個消息處理進程后就干不了其他了。

而且，如果有需求讓我把文本匹配服務封裝為接口給外部調用呢？我們知道，web 服務時，每一個請求處理進程的生存周期是從受理請求到響應結束，如果每次請求都用大量內存和時間來初始化服務，那接口響應時間和服務器壓力可想而知。

服務抽取

這樣，服務形式必須要改變，我們希望這個文本匹配這個服務能做到：

隨調隨走，不依賴，不再與“消息處理服務”耦合在一起；
一次初始化，進程運行期間持續(xù)提供服務；
同步響應，高效而準確，最好能不用各種鎖來保持資源占有；

解決辦法也很簡單，就是把這個文本匹配的服務抽取出來，單獨作為一個守護進程來運行，像一個特殊的服務器，多個“消息處理服務”在有需要時能調用此服務進程。

現在，我們需要考慮文本匹配服務進程如何與外界通信，接受匹配請求，響應匹配結果。繞來繞去，問題還是回到了進程間通信。

Unix Domain Sockets

進程間通信

進程間通信（IPC，Inter-Process Communication），指至少兩個進程或線程間傳送數據或信號的一些技術或方法。進程是計算機系統(tǒng)分配資源的最小單位(嚴格說來是線程)。每個進程都有自己的一部分獨立的系統(tǒng)資源，彼此是隔離的。為了能使不同的進程互相訪問資源并進行協(xié)調工作，才有了進程間通信。

進程間通信的方式有很多，網上對此介紹的也很多，下面根據文章的需求來分析一下這些方式：

管道：管道是Unix最初的IPC形式，但它只能用于具有共同祖先進程的各個進程，無法用于在沒有親緣關系的進程。如果使用它，需要在“消息處理服務”中啟動“文本匹配服務”，跟原來差別不大。
命名管道：也被稱為有名管道，它在Unix稱為FIFO，它通過一個文件來進行進程間數據交互，但服務于多個進程時，需要添加鎖來保證原子性，從而避免寫入和讀取不對應。
信號和信號量：用于進程/線程事件級的通信，但它們能交流的信息太少。
消息隊列和共享內存：都是通過一個公共內存介質來進行通信
socket：通過Unix封裝好的網絡API來進行通信，像數據庫、服務器都是通過這種方式實現，它們也能提供本地服務。不過網絡socket固然能使用，但是要面臨著數據包裝和網絡調用開銷，也不是完美的選擇。

簡單介紹

當然還是有完美的方式的，這就是今天的主角 - Unix Domain Sockets ，它可以理解為一種特殊的 Socket，但它不需要經過網絡協(xié)議棧，不需要打包拆包、計算校驗和、維護序號和應答等，只是將應用層數據從一個進程拷貝到另一個進程，所以在系統(tǒng)內通信效率更高。而且免去了網絡問題，它也更能保證消息的完整性，既不會丟失也不會順序錯亂。

作為特殊的 Socket，它的創(chuàng)建、調用方式和網絡 Socket 一樣，一次完整的交互，服務端都要經過create、bind、listen、accept、read、write，客戶端要通過create、connect、write、read。與普通 Socket 不同的是它綁定一個系統(tǒng)內的文件，而不是 IP 和端口。

適用場景

Unix Domain Sockets 真的是進程間通信的一個重型武器，用它可以快速實現進程間的數據、信息交互，而且不需要鎖等繁雜操作，也不用考慮效率，可謂是簡單高效。

當然，“重型武器” 的在各種場景下也有適合不適合。Unix Domain Sockets適用于以下場景：

服務長時間存在。 Unix Domain Sockets 的服務端是個服務器一樣的存在，在守護進程中，它阻塞并等待客戶端連接的特性可以被充分利用。
一服務器多客戶端。它能通過 Socket 的文件描述符來區(qū)分不同的客戶端，避免資源之間的鎖操作。
同一系統(tǒng)內。它只能在同一系統(tǒng)內進行進程數據復制，跨系統(tǒng)請使用傳統(tǒng) Sockets。

代碼實現

接下來要 show code 了，不過學 PHP 的都知道，PHP 不太適合處理 CPU 密集形的任務，我剛好學了點 Go，一時手癢，就用 Go 實現了下 Trie 樹，所以才牽扯到 PHP 和 Go 之間的通信，有了今天的文章。當然介紹的方法，并不只適合 PHP 與 Go 通信，其他語言也可以，至少 C系語言中是通用的。

Go 實現的 Trie 樹

Trie樹不再是今天的主題，這里介紹一下數據結構和需要注意的點。

// trie樹結點定義
type Node struct {
    depth    int
    children map[int32]Node // 用map實現key-value型的 字符-節(jié)點 對應
}

需要注意：

使用 slice 的 append() 函數保存遞增的匹配結果時，有可能由于 slice 容量不夠而重新分配地址，所以要傳入 slice 的地址來保存遞增后的匹配結果結果，*result = append(*result, word)，最后再將遞增之后的 slice 地址傳回。
由于 Go 中的編碼統(tǒng)一使用的 utf-8，不用像 PHP 一樣判斷字符的邊界，所以在進行關鍵詞拆散和消息拆散時，直接使用 int32() 方法將關鍵詞和消息都轉換為成員為 int32 類型的 slice，匹配過程中就使用 int32 類型的數字來代表這個中文字符，匹配完成后再使用fmt.Printf("%c", int32)將其轉換為中文。

Go Server

Go 中創(chuàng)建一個 socket 并使用的步驟非常簡單，只是 Go 沒有異常，判斷 error 會比較惡心一點，不知道有沒有大神有更好的寫法。下面為了精簡，把 error 全置空了。

 // 創(chuàng)建一個Unix domain soceket
    socket, _ := net.Listen("unix", "/tmp/keyword_match.sock")
    // 關閉時刪除綁定的文件
    defer syscall.Unlink("/tmp/keyword_match.sock") 
    // 無限循環(huán)監(jiān)聽和受理客戶端請求
    for {
        client, _ := socket.Accept()
        
        buf := make([]byte, 1024)
        data_len, _ := client.Read(buf)
        data := buf[0:data_len]
        msg := string(data)
        
        matched := trie.Match(tree, msg)
        response := []byte("[]") // 給響應一個默認值
        if len(matched) > 0 {
            json_str, _ := json.Marshal(matched)
            response = []byte(string(json_str))
        }
        _, _ = client.Write(response)
    }

PHP Client

下面是 PHP 實現的客戶端：

$msg = "msg";
// 創(chuàng)建 連接 發(fā)送消息 接收響應 關閉連接
$socket = socket_create(AF_UNIX, SOCK_STREAM, 0);
socket_connect($socket, '/tmp/keyword_match.sock');
socket_send($socket, $msg, strlen($msg), 0);
$response = socket_read($socket, 1024);
socket_close($socket);

// 有值則為匹配成功
if (strlen($response) > 3) {
    var_dump($response);
}

小結

效率

這里總結一下這套設計的效率表現：

純粹用 Go 進行文本關鍵詞匹配，一千條數據運行一秒多，差不多是 PHP 效率的兩倍。不過說好的 8倍效率呢？果然測評都是騙人的。當然，也可能是我寫法有問題或者 Trie 樹不在 Go 的發(fā)揮范圍之內。然后是 PHP 使用 Unix Domain Socket 調用 Go 服務的耗時，可能是進程間復制數據耗時或 PHP 拖了后腿，3秒多一點，跟純 PHP 腳本差不多。