作者介紹

張真，宜信技術(shù)研發(fā)中心高級架構(gòu)師，負責基礎(chǔ)系統(tǒng)架構(gòu)演進與優(yōu)化、服務(wù)治理、監(jiān)控平臺、微服務(wù)建設(shè)、DevOps平臺、自動化測試框架及電子簽約、短信、郵件等應(yīng)用系統(tǒng)。早年就職于IBM中國研發(fā)中心，負責IBM WebSphere應(yīng)用服務(wù)器的設(shè)計與開發(fā)。目前主要關(guān)注微服務(wù)架構(gòu)實施，微智能設(shè)計思想應(yīng)用，虛擬化技術(shù)應(yīng)用，共識計算研究。

本文將包括以下內(nèi)容：

1、經(jīng)典微服務(wù)架構(gòu)的特點及問題

2、微服務(wù)計算平臺的設(shè)計思想與抽象模型

3、打造微服務(wù)計算的基礎(chǔ)三件事

• 服務(wù)注冊與發(fā)現(xiàn)
• 服務(wù)情景感知與監(jiān)控
• 服務(wù)調(diào)用的自適應(yīng)機制

4、總結(jié)

一、經(jīng)典微服務(wù)架構(gòu)的特點以及問題

經(jīng)典的微服務(wù)架構(gòu)一般包含兩個部分：API網(wǎng)關(guān)，一組微服務(wù)。API網(wǎng)關(guān)是唯一的請求入口，它還要負責負載均衡，路由編排，失效切換等工作。

經(jīng)典的微服務(wù)架構(gòu)圖(來源網(wǎng)絡(luò)):

關(guān)于經(jīng)典微服務(wù)架構(gòu)的文章很多，這里重點想分享一些我們實踐經(jīng)典微服務(wù)架構(gòu)的一些問題：

1. “笨重”的API網(wǎng)關(guān)，由于它要負責各種核心功能，不能靈活擴展，比如負載均衡策略，也許每個微服務(wù)類型需求都不一樣，它很難靈活變更;隨著對接的微服務(wù)越來越多，每個API網(wǎng)關(guān)也集成大量的功能。
2. API網(wǎng)關(guān)自身需要高可用保證，經(jīng)典架構(gòu)并不提供，隨著后端接的微服務(wù)越來越多，也會造成很多穩(wěn)定性問題，它與微服務(wù)也需要兩套運維辦法，給運維帶來額外成本。
3. 服務(wù)注冊與發(fā)現(xiàn)還是傳統(tǒng)模式，不能級聯(lián)代理，長連接也有限制，不能很好解決跨大網(wǎng)段，跨機房，跨IDC中心的問題。
4. 心跳機制比較單一，只是從連接層面考慮，沒有上下文以及服務(wù)本身的監(jiān)控，需要依賴第三方實現(xiàn)。
5. 失效切換機制單一，只能是聯(lián)通性檢查，對業(yè)務(wù)異常無感知，意味著不能根據(jù)業(yè)務(wù)異常切換。
6. 沒有自動高效的重試機制，需要考慮對API網(wǎng)關(guān)的改造。
7. 幾乎沒有隔離機制，需要采用第三方技術(shù)解決。
8. 微服務(wù)實現(xiàn)沒有統(tǒng)一的技術(shù)棧支持，還處于原則規(guī)定階段。
9. 服務(wù)編排依靠人工，沒有動態(tài)編排能力。

整體看來，經(jīng)典微服務(wù)架構(gòu)還不夠“聰明和智能”，于是我們設(shè)計并著手研發(fā)新一代微服務(wù)計算平臺，希望能夠讓其充分發(fā)揮微服務(wù)架構(gòu)的優(yōu)勢和特性。

二、微服務(wù)計算平臺的設(shè)計思想與抽象模型

1、“微智能”的設(shè)計思想

“微智能”這個概念起源于智能家居，是目前智能硬件領(lǐng)域的一股創(chuàng)新思想。在提到“智能”這個詞，通常是相對人而言，智能家居通過“智”的體現(xiàn)，更好的服務(wù)人的生活。于是，我們就思考是否系統(tǒng)或者服務(wù)也能體現(xiàn)“智”，如果與微服務(wù)相結(jié)合，讓其更加“聰明”的工作?

先來看看微智能的設(shè)計思想：

1)自動發(fā)現(xiàn)：即真實的反映現(xiàn)實世界，盡可能利用“自動化”手段捕獲現(xiàn)實情況并提取有效”信息”。微服務(wù)實際上對原有的單體系統(tǒng)或”重”服務(wù)進行了拆分，意味著服務(wù)種類以及服務(wù)實例個數(shù)會成倍增加，依靠人工整理或編排的手段變得笨重滯后。自動發(fā)現(xiàn)實現(xiàn)了微服務(wù)生命周期管理初始環(huán)節(jié)的自動化。

2)自我維護：即形成“閉環(huán)”反饋回路，將“輸入”或“中間”或“結(jié)果”信息再反饋到系統(tǒng)中，合并成新的“輸入”或“中間”或“結(jié)果”信息。真實世界的信息變化很快，為了盡量趨近真實，需要不停的迭代。微服務(wù)架構(gòu)除了更多的服務(wù)實例個數(shù)(規(guī)模增長)，也意味著更加“多變復雜”的服務(wù)更迭(變更頻率增長)，自我維護實現(xiàn)了微服務(wù)生命周期管理更迭的自動化。

3)自動適應(yīng)(適配)：自動適應(yīng)拓展了自動發(fā)現(xiàn)+自我維護的思想外延，是“智”的體現(xiàn)。根據(jù)自動發(fā)現(xiàn)的信息適配相應(yīng)的處理(初次適應(yīng));根據(jù)自我維護的反饋，不斷調(diào)整(迭代適應(yīng))。比如服務(wù)降級的閥值，其實不同時間不同資源使用情況下這個閥值是動態(tài)變化的，在數(shù)百服務(wù)實例的級別都已無法依靠人工來進行調(diào)整，而需要每個服務(wù)實例依據(jù)上下文的環(huán)境以及歷史狀態(tài)的分析自主的調(diào)節(jié)。

所以微智能設(shè)計思想的三個核心原則正是構(gòu)建“智”的微服務(wù)計算平臺的基礎(chǔ)指導思想。

2、“擬社會化”的分布式設(shè)計

有了微智能的思想，我們還需要重新認識“服務(wù)”。什么是微服務(wù)，社群里有很多文章都分享了相關(guān)的內(nèi)容。我們理解服務(wù)的“微”體現(xiàn)在：

• 細粒度的服務(wù)能力：某個服務(wù)實例只完成一種或某幾種業(yè)務(wù)，或說只具備某一種或幾種能力。
• 完全獨立的部署結(jié)構(gòu)：每個服務(wù)實例都能獨立部署
• 服務(wù)能力可以編排：不同的服務(wù)實例之間需要協(xié)作才能完成“更大”的業(yè)務(wù)
• 更多同類型實例：業(yè)務(wù)種類決定了服務(wù)種類，而業(yè)務(wù)負載的大小決定了某種服務(wù)類型的實例數(shù)量，當然這可能也意味著更加穩(wěn)定的服務(wù)輸出。

這里引入一個很有意思的思考：社會是由人(個體)構(gòu)成的相互協(xié)作的群體，每個人都可能具備幾種技能，并使用這些技能參與到社會分工協(xié)作中去。具備同種技能的人可以一起協(xié)作來提高生產(chǎn)效率和提供可靠性高的生產(chǎn)輸出;具備不同技能的人可以在某一件事情上進行分工協(xié)作，形成生產(chǎn)流水線。

其實可以發(fā)現(xiàn)微服務(wù)的特性跟人類社會的運作方式很像。服務(wù)實例就是個體，服務(wù)能力就是技能，允許服務(wù)實例具備幾種服務(wù)能力，具備相同服務(wù)能力的實例可以看做同類型的實例，多個同類型實例構(gòu)成的集群可以實現(xiàn)負載均衡和高可用，不同類型實例可以被編排在一起完成業(yè)務(wù)流程。我們把這種分布式設(shè)計稱為“擬社會化”。

“擬社會化”分布式設(shè)計抽象圖：

“擬社會化”分布式設(shè)計的特點：

1. 服務(wù)計算節(jié)點與服務(wù)能力之間沒有必然聯(lián)系，這是與傳統(tǒng)分布式設(shè)計的重要區(qū)別。服務(wù)計算節(jié)點是運行資源的載體，服務(wù)能力是業(yè)務(wù)邏輯的載體。
2. 服務(wù)計算節(jié)點允許多個服務(wù)能力。
3. 服務(wù)能力有兩種狀態(tài)：激活(可以使用)，非激活(存在但不可用)。
4. 服務(wù)能力是獨立的，可裝配的。
5. 服務(wù)集群實際是服務(wù)能力的集群，這也是區(qū)別傳統(tǒng)單體架構(gòu)集群或SOA服務(wù)集群的關(guān)鍵。
6. 服務(wù)的協(xié)作過程實際是服務(wù)能力的協(xié)作過程，而不是服務(wù)計算節(jié)點的協(xié)作過程。
7. 由于協(xié)作過程因為服務(wù)能力的可變性，使得可以動態(tài)定義服務(wù)能力集群，即軟件定義服務(wù)集群(SDSC)。

這里可能有個疑問：為什么允許某個服務(wù)計算節(jié)點有多個服務(wù)能力，這是不是一種“倒退”，不符合微服務(wù)的原則?其實主要有兩個方面的原因：

• 資源使用方面：在實際實施過程中，難以保證每個服務(wù)能力都能獨享服務(wù)計算節(jié)點，而且事實上如此實施會過于極端了。微服務(wù)的服務(wù)實例數(shù)量會比傳統(tǒng)架構(gòu)的增長幾倍甚至幾十倍，難以依靠單純增加資源投入的方式來滿足部署需求。
• 服務(wù)編排的需要：這是更重要的一點，服務(wù)輸出是體現(xiàn)在服務(wù)能力上(再次強調(diào)不是服務(wù)計算節(jié)點)，這也是“微”的體現(xiàn)。由于服務(wù)能力可以激活也可以“休眠”，那么某個復合能力節(jié)點就具備了服務(wù)能力輸出的多樣可能性。比如某個服務(wù)計算節(jié)點可能在一段時間屬于某個服務(wù)能力集群，在另一段時間屬于另外一個服務(wù)能力集群，通過這種方式實現(xiàn)計算資源的最大化利用。

這里舉兩個例子對“擬社會化”分布式設(shè)計的應(yīng)用加以說明。

實踐實例一：短信系統(tǒng)是常見的高并發(fā)系統(tǒng)，在互聯(lián)網(wǎng)環(huán)境下可能因為各種營銷活動引起Peaktime，常規(guī)的做法是增加資源，但現(xiàn)實是資源池是有限的，而且多數(shù)時候Peaktime會波及整個營銷活動鏈條的系統(tǒng)，這些系統(tǒng)都需要增加資源，很快資源池就分光了。在“擬社會化”的分布式設(shè)計下，可以通過服務(wù)能力的快速切換，把一些業(yè)務(wù)休眠或在當前時間段體量小的服務(wù)能力的計算資源向Peaktime的服務(wù)能力集中，在Peaktime過去以后，又能快速的恢復原集群。同時，可以發(fā)現(xiàn)另一個特性的體現(xiàn)：軟件定義集群。這個特性會在以后的分享專題中專門說明。

實踐實例二：在P2P業(yè)務(wù)中，線下簽約通常是白天進行而晚上無業(yè)務(wù)，而簽約數(shù)據(jù)的統(tǒng)計工作是T+1的模式，是在晚上進行。傳統(tǒng)方式是部署兩個完全獨立的系統(tǒng)，而“擬社會化”的分布式系統(tǒng)通過復合能力節(jié)點，以服務(wù)能力切換的方式實現(xiàn)同一套計算資源的復用。

計算節(jié)點抽象模型

接下來，就是把微智能思想和擬社會化分布式設(shè)計統(tǒng)一起來，構(gòu)建微服務(wù)計算平臺的計算節(jié)點抽象模型。它遵循以下原則：

• 服務(wù)能力是實現(xiàn)業(yè)務(wù)邏輯的唯一方式，每種能力只包含一種業(yè)務(wù)邏輯
• 服務(wù)能力的實現(xiàn)方式遵守同一套技術(shù)實現(xiàn)框架，只有業(yè)務(wù)邏輯的差別，而運行機制，運維機制完全相同
• 每個計算節(jié)點是對等的，只有計算資源占用的差別，而運行機制，運維機制等完全相同
• 計算節(jié)點的分工由服務(wù)能力決定，部署的計算節(jié)點至少包含一種服務(wù)能力
• 計算節(jié)點的實現(xiàn)遵守同一套技術(shù)實現(xiàn)框架，且這套實現(xiàn)框架提供運行服務(wù)能力的容器
• 計算節(jié)點集群的構(gòu)建方式是自動發(fā)現(xiàn)的，集群元數(shù)據(jù)的維護是由計算節(jié)點集群自我維護的
• 服務(wù)能力的發(fā)現(xiàn)方式是自動發(fā)現(xiàn)的，服務(wù)調(diào)用元數(shù)據(jù)的維護是由計算節(jié)點集群自我維護的
• 服務(wù)調(diào)用過程應(yīng)具備自適應(yīng)能力，盡最大可能保證服務(wù)調(diào)用通暢，在面對風險時，能夠有一定的自主處理能力
• 允許服務(wù)能力的集成與編排，服務(wù)編排后的運行過程具備應(yīng)對異常或風險的自適應(yīng)性。

計算節(jié)點抽象模型：

服務(wù)能力是一種計算能力，分為基礎(chǔ)服務(wù)能力和業(yè)務(wù)服務(wù)能力。

1. 基礎(chǔ)服務(wù)能力是構(gòu)建計算平臺的前提，也提供了對計算平臺服務(wù)調(diào)用，監(jiān)控，運維的支持。基礎(chǔ)服務(wù)能力實際上是整個計算平臺的基石，會在以后的分享專題中逐個展開說明。
2. 業(yè)務(wù)服務(wù)能力是根據(jù)實際業(yè)務(wù)需求實現(xiàn)的服務(wù)能力

按照以上原則，服務(wù)計算節(jié)點還提供了三類基礎(chǔ)支持：

• 服務(wù)能力的生命周期管理：

值得注意的是，服務(wù)能力可以被裝配或卸載，這個過程分為Soft模式和Hard模式。Soft模式是通過配置的方式，服務(wù)能力的實現(xiàn)(例如jar包)還存在;Hard模式就是配置與實現(xiàn)一起裝配或卸載。實際應(yīng)用中，Soft模式更加靈活，服務(wù)能力實現(xiàn)的變更可以交給節(jié)點升級來做。

• 服務(wù)能力實現(xiàn)框架：為實現(xiàn)業(yè)務(wù)邏輯提供一套統(tǒng)一的編程和運行框架。

1. 組件化管理支持：服務(wù)能力在業(yè)務(wù)層面是原子，但在實現(xiàn)層面可以分解為組件，組件是具備特定邏輯又具備通用邏輯的代碼。
2. 常用的編程組件的支持：保持統(tǒng)一的，標準的技術(shù)棧，也加速服務(wù)能力的開發(fā)。一般包括：定時任務(wù)，HTTP服務(wù)端，HTTP客戶端，內(nèi)存隊列異步處理，多線程或并行編程支持。當然通訊層面是根據(jù)實際選型來定，我們以HTTP作為標準通信。

• 計算節(jié)點自身管理：為了實際運行和運維需要而提供的支持。

1. 元數(shù)據(jù)管理：比如每個計算節(jié)點需要一個唯一的ID來標識自己(就像人的身份證)，通過它第一次運行來創(chuàng)建，且持久化起來以便再次運行時能夠保持ID不變;有些服務(wù)能力運行是會產(chǎn)生臨時文件，這就需要計算節(jié)點提供一個“場所”(臨時目錄)供其施展。
2. 節(jié)點自動升級/回滾：這個是所有分布式系統(tǒng)中最重要的特性之一，它能大大提升變更大規(guī)模節(jié)點的效率，在微服務(wù)架構(gòu)下尤其適合。這個變更過程包含兩個方面：計算節(jié)點配置以及實現(xiàn)的變更，服務(wù)能力配置以及實現(xiàn)的變更。
3. 節(jié)點的配置管理：負責提供實際的配置讀取/改寫接口，以及將自身和服務(wù)能力的運行時的配置持久化等。

當然計算節(jié)點自身管理包含工作有很多擴展，要根據(jù)實際需求定義。

三、打造微服務(wù)計算的基礎(chǔ)三件事

微服務(wù)計算平臺實現(xiàn)服務(wù)治理首先要解決三個基礎(chǔ)：服務(wù)注冊與發(fā)現(xiàn)，服務(wù)監(jiān)控，服務(wù)調(diào)用控制。

1、服務(wù)注冊與發(fā)現(xiàn)

1)服務(wù)注冊

經(jīng)典的服務(wù)注冊方法有以下兩種：

• 顯式配置：人工將服務(wù)的接口信息(服務(wù)名，服務(wù)URI等)配置到服務(wù)注冊中心。WebService UDDI就是這種模式。它的問題是需要人工收集服務(wù)接口信息，這個過程可能產(chǎn)生滯后或者錯誤的信息，運維代價大。
• 代碼實現(xiàn)：調(diào)用服務(wù)注冊中心客戶端發(fā)送服務(wù)的接口信息到服務(wù)注冊中心。典型用例是基于Zookeeper服務(wù)注冊。它的優(yōu)勢是服務(wù)接口的URI可能是通過代碼收集出來的，較人工收集更加自動化。

但它也有如下問題：

• 需要編寫專門的代碼埋點，與服務(wù)注冊中心客戶端的緊耦合：如果使用Zookeeper，需要依賴它的jar包。
• 服務(wù)注冊代碼與服務(wù)接口代碼上下文緊耦合：必須在特定位置去使用服務(wù)注冊的代碼，而且可能還會包含特定服務(wù)的信息，這些信息可能是人工編排進去的。
• 由于不同系統(tǒng)是由不同團隊開發(fā)的，需要行政制度，“TopDown”規(guī)定服務(wù)注冊的編程，一旦有“不按套路出牌”的情況就會出現(xiàn)各種運維問題。
• 基于前文的計算節(jié)點模型，我們的微服務(wù)注冊過程如下：
• 以HTTP方式對外暴露功能的服務(wù)能力(如圖Http服務(wù)能力A)基于計算節(jié)點提供的Http服務(wù)框架實現(xiàn)。統(tǒng)一技術(shù)棧的目的之一，也是為服務(wù)注冊做準備。
• 在Http服務(wù)能力A裝配時，基礎(chǔ)服務(wù)能力“服務(wù)能力畫像”會對其進行畫像。畫像的過程實際是對編程模型的解析過程。提取的信息包括IP，Context路徑，服務(wù)接口的URL，服務(wù)接口對應(yīng)的實現(xiàn)方法，方法輸入?yún)?shù)的Pattern等等。這個過程就實現(xiàn)了服務(wù)的自動發(fā)現(xiàn)。
• 服務(wù)能力畫像完成畫像后會將畫像數(shù)據(jù)轉(zhuǎn)交給基礎(chǔ)服務(wù)能力“心跳客戶端”。
• 心跳客戶端通過心跳上行將服務(wù)接口數(shù)據(jù)發(fā)送到服務(wù)注冊中心。

我們的服務(wù)注冊過程是以心跳系統(tǒng)為基礎(chǔ)的，服務(wù)注冊是心跳事務(wù)中的一種。實際上服務(wù)注冊中心是基礎(chǔ)服務(wù)能力“心跳服務(wù)端”的功能，而它的載體是另一個計算節(jié)點(如圖服務(wù)計算節(jié)點B)，這也是計算節(jié)點的對等性體現(xiàn)，因為任何一個具備心跳服務(wù)端能力的計算節(jié)點都可以作為服務(wù)注冊中心。

服務(wù)注冊：常規(guī)模式

服務(wù)注冊：“心跳級聯(lián)代理”模式

在大規(guī)模部署服務(wù)計算節(jié)點時，往往還會遇到跨大網(wǎng)段，跨機房，跨IDC中心，白名單IP策略等問題。所以心跳系統(tǒng)還支持“心跳級聯(lián)代理”模式，其作用是允許建立多級的心跳群，每個群由若干“代理”心跳服務(wù)端組成，它們只負責轉(zhuǎn)發(fā)心跳信息，所以服務(wù)注冊信息也依靠這個過程進行轉(zhuǎn)發(fā)到服務(wù)注冊中心。

服務(wù)注冊：多級服務(wù)注冊中心模式

在某些特殊業(yè)務(wù)場景下，對服務(wù)注冊信息更新延遲容忍度較低，這時，讓心跳級聯(lián)的計算節(jié)點也作為服務(wù)注冊中心。如下圖，節(jié)點B是1級服務(wù)注冊中心(以下簡稱1級中心)，節(jié)點C是2級服務(wù)注冊中心(以下簡稱2級中心)。1級中心會存儲向自己提交的服務(wù)注冊信息，也會把這些信息轉(zhuǎn)發(fā)到上級服務(wù)注冊中心。2級中心上可見所有下級中心的服務(wù)注冊信息。這種模式可以獲得更快的服務(wù)發(fā)現(xiàn)，因為同級的節(jié)點發(fā)現(xiàn)其他節(jié)點服務(wù)能力只需經(jīng)過本級服務(wù)注冊中心即可，下文會結(jié)合服務(wù)發(fā)現(xiàn)做詳細解釋。

服務(wù)注冊中心依靠TTL的方式對服務(wù)接口注冊信息進行生命周期管理。我們定義生命狀態(tài)如下：

1. 存活(Alive)：服務(wù)接口健康，可被查詢
2. 可疑死亡(Dying)：由于網(wǎng)絡(luò)延遲等原因的假死狀態(tài)，服務(wù)接口健康狀態(tài)存疑，可被查詢。有可能經(jīng)過1~2個生命周期收到上行心跳，可恢復至Alive狀態(tài)
3. 死亡(Dead)：超過了較大的TTL，基本認為服務(wù)接口死亡，其接口信息被隔離不能查詢
4. 消失(Disappear)：超過了一個鐵定死亡的TTL，認為服務(wù)接口可以抹去，最終會從服務(wù)中心消息掉，其接口信息被隔離不能查詢

另一個關(guān)鍵點是服務(wù)接口名的定義，它應(yīng)該是全局唯一的命名，因為在多個服務(wù)能力之間互相調(diào)用時是以服務(wù)接口名為目標的。在服務(wù)畫像時，會自動生成服務(wù)接口名，它提取以下三類信息：

1. 計算節(jié)點類型名(服務(wù)計算節(jié)點相關(guān))：計算節(jié)點的類型由業(yè)務(wù)語義決定，比如MonitoAgent，SMSGateway，HealthManager等等
2. Http服務(wù)組件類型名(服務(wù)能力相關(guān))：對外提供Http服務(wù)組件的簡寫類名，比如MDFListenServer，NodeOperHandleServer，DigitSignServer等等
3. Context路徑(服務(wù)接口相關(guān))：相對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ì)是通過服務(wù)接口名查詢服務(wù)注冊中心，服務(wù)注冊中心基于某些策略返回服務(wù)接口可用地址列表，服務(wù)調(diào)用方也可以基于某些策略來使用地址列表。

微服務(wù)計算平臺的服務(wù)發(fā)現(xiàn)過程如下：

• 業(yè)務(wù)服務(wù)能力X以服務(wù)接口名為參數(shù)，調(diào)用組件API(每個服務(wù)能力組件都具備)。
• 組件API內(nèi)部是調(diào)用心跳客戶端向服務(wù)注冊中心查詢該服務(wù)接口。值得注意的是，除了第一次獲取某服務(wù)接口信息外，出于性能考慮，這個過程是獨立的，心跳客戶端可以通過下行心跳不停更新已經(jīng)用過的服務(wù)接口信息，通過TTL機制自動過期哪些長時間不使用的服務(wù)接口信息。
• 服務(wù)注冊中心根據(jù)某種策略(授權(quán)訪問策略，隔離策略等等)返回地址列表
• 業(yè)務(wù)服務(wù)能力X獲取服務(wù)接口地址列表后，可按照某種輪詢策略(Round Robin，權(quán)重等)使用。

在心跳級聯(lián)代理模式下的服務(wù)發(fā)現(xiàn)與常規(guī)模式類似，這里不做詳述。

多級服務(wù)中心模式下的服務(wù)發(fā)現(xiàn)：

上文提到在多級服務(wù)注冊中心模式下，可以獲得更快的服務(wù)發(fā)現(xiàn)。從心跳客戶端的角度來看，其實沒有差別，但是如果是查詢同級的服務(wù)接口，在1級中心立刻查到，無須去2級中心;對于查詢跨級的服務(wù)接口，則需要從2級中心獲取，并會在1級中心緩存，從而加快跨級查詢。有一點注意，1級中心的緩存也是TTL的，并且生存周期要短于2級中心，這是性能和時效性的互相適應(yīng)的結(jié)果。因為從1級查緩存雖然快，但是1級中心無法判斷跨級服務(wù)的存活，所以長時間的緩存可能是錯誤的信息，縮短TTL時長是為了更快更新跨級服務(wù)的地址信息。

服務(wù)接口失效的快速反饋：

當業(yè)務(wù)服務(wù)能力X調(diào)用Http服務(wù)能力A遇到異常時，服務(wù)能力實現(xiàn)框架會自動捕獲異常信息，并將系統(tǒng)性異常(Timeout，SocketException等等)以及某些業(yè)務(wù)異常(基于策略)提交到服務(wù)注冊中心，這個過程不必等到心跳周期到達而是立即觸發(fā)的，從而服務(wù)注冊中心可以實現(xiàn)對這些服務(wù)接口的快速隔離。而其他打算調(diào)用該服務(wù)接口的其他服務(wù)能力，通過心跳下行獲得地址列表更新。這樣的方式可以彌補TTL機制可能的延遲。

另外說明一下為什么沒有使用Zookeeper類似的長連接(盡管時效性更好)，主要有如下原因：

1. 長連接對服務(wù)注冊中心的壓力大，長連接意味著要支持大量的連接，常規(guī)的PC服務(wù)器能夠支持數(shù)千個長連接已經(jīng)是極限了，在微服務(wù)架構(gòu)下，如果實例個數(shù)在這個數(shù)量級尚可接受，但是如果是萬級實例，對硬件的配置要求太高，而且系統(tǒng)層面大量的長連接也存在管理問題。
2. 長連接難以實現(xiàn)跨大網(wǎng)段，跨機房，甚至跨IDC中心，甚至由于某些IP安全策略(隔離)會變得不可用。
3. 長連接的超時機制難以把控，太短會造成“中斷”假象，太長會造成”假存活”，而且受網(wǎng)絡(luò)層影響很大。
4. 長連接也無法支持級聯(lián)來實現(xiàn)擴展服務(wù)規(guī)模的能力。