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

01-07

本人用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應用的後端代理。

瀉藥

不太熟悉前端架構。不過從服務註冊的角度，倒是又一個想法。絕大多數的服務註冊其實沒有必要做成實時的，同步的，強依賴的。DNS是一個好的案例，值得研究。對於受限的可控環境，DNS的同步可以相當的快。可用從這個思路考慮考慮。

微服務中使用客戶端負載均衡我覺得是大趨勢，原因有三：一是性能有優勢，二是可靠性更高註冊中心down掉還是可以正常運行，三是客戶端本身就需要實現斷路器、服務降級之類的邏輯，多實現一個簡單的負載均衡邏輯也算是順路。PHP不太熟悉，是否可以考慮將服務配置寫入到某個service_config.php文件，其他文件來包含這個service_config.php？包含之前檢測一下文件的時間戳，如果超過某個時間（比如1分鐘）就再重新從註冊中心獲取配置寫入文件。

兩個方案

1、Swoole

Swoole: PHP的非同步、並行、高性能網路通信引擎

可以使用swoole寫一個常駐內測的php server

2、緩存

使用APCu(PHP: APCu - Manual)或者redis，把伺服器地址列表緩存起來

看具體的性能要求和服務列表的一致性要求，一致性要求比較高，緩存可以短點，擔心redis緩存讀寫的網路開銷，可以使用APCu這種本地緩存

ribbon負載策略：

RoundRobinRule", "輪訓(默認)"

BestAvailableRule", "選擇一個最小的並發請求的server"

AvailabilityFilteringRule", "過濾掉那些因為一直連接失敗的被標記為circuit tripped的後端server，並過濾掉那些高並發的server"

ZoneAvoidanceRule", "複合判斷server所在區域的性能和server的可用性選擇server"

RandomRule", "隨機選擇"

RetryRule", "對輪訓的負載均衡策略機上重試機制"

WeightedResponseTimeRule", "根據響應時間分配一個權重，響應時間越長，權重越小，被選中的可能性越低"