Context路徑(服務(wù)接口相關(guān))： 相對(duì)Http服務(wù)根的路徑，比如/ma/put/mdf，/hm/cache/q，/rtntf/oper等等。
它們共同構(gòu)成服務(wù)接口名，例如：
healthmanager-HealthMangerServerWorker-/hm/cache/q
runtimenotify-RuntimeNotifyServerWorker-/rtntf/oper
hbserveragent-HeartBeatServerListenWorker-/heartbeat
2 )服務(wù)發(fā)現(xiàn)
服務(wù)發(fā)現(xiàn)的本質(zhì)是通過(guò)服務(wù)接口名查詢服務(wù)注冊(cè)中心，服務(wù)注冊(cè)中心基于某些策略返回服務(wù)接口可用地址列表，服務(wù)調(diào)用方也可以基于某些策略來(lái)使用地址列表。
微服務(wù)計(jì)算平臺(tái)的服務(wù)發(fā)現(xiàn)過(guò)程如下：
業(yè)務(wù)服務(wù)能力X以服務(wù)接口名為參數(shù)，調(diào)用組件API(每個(gè)服務(wù)能力組件都具備)。
組件API內(nèi)部是調(diào)用心跳客戶端向服務(wù)注冊(cè)中心查詢?cè)摲?wù)接口。值得注意的是，除了第一次獲取某服務(wù)接口信息外，出于性能考慮，這個(gè)過(guò)程是獨(dú)立的，心跳客戶端可以通過(guò)下行心跳不停更新已經(jīng)用過(guò)的服務(wù)接口信息，通過(guò)TTL機(jī)制自動(dòng)過(guò)期哪些長(zhǎng)時(shí)間不使用的服務(wù)接口信息。
服務(wù)注冊(cè)中心根據(jù)某種策略(授權(quán)訪問(wèn)策略，隔離策略等等)返回地址列表
業(yè)務(wù)服務(wù)能力X獲取服務(wù)接口地址列表后，可按照某種輪詢策略(Round Robin，權(quán)重等)使用。
在心跳級(jí)聯(lián)代理模式下的服務(wù)發(fā)現(xiàn)與常規(guī)模式類似，這里不做詳述。
多級(jí)服務(wù)中心模式下的服務(wù)發(fā)現(xiàn)：
上文提到在多級(jí)服務(wù)注冊(cè)中心模式下，可以獲得更快的服務(wù)發(fā)現(xiàn)。從心跳客戶端的角度來(lái)看，其實(shí)沒(méi)有差別，但是如果是查詢同級(jí)的服務(wù)接口，在1級(jí)中心立刻查到，無(wú)須去2級(jí)中心;對(duì)于查詢跨級(jí)的服務(wù)接口，則需要從2級(jí)中心獲取，并會(huì)在1級(jí)中心緩存，從而加快跨級(jí)查詢。有一點(diǎn)注意，1級(jí)中心的緩存也是TTL的，并且生存周期要短于2級(jí)中心，這是性能和時(shí)效性的互相適應(yīng)的結(jié)果。因?yàn)閺?級(jí)查緩存雖然快，但是1級(jí)中心無(wú)法判斷跨級(jí)服務(wù)的存活，所以長(zhǎng)時(shí)間的緩存可能是錯(cuò)誤的信息，縮短TTL時(shí)長(zhǎng)是為了更快更新跨級(jí)服務(wù)的地址信息。
服務(wù)接口失效的快速反饋：
當(dāng)業(yè)務(wù)服務(wù)能力X調(diào)用Http服務(wù)能力A遇到異常時(shí)，服務(wù)能力實(shí)現(xiàn)框架會(huì)自動(dòng)捕獲異常信息，并將系統(tǒng)性異常(Timeout，SocketException等等)以及某些業(yè)務(wù)異常(基于策略)提交到服務(wù)注冊(cè)中心， 這個(gè)過(guò)程不必等到心跳周期到達(dá)而是立即觸發(fā)的，從而服務(wù)注冊(cè)中心可以實(shí)現(xiàn)對(duì)這些服務(wù)接口的快速隔離。而其他打算調(diào)用該服務(wù)接口的其他服務(wù)能力，通過(guò)心跳下行獲得地址列表更新。這樣的方式可以彌補(bǔ)TTL機(jī)制可能的延遲。
另外說(shuō)明一下為什么沒(méi)有使用Zookeeper類似的長(zhǎng)連接(盡管時(shí)效性更好)，主要有如下原因：
長(zhǎng)連接對(duì)服務(wù)注冊(cè)中心的壓力大，長(zhǎng)連接意味著要支持大量的連接，常規(guī)的PC服務(wù)器能夠支持?jǐn)?shù)千個(gè)長(zhǎng)連接已經(jīng)是極限了，在微服務(wù)架構(gòu)下，如果實(shí)例個(gè)數(shù)在這個(gè)數(shù)量級(jí)尚可接受，但是如果是萬(wàn)級(jí)實(shí)例，對(duì)硬件的配置要求太高，而且系統(tǒng)層面大量的長(zhǎng)連接也存在管理問(wèn)題。
長(zhǎng)連接難以實(shí)現(xiàn)跨大網(wǎng)段，跨機(jī)房，甚至跨IDC中心，甚至由于某些IP安全策略(隔離)會(huì)變得不可用。
長(zhǎng)連接的超時(shí)機(jī)制難以把控，太短會(huì)造成“中斷”假象，太長(zhǎng)會(huì)造成”假存活”，而且受網(wǎng)絡(luò)層影響很大。
長(zhǎng)連接也無(wú)法支持級(jí)聯(lián)來(lái)實(shí)現(xiàn)擴(kuò)展服務(wù)規(guī)模的能力。