微服務架構下，如何打造別具一格的服務治理體驗？(上)
一、經典微服務架構的特點以及問題
經典的微服務架構一般包含兩個部分：API閘道器，一組微服務。API閘道器是唯一的請求入口，它還要負責負載均衡，路由編排，失效切換等工作。
經典的微服務架構圖（來源網路）:
關於經典微服務架構的文章很多，這裡重點想分享一些我們實踐經典微服務架構的一些問題：
- “笨重”的API閘道器，由於它要負責各種核心功能，不能靈活擴充套件，比如負載均衡策略，也許每個微服務型別需求都不一樣，它很難靈活變更；隨著對接的微服務越來越多，每個API閘道器也整合大量的功能。
- API閘道器自身需要高可用保證，經典架構並不提供，隨著後端接的微服務越來越多，也會造成很多穩定性問題，它與微服務也需要兩套運維辦法，給運維帶來額外成本。
- 服務註冊與發現還是傳統模式，不能級聯代理，長連線也有限制，不能很好解決跨大網段，跨機房，跨IDC中心的問題。
- 心跳機制比較單一，只是從連線層面考慮，沒有上下文以及服務本身的監控，需要依賴第三方實現。
- 失效切換機制單一，只能是聯通性檢查，對業務異常無感知，意味著不能根據業務異常切換。
- 沒有自動高效的重試機制，需要考慮對API閘道器的改造。
- 幾乎沒有隔離機制，需要採用第三方技術解決。
- 微服務實現沒有統一的技術棧支援，還處於原則規定階段。
- 服務編排依靠人工，沒有動態編排能力。
整體看來，經典微服務架構還不夠“聰明和智慧”，於是我們設計並著手研發新一代微服務計算平臺，希望能夠讓其充分發揮微服務架構的優勢和特性。
二、微服務計算平臺的設計思想與抽象模型
“微智慧”這個概念起源於智慧家居，是目前智慧硬體領域的一股創新思想。在提到“智慧”這個詞，通常是相對人而言，智慧家居通過“智”的體現，更好的服務人的生活。於是，我們就思考是否系統或者服務也能體現“智”，如果與微服務相結合，讓其更加“聰明”的工作？
先來看看微智慧的設計思想：
1）自動發現：即真實的反映現實世界，儘可能利用“自動化”手段捕獲現實情況並提取有效”資訊”。微服務實際上對原有的單體系統或”重”服務進行了拆分，意味著服務種類以及服務例項個數會成倍增加，依靠人工整理或編排的手段變得笨重滯後。自動發現實現了微服務生命週期管理初始環節的自動化。
2）自我維護：即形成“閉環”反饋迴路，將“輸入”或“中間”或“結果”資訊再反饋到系統中，合併成新的“輸入”或“中間”或“結果”資訊。真實世界的資訊變化很快，為了儘量趨近真實，需要不停的迭代。微服務架構除了更多的服務例項個數（規模增長），也意味著更加“多變複雜”的服務更迭（變更頻率增長），自我維護實現了微服務生命週期管理更迭的自動化。
3）自動適應（適配）：自動適應拓展了自動發現+自我維護的思想外延，是“智”的體現。根據自動發現的資訊適配相應的處理（初次適應）；根據自我維護的反饋，不斷調整（迭代適應）。比如服務降級的閥值，其實不同時間不同資源使用情況下這個閥值是動態變化的，在數百服務例項的級別都已無法依靠人工來進行調整，而需要每個服務例項依據上下文的環境以及歷史狀態的分析自主的調節。
所以微智慧設計思想的三個核心原則正是構建“智”的微服務計算平臺的基礎指導思想。
有了微智慧的思想，我們還需要重新認識“服務”。什麼是微服務，社群裡有很多文章都分享了相關的內容。我們理解服務的“微”體現在：
- 細粒度的服務能力：某個服務例項只完成一種或某幾種業務，或說只具備某一種或幾種能力。
- 完全獨立的部署結構：每個服務例項都能獨立部署
- 服務能力可以編排：不同的服務例項之間需要協作才能完成“更大”的業務
- 更多同類型例項：業務種類決定了服務種類，而業務負載的大小決定了某種服務型別的例項數量，當然這可能也意味著更加穩定的服務輸出。
這裡引入一個很有意思的思考：社會是由人（個體）構成的相互協作的群體，每個人都可能具備幾種技能，並使用這些技能參與到社會分工協作中去。具備同種技能的人可以一起協作來提高生產效率和提供可靠性高的生產輸出；具備不同技能的人可以在某一件事情上進行分工協作，形成生產流水線。
其實可以發現微服務的特性跟人類社會的運作方式很像。服務例項就是個體，服務能力就是技能，允許服務例項具備幾種服務能力，具備相同服務能力的例項可以看做同類型的例項，多個同類型例項構成的叢集可以實現負載均衡和高可用，不同型別例項可以被編排在一起完成業務流程。我們把這種分散式設計稱為“擬社會化”。
“擬社會化”分散式設計抽象圖：
“擬社會化”分散式設計的特點：
- 服務計算節點與服務能力之間沒有必然聯絡，這是與傳統分散式設計的重要區別。服務計算節點是執行資源的載體，服務能力是業務邏輯的載體。
- 服務計算節點允許多個服務能力。
- 服務能力有兩種狀態：啟用（可以使用），非啟用（存在但不可用）。
- 服務能力是獨立的，可裝配的。
- 服務叢集實際是服務能力的叢集，這也是區別傳統單體架構叢集或SOA服務叢集的關鍵。
- 服務的協作過程實際是服務能力的協作過程，而不是服務計算節點的協作過程。
- 由於協作過程因為服務能力的可變性，使得可以動態定義服務能力叢集，即軟體定義服務叢集（SDSC）。
這裡可能有個疑問：為什麼允許某個服務計算節點有多個服務能力，這是不是一種“倒退”，不符合微服務的原則？其實主要有兩個方面的原因：
- 資源使用方面：在實際實施過程中，難以保證每個服務能力都能獨享服務計算節點，而且事實上如此實施會過於極端了。微服務的服務例項數量會比傳統架構的增長几倍甚至幾十倍，難以依靠單純增加資源投入的方式來滿足部署需求。
- 服務編排的需要：這是更重要的一點，服務輸出是體現在服務能力上（再次強調不是服務計算節點），這也是“微”的體現。由於服務能力可以啟用也可以“休眠”，那麼某個複合能力節點就具備了服務能力輸出的多樣可能性。比如某個服務計算節點可能在一段時間屬於某個服務能力叢集，在另一段時間屬於另外一個服務能力叢集，通過這種方式實現計算資源的最大化利用。
這裡舉兩個例子對“擬社會化”分散式設計的應用加以說明。
實踐例項一：簡訊系統是常見的高併發系統，在網際網路環境下可能因為各種營銷活動引起Peaktime，常規的做法是增加資源，但現實是資源池是有限的，而且多數時候Peaktime會波及整個營銷活動鏈條的系統，這些系統都需要增加資源，很快資源池就分光了。在“擬社會化”的分散式設計下，可以通過服務能力的快速切換，把一些業務休眠或在當前時間段體量小的服務能力的計算資源向Peaktime的服務能力集中，在Peaktime過去以後，又能快速的恢復原叢集。同時，可以發現另一個特性的體現：軟體定義叢集。這個特性會在以後的分享專題中專門說明。
實踐例項二：在P2P業務中，線下籤約通常是白天進行而晚上無業務，而簽約資料的統計工作是T+1的模式，是在晚上進行。傳統方式是部署兩個完全獨立的系統，而“擬社會化”的分散式系統通過複合能力節點，以服務能力切換的方式實現同一套計算資源的複用。
接下來，就是把微智慧思想和擬社會化分散式設計統一起來，構建微服務計算平臺的計算節點抽象模型。它遵循以下原則：
- 服務能力是實現業務邏輯的唯一方式，每種能力只包含一種業務邏輯
- 服務能力的實現方式遵守同一套技術實現框架，只有業務邏輯的差別，而執行機制，運維機制完全相同
- 每個計算節點是對等的，只有計算資源佔用的差別，而執行機制，運維機制等完全相同
- 計算節點的分工由服務能力決定，部署的計算節點至少包含一種服務能力
- 計算節點的實現遵守同一套技術實現框架，且這套實現框架提供執行服務能力的容器
- 計算節點叢集的構建方式是自動發現的，叢集元資料的維護是由計算節點叢集自我維護的
- 服務能力的發現方式是自動發現的，服務呼叫元資料的維護是由計算節點叢集自我維護的
- 服務呼叫過程應具備自適應能力，盡最大可能保證服務呼叫通暢，在面對風險時，能夠有一定的自主處理能力
- 允許服務能力的整合與編排，服務編排後的執行過程具備應對異常或風險的自適應性。
計算節點抽象模型：
服務能力是一種計算能力，分為基礎服務能力和業務服務能力。
- 基礎服務能力是構建計算平臺的前提，也提供了對計算平臺服務呼叫，監控，運維的支援。基礎服務能力實際上是整個計算平臺的基石，會在以後的分享專題中逐個展開說明。
- 業務服務能力是根據實際業務需求實現的服務能力
按照以上原則，服務計算節點還提供了三類基礎支援：
- 服務能力的生命週期管理：
值得注意的是，服務能力可以被裝配或解除安裝，這個過程分為Soft模式和Hard模式。Soft模式是通過配置的方式，服務能力的實現（例如jar包）還存在；Hard模式就是配置與實現一起裝配或解除安裝。實際應用中，Soft模式更加靈活，服務能力實現的變更可以交給節點升級來做。
- 服務能力實現框架：為實現業務邏輯提供一套統一的程式設計和執行框架。
- 元件化管理支援：服務能力在業務層面是原子，但在實現層面可以分解為元件，元件是具備特定邏輯又具備通用邏輯的程式碼。
- 常用的程式設計元件的支援：保持統一的，標準的技術棧，也加速服務能力的開發。一般包括：定時任務，HTTP服務端，HTTP客戶端，記憶體佇列非同步處理，多執行緒或並行程式設計支援。當然通訊層面是根據實際選型來定，我們以HTTP作為標準通訊。
- 計算節點自身管理：為了實際執行和運維需要而提供的支援。
- 元資料管理：比如每個計算節點需要一個唯一的ID來標識自己（就像人的身份證），通過它第一次執行來建立，且持久化起來以便再次執行時能夠保持ID不變；有些服務能力執行是會產生臨時檔案，這就需要計算節點提供一個“場所”（臨時目錄）供其施展。
- 節點自動升級/回滾：這個是所有分散式系統中最重要的特性之一，它能大大提升變更大規模節點的效率，在微服務架構下尤其適合。這個變更過程包含兩個方面：計算節點配置以及實現的變更，服務能力配置以及實現的變更。
- 節點的配置管理：負責提供實際的配置讀取/改寫介面，以及將自身和服務能力的執行時的配置持久化等。
當然計算節點自身管理包含工作有很多擴充套件，要根據實際需求定義。
三、打造微服務計算的基礎三件事
微服務計算平臺實現服務治理首先要解決三個基礎：服務註冊與發現，服務監控，服務呼叫控制。
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的方式對服務介面註冊資訊進行生命週期管理。我們定義生命狀態如下：
- 存活（Alive）：服務介面健康，可被查詢
- 可疑死亡（Dying）：由於網路延遲等原因的假死狀態，服務介面健康狀態存疑，可被查詢。有可能經過1~2個生命週期收到上行心跳，可恢復至Alive狀態
- 死亡（Dead）：超過了較大的TTL，基本認為服務介面死亡，其介面資訊被隔離不能查詢
- 消失（Disappear）：超過了一個鐵定死亡的TTL，認為服務介面可以抹去，最終會從服務中心訊息掉，其介面資訊被隔離不能查詢
另一個關鍵點是服務介面名的定義，它應該是全域性唯一的命名，因為在多個服務能力之間互相呼叫時是以服務介面名為目標的。在服務畫像時，會自動生成服務介面名，它提取以下三類資訊：
- 計算節點型別名（服務計算節點相關）：計算節點的型別由業務語義決定，比如MonitoAgent，SMSGateway，HealthManager等等
- Http服務元件型別名（服務能力相關）：對外提供Http服務元件的簡寫類名，比如MDFListenServer，NodeOperHandleServer，DigitSignServer等等
- Context路徑（服務介面相關）：相對Http服務根的路徑，比如/ma/put/mdf，/hm/cache/q，/rtntf/oper等等。
它們共同構成服務介面名，例如：
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類似的長連線（儘管時效性更好），主要有如下原因：
- 長連線對服務註冊中心的壓力大，長連線意味著要支援大量的連線，常規的PC伺服器能夠支援數千個長連線已經是極限了，在微服務架構下，如果例項個數在這個數量級尚可接受，但是如果是萬級例項，對硬體的配置要求太高，而且系統層面大量的長連線也存在管理問題。
- 長連線難以實現跨大網段，跨機房，甚至跨IDC中心，甚至由於某些IP安全策略（隔離）會變得不可用。
- 長連線的超時機制難以把控，太短會造成“中斷”假象，太長會造成”假存活”，而且受網路層影響很大。
- 長連線也無法支援級聯來實現擴充套件服務規模的能力。
文章出處：DBAplus社群（訂閱號ID：dbaplus）