框架層連接管理、心跳機制+優(yōu)雅退出來保證無異常流量

一、問題分析

plus平滑發(fā)布過程中出現(xiàn)的發(fā)布節(jié)點錯誤接收客戶端流量問題，一度被認定為mns下發(fā)服務(wù)狀態(tài)慢導(dǎo)致。因而得出一個粗放的結(jié)論：解決流量異常只能提升mns下發(fā)服務(wù)數(shù)據(jù)的速度，即保證客戶端感知服務(wù)狀態(tài)一致性。這其實是一個不嚴謹?shù)亩ㄕ?，下面重新定義問題。

A：mns下發(fā)狀態(tài)慢，客戶端感覺服務(wù)狀態(tài)變動不及時

B：服務(wù)端流量摘除異常，發(fā)布節(jié)點接收異常請求

應(yīng)該明確這是兩個不同的問題，它們不是綁定關(guān)系，因而不能同等看待。先給結(jié)論，出現(xiàn)mns下發(fā)狀態(tài)至客戶端慢問題時，也能夠避免服務(wù)節(jié)點錯誤接收流量現(xiàn)象。

A、B兩個問題的處理方案不應(yīng)混為一談的原因如下：

1.流量摘除本質(zhì)是連接管理問題，在通信框架層面進行處理更合理，第三節(jié)將進行分析

2.mns注冊中心是一個AP系統(tǒng)，難以兼顧客戶端狀態(tài)一致這樣的CP需求，2.1節(jié)詳述

3.服務(wù)狀態(tài)變更需要客戶端進行感知，優(yōu)化mns數(shù)據(jù)扇出(Fan-Out)性能后仍將存在一段數(shù)據(jù)分發(fā)真空期，難以杜絕流量異常case可能性，2.2節(jié)詳述

ok，我先說明提升mns數(shù)據(jù)下發(fā)速度，進而保證客戶端感知服務(wù)狀態(tài)一致性，所存在的挑戰(zhàn)性。

二、注冊中心定位

2.1 AP系統(tǒng)

CAP是分布式系統(tǒng)中一個重要的理論：分布系統(tǒng)的一致性(C)、可用性(A)以及分區(qū)容錯性(P)，三者不可兼得。設(shè)計分布式系統(tǒng)時，常常是在CP與AP之間針對業(yè)務(wù)場景進行權(quán)衡(trade-off)。

通過調(diào)研業(yè)界多個注冊中心后發(fā)現(xiàn)大家的結(jié)論一致：注冊中心是AP系統(tǒng)而非CP系統(tǒng)；也即注冊中心關(guān)注的重心是整體的高可用+性能，并且會犧牲部分一致性。諸如ConfigServer(阿里)、Eureka(Netflix)認為注冊中心使用Zookeeper這樣強一致性的組件，是錯誤的用法。業(yè)界對于注冊中心的定位是高可用、高融災(zāi)的AP系統(tǒng)，甚至容忍因客戶端感知服務(wù)狀態(tài)不一致，帶來的流量異常。

在此，不深入討論注冊中心使用ZK的否合理性；但是注冊中心是AP系統(tǒng)的結(jié)論得到廣泛認可，即保證高可用和性能，注冊中心本身會出現(xiàn)個別客戶端感知服務(wù)狀態(tài)不一致現(xiàn)象。

2.2 mns狀態(tài)分發(fā)

mns體系的狀態(tài)下發(fā)包括兩類網(wǎng)絡(luò)傳輸：notify，通知代理組件服務(wù)狀態(tài)發(fā)生變動；pull data，代理組件獲取變動后的服務(wù)信息。感知狀態(tài)信息的客戶端機器處于不同網(wǎng)絡(luò)環(huán)境，存在諸多不可控因素，直接影響mns狀態(tài)下發(fā)的時長。此外，mns狀態(tài)分發(fā)涉及zookeeper、mnsc、sg_agent、mns-invoker等多個組件交互、鏈路長，任何組件的抖動都會影響mns整體分發(fā)時間的穩(wěn)定性。一方面服務(wù)數(shù)據(jù)傳輸必然需要時間段，另一方面分發(fā)時間的整體穩(wěn)定性不可控，難以杜絕流量異常case可能性。

總結(jié)，結(jié)合注冊中心AP系統(tǒng)的定位，強制mns在一個穩(wěn)定+可預(yù)期的時間段內(nèi)，完成針對所有客戶端的服務(wù)數(shù)據(jù)分發(fā)具有很高的挑戰(zhàn)性，甚至限制mns本身的演進方向。

最后，流量異常是連接粒度的控制，從通信框架入手解決更容易。完全依賴注冊中心優(yōu)化來處理這個問題，會增加解決方案的復(fù)雜度，甚至影響整個mns的穩(wěn)定性，得不償失！

三、解決方案

正如第一節(jié)提及，mns狀態(tài)下發(fā)慢和流量異常輸出是兩個問題。mns本身的感知慢問題必須解決，但不是處理流量異常的根本方案。我們?nèi)绻軌蚱茐腂現(xiàn)象形成的必備條件，就能夠解決流量摘除異常問題。先看下流量異常復(fù)現(xiàn)必備的條件：

1.發(fā)送請求前，連接正常：服務(wù)端發(fā)布節(jié)點關(guān)閉進程后，因為有連接狀態(tài)檢測，新的請求不可能發(fā)送到已經(jīng)關(guān)閉的port。

2.數(shù)據(jù)返回時，連接關(guān)閉：服務(wù)接收到請求后，進程被關(guān)閉，處理后的response無法返回給用戶。

針對以上條件，接著說明plus平滑發(fā)布過程中流量異常問題的通信框架處理方案：

1.連接管理：通信框架完善連接狀態(tài)管理機制，保證服務(wù)端close socket后不再向服務(wù)端發(fā)送請求。

2.優(yōu)雅退出清理機制：框架層面開啟統(tǒng)一協(xié)議心跳，開始服務(wù)發(fā)布關(guān)閉進程前，通信框架關(guān)閉心跳包響應(yīng)機制；客戶端感知心跳檢測失敗，進而主動剔除即將下線的服務(wù)節(jié)點連接。2個心跳周期后進行實際的資源清理和進程關(guān)閉工作。這樣可以避免流量進入服務(wù)節(jié)點，卻無法返回調(diào)用端的問題。

3.調(diào)整心跳頻率，目前10s一次的心跳周期太長，適當(dāng)降低心跳探活周期，能夠配合以上方案避免流量異常問題出現(xiàn)。

總結(jié)來說：這個方案通過通信框架自身的心跳機制+優(yōu)雅退出，破壞了節(jié)點接收異常請求出現(xiàn)的必備條件，解決流量摘除問題。方案針對性強，可行性高。