高可用場景下，一般服務都是以集群模式對外提供服務，集群裡的ip隨時變化，呼叫方這個時候就需要乙個服務方的服務節點的列表了。
服務發現分為兩個步驟：
dns首先看下dns的查詢流程，如下：
通過dns拿到乙個服務者提供的ip，建立長鏈結，存在什麼問題呢？
造成上面問題的原因在於dns的多級快取機制。
改進版：加乙個負載均衡裝置
不太合適的原因如下：
zookeeper
搭建乙個zookeeper集群作為註冊中心集群，服務註冊的時候只需要服務節點向zookeeper節點寫入註冊資訊即可，利用zookeeper的watch機制完成服務訂閱與服務下發功能。
存在問題：
當連線到 zookeeper 的節點數量特別多，對 zookeeper 讀寫特別頻繁，且 zookeeper 儲存的目 錄達到一定數量的時候，zookeeper 將不再穩定，cpu 持續公升高，最終會產生宕機。
訊息匯流排的最終一致性註冊中心
註冊資料可以全量快取在每個註冊
中心記憶體中，通過訊息匯流排來同步資料。當有乙個註冊中心節點接收到服務節點註冊時，會
產生乙個訊息推送給訊息匯流排，再通過訊息匯流排通知給其它註冊中心節點更新資料並進行服
務下發，從而達到註冊中心間資料最終一致性
為了效能，這裡採用了兩級快取，註冊中心和消費者的記憶體快取，通過非同步推拉模式來確保
最終一致性。
目標節點存在已經下 線或不提供指定介面服務的情況，我們放到了 rpc 框架裡 面去處理，在服務呼叫方傳送請求到目標節點後，目標節點會進行合法性驗證，如果指定接 口服務不存在或正在下線，則會拒絕該請求。服務呼叫方收到拒絕異常後，會安全重試到其 它節點。
通過可以犧牲掉 cp(強制一致性)，而選擇 ap(最終一致)
RPC服務註冊與發現
rpc遠端過程呼叫中，存在2個角色，乙個服務提供者 另乙個服務消費者。那如何讓呼叫者知道，存在哪些服務可以呼叫呢？即如何讓別人使用我們的服務呢？有同學說很簡單嘛，告訴使用者服務的ip以及埠就可以了啊。確實是這樣，這裡問題的關鍵在於是自動告知還是人肉告知。人肉告知的方式 如果你發現你的服務一台機器不夠...
關於Python那些事兒
1.易於學習 python有相對較少的關鍵字，結構簡單，和乙個明確定義的語法，學習起來更加簡單。2.易於閱讀 python 定義的更清晰。3.易於維護 python的成功在於它的源 是相當容易維護的。4.乙個廣泛的標準庫 python的最大的優勢之一是豐富的庫，跨平台的，在unix，windows和...
關於Nginx那些事兒
記憶體少 併發能力強，效能優化 正向 在瀏覽器中配置 伺服器，實現客戶端對伺服器的訪問。也就是說，在一般情況下，我們客戶端無法直接訪問到伺服器，需要有那麼乙個中臺作為中間應用實現訪問。反向 反向 中，客戶端是無知的，不知道是否配置了伺服器，我們將資料發到反向 伺服器上去，反向 伺服器選擇目標伺服器獲...