本人用c++實現了微服務的【註冊中心】， 並對這個註冊中心實現了高可用，我的服務網通過TCP通信，服務上線的時候會註冊到【註冊中心】上面，【註冊中心】會推送這個伺服器位址到【服務消費者】。這樣【服務消費者】就持有了所以的【微服務的map】我的負載平衡是在【服務消費者】這樣做的，說白了【服務消費者】是要常駐內存的，這樣對python或者java還好做點，但是對於走FPM的PHP相當於判了死刑，如何對PHP做改造，能讓讓傳統的FPM的PHP支持這種架構。 看起來Dubbo 也是類似這樣子做的，那麼前端如果用php做的話 是不是就有點蛋痛了呢？
回覆內容：
負載平衡有2種做法：
客戶端負載平衡，典型的是 Finagle 和 Dubbo。好處是實現出來簡單，服務直接直連效能好。壞處是多語言的時候需要為每種語言實作一個客戶端。
服務端的負載平衡，典型的負載平衡器是 Nginx 和 HAProxy 。通常是在服務前面加一個反向代理。客戶端透過反向代理和服務端通信，具體的負載平衡邏輯由負載平衡器實現。負載平衡器本身也可以註冊到註冊中心。好處是客戶端非常簡單，多語言也好支援。壞處嘛就是有點性能損失。
具體怎麼選要看業務，也要看公司的技術選型。多語言的場景下服務端的方案會省去很多維護成本，當然如果有一個 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(PHP: APCu - Manual
)或redis，把伺服器位址清單快取起來
看具體的效能要求和服務清單的一致性要求，一致性要求比較高，快取可以短點，擔心redis快取讀寫的網路開銷，可以使用APCu這種本地緩存
swoole啊
