作者介紹

張真，宜信技術研發中心高級架構師，負責基礎系統架構演進與優化、服務治理、監控平臺、微服務建設、DevOps平臺、自動化測試框架及電子簽約、短信、郵件等應用系統。早年就職于IBM中國研發中心，負責IBM WebSphere應用服務器的設計與開發。目前主要關注微服務架構實施，微智能設計思想應用，虛擬化技術應用，共識計算研究。

本文將包括以下內容：

1、經典微服務架構的特點及問題

2、微服務計算平臺的設計思想與抽象模型

3、打造微服務計算的基礎三件事

• 服務注冊與發現
• 服務情景感知與監控
• 服務調用的自適應機制

4、總結

一、經典微服務架構的特點以及問題

經典的微服務架構一般包含兩個部分：API網關，一組微服務。API網關是唯一的請求入口，它還要負責負載均衡，路由編排，失效切換等工作。

經典的微服務架構圖(來源網絡):

關于經典微服務架構的文章很多，這里重點想分享一些我們實踐經典微服務架構的一些問題：

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

整體看來，經典微服務架構還不夠“聰明和智能”，于是我們設計并著手研發新一代微服務計算平臺，希望能夠讓其充分發揮微服務架構的優勢和特性。

二、微服務計算平臺的設計思想與抽象模型

1、“微智能”的設計思想

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

先來看看微智能的設計思想：

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

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

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

所以微智能設計思想的三個核心原則正是構建“智”的微服務計算平臺的基礎指導思想。

2、“擬社會化”的分布式設計

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

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

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

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

“擬社會化”分布式設計抽象圖：

“擬社會化”分布式設計的特點：

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

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

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

這里舉兩個例子對“擬社會化”分布式設計的應用加以說明。

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

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

計算節點抽象模型

接下來，就是把微智能思想和擬社會化分布式設計統一起來，構建微服務計算平臺的計算節點抽象模型。它遵循以下原則：

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

計算節點抽象模型：

服務能力是一種計算能力，分為基礎服務能力和業務服務能力。

1. 基礎服務能力是構建計算平臺的前提，也提供了對計算平臺服務調用，監控，運維的支持。基礎服務能力實際上是整個計算平臺的基石，會在以后的分享專題中逐個展開說明。
2. 業務服務能力是根據實際業務需求實現的服務能力

按照以上原則，服務計算節點還提供了三類基礎支持：

• 服務能力的生命周期管理：

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

• 服務能力實現框架：為實現業務邏輯提供一套統一的編程和運行框架。

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

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

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

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

三、打造微服務計算的基礎三件事

微服務計算平臺實現服務治理首先要解決三個基礎：服務注冊與發現，服務監控，服務調用控制。

1、服務注冊與發現

1)服務注冊

經典的服務注冊方法有以下兩種：

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

但它也有如下問題：

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

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

服務注冊：常規模式

服務注冊：“心跳級聯代理”模式

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

服務注冊：多級服務注冊中心模式

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

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

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

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

1. 計算節點類型名(服務計算節點相關)：計算節點的類型由業務語義決定，比如MonitoAgent，SMSGateway，HealthManager等等
2. Http服務組件類型名(服務能力相關)：對外提供Http服務組件的簡寫類名，比如MDFListenServer，NodeOperHandleServer，DigitSignServer等等
3. Context路徑(服務接口相關)：相對Http服務根的路徑，比如/ma/put/mdf，/hm/cache/q，/rtntf/oper等等。

它們共同構成服務接口名，例如：

healthmanager-HealthMangerServerWorker-/hm/cache/q 
runtimenotify-RuntimeNotifyServerWorker-/rtntf/oper 
hbserveragent-HeartBeatServerListenWorker-/heartbeat 

2)服務發現

服務發現的本質是通過服務接口名查詢服務注冊中心，服務注冊中心基于某些策略返回服務接口可用地址列表，服務調用方也可以基于某些策略來使用地址列表。

微服務計算平臺的服務發現過程如下：

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

在心跳級聯代理模式下的服務發現與常規模式類似，這里不做詳述。

多級服務中心模式下的服務發現：

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

服務接口失效的快速反饋：

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

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

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

【編輯推薦】