分布式服務治理的設計問題？

本人用c++實現了 微服務的 【註冊中心】， 並對這個註冊中心實現了高可用，我的服務網通過TCP通訊，服務上線的時候 會註冊到 【註冊中心】上面，【註冊中心】會推送這個伺服器位址到 【服務消費者】。這樣【服務消費者】就持有了所以的【微服務的map】我的負載平衡是在【服務消費者】這樣做的，說白了【服務消費者】是要常駐記憶體的，這樣對python或者java還好做點，但是對於走FPM的PHP相當於判了死刑，如何對PHP做改造，能讓讓傳統的 FPM的PHP支援這種架構。 看起來Dubbo 也是類似這樣子做的，那麼前端如果用php做的話 是不是就有點蛋疼了？

回複內容：

負載平衡有2種做法：

用戶端負載平衡，典型的是 Finagle 和 Dubbo。好處是實現出來簡單，服務直接直連效能好。壞處是多語言的時候需要為每種語言實現一個用戶端。

服務端的負載平衡，典型的負載平衡器是 Nginx 和 HAProxy 。通常是在服務前面加一個反向 Proxy。用戶端通過反向 Proxy和服務端通訊，具體的負載平衡邏輯由負載平衡器實現。負載平衡器本身也可以註冊到註冊中心。好處是用戶端非常簡單，多語言也好支援。壞處嘛就是有點效能損失。

具體怎麼選要看業務，也要看公司的技術選型。多語言的情境下服務端的方案會省去很多維護成本，當然如果有一個 team 來維護用戶端的話當我沒說，畢竟 team 需要有事幹麼。

純 Java 情境，已經用了 Dubbo 或者類似的架構，架構已經提供了支援就別折騰了。

回到題主的情境，如果非要在 php 服務裡實現服務發現，可以把服務註冊表緩衝起來，比如放到 memcache 裡，每隔一段時間可以重新拉一次。

以上這個最簡單（可能也是最靠譜）的方案是 agent，在 php 的伺服器上跑一個 agent，監聽你的註冊中心，這個 agent 在收到新地址後修改 php 的設定檔，php 被 fpm 調用的時候都去讀取一下這個配置。

一般來說，幾乎所有的架構都有設定檔，直接去改這個檔案就可以了，改造沒有增加任何成本（因為你本來也是要讀設定檔的）。現在這種設計方式有一定的優勢，即本身屬於服務匯流排的一些能力已經完全下層到服務消費方節點上，這樣匯流排本身功能更輕，只管理服務註冊和註冊資訊的分發。註冊中心down機基本對服務消費和調用沒有任何影響。

鑒於你剛才提到的問題，有兩種解決方案，一種是仍然將服務代理這塊的能力提升回匯流排上來實現，包括路由和負載平衡等。如果不希望這樣做，也可以考慮再單獨起一個server，在該server上來實現服務消費和路由均衡邏輯。這個server可以看作是對應php應用的後端代理。微服務中使用用戶端負載平衡我覺得是大趨勢，原因有三：一是效能有優勢，二是可靠性更高註冊中心down掉還是可以正常運行，三是用戶端本身就需要實現斷路器、服務降級之類的邏輯，多實現一個簡單的負載平衡邏輯也算是順路。PHP不太熟悉，是否可以考慮將服務配置寫入到某個service_config.php檔案，其他檔案來包含這個service_config.php？包含之前檢測一下檔案的時間戳記，如果超過某個時間（比如1分鐘）就再重新從註冊中心擷取配置寫入檔案。兩個方案

1、Swoole
Swoole: PHP的非同步、並行、高效能網路通訊引擎
可以使用swoole寫一個常駐內測的php server

2、緩衝
使用APCu(PHP: APCu - Manual )或者redis，把伺服器位址列表緩衝起來
看具體的效能要求和服務列表的一致性要求，一致性要求比較高，緩衝可以短點，擔心redis緩衝讀寫的網路開銷，可以使用APCu這種本機快取swoole啊

